By now you’ve certainly heard about the KRACK Internet security nightmare afflicting Wi-Fi. The exploit, discovered by Mathy Vanhoef and Frank Piessens, leverages a vulnerability in the IEEE 802.11i standard for  data encryption. While it doesn’t affect the Internet generally, it does allow a very determined attacker to hijack TCP connections, to steal some passwords and to inject data into browsers.

The fix for KRACK is pretty straightforward: patch the software on your Wi-Fi devices to make them deviate from the flawed IEEE standard. The problem is that the standard combines two perfectly sound crypto protocols in a very poor way.

While each protocol is correct in its own right, a combination that follows the text of the standard is broken. Some operating systems – Apple OS X and iOS and Microsoft Windows – found the problem long ago and worked around it by refusing to follow the literal text of the standard, and others such as OpenBSD have created patches already. The major problems are hard-to-update Linux devices. Because Android is based on Linux, it’s got troubles.

The patch doesn’t solve the whole problem because rogue access points can still do a great deal of mischief. Unfortunately, the FCC’s action in the 2014 Marriott consent decree magnifies the effect of the KRACK attack by removing countermeasures against rogue APs from the network operator’s toolkit. This order needs to be reconsidered with a risk/reward frame of reference.

How KRACK Works

Without getting too deep into the weeds, KRACK exploits a weakness in the setup for Wi-Fi security protocols WPA & WPA2. It affects both the shared password “personal” version that most people use on their home Wi-Fi networks and the user ID/unshared password “enterprise” version that should be running on company networks. Small businesses such as coffee shops tend to use shared passwords, so they’re vulnerable.

VPNs are not vulnerable, and if you use public Wi-Fi networks you should have a VPN already. You want one of the VPNs that you have to pay for because the free ones are either too slow or are fronts for scammers.

When you use a Wi-Fi network with WPA, your device goes through a four step setup process that creates a crypto key shared by the device and the access point. This key is used to scramble your data so nobody can snoop on your traffic. The key is modified in each exchange because it keeps track of sequence numbers.

But the key has to be setup in series of plain-text exchanges that have to deal with the fact that Wi-Fi loses packets. So your ability to encrypt data depends on an error-prone and unencrypted procedure.

Losing the third message of the four means it will be retransmitted, which is fine, but also that sequence numbers that need to be non-zero in the device and the access point to be secure will be reset to zero. If this number is zero before you’ve transmitted any data that’s fine, but if they’re reset to zero in mid-connection you’re vulnerable.

The obvious fix is not to allow retransmission of the third message after the fourth message has been successfully processed. This is what Apple and Microsoft do, and it works fine. But Linux programmers allow the third message to be retransmitted at any time (this is a simplification, see Section 3, “Attacking the 4-Way Handshake” of the research paper for details). Resetting the crypto state right before a TCP SYN packet makes it easy to break the code because the attacker knows what the plain text looks like.

Why KRACK Matters

There’s no reason to believe that anyone has been affected by KRACK so far, but it could have happened. The only plausible scenario for a KRACK exploit requires a rogue access point. This AP has to operate on a different radio channel than the legit access point but has to look identical in all other respects, all the way down to its MAC address.

The interesting thing about KRACK is that it finds a vulnerability in a crypto protocol that has been mathematically proved to be invulnerable to attack. Sounds weird, right? The problem is that the proof makes some assumptions about implementation that turn out to be incorrect in the case of Linux.

The 802.11i standard (and its much better specified follow-on 802.11r) are poorly written in terms of laying out a step-by-step procedure that an engineer unskilled in crypto can follow. The procedure is extremely complex and easy to screw up. In this case, the screwup is to follow the letter of the standard’s text instead of its intent.

So KRACK matters because it exposes a weakness in the standards process. It’s not enough for standards engineers to devise mathematically sound protocols, they (or “we”, as I am one on occasion) need to provide implementers with recipes they can follow without understanding the math.  See Matthew Green’s blog on this.

Why KRACK Doesn’t Matter

This attack is useful for targeting specific victims who use public Wi-Fi networks without VPNs. But it’s not useful for grabbing user credentials in general. Hackers can’t do this attack over the Internet, they can only do it over Wi-Fi on devices that are close by.

If you’ve been targeted by a hacker who is willing to follow you around and setup a rogue access point, we can probably assume that your home is bugged, your trash is being examined, and your computers have keyloggers installed. In this sense, KRACK may be the least of your worries. But it will find its way into Hollywood scripts, and that’s always fun.

Security researchers love to find obscure bugs like this one, and we all appreciate their work. But they do tend to overstate their significance out of enthusiasm for actually catching a fish after many weeks on the lake. While we don’t want to minimize the importance of good security research, we also don’t need to completely lose our minds because a 13 year old bug has been found.

How the FCC Made KRACK Worse

The KRACK attack has many forms and particular systems are vulnerable to different ones. Here’s the scorecard from the research paper for reference. Note a flags the weakest implementations.

The best way to retransmit message 3 is with a cloned access point that uses the same MAC address as the real one and operates on a different channel. Clients can be directed to change channels by a Wi-Fi control packet.

Once the device is communicating with the rogue access point, we’re in a man-in-the-middle scenario. Access points have a lot of power over devices in Wi-Fi, so enterprise Wi-Fi systems devote a lot of energy to detecting them and taking countermeasures against them.

Enterprise Wi-Fi can distinguish rogue AP clones from real APs because it knows that channel the real APs are using. The countermeasures consist of control messages that disconnect devices from the rogue APs.

The Marriott Affair

In its infinite wisdom, the FCC levied a $600,000 fine against the Marriott hotels for operating a perfectly conventional enterprise Wi-Fi system in 2014.  The agency believed that the system violated anti-jamming rules:

Section 333 of the Communications Act provides that “No person shall willfully or maliciously interfere with or cause interference to any radio communications of any station licensed or authorized by or under this Act or operated by the United States Government.” The Bureau previously has indicated that the use of jammers to interfere with Wi-Fi transmissions violates Section 333.

In other words, the FCC considers countermeasures against rogue APs to be unlawful jamming in public spaces. The use of rogue detection and countermeasures on the Marriott corporate network is outside the scope of the consent decree.

The FCC’s beef with Marriott was based on its belief that Marriott was “jamming” Wi-Fi hotspots in order to force conference attendees to purchase pricey access on Marriott’s for-fee Wi-Fi network.

While this was undeniably true, the means employed also have legitimate uses; such as removing the KRACK threat against Android devices, for example. So the FCC’s Marriott order compromised Wi-Fi security.

Anti-Jamming Risk and Reward

I don’t believe the FCC set out to make Wi-Fi less secure. It appears that it simply analyzed Marriott’s behavior from the perspective of public relations optics and took the easy path.

Defending obscure technical practices that have great value against the scorn of the masses wasn’t something the last FCC ever did. In fact, it was more likely to work alongside the pressure groups to inflame the public. But sometimes it’s more important to enlighten than to energize.

The FCC should open an inquiry into the question of Wi-Fi security in general and rogue access points in particular. It’s possible that the current anti-jamming regulations are the best of all possible policies.

But these rules were drafted without regard for rogue access point powers. Now that we know more, it’s wise to reassess the policy.