The WPA2 4-Way Handshake: A Step-by-Step Breakdown

The WPA2 4-Way Handshake: A Step-by-Step Breakdown

Every time a device connects to a WPA2 network, both sides prove they know the password without either one transmitting it. That sounds like a magic trick. It's actually a well-understood cryptographic protocol - the 4-way handshake - and understanding how it works explains both why WPA2 is secure in normal operation and why offline password cracking is possible when you have a capture.

This article walks through the handshake message by message, explains the key derivation math, and describes what a captured handshake actually contains. At the end, we cover how BLEShark Nano captures handshakes and what you can do with them in an authorized audit.

What the Handshake Accomplishes

The 4-way handshake achieves three things simultaneously:

1. Mutual proof of PMK possession: Both the AP and the client demonstrate they hold the same Pre-Shared Master Key without transmitting it. If either side has the wrong key, the MIC verification fails and the handshake is aborted.
2. Fresh session key derivation: Even if the WiFi password hasn't changed in years, every connection gets a fresh encryption key - the PTK (Pairwise Transient Key). This means capturing traffic from one session doesn't help you decrypt traffic from a different session. This property is called forward secrecy per-session (though WPA2 doesn't provide full forward secrecy; an attacker with the password can still decrypt all sessions).
3. Group key distribution: The AP securely delivers the GTK (Group Temporal Key) to the client. The GTK encrypts broadcast and multicast traffic, shared among all connected clients. It's distributed encrypted with a key derived from the session, so only authenticated clients can receive it.

sequenceDiagram
    participant C as Client (Supplicant)
    participant AP as Access Point (Authenticator)
    Note over C,AP: Both hold PMK derived from passphrase + SSID
    AP->>C: Message 1: ANonce (plaintext)
    Note over C: Generates SNonce
Derives PTK = PRF(PMK, ANonce, SNonce, MACs)
    C->>AP: Message 2: SNonce + MIC
    Note over AP: Derives same PTK
Verifies MIC proves client knows PMK
    AP->>C: Message 3: GTK (encrypted) + MIC
    Note over C: Verifies MIC
Installs PTK and GTK
    C->>AP: Message 4: ACK + MIC
    Note over AP: Installs PTK
    Note over C,AP: Encrypted data transfer begins using PTK

The complete WPA2 4-way handshake - four EAPOL-Key messages derive and confirm the session encryption key (PTK) without ever transmitting the WiFi password

Prerequisites: The PMK

Before the handshake starts, both sides independently derive the PMK (Pairwise Master Key). This is how the password enters the picture.

For WPA2-Personal (PSK) networks, the PMK is derived directly from the pre-shared key using PBKDF2:

PMK = PBKDF2(HMAC-SHA1, passphrase, SSID, 4096 iterations, 256 bits)

The PBKDF2 function runs the HMAC-SHA1 function 4096 times, mixing in the SSID as a salt. The result is a 256-bit (32-byte) PMK. The SSID is used as the salt specifically to prevent precomputed rainbow tables from working across different networks - a table for "HomeNetwork" doesn't help you against "OfficeWifi".

This derivation is computationally expensive by design. On a CPU, deriving one PMK candidate takes milliseconds. At scale, when you're trying millions of password candidates, this cost adds up - which is why GPU acceleration (hashcat on a gaming GPU) is so much faster than CPU cracking.

The client computes the PMK from the passphrase the user entered. The AP computes it from the PSK it has stored. Neither transmits the PMK or the passphrase. The handshake just verifies both sides got the same result.

Message 1: AP Sends ANonce

The handshake begins after the client has associated with the AP (completed the 802.11 authentication and association exchange). The AP sends the first EAPOL-Key frame.

Contents of Message 1:

• ANonce: a 32-byte cryptographically random nonce generated by the AP
• Key Information: Key ACK = 1, Key MIC = 0 (no MIC yet)
• Replay Counter: set by AP, e.g., 1

Message 1 is unencrypted and has no integrity protection. The ANonce travels in the clear. This is fine - the nonce's purpose is to provide freshness (preventing replay attacks), not secrecy. An attacker observing the nonce doesn't help them derive the PTK without the PMK.

When the client receives Message 1, it has everything it needs to start key derivation: the ANonce, the AP's MAC address (from the frame header), its own MAC address, its own generated SNonce, and the PMK. It immediately derives the PTK.

Message 2: Client Sends SNonce + MIC

The client generates its own 32-byte random nonce (SNonce), derives the PTK, and sends Message 2.

Contents of Message 2:

• SNonce: the client's 32-byte random nonce
• Key Information: Key MIC = 1, Key ACK = 0, Secure = 0
• MIC: HMAC computed over the entire Message 2 frame (with MIC field zeroed), using KCK from the derived PTK
• Key Data: client's RSN Information Element (RSNIE) - describing supported cipher suites
• Replay Counter: echoes the counter from Message 1

The MIC in Message 2 is the critical element. The client is saying: "I have the PTK. Here's proof - a keyed hash that only someone with the correct KCK could produce." The AP, which has both the ANonce and SNonce now (it generated ANonce; it just received SNonce), can derive the same PTK and verify the MIC.

If the MIC doesn't match, the AP knows the client derived a different PTK - meaning the client has a different PMK - meaning the client typed the wrong password. The handshake fails.

Message 3: AP Sends GTK

The AP has verified the MIC from Message 2. It now sends Message 3.

Contents of Message 3:

• ANonce: repeated from Message 1
• Key Information: Key MIC = 1, Key ACK = 1, Install = 1, Secure = 1, Encrypted Key Data = 1
• MIC: keyed hash proving the AP has the correct KCK
• Key Data: GTK (Group Temporal Key), encrypted with KEK from the PTK
• Replay Counter: incremented

The Install flag tells the client to install the PTK for use. The Secure flag indicates the PTK derivation is complete. The encrypted Key Data contains the GTK, wrapped using AES Key Wrap with the KEK.

Message 3 provides mutual authentication in the other direction. The client receives the MIC, verifies it using its derived KCK, and confirms the AP also has the correct PMK. If the MIC is valid, both sides have proven PMK possession without transmitting it.

Message 4: Client Confirms GTK Installation

Message 4 is the ACK. The client has installed the PTK and GTK and confirms this to the AP.

Contents of Message 4:

• Key Information: Key MIC = 1, Secure = 1, Key ACK = 0
• MIC: another keyed hash
• Empty Key Data
• Replay Counter: echoes Message 3's counter

After the AP receives and verifies Message 4, both sides install their keys and begin encrypting data frames with the TK (Temporal Key) component of the PTK. The handshake is complete.

Shared secret derivation: both parties independently compute the same secret from exchanged public values. WPA2 uses a similar principle with the PMK. (Diagram: Wikimedia Commons, CC BY-SA 4.0)

PTK Derivation in Detail

The PTK is derived using a Pseudo-Random Function (PRF) defined in the 802.11 standard:

PTK = PRF-X(PMK, "Pairwise key expansion",
            min(AA, SPA) || max(AA, SPA) ||
            min(ANonce, SNonce) || max(ANonce, SNonce))

Breaking this down:

PMK: The 256-bit key derived from the passphrase. This is the secret.

"Pairwise key expansion": A fixed ASCII string used as a label, ensuring that the same inputs in a different context (e.g., deriving a group key) produce a different output.

AA: Authenticator Address - the AP's MAC address.

SPA: Supplicant Address - the client's MAC address.

min(AA, SPA) || max(AA, SPA): The two MAC addresses concatenated in lexicographic order. Using min/max ordering ensures both sides produce the same input regardless of which one runs the derivation first.

min(ANonce, SNonce) || max(ANonce, SNonce): The two nonces concatenated in lexicographic order. Same ordering trick.

The PRF function is HMAC-SHA1 iterated until enough bits are generated. For CCMP (AES-CCMP), X = 384 bits (48 bytes). For GCMP-256, X = 512 bits.

The PRF inputs are entirely deterministic: given the PMK and the four public values (AA, SPA, ANonce, SNonce), the PTK can be computed. The four public values are all visible in the captured handshake. The only unknown is the PMK.

PTK Components: KCK, KEK, TK

The PTK output is divided into three sub-keys:

KCK - Key Confirmation Key (16 bytes for CCMP): Used to compute and verify the MIC in EAPOL-Key frames. KCK bytes are bytes 0-15 of the PTK. The HMAC-SHA1 MIC in the handshake messages is HMAC-SHA1-128(KCK, message) truncated to 16 bytes.

KEK - Key Encryption Key (16 bytes for CCMP): Used to encrypt the GTK in Message 3, using AES Key Wrap (RFC 3394). KEK bytes are bytes 16-31 of the PTK.

TK - Temporal Key (16 bytes for CCMP, 32 bytes for GCMP-256): The actual encryption key used for data frame confidentiality and integrity via AES-CCMP. TK bytes are bytes 32-47 of the PTK. This is the key that protects your actual traffic.

What a Captured Handshake Contains

A captured handshake PCAP contains four EAPOL-Key frames. From those frames, you can extract:

• AP MAC address (AA) - from frame header
• Client MAC address (SPA) - from frame header
• ANonce - from Message 1 (or 3)
• SNonce - from Message 2
• MIC - from Message 2 (most commonly used for cracking)
• SSID - from beacon/probe frames before the handshake

What the capture does not contain:

• The PMK
• The passphrase
• The PTK
• The TK (the data encryption key)

A captured handshake alone cannot decrypt previously recorded traffic. You'd also need the TK, which isn't in the handshake and isn't derivable without the PMK. The handshake capture is a starting point for offline password testing, not a direct decryption key.

Why Offline Cracking Works

Given a captured handshake, offline cracking works as follows:

1. Take a password candidate from a wordlist or rule-based generator
2. Compute PMK = PBKDF2(HMAC-SHA1, candidate, SSID, 4096 iterations, 256 bits)
3. Compute PTK = PRF-384(PMK, "Pairwise key expansion", sorted MACs || sorted nonces)
4. Extract KCK = PTK bytes 0-15
5. Compute MIC = HMAC-SHA1-128(KCK, EAPOL-Key Message 2 with MIC field zeroed)
6. Compare computed MIC to captured MIC
7. If they match: password found. If not: next candidate.

The bottleneck is step 2 - PBKDF2 with 4096 iterations is intentionally slow. On a modern GPU, hashcat can test hundreds of thousands to millions of candidates per second depending on hardware. Against a weak password (short, common word, keyboard pattern), this is fast. Against a randomly generated passphrase, it's computationally infeasible.

This is why password strength matters for WPA2 networks. The handshake provides no direct protection against offline cracking attempts. The only defense is the computational cost of PBKDF2 combined with a password that's not in any realistic wordlist.

Symmetric encryption: the PTK derived from the 4-way handshake is used as a symmetric key to encrypt all subsequent traffic. (Diagram: Wikimedia Commons, CC BY-SA 4.0)

BLEShark Nano and Handshake Capture

The BLEShark Nano captures WPA2 handshakes as standard PCAP files suitable for analysis with Wireshark, hashcat, hcxtools, and other standard tools.

In active mode (for authorized testing on networks you own or have written permission to test), BLEShark Nano sends a targeted deauthentication frame to a specific client, forcing it to disconnect. The device then monitors the channel for the reconnection event, capturing all four EAPOL-Key messages as the client re-authenticates. The entire process typically completes in a few seconds. The resulting PCAP contains the complete handshake plus the surrounding beacon and association frames for context.

In EU passive mode, BLEShark Nano only captures EAPOL frames that occur during natural client association events. No deauth frames are sent. This mode is appropriate for monitoring your own network's authentication traffic, auditing which devices are connecting and whether handshakes are completing cleanly, or building a corpus of handshakes for password policy analysis on your own infrastructure.

The captured PCAP format matches what Wireshark and hashcat expect. You can open the file, navigate to the EAPOL frames, and inspect every field described in this article - Key Information bits, nonces, MIC values, GTK Key Data. Or export directly to hccapx format for hashcat using hcxpcapngtool.

Shiver Mesh: Parallel Capture Across Networks

A single BLEShark Nano captures one channel at a time. If you're responsible for multiple access points across a building, or testing multiple networks in a lab environment, sequential capture is slow.

Shiver mesh lets multiple BLEShark Nano units operate in parallel. Each node independently targets a different network or channel, captures its handshakes, and syncs captures to a central collection point. In a multi-SSID enterprise environment, you can run simultaneous password audits across all your access points in the time it would take to test one sequentially.

For research environments with isolated test networks, Shiver mesh enables concurrent testing at a scale that would require significantly more expensive equipment through other approaches. Each Nano handles its own radio work independently; the mesh just coordinates the results.

Putting It Together

The WPA2 4-way handshake is elegant engineering. It solves the bootstrap problem - how do two parties prove shared knowledge without revealing it - using nonces, a PRF, and keyed hashes. The protocol is sound. The attack surface isn't a flaw in the handshake design; it's the consequence of using a human-memorable password as the root secret, combined with the necessarily public nature of the captured nonces and MIC.

graph TD
    PASS["WiFi Passphrase"] --> PMK["PMK
Pairwise Master Key
PBKDF2(passphrase, SSID, 4096)"]
    PMK --> PTK["PTK - Pairwise Transient Key
PRF(PMK, ANonce, SNonce, MAC_AP, MAC_Client)"]
    PTK --> KCK["KCK
Key Confirmation Key
MIC verification"]
    PTK --> KEK["KEK
Key Encryption Key
Encrypts GTK delivery"]
    PTK --> TK["TK
Temporal Key
Encrypts unicast data"]
    AP_KEY["AP Group Key"] --> GTK["GTK
Group Temporal Key
Encrypts broadcast/multicast"]

WPA2 key derivation hierarchy - the passphrase generates the PMK, which combines with handshake nonces to produce the PTK and its three sub-keys

Understanding the handshake at this level tells you exactly what you're looking at when you open a PCAP, exactly what an offline cracker is doing, and exactly why password complexity matters for WPA2 networks. For anyone responsible for WiFi security on their own infrastructure, this knowledge directly informs how you should set password policies and monitor for unauthorized access attempts.

BLEShark Nano is designed for authorized security research and educational use. Handshake capture should only be performed on networks you own or have explicit written permission to test. Unauthorized interception of network traffic is illegal in most jurisdictions.

Get BLEShark Nano - $36.99+