KRACK, ROCA, and device insecurity

Monday October 16 was not a particularly good day for those who are even remotely security conscious—or, in truth, even for those who aren't. Two separate security holes came to light; one probably affects almost all users of modern technology. The other is more esoteric at some level, but still serious. In both cases, the code in question is baked into various devices, which makes it more difficult to fix; in many cases, the devices in question may not even have a plausible path toward a fix. Encryption has been a boon for internet security, but both of these vulnerabilities have highlighted that there is more to security than simply cryptography.

The ROCA vulnerability affects keys that have been generated on keycards, which is decidedly not an activity the general public has ever heard of, much less knowingly used. There are digital IDs that use keys generated that way, however, so some are being unknowingly exposed to the flaw. The other vulnerability has far more widespread applicability, however: KRACK is a flaw in the WPA2 encryption protocol that is used to secure most WiFi conversations. Both bugs are serious, but here we will focus on KRACK and leave ROCA to another day.

Key reinstallation attacks

Mathy Vanhoef discovered the WPA2 flaws, which center around a way to cause clients to reinstall the keys used to encrypt the traffic; thus the name comes from key reinstallation attacks, yielding KRACK. As is de rigueur for security vulnerabilities these days, KRACK has its own logo and web page.

When a client connects to an access point (AP) using WPA2, there is a four-way handshake that is done to establish a key to be used for the session. That handshake is encrypted using the shared secret (i.e. the WPA2 password) so a man in the middle should not be able to see the contents (which include the session key). It turns out, though, that the attacker doesn't need to see inside the packet; instead they can simply cause part of the handshake to be replayed, which will allow breaking the encryption from the client.

If the acknowledgment for the third message of the handshake gets lost (or is blocked by an attacker), the AP will resend that third message. That will cause the client to reinstall the key and, crucially, to reset its initialization vector (or "nonce") back to zero. The ciphers used by WPA2 are susceptible when nonce values are reused, so the protocol arranges that each packet gets a new nonce by incrementing a packet counter. Unfortunately, that packet counter gets reset to zero when the "new" key is installed. Worse yet, in some implementations, including all Android versions since 6.0, the client's copy of the key will have been cleared after it was installed into the network interface. The replayed third message will then result in the cleared key replacing the previously installed key, causing subsequent encryption to be done with an all-zeroes key.

As detailed in Vanhoef's paper [PDF], the problem is in the WPA2 protocol itself and is not a bug in the implementations. Even the key clearing in wpa_supplicant versions 2.4 and 2.5 (which ended up in Android) "appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time", he said. One of the root causes of the problem is a poorly specified protocol that was created behind closed doors. As cryptographer Matthew Green put it:

He went on to point out that the IEEE has taken a few steps in the right direction to fix the problem, but that those steps are "hyper-timid incrementalist bullshit". The specifications are now available once they have been public for six months, "coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software". Beyond that, the standards are poorly specified and lack a formal description of the handshake state machine, which requires developers to "implement their code using scraps of pseudocode scattered around the standards document". That pseudocode leads directly to being vulnerable to KRACK.

Green also points out that those implementers bear some of the responsibility, particularly for the key clearing in wpa_supplicant:

Even though the four-way handshake and encryption scheme have been "proven" under various conditions as far back as 2005, Green said, those analyses did not take into account the integration of the handshake and the encryption. Each was separately proven to do the right thing, but the two were not analyzed together. He likened it to the "two unit tests, zero integration tests" meme.

Effects

With KRACK, a suitably positioned attacker could read the traffic being sent by a client to the AP. That traffic could contain various kinds of sensitive information but, in practice, it probably doesn't have all that much of interest. The ubiquity of HTTPS, SSL/TLS, and other layers of encryption (SSH, for example) for much of the traffic carried on networks these days makes KRACK somewhat less dangerous than it might first appear. Though, as Vanhoef notes, there have been various attacks against HTTPS along the way—there are sure to be more down the road.

Other attacks are possible, as well. A TCP connection could be hijacked and data could be injected into the session, for one thing. There are also three different handshakes that can be attacked under various circumstances. One of those can be used to get an AP to reinstall its key, which could then be used to decrypt traffic from the AP to the client. Injecting traffic in that direction could allow all kinds of nastiness.

KRACK is clearly a critical vulnerability that requires updating affected systems as quickly as possible. There is some traffic that is not further encrypted being carried on most WPA2 sessions; DNS queries, for example, might well contain information a user would rather not disclose. Injecting bogus DNS replies could also be highly problematic. Updating should be relatively straightforward for users of various desktop operating systems—wait for the vendor to release a fix (which most have done) and install it. The same goes for most "recent" mobile phones. Upgrading other WiFi devices may not be as easy—or even possible—for millions of devices.

Untold numbers of mobile phones, Internet of Things (IoT) devices, and other gadgets use WiFi (and WPA2) to communicate. Phone handsets typically have the best story regarding upgrades, in that they at least have the ability to be upgraded, but many existing phones are no longer receiving updates because their manufacturers deem them to be too old. Other devices may not even have a way to inform their owners that an upgrade is needed—or have no easy way for the owner to do an upgrade. As a Wired article said, it will take decades to clean all of this up.

It is a fairly bleak picture from a number of different viewpoints. One almost amusing outcome of this mess is contained near the end of Vanhoef's KRACK web page. He notified OpenBSD of the flaw in mid-July with an embargo (at the time) until the end of August. OpenBSD leader Theo de Raadt complained about the length of the embargo, so Vanhoef allowed OpenBSD to silently patch the flaw. "In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo." That might not quite be the outcome De Raadt was hoping for with his (quite reasonable) complaint, especially given that Vanhoef strongly hints that there are other WiFi vulnerabilities in the pipeline.