Wireless Security Deep Dive

Understanding the Wi-Fi 4-Way Handshake

From PMK to PTK, GTK, and secure data: how a Wi-Fi client and access point establish the keys that protect a wireless session.

Why Is the 4-Way Handshake So Important?

When a wireless client connects to a protected Wi-Fi network, authentication alone is not enough. The client and the access point must also establish fresh encryption keys before normal data traffic can be securely exchanged.

This is the purpose of the IEEE 802.11 4-Way Handshake.

The handshake allows the client and access point to:

Confirm that the client and Access Point (AP) possess the same Pairwise Master Key, or PMK
Derive a fresh Pairwise Transient Key, or PTK
Install encryption keys for unicast traffic
Securely distribute the Group Temporal Key, or GTK
Protect the exchange against message modification and replay attacks

Key pointThe PMK itself is never transmitted during the 4-Way Handshake. Both sides independently calculate the same PTK using information they already possess and newly generated nonces.

What Has Already Happened Before the Handshake?

Before the 4-Way Handshake starts, the client has normally completed:

802.11 discovery and association
Authentication through either 802.1X/EAP in an enterprise network or a pre-shared key mechanism in a personal network
Establishment or derivation of a PMK

At this point, both the client and the authenticator have access to the same PMK, but the temporary keys used to protect the wireless session have not yet been established.

The PMK is therefore the starting point for the 4-Way Handshake, not its final result.

Where Does the PMK Come From?

The origin of the PMK depends on the wireless security mode.

WPA2-Enterprise with 802.1X

In an enterprise deployment, the client, also called the supplicant or EAP peer, authenticates with an EAP server (aka Radius Server).

The access point or wireless controller acts as the authenticator. It carries EAP messages between the client and the RADIUS server.

With EAP-TLS, the client and EAP server participate in the TLS exchange and independently derive the same keying material:

Client side                         RADIUS/EAP server side
-----------                         ----------------------
TLS handshake                       TLS handshake
      |                                   |
TLS secret material                 TLS secret material
      |                                   |
EAP-TLS key derivation              EAP-TLS key derivation
      |                                   |
     MSK                                 MSK
      |                                   |
     PMK                                 PMK

The Master Session Key, or MSK, is keying material exported by the EAP method. In the original EAP-TLS key hierarchy described in RFC 5216, the MSK contains 64 octets:

MSK = Key_Material(0,63)

It is divided into two 32-octet portions:

Enc-RECV-Key = MSK(0,31)
Enc-SEND-Key = MSK(32,63)

RFC 5216 identifies Enc-RECV-Key, the first 32 octets of the MSK, as the PMK used by IEEE 802.11. It also describes the two portions as the peer-to-authenticator and authenticator-to-peer encryption keys.

In a RADIUS-based deployment, the EAP server sends the required keying material to the authenticator in a protected RADIUS exchange, commonly through the Microsoft MPPE key attributes:

MS-MPPE-Recv-Key
MS-MPPE-Send-Key

Client possesses PMK
Authenticator possesses corresponding PMK

Important distinctionThe Group Master Key, or GMK, is not simply the second half of the MSK. The GMK belongs to the authenticator’s group-key hierarchy and is used to generate group keys such as the GTK.

WPA2-Personal

In WPA2-Personal, the PMK is based on the pre-shared credentials.

When a human-readable passphrase is used, the passphrase, together with the SSID, is processed to derive the 256-bit key used as the PMK. If the configured PSK is already a raw 256-bit value, that value functions directly as the PMK.

The 4-Way Handshake does not send the passphrase or PMK over the air.

How Is the PTK Generated?

The Pairwise Transient Key is derived from several values known to both the client and the access point:

PTK = PRF(
    PMK,
    AP MAC address,
    Client MAC address,
    ANonce,
    SNonce
)

The inputs are:

PMK: The existing master key
ANonce: A random value generated by the authenticator
SNonce: A random value generated by the supplicant
AP MAC address: The authenticator address, often written as AA
Client MAC address: The supplicant address, often written as SPA

A precise representation normally orders the two MAC addresses and two nonces consistently:

