KRACK - WPA2 Broke, and Your Linux Clients Broke Worst

On Monday WPA2 stopped being trustworthy. Mathy Vanhoef and Frank Piessens of KU Leuven published Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, immediately branded KRACK, with the now-obligatory logo and microsite that every serious vulnerability apparently ships with these days. Strip the branding off and the result is hard to overstate: WPA2, the protocol that has secured essentially all Wi-Fi for thirteen years, can be manipulated into reusing an encryption key, and reusing a key is the one thing you are never allowed to do.

The part that should sting if you run Linux: of every platform on Earth, wpa_supplicant handles this worst. More on that below, because it is not the embarrassment it first looks like, and it is also genuinely the most dangerous variant of the attack.

The four-way handshake, briefly

When a client joins a WPA2 network it already shares a secret with the access point. With a passphrase that secret is the PMK derived from it; with WPA2-Enterprise it comes out of the 802.1X exchange. Either way, both sides hold the PMK, and neither side wants to use it directly. Instead they run a four-way handshake to derive a fresh session key, the Pairwise Transient Key, and from it the Temporal Key that actually encrypts your frames.

The choreography is four EAPOL messages. The AP sends a nonce, the client replies with its own nonce, both derive the PTK, the AP sends message three (carrying the group key and confirming its half), and the client installs the key and acknowledges with message four. Once the key is installed, CCMP encrypts traffic, using the key plus an ever-incrementing packet number as the nonce for AES in counter mode.

That incrementing packet number is the whole ballgame. Counter-mode encryption is a stream cipher in a trench coat: it generates a keystream from (key, nonce) and XORs it with your plaintext. Reuse the same (key, nonce) pair twice and you have encrypted two different plaintexts with the identical keystream. XOR the two ciphertexts together and the keystream cancels out, leaving you the XOR of the plaintexts, which is a long way down the road to recovering both. Nonce reuse is not a weakness in counter mode. It is the failure mode counter mode exists to avoid.

The flaw

Wi-Fi is lossy, so message three of the handshake can get lost. The standard handles this the obvious way: if the AP does not see message four, it retransmits message three. And the client, on receiving a retransmitted message three, dutifully reinstalls the key.

Here is the problem. Reinstalling the key also resets everything bound to it: the transmit packet number goes back to its starting value, and so does the receive replay counter. So an attacker sitting in a channel-based man-in-the-middle position between client and AP can capture message three and replay it whenever they like. Each replay forces the client to reinstall the same key and reset its nonce to a value it has already used. Now the client is happily encrypting fresh frames with (key, nonce) pairs it burned through minutes ago, and the attacker collects keystream, decrypts traffic, and depending on the cipher can replay and even forge frames.

The elegant and horrible part is that this is a flaw in the standard, not in any one vendor's code. A perfectly faithful implementation of WPA2 is vulnerable, because the protocol told it to reinstall on retransmission. There was nothing to misimplement.

Why Linux got the worst of it

Almost every platform reinstalls a usable key on the replay, which is bad. Linux and Android do something worse. The 802.11 standard contains a throwaway suggestion that an implementation may clear the temporal key from memory once it has been installed, presumably as tidy hygiene. wpa_supplicant versions 2.4 and 2.5 took that literally. So when the retransmitted message three arrives and the supplicant goes to reinstall the key, the key it reinstalls has already been wiped to zeros. It installs an all-zero encryption key.

There is no keystream to recover after that. The traffic is, for practical purposes, in the clear. Because Android above 6.0 is built on wpa_supplicant, roughly half of all Android devices in the field carry this exact variant. The most-deployed mobile OS on the planet and the dominant Linux Wi-Fi stack share the single most devastating instantiation of KRACK. That is not a comfortable sentence to write as a Linux person, but pretending otherwise helps nobody.

Calibrate the panic

Before you rip out your access points, be precise about what KRACK is not. It does not recover your Wi-Fi passphrase or the PMK; the secret is safe and you do not need to change it. It is not a remote attack; the adversary has to be within radio range and has to establish a man-in-the-middle on your channel, which is achievable but not trivial and not something a script kiddie on another continent can do to you. And it does not touch anything above the link layer. A TLS session, an SSH connection, a VPN tunnel: all of those ride on top of the Wi-Fi encryption and were never protected by it in the first place. KRACK peels off one layer. It does not peel off the layers you should have been relying on anyway.

If you run real wireless gear

This bug does not care whether you run a home PSK or full WPA2-Enterprise with 802.1X, because the four-way handshake happens after authentication regardless of how you authenticated. Enterprise is not a mitigation here.

It also has an access-point-side dimension, which matters if you run a controller and managed APs rather than a single consumer router. The Fast BSS Transition handshake from 802.11r, the thing that makes roaming between APs seamless, has its own key-reinstallation variant (CVE-2017-13082) that is exploitable against the AP side, not just the client. So if you have 802.11r enabled on a controller to keep voice and video sessions alive while clients roam, that is a second front. The fix is genuinely two-sided: patch the supplicants on every client, and patch the controller and AP firmware.

On timelines: the hostap and wpa_supplicant fix landed on disclosure day, so a Debian box with current updates is already sorted after an apt-get upgrade. Enterprise vendors are rolling controller and AP firmware over the coming weeks. The devices that will never be fixed are the usual suspects, the IoT junk drawer of cameras and smart plugs and printers running a Wi-Fi stack nobody will ever touch again. Assume those stay vulnerable forever and plan your network around that assumption.

The lesson worth keeping

KRACK is going to get patched, the supplicants are already done, and in a year it will be a footnote. The durable takeaway is not "patch your Wi-Fi", obvious as that is. It is that the link layer was never the right place to put your trust.

WPA2 encrypts the hop between your laptop and the access point. That is all it ever did. The moment your packet leaves the AP it is on whatever wire or fiber or upstream network it was always going to traverse, none of which you control and none of which WPA2 was ever encrypting. Treating "I am on my secure WPA2 network" as a meaningful security boundary was always a mistake, and KRACK just made the mistake expensive enough to notice.

So the correct response is the one you should already have adopted: treat every network as hostile, including your own, and encrypt end to end above the link layer. HTTPS everywhere, SSH for anything administrative, and a VPN tunnel for traffic you actually care about, so that the security of your session does not depend on the security of the radio it happens to be riding tonight. I run a tunnel over my own WLAN for exactly this reason, and on Monday that decision stopped looking paranoid and started looking like the only one that aged well.