mirror of
https://git.kernel.org/pub/scm/network/wireless/iwd.git
synced 2024-11-23 07:29:28 +01:00
138 lines
5.3 KiB
Plaintext
138 lines
5.3 KiB
Plaintext
Introduction
|
|
============
|
|
|
|
This document describes the various stages of the authentication / association
|
|
process for WPA/WPA2 Networks. It is intended to give the reader a 'map' of
|
|
what pieces come into play and when.
|
|
|
|
For a more broad overview of authentication procedures, refer to Section
|
|
4.10.3 of 802.11.
|
|
|
|
WPA is an earlier stop-gap solution to WEP security vulnerabilities.
|
|
Essentially it is a subset of draft 802.11i. WPA2 refers to the released
|
|
802.11i specification. WPA2 is more of a marketing term; term used inside
|
|
802.11 is RSN (Robust Security Network). Typically WPA uses TKIP with RC4
|
|
(also known as ARC4) stream cipher. WPA2 uses CCMP with AES stream cipher
|
|
which must always be supported. TKIP with ARC4 is also a supported mode of
|
|
operation.
|
|
|
|
|
|
Overview of Getting Connected
|
|
=============================
|
|
|
|
To get connected to a typical WPA2 network the user must first know the
|
|
Pre-Shared-Key or PSK. This key can be generated based on a passphrase
|
|
instead of being entered in hex form by the user. The passphrase generation
|
|
is specified in 802.11, Annex M.4. Since the PSK should be long-lived, it
|
|
should not be exposed over-the-air. For this purpose the PSK is not used
|
|
directly; instead a session key is derived. The process for derivation of
|
|
this key is called the 4-Way Handshake.
|
|
|
|
For the purposes of the 4-Way Handshake below, PSK becomes the PMK (Pairwise
|
|
Master Key). The PMK is also obtained from an EAP exchange, but that is a
|
|
different topic.
|
|
|
|
4-Way Handshake generates a key referred to as the PTK (Pairwise Transient
|
|
Key). PTK is generated by feeding the PMK, AP Nonce (ANonce), STA Nonce
|
|
(SNonce), AP MAC Address and the STA MAC Address through a hashing function.
|
|
The SNonce and ANonce are randomly generated numbers and are exchanged by the
|
|
STA and the AP during the initial two steps of the Four-Way Handshake. The
|
|
third step of the handshake establishes the GTK (Group Temporal Key). The
|
|
fourth step serves as the acknowledgement step.
|
|
|
|
The Four-Way Handshake is accomplished by exchanging EAPoL-Key protocol frames
|
|
after performing OPEN_SYSTEM Association to the target AP.
|
|
|
|
|
|
Key Derivation
|
|
==============
|
|
|
|
The PTK obtained from the 4-Way handshake is divided into 3 separate keys:
|
|
|
|
- 16 byte KCK (Confirmation Key). The KCK is used in the computation of the
|
|
MIC field used by EAPoL-Key frames. The KCK is used as input to HMAC-MD5,
|
|
HMAC-SHA1 or CMAC-AES depending on what hashing function is used.
|
|
|
|
- 16 byte KEK (Encryption Key). The KEK is used to encrypt data in message 3
|
|
if it contains the GTK.
|
|
|
|
- 16 byte TK (Temporal Key). Used to encrypt / decrypt normal packets flowing
|
|
between the STA and the AP.
|
|
|
|
If TKIP used, then the following elements are also derived from the same PTK:
|
|
|
|
- 8 byte Michael MIC Authenticator TX Key
|
|
- 8 byte Michael MIC Authenticator RX Key
|
|
|
|
For more details on the Four-Way Handshake, refer to 802.11 Section 11.6.2
|
|
|
|
|
|
Overall Process
|
|
===============
|
|
|
|
- The user selects a network to connect to. This network can be known
|
|
implicitly or via a scan. A Probe request or a Beacon must first be
|
|
received and the RSN IE must be stored in order to connect to the AP. The
|
|
RSN element contains the security parameters supported by the BSS. This RSN
|
|
element must also be compared against the RSN element received from the AP
|
|
in message 3 of the 4-Way Handshake.
|
|
|
|
- OPEN_SYSTEM Authentication and Association requests are sent to the AP. In
|
|
the case of the Association request, the RSN element with the selected
|
|
encryption parameters must be included.
|
|
|
|
- Once the OPEN_SYSTEM Association is successful, the AP shall send Message 1
|
|
of the 4-Way Handshake. This comes in the form of EAPoL-Key messages and
|
|
require special privileges / setup in order to be read from the netdev
|
|
device.
|
|
|
|
- STA records all necessary parameters from Message 1 (ANonce, Key Replay
|
|
Counter). STA Generates the PTK, constructs Message 2 and sends it to the
|
|
AP.
|
|
|
|
- Once Message 3 is received from the AP, the STA sanity checks certain
|
|
paremeters (Key Replay Counter, ANonce, MIC). The RSN received from the AP
|
|
is also checked against the one received in Message 3. If everything checks
|
|
out, then Message 4 is constructed and sent to the AP.
|
|
|
|
- Based on TK and GTK, the keys are set into the hardware. The Re-Key offload
|
|
is enabled as well (if supported?)
|
|
|
|
Here's an example of how this looks like:
|
|
|
|
< Request: New Key (0x0b) len 68 [ack]
|
|
Key Data: len 16
|
|
3c 7d 08 8b 94 10 0f 21 06 6d 7b 18 a1 7e e0 ad
|
|
Key Cipher: CCMP (0x000fac04)
|
|
Key Sequence: len 6
|
|
00 00 00 00 00 00
|
|
MAC Address: 24:A2:E1:EC:17:04
|
|
Key Index: 0 (0x00)
|
|
Interface Index: 3 (0x00000003)
|
|
|
|
< Request: Set Key (0x0a) len 28 [ack]
|
|
Key Index: 0 (0x00)
|
|
Interface Index: 3 (0x00000003)
|
|
Key Default: true
|
|
Key Default Types: len 4
|
|
Unicast: true
|
|
|
|
< Request: New Key (0x0b) len 64 [ack]
|
|
Key Data: len 16
|
|
2e 15 6e 7c 4e 3d f1 37 09 13 ed bd 62 8e 25 65
|
|
Key Cipher: CCMP (0x000fac04)
|
|
Key Sequence: len 6
|
|
00 00 00 00 00 00
|
|
Key Default Types: len 4
|
|
Multicast: true
|
|
Key Index: 2 (0x02)
|
|
Interface Index: 3
|
|
|
|
< Request: Set Rekey Offload (0x4f) len 64 [ack]
|
|
Interface Index: 3 (0x00000003)
|
|
Rekey Data: len 52
|
|
14 00 01 00 24 7a 90 94 e5 43 de 1b 1e 3d d4 a0
|
|
5c d0 e7 76 14 00 02 00 28 4d b5 b1 cf bc e4 25
|
|
f4 f5 00 47 64 83 87 bc 0c 00 03 00 00 00 00
|
|
00 00 00 01
|