PTK = PRF(
    PMK,
    Min(AA, SPA) || Max(AA, SPA) ||
    Min(ANonce, SNonce) || Max(ANonce, SNonce)
)

The PRF, or pseudo-random function, produces binary keying material. Packet-analysis applications such as Wireshark normally display binary values in hexadecimal notation to make them easier for humans to read.

Changing even one input produces a different PTK. Conversely, when both parties use exactly the same inputs and key-derivation algorithm, they calculate the same PTK.

RememberThe PMK is not normally different merely because the client connects to a different AP. The PTK changes because the AP MAC address and fresh nonces are PTK inputs. In fast-roaming designs such as 802.11r, AP-specific PMK derivatives such as PMK-R1 may also be involved.

The Four Messages of the 4-Way Handshake

Message 1: The AP Sends the ANonce

The access point generates a random number called the ANonce and sends it to the client in EAPOL-Key Message 1.

Access Point                         Client
     |                                  |
     |-------- Message 1: ANonce ------>|

Message 1 normally contains:

ANonce
Replay counter
Key information flags
No valid MIC in the normal initial exchange

Before receiving Message 1, the client already has the PMK, its own MAC address, the AP’s MAC address, and a locally generated SNonce. After receiving the ANonce, it has every input required to calculate the PTK.

PMK + ANonce + SNonce + AP MAC + Client MAC
                         |
                         v
                        PTK

Message 2: The Client Sends Its SNonce

After calculating the PTK, the client sends EAPOL-Key Message 2 to the access point and proves possession of the corresponding PMK.

Access Point                         Client
     |                                  |
     |<------- Message 2: SNonce -------|
     |               + MIC              |

Message 2 normally contains the SNonce, replay counter, a Message Integrity Code, or MIC, and relevant security parameters from the client. The MIC is calculated using the Key Confirmation Key, or KCK, which is part of the PTK.

Once the AP receives the SNonce, it independently derives the same PTK and uses its KCK to verify the MIC. A valid MIC shows that the message was not modified, that the client calculated the same PTK, and therefore that it possesses the corresponding PMK.

Message 3: The AP Sends the GTK

After successfully verifying Message 2, the access point sends EAPOL-Key Message 3.

Access Point                         Client
     |                                  |
     |-------- Message 3: GTK --------->|
     |         encrypted Key Data       |
     |               + MIC              |

Message 3 normally includes the ANonce, an incremented replay counter, Install and Secure indications, a MIC calculated using the KCK, and encrypted or wrapped Key Data containing the GTK.

The GTK is generated through the authenticator’s group-key hierarchy. It is not calculated from the individual client’s PTK. When the AP delivers it to a client, it protects the GTK using that client-specific Key Encryption Key, or KEK.

GTK
 |
 | encrypted or wrapped using the client's KEK
 v
Protected Key Data in Message 3

The client checks the replay counter, verifies the MIC using the KCK, unwraps the Key Data using the KEK, extracts the GTK, installs the required keys, and prepares the final acknowledgement.

Message 4: The Client Confirms Installation

The client sends the final EAPOL-Key message to the access point.

Access Point                         Client
     |                                  |
     |<------- Message 4: ACK ----------|
     |               + MIC              |

Message 4 normally contains the expected replay counter, a Secure indication, and a MIC calculated using the KCK. It carries no new nonce or GTK.

The AP validates the MIC and replay counter, completes the handshake, and authorizes protected data traffic.

Why Message 4 mattersMessage 4 is not required simply because Wi-Fi is half-duplex. It completes the protocol’s key-confirmation and installation sequence, letting the authenticator know that the client successfully processed Message 3.

Complete Authentication and Handshake Flow

