As we learned in the previous chapter, authentication is essential to WLAN security. This post will cover the key generation and distribution processes used during authentication. What this chapter does not cover is encryption (that’s coming up in Chapter 6), or WPA3 specifics (reserved for Chapter 10).
Pre-RSNA vs RSNA
Going back to Chapter 1, we’ve already seen the legacy pre-RSNA methods versus the RSNA we rely on today. If all stations in a wireless network support RSNA, the network forms what’s called a Robust Security Network. Pre-RSNA methods include WEP, Shared Key authentication, and Open System authentication. That last one is still quite commonly used today—mostly alongside captive portals. But we all know that’s not our favorite kind of SSID, so let’s just move along.
As much as I’d hope you won’t encounter any pre-RSNA networks besides open SSIDs, you can still occasionally run into what’s known as a Transition Security Network (TSN). This typically refers to a WPA2-PSK SSID that allows older, less secure encryption methods like TKIP/RC4 alongside modern options like CCMP/AES.
I’m glad I entered the industry late enough to have mostly avoided seeing those live in production, but I can imagine that these legacy technologies still exist—especially in industrial environments where a Wi-Fi refresh has to be carefully planned to avoid disruptions.
When even one legacy client connects to a Transition Network, it can dictate the overall security level for the whole BSS. Security is only as strong as the weakest link.
The RSN Element (RSNE) in Action
The security mode(s) in use within a secure network can be examined through the RSN Information Element in a packet capture (formerly called RSN IE, now referred to as RSNE). This element defines the cipher suites used, the Authentication and Key Management (AKM) suites required/supported in the RSN, and additional capabilities such as pre-authentication support for roaming.
You’ll find this RSNE in beacon frames, probe responses, association requests, and reassociation requests.
Let’s take a closer look at the fields with an example capture:
The three key elements you’ll want to look for are:
- Group Cipher Suite – used to encrypt broadcast/multicast traffic
- Pairwise Cipher Suite – used to encrypt unicast traffic
- Authentication Key Management Suite – indicates the security method in use
In this example, we’re looking at a beacon frame from an SSID configured with WPA2-PSK and AES-CCMP encryption. Since it’s a beacon, it often includes a full list of supported cipher suites. That’s where you might spot older options like TKIP.
For instance, even if AES-CCMP is used as the pairwise cipher, the group cipher might still default to TKIP. Why? Because group keys tend to fall back to the most legacy-compatible cipher—broadcast traffic needs to be understood by all connected clients, including the older ones.
Common AKM and Cipher Suite Selectors
Some AKM suite selectors you’ll see frequently in the field:
- 01 – 802.1X
- 02 – PSK
- 03 – FT over 802.1X
- 08 – SAE
Cipher suite selectors to keep in mind:
- 00 – Use Group Cipher
- 01 – WEP-40
- 02 – TKIP
- 04 – CCMP
- 05 – WEP-104
- 09 – GCMP-256
Others exist, and Wireshark will happily show them, but these are the most commonly encountered—and definitely the ones you’ll want to remember for the CWSP exam.
PMKID – Fast Roaming Cheat Code
One last key field in the RSNE is the PMKID (Pairwise Master Key Identifier). This value uniquely identifies the PMK Security Association (PMKSA) between a client and AP.
You’ll only see the PMKID when Fast Secure Roaming features like 802.11r are enabled. It shows up in association and reassociation request frames and acts as a shortcut to bypass full 802.1X/EAP authentication—if a valid PMKSA is already in place between the two devices.
Key Hierarchy in 802.11
For those just getting into 802.11 security, it’s easy to assume that Wi-Fi encryption just uses one single key—like a password you type in once and you’re good to go. But that’s not how it works. If you’ve gone through your CWNA studies, you’ve probably already seen that there’s actually an entire key hierarchy at play. The 802.11-2020 standard defines this structure under the RSN (Robust Security Network) framework. This hierarchy is closely tied to what’s called AKM—Authentication and Key Management—and it’s what governs how encryption and authentication keys are created and used.
Think of it like a pyramid, starting from the very top with something you know or are given (like a password), and gradually building down to the actual encryption keys that protect your Wi-Fi data on the air.
Let’s walk through the process, top to bottom:
- It starts with either a passphrase (in WPA2/3-Personal), a Pre-Shared Key (PSK), or a Master Session Key (MSK).
- The passphrase is something you type in, and through a hashing process (PBKDF2), it gets converted into a PSK.
- In WPA2/3-Enterprise, instead of a passphrase, you go through 802.1X/EAP authentication. This generates an MSK, which is then used to derive the next key: the PMK.
- The PMK (Pairwise Master Key) is the base key used to derive encryption material for that specific session. If Fast Roaming (802.11r) is used, the PMK can be cached or derived in a hierarchy (PMK-R0, PMK-R1), but we’ll keep it simple for now.
- From this PMK, the PTK (Pairwise Transient Key) is generated. This happens during the 4-Way Handshake and uses several inputs: the PMK, a nonce from the AP (ANonce), a nonce from the client (SNonce), and the MAC addresses of both devices. The result is unique per session.
- The PTK is then split into several functional subkeys:
- KEK (Key Encryption Key) – used to securely encrypt other keys like the GTK.
- KCK (Key Confirmation Key) – used to ensure message integrity, like verifying MICs on the 4-Way Handshake frames.
- Temporal Encryption Keys (TEKs or TK) – used for actually encrypting unicast data traffic between the AP and client.
Group Key Hierarchy
So far we’ve only talked about keys used for one-on-one (unicast) communication. But what about broadcast or multicast messages?
That’s where the Group Key Hierarchy comes in.
- The GMK (Group Master Key) is generated locally on the AP based on some randomized calculations. This key is never sent over the air.
- The AP uses the GMK to derive a GTK (Group Temporal Key). This is the key used to encrypt broadcast and multicast traffic within the BSS.
And here’s the important part: the GTK is transmitted to the client during Message 3 of the 4-Way Handshake, and it’s encrypted using the KEK (so only the intended client can decrypt and use it). That’s how group traffic can be secured, even when sent to multiple clients.
So to sum it up: what looks like a single key from a user’s perspective is actually a complex tree of keys working together behind the scenes. And understanding this hierarchy is crucial—not just for exams like CWSP, but also for securing networks in real-world deployments.
Even though this whole key hierarchy looks solid on paper, it’s important to realize that the slightest flaw or manipulation—like a replay attack or key reinstallation—can lead to a serious security breach. As much as we’d like to think WPA2 is bulletproof, vulnerabilities like the KRACK attack have shown otherwise. That’s why it’s crucial to understand each layer and each key in this whole process. When you’re responsible for network security (and if you’re reading this, you probably are), knowing how the puzzle fits together isn’t just theory—it’s essential.
Quick Recap: The 4-Way Handshake
If you’ve followed along with my CWAP blog series, you’ll know I’ve already covered the 4-way handshake pretty extensively back in CWAP Chapter 5. But since it’s a core part of Wi-Fi security and directly tied to how encryption keys come into play, here’s a quick refresher to keep the picture complete.
After the 802.1X/EAP authentication phase (or PSK passphrase to PMK derivation), both the AP and the client have the PMK. The 4-way handshake’s job is to derive the Pairwise Transient Key (PTK) and securely deliver the Group Temporal Key (GTK) to the client.
- Message 1: The AP sends its ANonce to the client.
- Message 2: The client generates its SNonce, derives the PTK, and sends back the SNonce + a MIC.
- Message 3: The AP derives the PTK on its side, checks the MIC, and sends the encrypted GTK.
- Message 4: The client installs the keys and confirms with a MIC.
The PTK includes several subkeys like the Key Encryption Key (KEK) and Key Confirmation Key (KCK), which are crucial for securing key distribution and verifying message integrity.
So while I won’t dive too deep into the 4-way exchange again here, just know it plays a key role in completing the RSNA process—wrapping up authentication and moving us into secure, encrypted communication.
This chapter gave us a solid look at how key management actually works in Wi-Fi networks. From the initial authentication to the inner workings of the key hierarchy and the role of the 4-way handshake—it’s all part of what keeps our connections secure.
If you’re studying for CWSP or just want to better understand what’s happening behind the scenes when a device connects, these are the building blocks worth knowing. Thanks again for reading, and I hope it helped bring a bit more structure to the whole key exchange puzzle.
Let’s keep it going with Chapter 6.
Source(s):
Carpenter, T., et al. (2023). CWSP-207: Certified Wireless Security Professional Study Guide (1st ed.). Durham NC, USA: Certitrek Publishing