Summary

  • WPA2's four-way handshake legitimately retransmits message 3 when message 4 appears lost. Vulnerable clients interpreted the valid repeat as permission to reinstall the same session key and reset its packet-number and replay state.
  • KRACK did not recover the Wi-Fi password or negotiated key. It forced reuse of security state under a still-secret key; practical impact depended on the cipher, traffic direction, handshake and implementation.
  • The durable fix kept compatibility intact: answer a valid retransmission, but install each fresh key only once and never reset monotonic state for a key already in use.

The WPA2 four-way handshake has a mundane operational problem to solve. After an access point and a client derive a pairwise transient key, the access point sends message 3 and expects message 4. Wireless frames disappear. If the reply never arrives, retransmitting message 3 is not suspicious behavior; it is how a lossy network makes progress.

KRACK turned that ordinary retry into a state-machine attack. In the construction presented by Mathy Vanhoef and Frank Piessens at CCS 2017, a channel-based intermediary could prevent message 4 from reaching the access point, obtain a retransmitted message 3 and forward it to the victim. The message was authentic. The client could therefore accept it—and some implementations installed the already-active key again.

Installation was not an inert copy operation. It initialized the state that made repeated use of the key safe. Reinstalling it could reset the transmit packet number, and could also reset a receive replay counter. The key itself remained private. Authentication was not undone. Yet packets could once again be processed with nonce or replay state that the protocol expected to move only forward.

That distinction prevents two misleading summaries. KRACK was not a password-recovery attack, so changing a Wi-Fi password did not repair it. It was also not one uniform power over every WPA2 connection. Under CCMP, the paper described replay and decryption possibilities but not direct arbitrary Wi-Fi-frame forgery; TKIP and GCMP could also expose forgery. Injecting into TCP or HTTP still required suitable traffic and additional manipulation. The especially severe all-zero temporal key behavior belonged to affected Linux and Android uses of wpa_supplicant, not to every WPA2 implementation.

The attack reached beyond a single programming mistake because the surrounding assurance story had a blind spot. Formal analyses cited by the researchers established properties such as key secrecy and session authentication. They did not model the moment at which an implementation installs a negotiated key, or what happens if that installation event repeats. The cryptographic proof and the running transition system were answering different questions.

The repair illustrates how a minimum rule can be both narrow and decisive. A client may still receive a duplicate message 3 and send message 4 again. What it must not do is reinstall the session key or reset its associated counters. An implementation can enforce this by refusing to reinitialize state when an already-used key is configured, or by allowing a fresh key to be installed only once during a handshake execution.

Nothing in that repair requires a new packet format. A patched client can continue speaking to an unpatched access point because the retransmission remains visible on the wire and the reply still occurs. The constraint sits in local execution: repeated evidence may justify a repeated response, but not a repeated irreversible state transition.

The patch surface was nevertheless wider than the slogan. CERT/CC's VU#228519 mapped a family of CVEs across pairwise, group-key, fast-transition and related handshakes. The upstream hostapd and wpa_supplicant advisory separated station behavior, access-point modes, 802.11r fast transition, group rekeying, drivers and firmware. Android assigned fixes to the 2017-11-06 patch level while warning that chipset-specific updates could also be necessary. A package version alone could not prove what the loaded radio path actually did.

The researchers' 2018 follow-up is the useful final chapter. Most tested vendors had issued fixes, but residual implementation errors and a lower-impact group-key bypass remained. The response did not invalidate the first repair. It showed why a protocol lesson becomes trustworthy only when independent implementations and deployed products are tested against the actual transition.

KRACK therefore belongs in a broader class of failures where a legitimate message carries too much repeatable authority. Authenticity answers who produced a message. It does not, by itself, answer whether the operation it authorizes may safely occur twice.