KRACK: How WPA2 Wi-Fi Encryption Was Broken by Reusing a Key

In October 2017, researcher Mathy Vanhoef published an attack that broke WPA2, the encryption that had protected almost every Wi-Fi network on the planet for over a decade. The surprise was how it worked. KRACK did not guess your Wi-Fi password or brute-force any key. It tricked your device into installing a key it had already used, and that single mistake unraveled the encryption.

WPA2 replaced the badly broken WEP standard in 2004 and quickly became the baseline for wireless security. For thirteen years it held up well. The passphrase-based version most homes use (WPA2-Personal) was vulnerable to offline password guessing if you chose a weak passphrase, but the protocol itself was considered sound. KRACK, short for Key Reinstallation Attack, was different. It targeted a flaw in the WPA2 standard itself, which meant every correct implementation was affected.

The four-way handshake, briefly

When a device joins a WPA2 network, the client and the access point run a four-message exchange called the four-way handshake. Both sides already share a secret (derived from the passphrase or from an enterprise authentication server). The handshake uses that shared secret to agree on a fresh session key, the Pairwise Transient Key, that will actually encrypt the traffic for this session.

The important part is message three. The access point sends message three to tell the client the key is ready, and the client responds with message four and installs the key. Once installed, that key encrypts frames using a counter, called a nonce or packet number, that increments with every frame. The security of the encryption depends on one rule: a given key must never encrypt two different frames with the same nonce.

The reinstallation trick

Wi-Fi is a lossy medium. Messages get dropped. So the standard says that if the access point does not receive message four, it retransmits message three. When the client receives a retransmitted message three, it reinstalls the same key and, critically, resets the nonce counter back to its starting value.

That reset is the whole attack. Vanhoef showed that an attacker sitting between the client and the access point can capture and replay message three at will. Each replay forces the client to reinstall the key and rewind the nonce to a value it has already used. Now the same key is encrypting new frames with nonces that were used before.

Why nonce reuse is fatal. WPA2 uses a stream-cipher-style construction (AES in CCM counter mode). The nonce plus the key produces a keystream that is combined with the plaintext. Reuse the nonce and you reuse the keystream. Combine two ciphertexts that share a keystream and the keystream cancels out, leaking the relationship between the two plaintexts. From there an attacker can recover content and, in some configurations, forge and replay packets.

This is the same class of failure that shows up whenever a counter is reused. KRACK is the highest-profile real-world example: a nonce reset baked into a widely deployed standard.

The worst-case variant

One implementation detail made KRACK far more damaging on certain devices. The Wi-Fi client software wpa_supplicant, used by Linux and by Android 6.0 and later, cleared the key from memory after installing it. When the attacker forced a reinstallation, the client dutifully installed an all-zero key. That turned a partial decryption attack into full traffic decryption on a large fraction of Android phones at the time, with a trivially known key.

For those devices the practical result was that an attacker within Wi-Fi range could decrypt traffic on the local hop. Against a website served over plain HTTP, that meant reading and modifying the page. Against a network login without additional protection, it could mean capturing session data.

What KRACK did not do

It helps to be precise about the limits, because the coverage at the time was alarming.

• 
  It did not recover your Wi-Fi password. The attacker never learned the passphrase or the master key. The network name and password were unchanged after the attack.


• 
  It did not break encryption above the link layer. A connection already protected by TLS (HTTPS) stayed protected. KRACK exposed the Wi-Fi hop, not the end-to-end tunnel running inside it.


• 
  It required proximity. The attacker had to be within radio range and positioned in the traffic path, not sitting anywhere on the internet.

That third point is why KRACK never became a mass-exploitation event on the scale the headlines implied. It was a serious protocol flaw with a narrow physical reach.

The fix and the WPA3 question

The repair was straightforward once the flaw was understood. Patched clients and access points refuse to reinstall a key that is already in use, so the nonce never rewinds. Because the fix could live on either side of the handshake, a patched phone was protected even against an unpatched router, and vice versa. Vendors shipped updates through late 2017 and 2018.

KRACK also became part of the argument for WPA3, which was finalized in 2018. WPA3-Personal replaces the passphrase handshake with SAE (Simultaneous Authentication of Equals, based on the Dragonfly exchange), which resists the offline password guessing that always haunted WPA2-Personal, and it mandates Protected Management Frames. WPA3 was not a direct response to KRACK, and researchers later found separate weaknesses in early SAE implementations (the Dragonblood set of bugs). The honest summary is that WPA3 improved the handshake meaningfully while proving, again, that new protocols carry new bugs.

The lasting lesson

The most useful takeaway from KRACK is not about Wi-Fi at all. It is about where you place your trust. Wi-Fi encryption protects one link: the hop between your device and the access point. It was never designed to protect your data across the whole path to the server you are talking to. When that single link broke, the only thing that stood between users and full exposure was whether the traffic riding on top was independently encrypted.

This is the argument for defense in depth, and specifically for end-to-end encryption. The network you happen to be on should not determine whether your communication is private. A device running an evil-twin access point or a compromised hotel network is functionally the same threat as a KRACK attacker: someone who controls your local link. In every case, the answer is the same. Encrypt above the link, and treat the link as untrusted by default.

Originally published at havenmessenger.com