Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2

Abstract

📜 Abstract

We introduce the key reinstallation attack. This attack abuses design or implementation flaws in cryptographic protocols to reinstall an already-in-use key. This resets the key’s associated parameters such as transmit nonces and receive replay counters. Several types of cryptographic Wi-Fi handshakes are affected by the attack. All protected Wi-Fi networks use the 4-way handshake to generate a fresh session key. So far, this 14-year-old handshake has remained free from attacks, and is even proven secure. However, we show that the 4-way handshake is vulnerable to a key reinstallation attack. Here, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying handshake messages. When reinstalling the key, associated parameters such as the incremental transmit packet number (nonce) and receive packet number (replay counter) are reset to their initial value. Our key reinstallation attack also breaks the PeerKey, group key, and Fast BSS Transition (FT) handshake. The impact depends on the handshake being attacked, and the data-confidentiality protocol in use. Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged. Because GCMP uses the same authentication key in both communication directions, it is especially affected. Finally, we confirmed our findings in practice, and found that every Wi-Fi device is vulnerable to some variant of our attacks. Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.

Description

✨ Summary

The paper introduces key reinstallation attacks, in which an adversary causes a device to reinstall a cryptographic key that is already in use. Reinstallation resets state associated with the key, especially transmit nonces and receive replay counters. Reusing a nonce with the same key can expose weaknesses in the underlying confidentiality and integrity protocol.

The principal attack targets the WPA/WPA2 4-way handshake. The attacker manipulates traffic so that the authenticator retransmits handshake message 3. If the client accepts that retransmission after the session key has already been installed, it reinstalls the same Pairwise Transient Key and resets its packet-number state. The authors develop practical variants using a channel-based man-in-the-middle position, implementation-specific behavior, and race conditions between the host processor and wireless network interface.

The paper extends the analysis to the PeerKey, group key, and 802.11r Fast BSS Transition handshakes. The group-key attack resets a client’s receive replay counter and enables replay of broadcast or multicast frames. The FT attack targets the access point by replaying a reassociation request; in the implementations tested, this causes the AP to reinstall the session key and reuse packet numbers. Some attacks may also occur without an active adversary when handshake messages are lost and retransmitted.

The consequences depend on the data-confidentiality protocol. With AES-CCMP, nonce reuse enables packet decryption and replay, but the authors do not demonstrate practical arbitrary packet forgery. With TKIP, recovery of the weak Michael message-integrity key enables packet forgery in one direction. With GCMP, nonce reuse permits recovery of the GHASH authentication key, enabling packet forgery in both directions because the same authentication key is used for both traffic directions. These capabilities can support TCP-stream hijacking and injection into unencrypted HTTP connections. The study also identifies an especially severe implementation flaw in wpa_supplicant versions 2.4 and 2.5 and Android 6.0, where the attack can cause installation of an all-zero temporal key.

A central result is that existing formal security proofs did not capture the vulnerability because they modeled key secrecy and authentication but did not specify when, or how many times, negotiated keys could be installed. The proposed mitigations are to prevent installation of an already-installed key from resetting nonce and replay-counter state, or to ensure that each freshly negotiated key is installed only once during a handshake. The paper also recommends more precise protocol specifications, continued implementation testing, and nonce-misuse-resistant encryption modes.

The work became associated with the KRACK vulnerability disclosure. CERT/CC coordinated disclosure and documented the issue as affecting WPA/WPA2 handshake processing; vendors subsequently issued implementation-specific advisories and patches. (kb.cert.org)

The paper also prompted subsequent formal work on WPA2 modeling. A later USENIX Security study explicitly describes its model as the first sufficiently detailed model to detect KRACK attacks, including interactions among the four-way handshake, group-key handshake, WNM sleep mode, and data confidentiality. (usenix.org)

The authors’ later technical addendum reported additional key-reinstallation issues involving TDLS and WNM Sleep Mode, extending the scope beyond the handshakes analyzed in the original paper. (krackattacks.com)