Our key reinstallation attack against the 4-way handshake uncovered special behavior in wpa_supplicant. First, version 2.3 andblower are vulnerable to our attacks without unexpected side-effects. However, we found that version 2.4 and 2.5 install an all-zero encryption key (TK) when receiving a retransmitted message 3. This vulnerability appears to be caused by a remark in the 802.11 standard that indirectly suggests to clear the TK from memory once it has been installed [1, §12.7.6.6]. Version 2.6 fixed this bug by only installing the TK when receiving message 3 for the first time [50]. However, when patching this bug, only a benign scenario was con-sidered where message 3 got retransmitted because message 4 was lost due to background noise. They did not consider that an active attacker can abuse this bug to force the installation of an all-zero key. As a result, the patch was not treated as security critical, and was not backported to older versions. Independent of this bug, all versions of wpa_supplicant reinstall the group key when receiv-
ing a retransmitted message 3, and are also vulnerable to the group key attack of Section 4.
Because Android internally uses a slightly modified version of wpa_supplicant, it is also affected by these attacks. In particular, we inspected the official source code repository of Androids wpa_supplicant [32, 34], and found that all Android 6.0 releases contain the all-zero encryption key vulnerability. Android Wear 2.0 also is vulnerable to this attack. Though third party manufacturers might use a different wpa_supplicant version in their Android builds, this is a strong indication that most Android 6.0 releases are vulnerable. In other words, 31.2% of Android smartphones are likely vulnerable to the all-zero encryption key vulnerability [33]. ulnerabilityalso empirically confirmed that Chromium is vulnerable to the all-zero encryption key vulnerability [68].