Wi-Fi Client                  Access Point                  RADIUS Server
Supplicant / EAP Peer         Authenticator                  EAP Server
      |                            |                             |
      |<=============== EAP-TLS authentication ===============>  |
      |       EAP messages relayed by the authenticator          |
      |                            |                             |
      | Derives MSK locally        |       Derives MSK locally   |
      | from TLS/EAP key material  |       from TLS/EAP material |
      |                            |                             |
      | Obtains PMK from MSK       |                             |
      |                            |<-- RADIUS Access-Accept ----|
      |                            |    + protected key material |
      |                            |                             |
      | Client possesses PMK       | Authenticator has PMK       |
      |                            |                             |
      |            IEEE 802.11 4-WAY HANDSHAKE                   |
      |                            |                             |
      |                            | Generates ANonce            |
      |<--------- Message 1 -------|                             |
      |           ANonce           |                             |
      |           Replay Counter   |                             |
      |                            |                             |
      | Generates SNonce           |                             |
      | Derives PTK                |                             |
      |---------- Message 2 ------>|                             |
      |           SNonce           |                             |
      |           Replay Counter   |                             |
      |           MIC using KCK    |                             |
      |                            |                             |
      |                            | Derives same PTK            |
      |                            | Verifies MIC using KCK      |
      |<--------- Message 3 -------|                             |
      |           Protected GTK    |                             |
      |           MIC using KCK    |                             |
      |                            |                             |
      | Verifies MIC using KCK     |                             |
      | Unwraps GTK using KEK      |                             |
      | Installs PTK/TK and GTK    |                             |
      |---------- Message 4 ------>|                             |
      |           Replay Counter   |                             |
      |           MIC using KCK    |                             |
      |                            |                             |
      |                            | Completes handshake         |
      |<====== Protected unicast and group data traffic =======> |

PTK and GTK: What Is the Difference?

PTK

The PTK is pairwise and client-specific. It provides the key material used to authenticate EAPOL-Key messages, protect transported key information, and encrypt and integrity-protect unicast data.

Client A <-> AP = PTK-A
Client B <-> AP = PTK-B
Client C <-> AP = PTK-C

GTK

The GTK is a group key used for broadcast and multicast traffic. Clients associated with the same BSS normally receive the applicable GTK from the authenticator. The AP distributes it individually to each client, protecting it with that client’s pairwise KEK.

PTK/TK -> unicast traffic between one client and the AP
GTK    -> broadcast and multicast traffic within the BSS

Understanding the PTK Subkeys

A simplified WPA2/CCMP representation is:

PTK = KCK || KEK || TK

KCK = 128 bits / 16 bytes
KEK = 128 bits / 16 bytes
TK  = 128 bits / 16 bytes

Total = 384 bits / 48 bytes

The exact PTK structure and subkey lengths can vary with the negotiated Authentication and Key Management suite and cipher.

KCK

Confirms the handshake. It authenticates and integrity-protects EAPOL-Key messages through their MICs.

KEK

Protects transported keys. It encrypts or wraps the GTK and other sensitive Key Data.

TK

Protects unicast traffic. It is used with the negotiated data-protection cipher.

1. KCK: EAPOL-Key Key Confirmation Key

The KCK protects the integrity and authenticity of EAPOL-Key messages. Its most visible role is calculating and validating the EAPOL-Key MIC.

Message 1: Normally no valid MIC
Message 2: MIC calculated using KCK
Message 3: MIC calculated using KCK
Message 4: MIC calculated using KCK

When the AP validates the Message 2 MIC using its locally derived KCK, it confirms that the client calculated the same KCK. Because KCK comes from the PTK and PTK depends on the PMK, a valid MIC demonstrates possession of the required PMK-derived key material.

Think of KCK as:The handshake authentication and integrity key.

2. KEK: EAPOL-Key Key Encryption Key

The KEK protects sensitive information transported inside the Key Data field of an EAPOL-Key message. Its best-known use is protecting the GTK when the AP sends it to the client.

The KEK may protect GTK distribution, other protected key data, and IGTK or BIGTK distribution when applicable to protected management-frame configurations.

Think of KEK as:The key-transport protection key.

3. TK: Temporal Key

The TK protects normal unicast 802.11 data traffic between a specific client and the access point. It is used with the negotiated data-protection cipher, such as AES-CCMP, AES-GCMP, or historically TKIP.

