KRACK mass Wi-Fi attack: Who is to blame?
A cryptography expert believes that the IEEE itself, alongside difficulties in analysis of new protocols, are to blame for the existence of the KRACK vulnerability.
Security
KRACK, made public on Monday, is a severe issue in the way Wi-Fi Protected Access II (WPA2) operates.
The exploit utilizes a fundamental issue in the 802.11i (WPA2) four-way handshake sent between communicating parties. The protocol includes a record layer, which encrypts Wi-Fi frames alongside the handshake to encrypt and protect data; however, a problem with the cryptographic nonce means that one of these messages can be blocked in order to force a reinstall of keys onto a client.
If this key is reinstalled, all packet counters are reset to zero, replays can be forced and with some tweaks, an attacker is then able to decrypt all traffic, hijack communication, spy on users and more -- leaving everything from routers to smartphone communication and Internet of Things (IoT) devices open to compromise.
Vendors are scrambling to apply patches, but the protocol was formerly proven as secure back in 2005 (.PDF) by academics, so how was this vulnerability permitted to enter the mainstream in the first place?
Must read: Here's every patch for KRACK Wi-Fi vulnerability available right now
According to Matthew Green, a cryptography expert, and professor at Johns Hopkins University, the Institute of Electrical and Electronics Engineers (IEEE) is a good place to start.
The cryptography expert says that the institution -- rather than the engineers -- is a fair option to point the finger. Green says that the institution's practice of closed-door, private meetings to create standards are "highly complex" and even after the fact, it is "hard for ordinary security researchers to access," which in turn makes finding these kinds of bugs and vulnerabilities in good time nigh on impossible.
As the professor notes, it is not difficult to find the specifications for other protocols, such as the IETF TLS or IPSec specifications. However, trying to find the 802.11i standards online simply won't happen.
There is, however, an IEEE program called GET that gives researchers access to some standards including 802.11 for free, but this is only possible six months after release.
By this point, vendors and developers are already baking standards into their products and solutions, rendering the point of access useless.
Green describes such a program and IEEE's efforts to ease the access issue as "hyper-timid incrementalist bullsh*t."
"This whole process is dumb and -- in this specific case -- probably just cost industry tens of millions of dollars," Green commented. "It should stop."
Another issue is that IEEE standards are not explained well. There is no formal description available for 802.11i handshake state machine that can lead to the broken implementation of the system as implementers are relying on guesswork -- which has not helped eradicated bugs such as KRACK.
"One of the truly terrible things about KRACK is that implementers of the WPA supplicant (particularly on Linux) managed to somehow make Lemon Pledge out of lemons," Green says. "On Android 6 in particular, replaying message #3 actually sets an all-zero key. There's an internal logic behind why this happens, but Oy Vey. Someone actually needs to look at this stuff."
The 2005 paper, which concludes that the 802.11i standard is secure is not necessarily wrong, but as the two components, the handshake and encryption protocol, have been studied in isolation rather than as a whole, this may have also led to problems finding bugs that connect the two.
Combining and analyzing protocols is difficult -- not to mention the additional problems created by IEEE's roadblocks -- and so it is not necessarily surprising that bugs like this continue to emerge.
Green commented:
"In the end, we all know that the answer is for humans to stop doing this work. We need machine-assisted verification of protocols, preferably tied to the actual source code that implements them. This would ensure that the protocol actually does what it says and that implementers don't further screw it up, thus invalidating the security proof.
"This needs to be done urgently, but we're so early in the process of figuring out how to do it that it's not clear what it will take to make this stuff go live. All in all, this is an area that could use a lot more work. I hope I live to see it."
ZDNet has reached out to IEEE and will update if we hear back.