Hello World! As mentioned in the previous post, WEP is now broken beyond repair, and new devices are implementing stronger and reliable security mechanisms such as WPA or 802.1x/EAP. In 2002, WPA was released as an urgent fix for WEP that does not require hardware change and can be done by simply updating the firmware. When WPA2 was released in the 802.11i-2004 standard, it added more security.
In this post, I'll discuss the authentication and encryption methods used in both WPA and WPA2. To summarise, both use the same four-step handshakes, but the encryption algorithm is different.
Robust Security Network – RSN
The task group defined and implemented improved encryption and authentication algorithms in the 802.11i amendment which is now part of 802.11-2012 standard, they had published a protocol discussing dynamic key generation via 4 way handshake and two types of keys for unicast and multicast transmission, also called Robust Security Network (RSN).
RSN is implemented at the link level and offers protection for traffic between a connected station with access point, also known as Robust Security Network Associations (RSNA). This addresses numerous issues with the previous encryption methods:
- Enhanced user authentication mechanisms using 4-way handshake and also provide deauthentication when authentication is failed.
- Cryptographic key management and improved data confidentiality let different user have two kind of keys for unicast traffic access point \( \longleftrightarrow \) station (PTK), and another is for multicast traffic access point \( \longleftrightarrow \) stations or stations \( \longleftrightarrow \) stations (GTK)
RSN associations use unique keys for each client station in the network. The GTK and PTK can have different or same cipher suite depending on negotiations.
- Lastly, replay protection uses a sequence counter to prevent packet injection by discarding packets with a lower value. When a new master key is installed, the initialisation vector/sequence counter is reset to one and then incremented by one for each frame. It is implemented from the initial release of TKIP.
frame.number == 835 || frame.number == 837filter.
Here is a quick comparison of different security feature implemented in pre-RSN and RSN security mechanisms. This image is take from Page 51 of RSN guide US Govinfo.
RSN Information Element – RSNIE
You will see RSN Information tag with special number 48 in the "Tagged Parameters" of the beacon or probe response frames. The authentication management method is PSK (pre-shared key), and the cipher suite (encryption method) is TKIP, hence WPA is used in this WiFi network.
The GTK supports only TKIP in the above screenshot, and PTK supports both TKIP and CCM encryption. However, because it is a matter of security, both the station and the access point will use the strongest algorithm available on both ends. In this context, CCMP is stronger than TKIP, so it will be used in the unicast traffic.
Authentication and Key Management – AKM
Although the 802.1X/EAP framework does not require encryption, it strongly recommends it for data privacy. The use of encryption keys in both the authentication and information exchange phases is explained in RSN standards. The Authentication and Key Management Protocol (AKMP) can be either a pre-shared key (PSK) or a port-based access control using RADIUS server.
This image is taken from Chapter 5 of CWSP Study Guide.
The access point of your personal network will broadcast the AKM information in the RSNIE tag as shown above.
Extensible Authentication Protocol – EAP
It is an old authentication protocol that dates back even before I was born 😅 for Point-to-Point protocols, used to connect your devices to the internet. Unlike the environments where certain methods of authentication are enforced (like email/password in websites), EAP allows protocol designers to either use existing and standardised methods, or create their own EAP methods, so it is flexible, as it can also be configured with smart cards, LDAP, certificates, and other methods.
In a nutshell, EAP protocols are similar to GCP's Identity Platform or AWS Cognito in that they are all used to facilitate user authentication and management.
This image is taken from Chapter 6 of Wireless Networks - The Definitive Guide book shows how different EAP methods can be implemented to secure different link layer protocols.
IEEE-802.1X is a framework that is an IEEE adaptation of EAP (RFC 3748) to generate dynamic keys every time a station connects to a WLAN network, also known as Extensible Authentication Protocol over Wireless (EAPoW) or Extensible Authentication Protocol over LAN (EAPoL). As a result, even if the same device reconnects to the network, the keys will be different than before.
Quoting from the RFC documentation, why EAP is preferred
EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP.
It usually works by authenticating the station with Open System and associating it with the network, after which the 4-way handshake process begins, as shown below.
In personal networks, the use of pre-shared keys is favoured for convenience and accessibility, while in corporate settings, an AAA server with RADIUS technology is deployed to manage user authentication, authorisation, and accounting centrally, mitigating insider security risks. Currently, most WiFi access points come equipped with built-in AAA servers, including those found in homes.
Why Did IEEE Opt for EAP Instead of a Custom Protocol?
I've formulated multiple considerations.
- The adoption of the EAP protocol in networking standards is rooted in its well-established history, community testing, vendor acceptance, and its proven role as a reliable authentication framework.
- IEEE standards gain adaptability to diverse authentication needs across varied networking setups, technologies, and organisations. Moreover, it is flexible enough to implement organisation specific authentication protocols. For example, Microsoft implemented their own version of MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol).
- At last, creating an entirely new authentication protocol from scratch can be time-consuming and resource-intensive. The IEEE can leverage an existing framework and focus its efforts on other aspects of its networking standards by adopting EAP.
Although you will realise while reading the MoM of this meeting, it was not easy to adopt the protocol, but this was the good approach to inherit the capabilities of something that is already implemented and wanting. In terms of git, you can call it a fork.
Key Generation Process
I will show you the working of EAPoL messages and how both unicast and multicast keys are generated and installed on the stations and access points The flow on the Wireshark can also be understood like the image I got from eTutorials.org.
Note: In this image, authenticator means the access point and supplicant means station device. We will use this nomenclature as defined in the EAP RFC.
After a successful association, and before the first key message, the supplicant will generate a 256-bit Pairwise Master Key (PMK) by providing SSID and Pre-Shared Key (PSK) to the Password Based Key Derivation Function v2 (PBKDF2) and an HMAC-SHA1 digest. This can be accomplished in Python using the
Key Message 1
This message is fairly simple and straightforward where the authenticator creates a random 256-bit nonce value (let's call it A-Nonce) and sends along with a request to the supplicant.
Key Message 2
The client will now also generate a supplicant nonce (let's call it S-Nonce) and use the information to generate the Pairwise Transient Key (PTK) using PMK, S-Nonce, A-Nonce, Supplicant Address (SA) and Authenticator Address (AA) which will be used to encrypt the unicast frames. Each PTK is actually a concatenation of three (or five, in case of TKIP) separate keys and values:
- 128-bits Key Confirmation Key (KCK) is used in the MIC function to create the payload checksum.
- 128-bits Key Encryption Key (KEK) is used to encrypt the GTK key in message 3.
- 128-bits Temporal Key (TK) is the one actually used to encrypt / decrypt traffic once EAPoL is completed.
- 64-bits MIC Authenticator Tx Key (MIC Tx) [TKIP Specific]
- 64-bits MIC Authenticator Rx Key (MIC Rx) [TKIP Specific]
Now to perform encryption and decryption on the access point, it needs to be installed on its end, which is done by second message from supplicant to authenticator. The authenticator at this point will also have all the required information to generate the PTK for the user on its end, and verify using MIC code.
Because the PTK generation is not specific to vendor and any device can be used with any access point network, a pseudo random function (PRF) should be defined and accepted globally. I found it on this blog (original link is not working so I shared the way back link).
Key Message 3
If the authenticator successfully generated and installed the PTK, it will send an acknowledgement along with a randomly generated Group Transient Key (GTK). Because it is typically encrypted by KEK, it will be unique for each device and is intended to be used for all broadcast messages in the network.
Now supplicant has all the information required to generate and install the GTK on its end.
Key Message 4
Now, supplicant sends the final EAPOL-Key frame to authenticator to confirm temporal keys have been installed and it is ready to send and recieve the encrypted traffic.
A MIC is computed and transmitted along with the message to provide an additional verification of its proper functioning.