wifi-security

Robust Security Network and Extended Authentication Protocol in Detail

Learn about the Robust Security Network, its features, and the use of the 802.11X Extended Authentication Protocol. Understand how the 4 way handshake generates dynamic keys for each network device.

Gurkirat Singh

Feb 12, 2023 • 10 min read

Photo by Takashi Miyazaki / Unsplash

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.

On multiple failed attempts, the access point sends a deauthentication frame to the station.

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)

Key management for the different clients connected to same network

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.

💡

Regardless of the retry flag set in frame control, each frame contains a different value of the initialisation vector which is trivially incremented from previous transmission. This will result in a different digest for the same plain text. If you don't believe me, download the wpa-Induction.pcap file and use the wireshark frame.number == 835 || frame.number == 837 filter.

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.

Security comparison between pre-rsn and rsn encryption

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.

wlan.tag.number == 48

Wireshark filter to get beacon frames containing RSN tag

RSN information (from beacon frame) supported by access point

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.

ℹ️

The 802.112012 standard also defines a third type of AKMP known as Simultaneous Authentication of Equals (SAE), which is used to replace PSK authentication in WPA3 encryption.

This image is taken from Chapter 5 of CWSP Study Guide.

Authentication and authorisation process

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.

Simply put, it acts similar to what passport.js is for the websites.

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.

4-way handshake in the wire-shark capture

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.

Open authentication and association before 4-way handshake

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.

Options to configure AAA for the personal networks

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.

Section 4 of Tentative Minutes of TGi for Portland Meeting June 2001

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.

Authentication process to generate and install keys

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 passlib.crypto.digest.pbkdf2_hmac function.

from passlib.crypto.digest import pbkdf2_hmac
import binascii

SSID = "Home"
PSK = "Query@1234"

PMK = pbkdf2_hmac("SHA1",	# digest algorithm (SHA1) 
	PSK.encode(), 			# password to derive the key
	SSID.encode(),			# SSID used as salt
	4096, 					# number of rotations on the generator function
	32						# desired output length in bytes
)

print(binascii.hexlify(PMK))

Deriving PMK from the SSID and the PSK on supplicant

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.

Authenticator sending the nonce value 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]

Order of different parts of PTK (taken from here)

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.

Supplicant providing its key Nonce and MIC (calculated on PTK) to the authenticator

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).

import hmac, hashlib, binascii, sha
from pbkdf2 import PBKDF2


def customPRF512(key, A, B):
    blen = 64
    i = 0
    R = ""
    while i <= ((blen * 8 + 159) / 160):
        hmacsha1 = hmac.new(key, A + chr(0x00) + B + chr(i), hashlib.sha1)
        i += 1
        R = R + hmacsha1.digest()
    return R[:blen]

512-bits PTK generation function

ℹ️

Does this sound familiar? Check out this post to learn how to get the pre-shared key from a live capture using a dictionary-based attack.

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.

Authenticator is replying with multiple messages in one frame and asking supplicant to install GTK

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.

Supplicant sends acknowledgement to authenticator

A MIC is computed and transmitted along with the message to provide an additional verification of its proper functioning.