Stefan Sperling: > Also this was *NOT* a protocol bug. > arstechnica claimed such nonesense without any basis in fact and > now everybody keeps repeating it :(
Actually, the researcher claimed that are in the standard itself. https://www.krackattacks.com/ The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. Some paragraphs remarks about OpenBSD in a direct way. Paper Although this paper is made public now, it was already submitted for review on 19 May 2017. After this, only minor changes were made. As a result, the findings in the paper are already several months old. In the meantime, we have found easier techniques to carry out our key reinstallation attack against the 4-way handshake. With our novel attack technique, it is now trivial to exploit implementations that only accept encrypted retransmissions of message 3 of the 4-way handshake. In particular this means that attacking macOS and OpenBSD is significantly easier than discussed in the paper. Some attacks in paper seem hard We have follow-up work making our attacks (against for example macOS and OpenBSD) significantly more general and easier to execute. So although we agree that some of the attack scenarios in the paper are rather impractical, do not let this fool you into believing key reinstallation attacks cannot be abused in practice. How did you discover these vulnerabilities? When working on the final (i.e. camera-ready) version of another paper, I was double-checking some claims we made regarding OpenBSD's implementation of the 4-way handshake. In a sense I was slacking off, because I was supposed to be just finishing the paper, instead of staring at code. But there I was, inspecting some code I already read a hundred times, to avoid having to work on the next paragraph. It was at that time that a particular call to ic_set_key caught my attention. This function is called when processing message 3 of the 4-way handshake, and it installs the pairwise key to the driver. While staring at that line of code I thought “Ha. I wonder what happens if that function is called twice”. At the time I (correctly) guessed that calling it twice might reset the nonces associated to the key. And since message 3 can be retransmitted by the Access Point, in practice it might indeed be called twice. “Better make a note of that. Other vendors might also call such a function twice. But let's first finish this paper...”. A few weeks later, after finishing the paper and completing some other work, I investigated this new idea in more detail. And the rest is history.
