4-Way Handshake Visualizer

User types their Wi-Fi password. Phone says "Couldn't join network." They try five times. Same result. They swear the password is right.

If one character was wrong, the phone derived an incorrect PMK from that passphrase (PMK is a deterministic function of passphrase + SSID). During the 4-way handshake, the phone sent M2 with a MIC computed from the wrong PMK. The AP's independently-derived MIC didn't match, so the AP silently dropped M2. The phone retried M2 three or four times, never received M3, and gave up with a generic error.

A packet capture shows the clean fingerprint: M1 from AP, M2 from phone, then nothing from the AP. That pattern — first two messages present, third missing — points to a key mismatch every time. In WPA2/WPA3 Enterprise, the same fingerprint points to a RADIUS cert issue or broken PMKID caching instead of a typo.

The 4-way handshake is a clever trick: two parties prove they share the same Wi-Fi password without ever transmitting the password over the air, and they agree on a fresh encryption key used only for this session.

Here's the intuition. The password (via PSK) generates a PMK — a shared secret that both the AP and the client already know before the handshake begins. Neither side sends the PMK. Instead, each side generates a random number (ANonce on the AP, SNonce on the client), they exchange those random numbers, and then both independently compute a session key (the PTK) from PMK + ANonce + SNonce + the two MAC addresses. The session key never travels — it's derived on each side.

To prove both sides actually derived the same key (i.e., both knew the PMK), the client sends a MIC over M2 using the new key as the signing material. The AP independently computes the expected MIC. If the values match, both sides have proven key knowledge. M3 then delivers the group key (GTK, used for broadcast frames). M4 is the client's final acknowledgment. After M4, every data frame is encrypted with the fresh session key.

The 4-way handshake isn't just about key agreement — it's also a cipher suite binding step that defends against downgrade attacks. The client's RSN IE from AssocReq must appear in M2; the AP's RSN IE from Beacon must appear in M3. If either doesn't match, the receiver aborts the handshake. This protects against an attacker tricking one side into believing a weaker cipher was negotiated (this is separate from KRACK — which was about nonce reuse on key reinstallation, not cipher downgrade).

The MIC is the choke point for authentication. It's computed with the KCK (Key Confirmation Key), one of three derivatives produced when PTK is split:

If any input to PTK derivation is wrong — PMK, either Nonce, or a MAC address — the MIC won't match and the handshake silently fails. That's why the scenario above (wrong password) produces the M1-M2-silence fingerprint.

GTK rotation triggers a 2-way group key handshake on a timer (typically 1-24 hours). The AP sends a new GTK encrypted with each associated client's KEK. No new PTK is derived. Frequent rotation limits exposure if a client is compromised; too-frequent rotation creates handshake load that can drop IoT clients.

KRACK mitigation (IEEE 802.11-2020 clauses 12.7.6.6 and 12.7.7). The Key Reinstallation Attack (CVE-2017-13077) exploited resetting the IV/nonce counter when the supplicant re-installed an already-installed PTK. The spec-level mitigation: supplicants must not reinstall already-installed keys, and APs should set the Install bit in M3 only once. Clients that receive a retransmitted M3 with Install=1 reply with M4 but do not reinstall the key. In captures this is visible as: one M3 + one M4, then any subsequent M3 retransmissions get an M4 reply but no observable key change on the wire.

PTK rekey without full re-association. An AP can initiate PTK rekey (distinct from GTK rotation) by sending a new M1 to an already-associated client. The client generates a new SNonce, the exchange runs again, and the PTK is refreshed without disrupting the association. Useful when the TK packet-number counter approaches exhaustion. Vendor implementation varies — some APs never initiate PTK rekey, relying on association timeout; others do it every few hours.

WPA3-SAE (Simultaneous Authentication of Equals) replaces the PSK-to-PMK step with a dragonfly handshake before the 4-way handshake runs. The PMK output of SAE is used in the 4-way handshake identically to WPA2's PSK-derived PMK — so M1 through M4 look almost the same on the wire. Differences: PMF is mandatory (MFPC=1, MFPR=1), AKM suite is 00:0F:AC:8, and a wrong password fails at the SAE exchange (Auth frames) rather than at M2. The dragonfly handshake also adopted Hash-to-Element (H2E) to close the timing side-channel documented in CVE-2019-9494 and CVE-2019-9495.

Beacon Protection. Wi-Fi 7 mandates, and many Wi-Fi 6E APs implement, Beacon Integrity Protection: each Beacon carries a MIC computed with the BIGTK (Beacon Integrity Group Temporal Key), which is distributed in M3 alongside the GTK. A forged beacon advertising malicious parameters (e.g., a channel-switch to a jammed channel) fails MIC verification at clients and is dropped.

R-TWT interaction with EAPOL. Restricted TWT (Wi-Fi 7) reserves airtime slots for latency-sensitive clients. EAPOL frames are ordinary unicast management frames and contend for airtime normally. In a heavily R-TWT-scheduled BSS, handshake retries can queue behind R-TWT-protected traffic, extending 4-way handshake completion to hundreds of milliseconds. Visible as: normal Beacon rate, abnormally spaced EAPOL frames. Vendor workaround: map EAPOL to a high-priority Access Category to bypass R-TWT queuing; behavior varies.

Hardware MIC offload edge case. Some Wi-Fi chipsets offload MIC verification to hardware. On firmware state corruption, the offload path can return "MIC valid" for frames that should fail — a silent vulnerability not covered by the IEEE spec, observable only through reference-implementation comparison. Documented across vendors over the last several years; review the specific driver CVE feed for your deployed hardware.

Wireshark — handshake forensics. eapol && wlan.sa == aa:bb:cc:dd:ee:ff filters handshake for one client, wlan_rsna_eapol.keydes.key_info.install == 1 finds M3, wlan.rsn.akms.type == 8 identifies WPA3-SAE, wlan_mgt.fixed.reason_code == 15 catches the ambiguous 4-way handshake timeout.