802.11i RSN defined the RSNA (Robust Security Network Association), which significantly improved the authentication and encryption mechanisms used in Wi-Fi networks. Prior to RSNA, networks only used WEP, which can be cracked in just a few seconds.
In this post, we will dive into the RSNA based on PSK and analyze real data using CCMP/AES (WPA2 Personal).
Key Hierarchy
The RSNA defines two key hierarchies: one for individually addressed traffic (unicast) and another for protecting group-addressed traffic (broadcast/multicast).
- Pairwise Key hierarchy, unicast traffic.
- Group temporal key hierarchy (GTK), for broadcast/multicast traffic.
Pairwise key hierarchy
PMK (Pairwise Master Key)
The PMK (Pairwise Master Key) is the root key from which all other keys are derived. When using 802.1X authentication, the PMK is generated during the EAP process. In the case of using PSK (Pre-Shared Key) as the authentication key management method, the PMK is equivalent to the PSK.
PTK (Pairwise transient key)
The PTK is generated using a Pseudo-Random Function (PRF). For CCMP/AES, it can be described as:
- PRF(PMK, “Pairwise key expansion”, Min(AA, SPA) || Max(AA, SPA) || Min(Anonce, Snonce) || Max(Anonce, Snonce), Length )
- Where:
- AA: Authenticator Address
- SPA: Supplicant Address
- Anonce: A random number generated by the Authenticator
- Snonce: A random number generated by the Supplicant
- Length: The length of the PTK (WPA2 uses 512 bits)
- The PRF function is covered in the post: https://1hundredwire.com/hash-functions-in-802-11-hmac-and-prf-explained/
- Where:
KCK (Key Confirmation Key)
The KCK (Key Confirmation Key) is used for Message Integrity Code (MIC) calculation to ensure that the EAPOL frame remains intact and was generated using the correct PTK. It is derived from the first 128-bit block of the PTK (Pairwise Transient Key).
KEK (Key Encryption Key)
The KEK (Key Encryption Key) is used to encrypt and decrypt the GTK (Group Temporal Key) using the AES Key Wrap algorithm. It is derived from the second 128-bit block of the PTK (Pairwise Transient Key).
TK (Temporal Key)
The TK (Temporal Key) is used for the encryption and decryption of unicast frames. It is derived from the third 128-bit block of the PTK (Pairwise Transient Key).
Group Master Key hierarchy
GMK (Group Master Key) and GTK (Group Temporal Key)
The Group Master Key (GMK) is generated by the Authenticator. According to the 802.11 standard, the GMK must:
- Be random with high entropy to ensure security.
- Be kept secret and never transmitted over the air.
The Group Temporal Key (GTK) is used to encrypt broadcast and multicast frames. It is derived from the GMK using a Pseudo-Random Function (PRF).
Passphrase to PSK Mapping
As previously described, when using CCMP/AES with PSK, the Pairwise Master Key (PMK) is the Pre-Shared Key (PSK). But how is the PSK generated?
The PSK is derived from the passphrase using the PBKDF2 (Password-Based Key Derivation Function 2) algorithm as follows:
PBKDF2(passphrase,SSID,4096,32)
Where:
- Passphrase (P): A string between 8 and 63 ASCII-encoded characters.
- SSID: The SSID of the Extended Service Set (ESS).
- 4096: The number of iterations used for key stretching.
- 32 bytes (256 bits): The intended length of the derived PSK.
For a detailed explanation of how PBKDF2 converts a passphrase into a key, check out this post:
How PBKDF2 Converts a Passphrase to a Key
RSNA Association Flow
RSNA Establishment
- The STA identifies the AP to connect to by analyzing the beacon information or probe response.
- The STA initiates the Open System authentication process.
- The STA negotiates the cipher suite to be used in the association process.
- The AP and STA perform the 4-way handshake, during which authentication takes place and the necessary keys are created.
4-Way Handshake Process:
- The authenticator (AP) sends EAPOL Message 1, which contains the ANonce. At this stage, the authenticator cannot yet calculate the PTK because it has not received the SNonce from the supplicant.
- The supplicant receives EAPOL Message 1 with the ANonce. Now, it can compute the PTK. The supplicant then creates EAPOL Message 2, including the SNonce and a MIC (Message Integrity Code) calculated using the KCK derived from the PTK. It then sends this message to the authenticator.
- The authenticator receives EAPOL Message 2, calculates the PTK using both the ANonce and SNonce, and derives the KCK. It verifies the MIC from EAPOL Message 2. If the MIC is correct, the authenticator derives the KEK and encrypts the RSN GTK element, which contains the GTK, using AES Key Wrap. It then calculates the MIC for EAPOL Message 3 and sends it to the supplicant.
- The supplicant receives EAPOL Message 3, verifies the MIC, installs the GTK, and responds with EAPOL Message 4. This message includes flags indicating successful key installation and a MIC, allowing the authenticator to perform a final verification.
Hands-On Time!
Now, let’s dive into a real example demonstrating an RSNA. If you want to follow along, you can download the PCAP file from the Wireshark repository: wpa2linkuppassphraseiswireshark.
This capture does not include ACK packets, making it easier to see the packet exchange.
Beacon
Let’s analyze the Beacon frame to learn more about the network.
The SSID is “ikeriri-5g” (0x696b65726972692d3567), the Access Point transmitter address is 50:0f:80:70:18:d0.
Let’s check the RSNIE (Robust Secure Network Information Element):
Findings:
- Group Cipher Suite: 00:0F:AC:4 AES (CCM)
- Pairwise Cipher Suite: 00:0F:AC:4 AES (CCM)
- Auth Key Management (AKM) : 00:0F:AC:2 PSK
Probe Request
In the Probe Request, we have the STA address, which is the transmitter address: 40:40:a7:50:73:db.
The Probe Response RSNIE contains the same information as the previously shown Beacon.
Open Authentication
Now the STA begins authentication; there is not much to see in the open authentication frame exchange.
The STA proceeds to the Association Request, including the RSNIE with its supported cipher suites and AKM. Since these match the AP’s capabilities, the AP responds with a positive Association Response.
Now, the fun part begins: the 4-way handshake!
EAPOL Message 1
The Access Point and STA calculate the PMK, which in this case is the PSK (WPA-2 Personal). The password used here is ‘wireshark’ (0x77697265736861726b).
PSK = PBKDF2(passphrase,ssid,4096,32)
PSK = PBKDF2(0x77697265736861726b, 0x696b65726972692d3567, 4096,32)
PMK = 0x9b14886c1a4915a1a68baae91b67b903c356135bcb71ee44a4a6f5dad9af738f
The authenticator also calculates the PMKID:
PMKID = Truncate-128(HMAC-SHA-1(PMK, “PMK Name” || AA || SPA))
PMKID = 0xb9c9f71f0c96f62b6c11f545d2dff41b
The authenticator generates a random ANonce, in this case:
ANounce = 0x15adf473164f43a34f211ebc34495b588af5b915c0dd4478f5fbc89d2f7bd0fa
The authenticator sends EAPOL Message 1 to the supplicant, containing the ANonce and PMKID. The PMKID is used in the fast-reassociation process when a cached PMK is available on the authenticator.
EAPOL Message 2
Upon receiving EAPOL Message 1, the supplicant will be able to derive the PTK using the ANonce it received and the SNonce it randomly generated.
The SNonce generated is ‘0x1b9717293f9d9d6979d94b36dbc9d83418bbce09f72edc1e1ae4fd79821ffda4‘
PTK = PRF(PMK, “Pairwise key expansion”, Min(AA, SPA) || Max(AA, SPA) || Min(Anonce, Snonce) || Max(Anonce, Snonce), Length )
where:
PMK = 0x9b14886c1a4915a1a68baae91b67b903c356135bcb71ee44a4a6f5dad9af738f
Label = “Pairwise key expansion” encoded in ASCII
Min(AA, SPA) = Min(0x500f807018d0, 0x4040a75073db) = 0x4040a75073db
Max(AA, SPA) = Min(0x500f807018d0, 0x4040a75073db) = 0x500f807018d0
Min (Anonce, Snonce) = 0x15adf473164f43a34f211ebc34495b588af5b915c0dd4478f5fbc89d2f7bd0fa
Max(Anonce, Snonce) = 0x1b9717293f9d9d6979d94b36dbc9d83418bbce09f72edc1e1ae4fd79821ffda4
Length is 512 bits (64 bytes)
PTK = 0xd9eb99b06ea78764cf358998050f017f22fffbcadfbbd96816884599c16d65dd99775e9a0854ac7899e11147547dd8f7621f749257f64eef1cf2bf3bff98a523
Dividing the PTK into 128-bit blocks, we have:
KCK= PTK[1] = 0xd9eb99b06ea78764cf358998050f017f
KEK = PTK[2] = 0x22fffbcadfbbd96816884599c16d65dd
TK = PTK[3] = 0x99775e9a0854ac7899e11147547dd8f7
The last 128 bit block is not used in CCMP.
The supplicant also calculates the MIC, which is the HMAC-SHA1 hash using the KCK and the message from EAPOL Message 2 (excluding the MIC field). The MIC is 128 bits long.
Let me show how the Key MIC is calculated. Before sending the 802.1X EAPOL message, the supplicant creates an 802.1X packet, excluding the Key MIC field. To reverse-engineer the process:
The image above shows EAPOL Message 2, with the 802.1X authentication bytes on the right side.
The 802.1X bytes are:
0103007502010a000000000000000000011b9717293f9d9d6979d94b36dbc9d83418bbce09f72edc1e1ae4fd79821ffda400000000000000000000000000000000000000000000000000000000000000002f8e7921e572afd75a7c898e625ffb43001630140100000fac040100000fac040100000fac023c00
Muting the MIC we get the bytes:
0103007502010a000000000000000000011b9717293f9d9d6979d94b36dbc9d83418bbce09f72edc1e1ae4fd79821ffda4000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac023c00
Now, perform the HMAC-SHA1 using the KCK and extract the first 128 bits.
The HMAC-SHA1 by default outputs 160 bits. We take the first 128 bits, and we have:
Key MIC: 0x2f8e7921e572afd75a7c898e625ffb43
Which matches what we observed in the packet capture.
EAPOL Message 3
When the authenticator receives EAPOL Message 2, it will finally have all the necessary ingredients to create the PTK and verify if the supplicant has the correct key by checking whether the MIC of Message 2 is correct.
If everything is correct, the authenticator will generate the GMK using a secret random function, derive the GTK using a PRF, and send it to the supplicant in Message 3.
The authenticator will perform the exact same process to derive the PTK. In our example, the same KCK, KEK, and TK will be generated.
Now, the WPA Key data field, which was not encrypted in EAPOL Messages 1 and 2, will be encrypted. This field is encrypted using the KEK and the AES Key Wrap algorithm.
The WPA key data field encrypted is:
0xb43c7737faedbf17306b5ea1d5059fd5379d0145fa6ddac1e08d460de93cd72c103a7fb2c21445d2b740139c80ac569ae1e865a198c79a21
KEK = 0x22fffbcadfbbd96816884599c16d65dd
Decrypting using AES Key Unwrap:
The result is 0x30140100000fac040100000fac040100000fac023c00dd16000fac010100eab4e5b93588db11d1ecfda6eac5606bdd00
Which is the decrypted WPA key data field.
The GTK is 0xeab4e5b93588db11d1ecfda6eac5606b
When the supplicant receives EAPOL Message 3, it will perform the exact same process. It will also check the MIC to ensure everything is as expected. It will then install the GTK, which will be used to encrypt broadcast/multicast traffic.
EAPOL Message 4
The final message serves to inform the authenticator that everything is fine and that the GTK has been installed. There’s not much happening with this message.
Once the authenticator receives and acknowledges it, both sides are ready to begin sending encrypted/authenticated data!
Now the Access Point and STA can begin sending encrypted data!
Security Considerations
The steps we’ve covered highlight the potential vulnerabilities of WPA2 PSK, especially when it comes to offline dictionary attacks. If an attacker captures the 4-way handshake, they can perform a trial-and-error process to guess the password. With increasing computational power, cracking short passwords has become much easier.
To mitigate this risk, it’s crucial to use strong, complex passphrases for WPA2 PSK.
Additionally, keep in mind that anyone with access to the PSK can decrypt traffic from other stations (STAs), as long as they have captured the 4-way handshake. This handshake provides the necessary ANonce and SNonce to generate the Pairwise Transient Key (PTK), which is used to decrypt traffic.
If you need a refresher on any of the functions we’ve discussed, be sure to check out the earlier posts.
It’s been quite the journey, but we’re getting close! Thanks for following along—hope this has been useful, and don’t miss the next post where we dive deeper into CCMP encryption!
Stay tuned!
Diego Capassi
References
IEEE Std 802.11™-2016, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE, 2016.