This makes the implementation less likely to provide useful timing
information to potential attackers from comparisons of information
received from a remote device and private material known only by the
authorized devices.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is not much point in building devices with WPS 1.0 only supported
nowadays. As such, there is not sufficient justification for maintaining
extra complexity for the CONFIG_WPS2 build option either. Remove this by
enabling WSC 2.0 support unconditionally.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
When wpa_psk_file is used instead of wpa_psk/wpa_passphrase, each WPS
Enrollee was given a unique PSK. This did not work for the
station-as-Registrar case where ER would learn the current AP settings
instead of enrolling itself (i.e., when using the AP PIN instead of
station PIN). That case can be covered with a similar design, so
generate a per-device PSK when building M7 as an AP in wpa_psk_file
configuration.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, unconfigured state was forcing the best supported
authentication and encryption state to be shown in WPS messages,
including AP Settings in M7 in case the AP acts as an Enrollee. This is
not really correct for the AP Settings case, so change that one to
indicate the currently configured state.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This was already done for Registrar, but the Enrollee case did not
set config error properly if Registrar public key did not match the
hash received during NFC connection handover.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
When both the Registrar and Enrollee public key hashes are delivered
out-of-band (in NFC connection handover), use abbreviated WPS handshake
(skip M3-M8).
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Since the Enrollee can now get the public key hash from the Registrar,
there is need to validate this during the WPS protocol run.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Some APs may incorrectly change Device Password ID from PBC in M1 to
Default PIN in M2 even when they are ready to continue with PBC. This
behavior used to work with earlier implementation in wpa_supplicant, but
commit b4a17a6ea7 started validating this
as part of a change that is needed to support NFC configuration method.
While this kind of AP behavior is against the WSC specification and
there could be potential use cases for moving from PBC to PIN, e.g., in
case of PBC session overlap, it is justifiable to work around this issue
to avoid interoperability issues with deployed APs. There are no known
implementations of PBC-to-PIN change from M1 to M2, so this should not
reduce available functionality in practice.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
According to WSC specification (Ver 2.0.2, section 8.3), RF Bands
attribute should be set to the specific RF band used for the current
message. Add an option to set wanted band in wps_build_rf_bands() and
add a callback to get the current band from wpa_supplicant and hostapd.
Signed-hostap: David Spinadel <david.spinadel@intel.com>
Commit b4a17a6ea7 added support for the
WPS Registrar to change the Device Password based on WSC specification
design. However, this added validation for Registrar behavior which
resulted in preventing a common P2P use case from working. Relax the
validation rules for builds with P2P enabled to allow the Enrollee (P2P
client) accepting M1/M2 changes in Device Password Id between Default
and Registrar-specified PIN.
Signed-hostap: Jouni Malinen <j@w1.fi>
Registrar is allowed to propose another Device Password ID in M2. Make
Enrollee validate Device Password ID in M2 to check if this happened.
This commit adds support for changing from NFC password token to default
PIN for the case where the AP is the Enrollee and has both the NFC
password token and AP PIN enabled at the same time.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The UFD (USB flash drive) configuration method was deprecated in WSC
2.0. Since this is not known to be used, remove the UFD implementation
from hostapd and wpa_supplicant to allow the WPS implementation to be
cleaned up. This removes the now unused OOB operations and ctrl_iface
commands that had already been deprecated by the new NFC operations.
Signed-hostap: Jouni Malinen <j@w1.fi>
If WPS Registrar tries to provision a WPA/WPA2-Personal network without
including a valid Network Key, the network block cannot be used to
connect to the network. Reject such credential without adding the
network block. This makes wpa_supplicant send WSC_NACK as a response to
the invalid Credential and stop the provisioning process immediately
rather than only after trying unsuccessfully to connect to the network.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Multiple memcmps of nonces were actually comparing only the first byte
instead of all 16 bytes. [Bug 462]
Signed-hostap: Eyal Shapira <eyal@wizery.com>
intended-for: hostap-1
wps_vendor_ext_m1 configuration parameter can now be used to add a
vendor specific attribute into the WPS M1 message, e.g., for
Windows Vertical Pairing.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
While the exponential increase in the lockout period provides an
efficient mitigation mechanism against brute force attacks, this
additional trigger to enter indefinite lockout period (cleared by
restarting hostapd) will limit attacks even further by giving maximum of
10 attempts (without authorized user action) even in a very long term
attack.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like Windows 7 WPS implementation does not like multiple
Authentication/Encryption Type bits to be set in M7 AP Settings
attributes, i.e., it refused to add a network profile if the AP
was configured for WPA/WPA2 mixed mode and AP PIN was used to
enroll the network.
Leave only a single bit set in the Authentication/Encryption Type
attributes in M7 when the AP is acting as an Enrollee to avoid this
issue.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Windows 7 uses incorrect way of figuring out AP's WPS capabilities by
acting as a Registrar and using M1 from the AP. The config methods
attribute in that message is supposed to indicate only the configuration
method supported by the AP in Enrollee role, i.e., to add an external
Registrar. For that case, PBC shall not be used and as such, the
PushButton config method is removed from M1 by default. If pbc_in_m1=1
is included in the configuration file, the PushButton config method is
left in M1 (if included in config_methods parameter) to allow Windows 7
to use PBC instead of PIN (e.g., from a label in the AP).
Previously, only the Configuration Error values were indicated in
WPS-FAIL events. Since those values are defined in the specification
it is not feasible to extend them for indicating other errors. Add
a new error indication value that is internal to wpa_supplicant and
hostapd to allow other errors to be indicated.
Use the new mechanism to indicate if negotiation fails because of
WEP or TKIP-only configurations being disallows by WPS 2.0.
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
ap_setup_locked=2 can now be used to enable a special mode where
WPS ER can learn the current AP settings, but cannot change then.
In other words, the protocol is allowed to continue past M2, but
is stopped at M7 when AP is in this mode. WPS IE does not
advertise AP Setup Locked in this case to avoid interoperability
issues.
In wpa_supplicant, use ap_setup_locked=2 by default. Since the AP PIN
is disabled by default, this does not enable any new functionality
automatically. To allow the read-only ER to go through the protocol,
wps_ap_pin command needs to be used to enable the AP PIN.
This makes it easier to figure out what could have failed in the
WPS protocol and potentially provide more information for the
user on how to resolve the issue.
Need to figure out whether the message is from a WSC 2.0 -based
device based on the unencrypted attributes, not the contents of the
encrypted data since the Version2 subelement is only included in the
unencrypted area.
The WSC 2.0 specification moved to use another design for the new
attributes to avoid backwards compatibility issues with some
deployed implementations.
If CONFIG_WPS_STRICT is set, validate WPS IE(s) in management frames and
reject the frames if any of the mandatory attributes is missing or if an
included attribute uses an invalid value. In addition, verify that all
mandatory attributes are included and have valid values in the WSC
messages.
This adds definitions and parsing of the new attributes that were added
in WPS 2.0. In addition, the version negotiation is updated to use the
new mechanism, i.e., accept everything received and use the new Version2
attribute in transmitted messages.
There is no need to process the public key and generate keys if
the AP is going to reject this M2 anyway. This limits effect of
potential CPU DoS attacks in cases where AP PIN is disabled.
This can happen on the AP if the AP PIN is not configured and
the client tries to go through the protocol instead of just using
Registrar mode to receive M1 from the AP. It is cleaner to send
out the WSC_NACK instead of just stopping the protocol.
This adds config_methods configuration option for wpa_supplicant
following the design used in hostapd. In addition, the string is
now parsed in common code from src/wps/wps_common.c and the list
of configurable methods include all the defined methods from
WPS 1.0h spec.
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
The WPS 1.0h specification is quite unclear on what exactly should be
used as the MAC Address value in the Credential and AP Settings. It
looks like this should after all be the MAC Address of the Enrollee,
so change Registrar implementation to use that address instead of the
AP BSSID.
In addition, add validation code to the Enrollee implementation to
check the MAC Address value inside Credential (and also inside AP Settings)
to make sure it matches with the Enrollee's own address. However, since
there are deployed implementations that do not follow this interpretation
of the spec, only show the mismatch in debug information to avoid breaking
interoperability with existing devices.
Store a copy of device attributes during WPS protocol run and make it
available for external programs via the control interface STA MIB
command for associated stations. This gives access to device name and
type which can be useful when showing user information about associated
stations.
The new file wps_nfc.c and ndef.c implements NFC device independent
operation, wps_nfc_pn531.c implements NFC device dependent operation.
This patch is only for the following use case:
- Enrollee = wpa_supplicant
- Registrar = hostapd internal Registrar
Following NFC methods can be used:
- Enrollee PIN with NFC
- Registrar PIN with NFC
- unencrypted credential with NFC
Encrypted credentials are not supported.
Enrollee side operation:
Registrar side operation:
Example configuration.
CONFIG_WPS=y
CONFIG_WPS_NFC=y
CONFIG_WPS_NFC_PN531=y
I used NFC device "NXP PN531". The NFC device access method is
confidential, so I used outer library. Please download below files from
https://www.saice-wpsnfc.bz/index.php
[WPS NFC Library]
WpsNfcLibrary/WpsNfc.h
WpsNfcLibrary/WpsNfcType.h
WpsNfcLibrary/WpsNfcVersion.h
WpsNfcLibrary/linux/libnfc_mapping_pn53x.dll
WpsNfcLibrary/linux/wpsnfc.dll
[NFC Reader/Writer Kernel Driver]
NFCKernelDriver-1.0.3/linux/kobj/sonyrw.ko
<WiFi test>
The hostapd/wpa_supplicant with this patch passed below tests on
"Wi-Fi WPS Test Plan Version 1.6".
4.2.5 Add device using NFC Method with password token
(I used SONY STA instead of NXP STA.)
4.2.6 Add device using NFC Method with configuration token
5.1.9 Add to AP using NFC Method with password token
through internal registrar
(I used SONY AP instead of NXP AP.)
5.1.10 Add to AP using NFC Method with configuration token
through internal registrar
The old behavior of generating new DH keys can be maintained for non-OOB
cases and only OOB (in this case, with UFD) will use the pre-configured
DH keys to allow the public key hash to be checked.
