A brief history of Wi-Fi security protocols from “oh my, that’s bad” to WPA3
By Jim Salter
8 - 10 minutes
Thanks to upcoming developments in Wi-Fi, all of us connectivity-heads out there can look forward to getting familiar with new 802.11 protocols in the near future. Ars took a deep look at what's on the horizon last fall, but readers seemed to have a clear request in response—the time had come to specifically discuss the new Wi-Fi security protocol, WPA3.
Before anyone can understand WPA3, it's helpful to take a look at what came before it during The Dark Ages (of Internet)—a time with no Wi-Fi and unswitched networks. Swaths of the Internet today may be built upon "back in my day" ranting, but those of you in your 20s or early 30s may genuinely not remember or realize how bad things used to be. In the mid-to-late 1990s, any given machine could "sniff" (read "traffic not destined for it") any other given machine's traffic at will even on wired networks. Ethernet back then was largely connected with a hub rather than a switch, and anybody with a technical bent could (and frequently did) watch everything from passwords to Web traffic to emails wing across the network without a care.
Closer to the turn of the century, wired Ethernet had largely moved on from hubs (and worse, the old coax thinnet) to switches. A network hub forwards every packet it receives to every machine connected to it, which is what made widespread sniffing so easy and dangerous. A switch, by contrast, only forwards packets to the MAC address for which they're destined—so when computer B wants to send a packet to router A, the switch doesn't give a copy to that sketchy user at computer C. This subtle change made wired networks far more trustworthy than they had been before. And when the original 802.11 Wi-Fi standard released in 1997, it included WEP—the Wireless Encryption Protocol—which supposedly offered the same expectations of confidentiality that users today now expect from wired networks.
In retrospect, WPA3's early predecessor missed the mark. Badly.
WEP—the original Wireless Encryption Protocol
If you want to describe WEP with a single word, that single word should be "awful." The original release of WEP required a 10-digit or 26-digit hexadecimal preshared key, which would look something like this: 0A3FBE839A. It was deadly serious about both the hexadecimal (0-9 and A-F) part and the 10-digit or 26-digit part—put in one digit too few or one too many, and you got an error and nothing worked. Put in a character that wasn't in the 0-F range, and you got an error and nothing worked.
Unsurprisingly, most people—even in business settings—turned this early WEP off, that is, if it was even enabled in the first place. If you think expecting people to effectively and accurately share 10- or 26-digit arbitrary hexadecimal numbers seems unreasonable now, just imagine trying to do it in 1997. Roughly half of the workforce still hadn't mastered the double-click.
Later revisions of WEP offered the ability to automatically hash a human-readable password of arbitrary length into those 10- or 26-digit hexadecimal codes in a way that was consistent between the clients and the routers. So while WEP really still worked on raw 40-bit or 104-bit numbers, you could at least share those numbers in ways where actual humans wouldn't immediately revolt with torches and pitchforks. Beginning with this shift from numbers to passwords, WEP started seeing much more heavy usage.
While it was nice that people were actually using WEP, this early security protocol was still pretty terrible—for one thing, it used deliberately-weak RC4 encryption, because the US Government was still treating encryption algorithms as "weapons" which couldn't be exported overseas. And even if you handwaved away the weak encryption, you were still vulnerable to sniffing from anyone else joined to the same network. Since all traffic was encrypted and decrypted with the same PSK, Eve at the coffee shop could (and all too frequently, did) easily intercept and read any traffic Bob sent out to the Internet. There was no real skullduggery required.
The original implementation of WPA came in with the 802.11g Wi-Fi standard, and it was a huge improvement over WEP. WPA was designed from the start to accept human-friendly passwords and passphrases, but its improvements went much further than that.
WPA introduced TKIP, the Temporal Key Integrity Protocol. TKIP served two major purposes; first, it governed the creation of a new 128-bit for each packet sent. This prevents the sort of replay attacks that make any WEP network crackable in minutes. TKIP also offers a Message Authentication Code much stronger than the simple Cyclic Redundancy Check used for this purpose by WEP. CRCs are generally OK for low-confidence verification of data to mitigate the effects of line noise, but they're not strong enough to effectively defend against deliberate attacks (or extremely high-volume transmission of high-value data).
TKIP also made it possible to join a Wi-Fi network without automatically exposing your traffic to everyone else joined to the network. WEP's static pre-shared key meant that everybody on the coffee shop Wi-Fi could receive everybody else's traffic completely in the clear with no additional work; but TKIP's use of a new ephemeral key for each transmitted packet meant this no longer worked. Connecting to a "public private" Wi-Fi network where everybody knows the password no longer meant sharing everything you sent and received with anybody else who happened to be nearby and know the password. Progress!
But TKIP first fell by way of Man-In-The-Middle attacks in 2008, when Martin Beck and Erik Tews discovered a way to exploit 802.11e QoS features to decrypt short packets in a WPA/TKIP network. This was pretty bad—the attacks only took 12-15 minutes—but it wasn't the end of the world for TKIP, since relatively few networks in the real world actually implemented 802.11e. The end of the world instead came one year later in 2009, when Toshihiro Ohigashi and Masakatu Morii published details on a new variation on the Beck-Tews attack which was viable against any WPA/TKIP network. That attack worked in the same 12-15 minute timeframe.
WPA2—down with TKIP, up with AES-CCMP
In 2004, the known weaknesses of WEP and TKIP led the Institute of Electrical and Electronics Engineers (IEEE) to create a new addendum to the basic 802.11 wireless network standard, 802.11i. The Wi-Fi Alliance, an industry regulation organization which owns the trademark for Wi-Fi, in turn declared that WPA2 certification meant implementing everything in the 802.11i extension fully. The major improvement here was the replacement of TKIP with AES-CCMP for non-enterprise authentication. (Enterprises typically use RADIUS to assign individual per-user passwords, which both allows for scenarios like "turn Bob's Wi-Fi access off, but only Bob's" and dispenses with the majority of the authentication attack problems we're going through here).
The alphabet soup here is thick and hot: AES is the Advanced Encryption Standard, and CCMP is the Counter Mode Cipher Block Chaining Message Authentication Code Protocol. AES-CCMP is not vulnerable to the same replay attacks that brought the downfall of TKIP in 2009. Unfortunately, while WPA2 certification required supporting AES-CCMP, it did not mandate its usage, and many if not most users kept right on using TKIP for many years in order to ensure older, non-WPA2 devices could connect.
At the same time, WPA2 and AES-CCMP didn't stay secure forever; the well-published KRACK attack brought AES/CCMP low in late 2017. The 802.11i anticipates the occasional dropped network connection, and in order to speed up re-connection, it allows a disconnected device to re-use an old key to reconnect. A crafty listener can therefore capture packets and use a replay attack to force the network to repeatedly send the same known blocks with new nonces. This eventually allows the attacker to reconstruct the entire keychain, at which point full network access is possible.
KRACK cannot actually be fixed in WPA2, since it exploits a weakness in the 802.11i standard itself, not in a particular implementation of it. The attack can largely be mitigated by disabling EAPOL-Key frame re-transmission during key installation, which results in potentially longer times for dropped devices to re-establish connections to the network. Still, such a hassle is well worth it in light of the high security risk otherwise.
WPA3—NFC, PFS, SAE, and other three-letter words
The Wi-Fi Alliance announced WPA3 in January 2018, shortly after the KRACK attacks went public. WPA3 avoids replay vulnerabilities by replacing the Pre-Sharing of Keys (PSK) with Simultaneous Authentication of Equals (SAE). SAE is a protocol designed to strongly and safely identify peer devices with one another; it debuted with the 802.11s standard for Wi-Fi mesh networks. In addition to nerfing KRACK, the Wi-Fi Alliance claims that the implementation of SAE as outlined in IEEE 802.11-2016 will protect users from their own folly; SAE should make cryptographic (not brute-force, or dictionary) attack on networks with short passwords no easier than cryptographic attack of networks with long passwords.
WPA3 certification also includes the ability to leverage NFC for authentication. NFC, or Near-Field Communication, is an extremely short-range technology used to authenticate devices by tapping them together; there is no known way to spoof NFC at longer range. If a WPA3 router or access point has NFC network joining enabled, you can just tap a phone or IoT device against the router/access point, and presto, it's now joined to the network. Although this is low security in one sense—anybody who can tap their phone against a little plaque can get on the network—it's much higher security in ways relevant to most real-world small networks. You can't capture an NFC session remotely, and the no-typing configuration removes a lot of the temptation to give your Wi-Fi network a really short, stupid password, since your guests won't have to remember it, figure out how you spelled it, or curse your name while they try to enter it on a touchscreen keyboard.
There are a few devices in the wild using this capability already. I have yet to see an actual router which supports NFC network joining via WPA3, but a vendor sent me a sample of a device called Wi-Fi Porter that uses NFC similarly. After an owner configures the Porter with a smartphone app, new devices which support NFC can be joined to the Wi-Fi merely by tapping them against the Porter—and no app is required, for those new devices. Only the very latest iPhones support NFC configuration this way, but every Android device with an NFC sensor that I've tested worked fine. Tap, do you want to join the guest Wi-Fi? Tap the dialog that pops up on your device's screen, and you're done. I can testify that this is super neat when it works; once Apple catches up with the Android world, I expect NFC network configuration to very rapidly replace publicly posted passwords as the preferred way to join public or semi-public Wi-Fi networks.
WPA3 also patches another glaring hole in Wi-Fi's implementation of crypto by adding Perfect Forward Secrecy. With WEP, WPA, or WPA2, an attacker who doesn't know the Wi-Fi password can record everything they're in range of, then decrypt it later once they have the key. Perfect Forward Secrecy means that that pre-recorded stream is useless; even if you crack the network itself later, the pre-recorded streams you captured are still unreadable garbage. Many—not all!—HTTPS connections already implement PFS, which means they're useless to an attacker at a later date even if snooped across a Wi-Fi connection. With WPA3, even weaker HTTPS connections (not to mention unencrypted network traffic, such as DNS resolution) will be protected as well.
What do I need to be safe?
The ink is still so wet on WPA3 that you may not be able to find a router that supports it yet. But don't panic; most modern routers, mesh kits, access points, and devices should include the KRACK mitigation features introduced in early 2018 at this point. You should absolutely not be using any non-802.11ac devices any more, if at all possible; and you should make absolutely certain you've updated the firmware on all routers et al to the latest available version. If that newest available firmware version is older than November 2017, it is without a doubt vulnerable to KRACK, and you're going to need to discard and replace that device. If it's older than, say, July 2018 it might or might not include KRACK mitigations, and you should go through all of that device's firmware release notes since November 2017 to make certain.
Windows, Linux or BSD, and Apple personal computers should generally be in good shape, as long as the operating system itself is patched and up-to-date. WPA2 authentication on general-purpose computers is typically handled independently of the hardware driver in the operating system stack itself. Apple IOS devices, and Google Pixel and Nexus devices, will be fine if the device itself is brought up-to-date. Android devices in general are much more of a crapshoot, since many Android OEMs and wireless carriers are absolutely awful about making security patches available. IoT devices are similarly a dubious proposition; if you've got a non-Google Android device or IoT device in general, you're going to have to do some determined Googling to make sure you're OK—and some determined tweeting at vendors to fix it already if you turn out not to be.
If the history of Wi-Fi security protocols teaches us anything, the rollout of WPA3 may take a minute for the masses to truly adopt it. And eventually, some enterprising White Hats or Black Hats may devise a new, currently unimagined attack that goes and changes our whole secure perception of this latest WPA iteration. But for now at least, things appear to be a lot better than the days of unswitched networks or all traffic being encrypted and decrypted by the same PSK.