When we send M5 & M7, we need to generate a random IV. For testing
purposes, the IV can be provided in settings, otherwise it will be
generated randomly.
We need quite a bit of attributes of M2 for the duration of the WSC
handshake. Most importantly, we need to use the peer's public key when
processing M4 and M6. RegistrarNonce is also needed for generating any
ACK/NACK messages as needed.
Also, peer's device attributes such as Model, Manufacturer, etc might be
useful to report upon successful handshake.
AuthKey is already uploaded into auth_key_hmac. KeyWrapKey is now
uploaded into the AES-CBC(128) cipher. We currently have no use for
EMSK.
So we no longer need to keep the wsc_session_key structure around.
Encrypted Settings TLVs are structured similarly to the various WSC
messages. However, they lack a version2 extension field and use a Key
Wrap Authenticator element instead of Authenticator.
DevicePassword is the PIN, either static, dynamically generated or
entered by the user. For PushButton mode, DevicePassword is set to
'00000000'. It can also be provided via external means, such as NFC.
This patch allows DevicePassword to be externally configured into the
EAP-WSC layer. Optionally, the secret nonce values can also be
provided for testing purposes. If omitted, they will be generated using
l_getrandom.
We use the load_settings method to bootstrap the internal state of the
EAP WSC state machine. We require certain information to be provided by
the higher layers, namely:
Global Device parameters
- Manufacturer
- Model Name
- Model Number
- Serial Number
- Device Name
- Primary Device Type
- OS Version
Session specific parameters
- MAC Address
- Configuration Methods
- RF Bands
The following parameters are auto-generated for each new session, but
can be over-ridden if desired
- Private Key
- Enrollee Nonce
Expanded EAP methods should get their packets for handling starting at
the op-code field. They're not really interested in
type/vendor-id/vendor-type fields.
Denis Kenzior