Tech Solvency / The Story So Far / KRACK Attack

Executive summary

Core announcements

Rolling summaries and key commentary


Absract and conclusion from paper

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 WPATKIP 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.

Conclusion - Despite the security proof of both the 4-way and group key handshake, we showed that they are vulnerable to key reinstallation attacks. These attacks do not violate the security properties of the formal proofs, but highlight limitations of the models employed by them. In particular, the models do not specify when a key should be installed for usage by the data-confidentiality protocol. Additionally, we showed that the PeerKey and fast BSS transition handshake are vulnerable to key reinstallation attacks.
- All Wi-Fi clients we tested were vulnerable to our attack against the group key handshake. This enables an adversary to replay broadcast and multicast frames. When the 4-way or fast BSS transition handshake is attacked, the precise impact depends on the data-confidentiality protocol being used. In all cases though, it is possible to decrypt frames and thus hijack TCP connections. This enables the injection of data into unencrypted HTTP connections. Moreover, against Android 6.0 our attack triggered the installation of an all-zero key, completely voiding any security guarantees.
- Rather worryingly, our key reinstallation attack even occurs spontaneously if certain handshake messages are lost due to background noise. This means that under certain conditions, implementations are reusing nonces without an adversary being present.
- An interesting future research direction is to determine whether other protocol implementations are also vulnerable to key reinstallation attacks. Protocols that appear particularly vulnerable are those that must take into account that messages may be lost. After all, these protocols are explicitly designed to process retransmitted frames, and are possibly reinstalling keys while doing so.

Remediation and mitigation


Product summaries:

    Patched in November 6th patch level, per

    Was initially only unofficial, only in betas:
    Now available in iOS 11.1


    (Aruba patch info also has WIPS updates to detect and alert on attempts to exploit)

Asus (nothing at this writing but should appear here:

Cisco / Meraki:
    (Note: Meraki fix only addresses 802.11r vuln, not the client-level ones):

DD-WRT - patched, but patched version not yet released

        Jessie: fixed in version 2.3-1+deb8u5.
        Stretch: fixed in version 2:2.4-1+deb9u1.


Fedora - updates available in testing





Microsoft (released Oct 10 as part of Patch Tuesday):

MikroTik (patches published previous week?)


OpenBSD - fixed (ahead of the embargo, so they will be notified later in the embargo cycle next time?):

pfSense - wpa_supplicant and hostapd vulnerable
    Fix committed to source tree
    Fix available in OS snapshots, not yet released to release

Red Hat


Sophos - affected, fixed TBD:

SUSE - affected


TP-LINK (in progress):
    Official statement, with list of affected/unaffected devices:
    Forum link:

Ubiquiti - affected, some patches available:
    (per NANOG post:)
    Unconfirmed: patched in UniFi firmware release 3.9.3 (see forums or /r/ubiquiti.
    3.8.15 for Broadcom based APs like the first gen UAP-AC and ACv2 should be soon from what I read.


wpa_supplicant - affected, patched upstream:

Zyxel (roadmap, some fixes not expected until Feb 2018!)

CVE list

CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame

Detection and testers


News and posts

Return to The Story So Far (list of notable security events)