Client A <-> AP = TK-A
Client B <-> AP = TK-B
Client C <-> AP = TK-C

One client cannot use its own TK to decrypt another client’s protected unicast traffic.

Key	Primary function	What it protects
KCK	Calculates and verifies MICs	EAPOL-Key messages
KEK	Encrypts or wraps distributed key material	GTK, IGTK, BIGTK, and other Key Data
TK	Protects unicast data	Client-to-AP and AP-to-client unicast frames

What Happens After Message 4?

Most explanations stop after Message 4 because the initial security association is complete and client data can begin flowing. However, the AP may later need to replace the GTK because of a configured periodic rotation timer, changes in group membership, security policy, implementation behavior, or a session event.

The AP does not need to repeat the complete 4-Way Handshake merely to distribute a new GTK. It can use the Group Key Handshake.

Naming noteThese frames are sometimes informally described as “Message 5” and “Message 6.” More accurately, they are Group Key Message 1 and Group Key Message 2, a separate two-message exchange.

Group Key Message 1: The AP Sends a New GTK

The AP generates or selects a new GTK, places it in the EAPOL-Key Key Data field, protects it using the client’s KEK, calculates the MIC using the client’s KCK, advances the replay counter, and sends the frame.

The client validates the replay counter and MIC, unwraps the Key Data using the KEK, extracts and installs the new GTK, and prepares an acknowledgement.

Group Key Message 2: The Client Acknowledges the Update

The response normally contains the corresponding replay counter, a MIC calculated using the KCK, and the necessary acknowledgement indication. It normally carries no new GTK or nonce.

The AP checks the replay counter, verifies the MIC, confirms that the client received the update, and marks the Group Key Handshake as complete for that client.

Why Is the Group Key Handshake Useful?

The AP can rotate the GTK without repeating the full 4-Way Handshake, replacing the client’s PTK solely for GTK distribution, repeating 802.1X/EAP authentication, or reassociating the client.

GTK Rotation and Controller Timers

How often the GTK rotates is generally controlled by the wireless infrastructure configuration. The exact setting, valid range, and default value depend on the controller platform, software version, WLAN configuration, and security mode.

Some older Cisco controller references discuss a broadcast-key rotation interval of approximately 3,600 seconds, or one hour, but this should not be treated as a universal default across all Cisco platforms or releases.

An overly aggressive rekey interval creates more Group Key Handshake exchanges. If a AP does not receive an acknowledge after a GTK update, the update may be retried, the client may temporarily lose broadcast or multicast connectivity, or the security association may eventually be removed and established again.

The GTK rotation interval should balance security requirements, client compatibility, broadcast and multicast usage, infrastructure scale, operational stability, and vendor recommendations.

Final Key Hierarchy

EAP authentication
       |
       v
      MSK
       |
       v
      PMK
       |
       +----------------------------------+
       |                                  |
       v                                  v
4-Way Handshake                    Group-key hierarchy
       |                                  |
       v                                  v
      PTK                                GTK
       |
       +------------+------------+
       |            |            |
       v            v            v
      KCK          KEK           TK

KCK -> EAPOL-Key integrity and authentication
KEK -> Protection of distributed key material
TK  -> Unicast data protection
GTK -> Broadcast and multicast data protection

Conclusion

The 4-Way Handshake does much more than exchange four packets. It connects the authentication phase with the encrypted data phase of a Wi-Fi session.

Its core objective is to prove that the client and authenticator possess corresponding PMK material while deriving fresh, session-specific keys without transmitting the PMK itself.

Message 1 -> AP provides ANonce
Message 2 -> Client provides SNonce and proves PMK possession
Message 3 -> AP proves possession and securely distributes GTK
Message 4 -> Client confirms successful processing

After the handshake, KCK authenticates EAPOL-Key exchanges, KEK protects transported key material, TK protects pairwise unicast traffic, and GTK protects broadcast and multicast traffic.

Later, the two-message Group Key Handshake can replace the GTK without repeating the entire authentication and initial 4-Way Handshake.

Primary technical reference: RFC 5216: The EAP-TLS Authentication Protocol

Post Views: 34