Mathy Vanhoef
imec-DistriNet, KU Leuven Mathy.Vanhoef@cs.kuleuven.be
Frank Piessens
imec-DistriNet, KU Leuven Frank.Piessens@cs.kuleuven.be
ABSTRACT
We introduce the key reinstallation attack. This attack abuses design or implementation laws in cryptographic protocols to reinstall an already-in-use key. This resets the key’s associated parameters such as transmit nonces and receive replay counters. Several types of cryptographic Wi-Fi handshakes are afected by the attack.
All protected Wi-Fi networks use the 4-way handshake to gen-erate a fresh session key. So far, this 14-year-old handshake has remained free from attacks, and is even proven secure. However, we show that the 4-way handshake is vulnerable to a key reinstalla-tion attack. Here, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying handshake messages. When reinstalling the key, associated param-eters such as the incremental transmit packet number (nonce) and receive packet number (replay counter) are reset to their initial value. Our key reinstallation attack also breaks the PeerKey, group key, and Fast BSS Transition (FT) handshake. The impact depends on the handshake being attacked, and the data-conidentiality pro-tocol in use. Simpliied, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged. Because GCMP uses the same authentication key in both communication directions, it is especially afected.
Finally, we conirmed our indings in practice, and found that every Wi-Fi device is vulnerable to some variant of our attacks. Notably, our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key.
KEYWORDS
security protocols; network security; attacks; key reinstallation; WPA2; nonce reuse; handshake; packet number; initialization vector
1
INTRODUCTION
All protected Wi-Fi networks are secured using some version of Wi-Fi Protected Access (WPA/2). Moreover, nowadays even public hotspots are able to use authenticated encryption thanks to the Hotspot 2.0 program [7]. All these technologies rely on the 4-way handshake deined in the 802.11i amendment of 802.11 [4]. In this
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proit or commercial advantage and that copies bear this notice and the full citation on the irst page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speciic permission and/or a fee. Request permissions from permissions@acm.org.
CCS’17, October 30śNovember 3, 2017, Dallas, TX, USA.
© 2017 Copyright held by the owner/author(s). Publication rights licensed to Associa-tion for Computing Machinery.
ACM ISBN 978-1-4503-4946-8/17/10. . . $15.00 https://doi.org/10.1145/3133956.3134027
work, we present design laws in the 4-way handshake, and in related handshakes. Because we target these handshakes, both WPA-and WPA2-certiied products are afected by our attacks.
The 4-way handshake provides mutual authentication and ses-sion key agreement. Together with (AES)-CCMP, a data-coniden-tiality and integrity protocol, it forms the foundation of the 802.11i amendment. Since its irst introduction in 2003, under the name WPA, this core part of the 802.11i amendment has remained free from attacks. Indeed, the only currently known weaknesses of 802.11i are in (WPA-)TKIP [57, 66]. This data-conidentiality pro-tocol was designed as a short-term solution to the broken WEP protocol. In other words, TKIP was never intended to be a long-term secure solution. Additionally, while several attacks against protected Wi-Fi networks were discovered over the years, these did not exploit laws in 802.11i. Instead, attacks exploited laws in Wi-Fi Protected Setup (WPS) [73], lawed drivers [13, 20], lawed random number generators [72], predictable pre-shared keys [45], insecure enterprise authentication [21], and so on. That no major weakness has been found in CCMP and the 4-way handshake, is not surpris-ing. After all, both have been formally proven as secure [39, 42]. With this in mind, one might reasonably assume the design of the 4-way handshake is indeed secure.
In spite of its history and security proofs though, we show that the 4-way handshake is vulnerable to key reinstallation attacks. Moreover, we discovered similar weaknesses in other Wi-Fi hand-shakes. That is, we also attack the PeerKey handshake, the group key handshake, and the Fast BSS Transition (FT) handshake.
The idea behind our attacks is rather trivial in hindsight, and can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh session key. It will install this key after receiving message 3 of the handshake. Once the key is installed, it will be used to encrypt normal data frames using a data-conidentiality protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it willreinstallthe same session key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the data-conidentiality protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3. By forcing nonce reuse in this manner, the data-conidentiality protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique is used to attack the group key, PeerKey, and fast BSS transition handshake.
content into unencrypted HTTP connections. If TKIP or GCMP is used, an adversary can both decrypt and inject arbitrary packets. Although GCMP is a relatively new addition to Wi-Fi, it is expected to be adopted at a high rate in the next few years [58]. Finally, when the group key handshake is attacked, an adversary can replay group-addressed frames, i.e., broadcast and multicast frames.
Our attack is especially devastating against version 2.4 and 2.5 of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the 802.11 standard that suggests to clear parts of the session key from memory once it has been installed [1, ğ12.7.6.6]. Because Android uses a modiiedwpa_supplicant, Android 6.0 and Android Wear 2.0 also contain this vulnerability. As a result, currently 31.2% of Android devices are vulnerable to this exceptionally devastating variant of our attack [33].
Interestingly, our attacks do not violate the security properties proven in formal analysis of the 4-way and group key handshake. In particular, these proofs state that the negotiated session key remains private, and that the identity of both the client and Access Point (AP) is conirmed [39]. Our attacks do not leak the session key. Additionally, although normal data frames can be forged if TKIP or GCMP is used, an attacker cannot forge EAPOL messages and hence cannot impersonate the client or AP during (subsequent) handshakes. Instead, the problem is that the proofs do not model key installation. Put diferently, their models do not state when a negotiated key should be installed. In practice, this means the same key can be installed multiple times, thereby resetting nonces and replay counters used by the data-conidentiality protocol.
To summarize, our main contributions are:
•We introduce key reinstallation attacks. Here, an attacker forces the reinstallation of an already-in-use key, thereby resetting any associated nonces and/or replay counters. •We show that the 4-way handshake, PeerKey handshake,
group key handshake, and fast BSS transition handshake are vulnerable to key reinstallation attacks.
•We devise attack techniques to carry out our attacks in prac-tice. This demonstrates that all implementations are vulner-able to some variant of our attack.
•We evaluate the practical impact of nonce reuse for all data-conidentiality protocols of 802.11.
The remainder of this paper is structured as follows. Section 2 introduces relevant aspects of the 802.11 standard. Our key reinstal-lation attack is illustrated against the 4-way and PeerKey handshake in Section 3, against the group key handshake in Section 4, and against the fast BSS transition handshake in Section 5. In Section 6 we asses the impact of our attacks, present countermeasures, ex-plain where proofs failed, and discuss lessons learned. Finally, we present related work in Section 7 and conclude in Section 8.
2
BACKGROUND
In this section we introduce the 802.11i amendment, the various messages and handshakes used when connecting to a Wi-Fi net-work, and the data-conidentiality and integrity protocols of 802.11.
2.1
The 802.11i Amendment
After researchers showed that Wired Equivalent Privacy (WEP) was fundamentally broken [30, 65], the IEEE ofered a more robust solu-tion in the 802.11i amendment of 802.11. This amendment deines the 4-way handshake (see Section 2.3), and two data-conidentiality and integrity protocols called (WPA-)TKIP and (AES-)CCMP (see Section 2.4). While the 802.11i amendment was under development, the Wi-Fi Alliance already began certifying devices based on draft version D3.0 of 802.11i. This certiication program was called Wi-Fi Protected Access (WPA). Once the inal version D9.0 of 802.11i was ratiied, the WPA2 certiication was created based on this oicially ratiied version. Because both WPA and WPA2 are based on 802.11i, they are almost identical on a technical level. The main diference is that WPA2 mandates support for the more secure CCMP, and optionally allows TKIP, while the reverse is true for WPA.
Required functionality of both WPA and WPA2, and used by all protected Wi-Fi networks, is the 4-way handshake. Even enterprise networks rely on the 4-way handshake. Hence, all protected Wi-Fi networks are afected by our attacks.
The 4-way handshake, group key handshake, and CCMP proto-col, have formally been analyzed and proven to be secure [39, 42].
2.2
Authentication and Association
When a client wants to connect to a Wi-Fi network, it starts by (mutually) authenticating and associating with the AP. In Figure 2 this is illustrated in the association stage of the handshake. However, when irst connecting to a network, no actual authentication takes places at this stage. Instead, Open System authentication is used, which allows any client to authenticate. Actual authentication will be performed during the 4-way handshake. Real authentication is only done at this stage when roaming between two APs of the same network using the fast BSS transition handshake (see Section 3).
After (open) authentication, the client associates with the net-work. This is done by sending an association request to the AP. This message contains the pairwise and group cipher suites the client wishes to use. The AP replies with an association response, informing the client whether the association was successful or not.
2.3
The 4-way Handshake
header replay counter nonce RSC MIC Key Data
encrypted
82 bytes variable
Figure 1: Simpliied layout of an EAPOL frame.
Every message in the 4-way handshake is deined using EAPOL frames. We will briely discuss the layout and most important ields of these frames (see Figure 1). First, the header deines which mes-sage in the handshake a particular EAPOL frame represents. We will use the notationmessagenandMsgNto refer to then-th message of the 4-way handshake. The replay counter ield is used to detect replayed frames. The authenticator always increments the replay counter after transmitting a frame. When the supplicant replies to an EAPOL frame of the authenticator, it uses the same replay counter as the one in the EAPOL frame it is responding to. The nonce ield transports the random nones that the supplicant and authenticator generate to derive a fresh session key. Next, in case the EAPOL frame transports a group key, the Receive Sequence Counter (RSC) contains the starting packet number of this key. The group key itself is stored in the Key Data ield, which is encrypted using the KEK. Finally, the authenticity of the frame is protected using the KCK with a Message Integrity Check (MIC).
Figure 2 illustrates the messages that are exchanged during the 4-way handshake. In it, we use the following notation:
MsgN(r, Nonce; GTK)
It represents message N of the 4-way handshake, having a replay counter ofr, and with the given nonce (if present). All parameters after the semicolon are stored in the key data ield, and hence are encrypted using the KEK (recall Figure 1).
The authenticator initiates the 4-way handshake by sending mes-sage 1. It contains the ANonce, and is the only EAPOL mesmes-sage that is not protected by a MIC. On reception of this message, the sup-plicant generates the SNonce and derives the PTK (i.e., the session key). The supplicant then sends the SNonce to the authenticator in message 2. Once the authenticator learns the SNonce, it also derives the PTK, and sends the group key (GTK) to the supplicant. Finally, to inalize the handshake, the supplicant replies with message 4 and after that installs the PTK and GTK. After receiving this message, the authenticator also installs the PTK (the GTK is installed when the AP is started). To summarize, the irst two messages are used to transport nonces, and the last two messages are used to transport the group key and to protect against downgrade attacks.
Note that in an existing connection, the PTK can be refreshed by initiating a new 4-way handshake. During this rekey, all 4-way handshake messages are encrypted by the data-conidentiality pro-tocol using the current PTK (we rely on this in Section 3.4).
2.4
Conidentiality and Integrity Protocols
The 802.11i amendment deines two data-conidentiality protocols. The irst is called the Temporal Key Integrity Protocol (TKIP). How-ever, nowadays TKIP is deprecated due to security concerns [74]. The second protocol is commonly called (AES-)CCMP, and is cur-rently the most widely-used data-conidentiality protocol [69]. In 2012, the 802.11ad amendment added a new data-conidentiality protocol called the Galios/Counter Mode Protocol (GCMP) [3]. This
Supplicant (client) Authenticator (AP)
Authentication Request
Authentication Response
(Re)Association Request
(Re)Association Response
asso
ciation
stage
optional 802.1x authentication
Msg1(r, ANonce)
Derive PTK
Msg2(r, SNonce)
Derive PTK Msg3(r+1; GTK)
Msg4(r+1)
Install PTK & GTK Install PTK
4-way
handshake
encrypted data frames can now be exchanged
Refresh GTK Encxptk{ Group1(r+2; GTK) }
Encyptk{ Group2(r+2) }
Install GTK Install GTK
gr
oup
ke
y
handshake
Figure 2: Messages exchanged when a supplicant (client) con-nects with an authenticator (AP), performs the 4-way hand-shake, and periodically executes the group key handshake.
amendment also adds support for short-range communications in the 60 GHz band, which requires a fast cipher such as GCM [3]. Right now, 802.11ad is being rolled out under the name Wireless Gigabit (WiGig), and is expected to be adopted at a high rate over the next few years [58]. Finally, the 802.11ac amendment further extends GCMP by adding support for 256-bit keys [2].
When TKIP is used, the Temporal Key (TK) part of the session key (PTK) is further split into a 128-bit encryption key, and two 64-bit Message Integrity Check (MIC) keys. The irst MIC key is used for AP-to-client communication, while the second key is used for the reverse direction. RC4 is used for encryption, with a unique per-packet key that is a mix of the 128-bit encryption key, the sender MAC address, and an incremental 48-bit nonce. This nonce is incre-mented after transmitting a frame, used as a replay counter by the receiver, and initialized to 1 when installing the TK [1, ğ12.5.2.6]. Message authenticity is provided by the Michael algorithm. Unfor-tunately, Michael is trivial to invert: given plaintext data and its MIC value, one can eiciently recover the MIC key [66, 69].
key1. In CCMP, the IV is the concatenation of the sender MAC address, a 48-bit nonce, and some additional lags derived from the transmitted frame. The nonce is also used as a replay counter by the receiver, incremented by one before sending each frame, and initialized to 0 when installing the TK [1, ğ12.5.3.4.4]. This is supposed to assure that IVs do not repeat. Additionally, this construction allows the TK to be used directly as the key for both communication directions.
The GCMP protocol is based on AES-GCM, meaning it uses counter mode for encryption, with the resulting ciphertext being authenticated using the GHASH function [28]. Similar to CCMP, it is an AEAD cipher, and secure as long as no IV is repeated under a particular key. In GCMP, the IV is the concatenation of the sender MAC address and a 48-bit nonce. The nonce is also used as a replay counter by the receiver, incremented by one before sending each frame, and initialized to 0 when installing the TK [1, ğ12.5.5.4.4]. This normally assures each IV is only used once. As with CCMP, the TK is used directly as the key for both communication direc-tions. If a nonce is ever repeated, it is possible to reconstruct the authentication key used by the GHASH function [43].
To denote that a frame is encrypted and authenticated using a data-conidentiality protocol, we use the following notation:
Encn k{·}
Herendenotes the nonce being used (and thus also the replay counter). The parameterkdenotes the key, which is the PTK (ses-sion key) for unicast traic. For group-addressed traic, i.e., broad-cast and multibroad-cast frames, this is the GTK (group key). Finally, the two notations
Data(payload) GroupData(payload)
are used to represent an ordinary unicast or group-addressed data frame, respectively, with the given payload.
2.5
The Group Key Handshake
The authenticator periodically refreshes the group key, and dis-tributes this new group key to all clients using the group key hand-shake. This handshake was proven to be secure in [39], and is illustrated in the last stage of Figure 2. The authenticator initiates the handshake by sending a group message 1 to all clients. The supplicant acknowledges the receipt of the new group key by reply-ing with group message 2. Dependreply-ing on the implementation, the authenticator installs the GTK either after sending group message 1, or after receiving a reply from all connected clients (see Section 4). Finally, group message 1 also contains the current receive replay counter of the group key in the RSC ield (see Figure 1).
Both messages in the group key handshake are deined using EAPOL frames, and are represented using Group1 and Group2 in Figure 2. Note that group message 1 stores the new group key in the Key Data ield, and hence is encrypted using the KEK (recall Figure 1). Since at this point a PTK is installed, the complete EAPOL frame is also protected using a data-conidentiality protocol.
Finally, if a client transmits a broadcast or multicast frame, she irst sends it as a unicast frame to the AP. The AP then encrypts
1Note that we deviate from oicial 802.11 terminology, where what we call the nonce
is called the packet number, and what we call the IV is called the nonce.
PTK-INIT PMK = shared master secret
PTK-START Calculate SNonce
TPTK = CalcPTK(PMK, ANonce, SNonce) Send Msg2(SNonce)
PTK-NEGOTIATING PTK = TPTK
Send Msg4()
PTK-DONE MLME-SETKEYS.request(PTK) MLME-SETKEYS.request(GTK) 802.1X::portValid = TRUE
Enter 4-way handshake stage
Msg1 Received
Msg3 Received && MIC-Veriied && !ReplayedMsg
Msg1 Received
unconditional Msg3 Received && MIC-Veriied && !ReplayedMsg Msg1 Received
Figure 3: Supplicant 4-way handshake state machine as de-ined in the 802.11 standard [1, Fig. 13-17]. Keys are installed for usage by calling the MLME-SETKEYS.request primitive.
the frame using the group key, and broadcasts it to all clients. This assures all clients within the range of the AP receive the frame.
3
ATTACKING THE 4-WAY HANDSHAKE
In this section we show that the state machine behind the 4-way handshake is vulnerable to a key reinstallation attack. We then demonstrate how to execute this attack in real-life environments.
3.1
Supplicant State Machine
The 802.11i amendment does not contain a formal state machine de-scribing how the supplicant must implement the 4-way handshake. Instead, it only provides pseudo-code that describes how, but not when, certain handshake messages should be processed [4, ğ8.5.6].2 Fortunately, 802.11r slightly extends the 4-way handshake, and does provide a detailed state machine of the supplicant [1, Fig. 13-17]. Figure 2 contains a simpliied description of this state machine.
When irst connecting to a network and starting the 4-way hand-shake, the supplicant transitions to the PTK-INIT state (see Figure 3). Here, it initializes the Pairwise Master Key (PMK). When receiving message 1, it transitions to the PTK-START stage. This may hap-pen when connecting to a network for the irst time, or when the session key is being refreshed after a previous (completed) 4-way handshake. When entering PTK-START, the supplicant generates a random SNonce, calculates the Temporary PTK (TPTK), and sends its SNonce to the authenticator using message 2. The authenticator will reply with message 3, which is accepted by the supplicant if
2Strangely, this pseudo-code is only present in the original 802.11i amendment. Later
the MIC and replay counter are valid. If so, it moves to the PTK-NEGOTIATING state, where it marks the TPTK as valid by assigning it to the PTK variable, and sends message 4 to the authenticator. Then it immediately transitions to the PTK-DONE state, where the PTK and GTK are installed for usage by the data-conidentiality protocol using the MLME-SETKEYS.request primitive. Finally, it opens the 802.1x port such that the supplicant can receive and send normal data frames. Note that the state machine explicitly takes into account retransmissions of either message 1 or 3, which occur if the authenticator did not receive message 2 or 4, respectively. These retransmissions use an incremented EAPOL replay counter. We conirmed that the state machine in 802.11r matches the orig-inal state machine, that was “deinedž in 802.11i using textual de-scriptions scattered throughout the amendment. Most importantly, we veriied two properties which we abuse in our key reinstallation attack. First, 802.11i states that the AP retransmits message 1 or 3 if it did not receive a reply [4, ğ8.5.3.5]. Therefore, the client must han-dle retransmissions of message 1 or 3, matching the state machine of 802.11r. Additionally, 802.11i states that the client should install the PTK after processing and replying to message 3 [4, ğ8.5.3.3]. This again matches the state machine given in 802.11r.
3.2
The Key Reinstallation Attack
Our key reinstallation attack is now easy to spot: because the sup-plicant still accepts retransmissions of message 3, even when it is in the PTK-DONE state, we can force a reinstallation of the PTK. More precisely, we irst establish a man-in-the-middle (MitM) posi-tion between the supplicant and authenticator. We use this MitM position to trigger retransmissions of message 3 by preventing message 4 from arriving at the authenticator. As a result, it will retransmit message 3, which causes the supplicant to reinstall an already-in-use PTK. In turn, this resets the nonce being used by the data-conidentiality protocol. Depending on which protocol is used, this allows an adversary to replay, decrypt, and/or forge packets. In Section 6.1 we will explore in detail what the practical impacts of nonce reuse are for each data-conidentiality protocol.
In practice, some complications arise when executing the attack. First, not all Wi-Fi clients properly implement the state machine. In particular, Windows and iOS do not accept retransmissions of mes-sage 3 (see Table 1 column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key rein-stallation attack against the 4-way handshake. Unfortunately, from a defenders perspective, both iOS and Windows are still vulnera-ble to our attack against the group key handshake (see Section 4). Additionally, because both OSes support 802.11r, it is still possible to indirectly attack them by performing a key reinstallation attack against the AP during an FT handshake (see Section 5).
A second minor obstacle is that we must obtain a MitM posi-tion between the client and AP. This is not possible by setting up a rouge AP with a diferent MAC address, and then forwarding packets between the real AP and client. Recall from Section 2.3 that the session key is based on the MAC addresses of the client and AP, meaning both would derive a diferent key, causing the handshake and attack to fail. Instead, we employ a channel-based MitM attack [70], where the AP is cloned on a diferent channel
Table 1: Behaviour of clients: 2nd column shows whether re-transmission of message 3 are accepted, 3rd whether plain-text EAPOL messages are accepted if a PTK is conigured, 4th whether it accepts plaintext EAPOL messages if sent im-mediately after the irst message 3, and 5th whether it is af-fected by the attack of Section 3.4. The last two columns de-note if the client is vulnerable to a key reinstallation attack against the 4-way or group key handshake, respectively.
Implementation Re
.Msg3
Pt.
EAPOL
Quick
Pt.
Quick
Ct.
4-way Gr
oup
OS X 10.9.5 ✓ ✗ ✗ ✓ ✓ ✓
macOS Sierra 10.12 ✓ ✗ ✗ ✓ ✓ ✓
iOS 10.3.1c ✗ N/A N/A N/A ✗ ✓
wpa_supplicantv2.3 ✓ ✓ ✓ ✓ ✓ ✓
wpa_supplicantv2.4-5 ✓ ✓ ✓ ✓a ✓a ✓
wpa_supplicantv2.6 ✓ ✓ ✓ ✓b ✓b ✓
Android 6.0.1 ✓ ✗ ✓ ✓a ✓a ✓
OpenBSD 6.1 (rum) ✓ ✗ ✗ ✗ ✗ ✓
OpenBSD 6.1 (iwn) ✓ ✗ ✗ ✓ ✓ ✓
Windows 7c ✗ N/A N/A N/A ✗ ✓
Windows 10c ✗ N/A N/A N/A ✗ ✓
MediaTek ✓ ✓ ✓ ✓ ✓ ✓
aDue to a bug, an all-zero TK will be installed, see Section 6.3. bOnly the group key is reinstalled in the 4-way handshake. cCertain tests are irrelevant (not applicable) because the
im-plementation does not accept retransmissions of message 3.
with the same MAC address as the targeted AP. This assures the client and AP derive the same session key.
The third obstacle is that certain implementations only accept frames protected using the data-conidentiality protocol once a PTK has been installed (see Table 1 column 3). This is problematic for our attack, because the authenticator will retransmit message 3 without encryption. This means the retransmitted message will be ignored by the supplicant. Although this would seem to foil our attack, we found a technique to bypass this problem (see Section 3.4).
reject them. However, Android phones with a diferent wireless NIC may in fact accept plaintext retransmissions of message 3.
3.3
Plaintext Retransmission of message 3
If the victim still accepts plaintext retransmissions of message 3 after installing the session key, our key reinstallation attack is straight-forward. First, the adversary uses a channel-based MitM attack so she can manipulate handshake messages [70]. Then she blocks message 4 from arriving at the authenticator. This is illustrated in stage 1 of Figure 4. Immediately after sending message 4, the victim will install the PTK and GTK. At this point the victim also opens the 802.1x port, and starts transmitting normal data frames (recall Section 2.3). Notice that the irst data frame uses a nonce value of 1 in the data-conidentiality protocol. Then, in the third stage of the attack, the authenticator retransmits message 3 because it did not receive message 4. The adversary forwards the retransmit-ted message 3 to the victim, causing it to reinstall the PTK and GTK. As a result, it resets the nonce and replay counter used by the data-conidentiality protocol. Note that the adversary cannot replay an old message 3, because its EAPOL replay counter is no longer fresh. We ignore stage 4 of the attack for now. Finally, when the victim transmits its next data frame, the data-conidentiality pro-tocol reuses nonces. Note that an adversary can wait an arbitrary amount of time before forward the retransmitted message 3 to the victim. Therefore, we can control the amount of nonces that will be reused. Moreover, an adversary can always perform the attack again by deauthenticating the client, after which it will reconnect with the network and execute a new 4-way handshake.
Figure 4 also shows that our key reinstallation attack occurs spontaneously if message 4 is lost due to background noise. Put diferently, clients that accept plaintext retransmissions of mes-sage 3, may already be reusing nonces without an adversary even being present. Inspired by this observation, an adversary could also selectively jam message 4 [70], resulting in a stealthy attack that is indistinguishable from random background interference.
We now return to stage 4 of the attack. The goal of this stage is to complete the handshake at the authenticator side. This is not trivial because the victim already installed the PTK, meaning its last message 4 is encrypted.3And since the authenticator did not yet install the PTK, it will normally reject this encrypted message 4.4 However, a careful inspection of the 802.11 standard reveals that the authenticator may acceptanyreplay counter that was used in the 4-way handshake, not only the latest one [1, ğ12.7.6.5]:
“On reception of message 4, the Authenticator veriies that the Key Replay Counter ield value is one that it used on this 4-way handshake.ž
In practice, we found that several APs indeed accept an older replay counter. More precisely, some APs accept replay counters that were used in a message to the client, but were not yet used in a reply from the client (see column 2 in Table 2 on page 8). These APs will accept the older unencrypted message 4, which has the replay
3The 802.11 standard says that a retransmitted message 4 must be sent in plaintext in
the initial 4-way handshake [1, ğ12.7.6.5], but nearly all clients send it using encryption.
4Similar to ixes in [63, 64], a non-standard implementation may already install the
PTK for reception-only after sending message 3. We found no AP doing this though.
Supplicant (victim) Adversary (MitM) Authenticator
Msg1(r, ANonce) Msg1(r, ANonce)
Msg2(r, SNonce) Msg2(r, SNonce)
Msg3(r+1; GTK) Msg3(r+1; GTK)
Msg4(r+1) 1
○
Install PTK & GTK
Enc1ptk{ Data(. . . ) } 2
○
Msg3(r+2; GTK) Msg3(r+2; GTK)
Enc2ptk{ Msg4(r+2) }
Reinstall PTK & GTK 3
○
Enc2ptk{ Msg4(r+2) }
Msg4(r+1)
Install PTK ? 4
○
next transmitted frame(s) will reuse nonces
Enc1ptk{ Data(. . . ) } Enc1ptk{ Data(. . . ) } 5
○
Figure 4: Key reinstallation attack against the 4-way hand-shake, when the supplicant (victim) still accepts plaintext retransmissions of message 3 if a PTK is installed.
counterr+1 in Figure 4. As a result, these AP will install the PTK, and will start sending encrypted unicast data frames to the client. Although Figure 4 only illustrates nonce reuse in frames sent by the client, our attack also enables us to replay frames. First, after the client reinstalls the GTK in stage 3 of the attack, broadcast and multicast frames that the AP sent after retransmitting message 3 can be replayed. This is because replay counters are also reset when reinstalling a key. Second, if we can make the AP install the PTK, we can also replay unicast frames sent from the AP to the client.
We conirmed that the attack shown in Figure 4 works against MediaTek’s implementation of the Wi-Fi client, and against certain versions ofwpa_supplicant(see Section 6.3). How we attacked other implementations is explained in the next section.
3.4
Encrypted Retransmission of message 3
We now describe how we can attack clients that, once they installed the PTK, only accept encrypted retransmissions of message 3. To accomplish this, we exploit an inherent race condition between the entity executing the 4-way handshake, and the entity implementing the data-conidentiality protocol.
Main CPU Wireless NIC Adversary (MitM) Supplicant (victim)
Msg1(r, ANonce) Msg1(r, ANonce)
Msg2(r, SNonce) Msg2(r, SNonce) 1
○
Msg3(r+1; GTK)
Msg3(r+2; GTK) Msg3(r+1; GTK)
Msg3(r+2; GTK) 2
○
Msg4(r+1)
Msg4(r+1) Install-keys command
Install PTK & GTK 3
○
Msg4(r+2)
Enc1ptk{ Msg4(r+2) } Install-keys command
Reinstall PTK & GTK 4
○
next transmitted frame will reuse nonce 1
Data(. . . ) Enc1
ptk{ Data(. . . ) }
5 ○
Figure 5: Key reinstallation attack against the 4-way hand-shake, when the victim accepts a plaintext message 3 re-transmission if sent instantly after the irst one. We assume encryption and decryption is ofloaded to the wireless NIC.
this happens, and how it can be exploited. Note that the AP is not drawn in this igure: its actions are clear from context. In our attack, we irst let the client and AP exchange Message 1 and 2. However, we do not forward the irst message 3 to the client. Instead we wait until the AP retransmits a second message 3. In stage two of the attack, we send both message 3’s instantly after one another to the client. The wireless NIC, which implements the data-conidentiality protocol, does not have a PTK installed, and hence forwards both messages to the packet receive queue of the main CPU. The main CPU, which implements the 4-way handshake, replies to the irst message 3 and commands the wireless NIC to install the PTK. In stage 4 of the attack, the main CPU of the client grabs the second message 3 from its receive queue. Although it notices the frame was not encrypted, Android and Linux allow unencrypted EAPOL frames as an exception, and therefore the main CPU will process the retransmitted message 3. Because the NIC has just installed the PTK, the reply will be encrypted with a nonce value of 1. After this, it commands the wireless NIC to reinstall the PTK. By doing this, the NIC resets the nonce and replay counter associated to the PTK, meaning the next transmitted data frame will reuse nonce 1.
Main CPU Wireless NIC Adversary (MitM) Supplicant (vitcim)
initial 4-way or FT handshake
Install PTK & GTK 1
○
pairwise rekey in progress
Encxptk{ Msg3(r+1; GTK) }
Encx+1
ptk{ Msg3(r+2; GTK) }
Msg3(r+1; GTK)
Msg3(r+2; GTK) 2
○
Msg4(r+1) Ency
ptk{ Msg4(r+1) }
Install-keys command
Install PTK′& GTK 3
○
Msg4(r+2) Enc1
ptk′{ Msg4(r+2) }
Install-keys command
Reinstall PTK′& GTK 4
○
next transmitted frame will reuse nonce 1
Data(. . . ) Enc1
ptk′{ Data(. . . ) }
5 ○
Figure 6: Key reinstallation attack against the 4-way hand-shake, when the victim only accepts encrypted message 3 retransmissions once a PTK is installed. We assume encryp-tion and decrypencryp-tion is ofloaded to the wireless NIC.
We now show how to attack OpenBSD, OS X, and macOS (see Table 1 column 5). These devices only accept encrypted retransmis-sions of message 3. Similar to the Android attack, we abuse race conditions between the wireless NIC and main CPU. However, we now target a 4-way handshake execution that refreshes (rekeys) the PTK. Recall from Section 2.3 that all messages transmitted during a rekey undergo encryption by the data-conidentiality protocol.
both messages using the current PTK, and forwards them to the packet receive queue of the main CPU. In the third stage of the attack, the main CPU of the victim processes the irst message 3, replies to it, and commands the NIC to install the new PTK. In the fourth stage, the main CPU picks the second message 3 from the receive queue. Since a PTK is installed, OpenBSD, OS X, and macOS (here called the main CPU) will mandate that the message was encrypted. However, they do not check under which key the message was encrypted. As a result, even though the message was decrypted under the old PTK, the main CPU will process it. The message 4 sent as a reply is now encrypted under the new PTK using a nonce value of 1. After this, the main CPU commands the NIC to reinstall the PTK, thereby resetting the nonce and replay counters. Finally, the next data frame that the victim transmits will again be encrypted using the new PTK with a nonce of 1. We conirmed this attack against OpenBSD 6.1, OS X 10.9.5, and macOS Sierra 10.12.
OpenBSD is only vulnerable if encryption is oloaded to the wire-less NIC. For example, theiwndriver and associated devices support hardware encryption, and therefore are vulnerable. However, the rumdriver performs software encryption in the same entity as the 4-way handshake, and is not vulnerable (see Table 1 column 5).
This attack technique requires us to wait until a rekey of the session key occurs. Several APs do this every hour [66], some exam-ples being [24, 26]. In practice, clients can also request a rekey by sending an EAPOL frame to the AP with theRequestandPairwise bits set. Coincidently, Broadcom routers do not verify the authentic-ity (MIC) of this frame, meaning an adversary can force Broadcom APs into starting a rekey handshake. All combined, we can assume a rekey will eventually occur, meaning an adversary can carry out the key reinstallation attack.
3.5
Attacking the PeerKey Handshake
The PeerKey handshake is related to the 4-way handshake, and used when two clients want to communicate with each other di-rectly in a secure manner. It consists of two phases [1, ğ12.7.8]. In the irst phase, a Station-To-Station Link (STSL) Master Key (SMK) handshake is performed. It negotiates a shared master secret be-tween both clients. In the second phase, a fresh session key is derived from this master key using the STSL Transient Key (STK) handshake. Although this protocol does not appear to be widely supported [49], it forms a good test case to gauge how applicable our key reinstallation technique is.
Unsurprisingly, the SKM handshake is not afected by our key reinstallation attack. After all, the master key negotiated in this handshake is not used by a data-conidentiality protocol, meaning there are no nonces or replay counters to reset. However, the STK handshake is based on the 4-way handshake, and it does install a key for use by a data-conidentiality protocol. As a result, it can be attacked in precisely the same manner as the 4-way handshake. The resulting attack was tested againstwpa_supplicant. To carry out the test, we modiied anotherwpa_supplicantinstance to send a second (retransmitted) message 3. This conirmed that an unmod-iiedwpa_supplicantwill reinstall the STK key when receiving a retransmitted message 3 of the STK handshake. However, we did
Table 2: Behaviour of Access Points. The 2nd column shows whether it accepts replay counters it used in a message to the client, but did not yet receive in a reply, or if it only accepts the latest used counter. Column 3 shows whether the GTK is installed immediately after sending group message 1, or if this is delayed until all clients replied with group message 2.
Implementation Replay Check GTK Install Time
802.11 standard not yet received delayed
Broadcom latest only immediate
Hostapd not yet received delayed
OpenBSD latest only delayed
MediaTek latest only immediate
Aironet (Cisco) latest only immediate Aerohive not yet received delayed Ubiquiti not yet received delayed macOS Sierra 10.12 latest onlya immediate Windows 7 latest only The group key is
never refreshed Windows 10 latest only
aRetransmitted handshake messages do not use a new
re-play counter, so at all times there is only one allowed value.
not ind other devices that support PeerKey. As a result, the impact of our attack against the PeerKey handshake is rather low.
4
BREAKING THE GROUP KEY HANDSHAKE
In this section we apply our key reinstallation technique against the group key handshake. We show all Wi-Fi clients are vulnerable to it, enabling an adversary to replay broadcast and multicast frames.
4.1
Details of the Group Key Handshake
Networks periodically fresh the group key, to assure that only re-cently authorized clients posses this key. In the most defensive case, the group key is renewed whenever a client leaves the network. The new group key is distributed using a group key handshake, and this handshake has been formally proven as secure in [39]. As shown in Figure 2, the handshake is initiated by the AP when it sends a group message 1 to all clients. The AP retransmits this message if it did not receive an appropriate reply. Note that the EAPOL replay counter of these retransmitted messages is always incremented by one. In our attack, the goal is to collect a retransmitted group message 1, block it from arriving at the client, and forward it to the client at a later point in the time. This will trick to client into reinitializing the replay counter of the installed group key.
The second prerequisite is that we must be able to collect a group message 1 that the client (still) accepts, and that contains a group key that is already in use by the AP. How to achieve this depends on when the AP starts using the new group key. In particular, the AP may start using the new group key immediately after sending the irst group message 1, or it may delay the installation of the group key until all clients replied using group message 2. Table 2, column 3, summarizes this behaviour for several APs. Note that according to the standard, the new group key should be installed after all stations replied with a group message 2, i.e., the GTK should be installed in a delayed fashion [1, Fig. 12-53]. When the AP immediately installs the group key, our key reinstallation attack is straightforward. However, if the AP installs the group key in a delayed fashion, our attack becomes more intricate. We will discuss both these cases in more detail in Section 4.2 and 4.3, respectively. Recall from Section 2.3 that only the AP will transmit real broad-cast and multibroad-cast frames (i.e., group frames) which are encrypted using the group key. Since our key reinstallation attack targets the client, this means we cannot force nonce reusing during encryption. However, the client resets the replay counter when reinstalling the group key, which can be abused to replay frames towards clients. Most APs refresh the group key every hour. Some networks even refresh this key whenever a client leaves the network. Additionally, clients can trigger a group key handshake by sending an EAPOL frame having the lagsRequestandGroup[1, ğ12.7.7.1]. Again, Broadcom routers do not verify the authenticity of this message, meaning an attacker can forge it to trigger a group key update. All combined, we can assume most networks will eventually execute a group key update, which we can subsequently attack.
4.2
Attacking Immediate Key Installation
Figure 7 illustrates our key reinstallation attack when the AP imme-diately installs the group key after sending group message 1 to all clients. Notice that the group key handshakes messages themselves are encrypted using the data-conidentiality algorithm under the current PTK. On receipt of group message 1, the client installs the new GTK, and replies with group message 2. The adversary blocks this message from arriving at the AP. Hence, the AP will retransmit a new group message 1 in stage 2 of the attack. We now wait until a broadcast data frame is transmitted, and forward it to the victim. After this, we forward the retransmitted group message 1 from stage 2 to the victim. As a result, the victim will reinstall the GTK, and will thereby reinitialize its associated replay counter. This al-lows us to replay the broadcast data frame (see stage 5). The client accepts this frame because its replay counter was reinitialized.
It is essential that the broadcast frame we replay is sent before the retransmission of group message 1. This is because group message 1 contains the group key’s current value of the replay counter (recall Section 2.5). Therefore, if it is sent after the broadcast frame, it would contain the updated replay counter and therefore cannot be abused to reinitialize the replay counter of the victim.
We conirmed this attack in practice for APs that immediately install the group key after sending group message 1 (see Table 2 col-umn 3). Based on our experiments, all Wi-Fi clients are vulnerable to this attack when connected to an AP behaving in this manner.
Supplicant (victim) Adversary (MitM) Authenticator
initial 4-way or FT handshake
Refresh GTK
Encxptk{ Group1(r; GTK) } Encxptk{ Group1(r; GTK) }
Install GTK Install GTK
Encyptk{ Group2(r) } 1
○
Encx+1
ptk{ Group1(r+1; GTK) }
2 ○
Enc1gtk{ GroupData(. . . ) } Enc1gtk{ GroupData(. . . ) }
3 ○
Encx+1
ptk{ Group1(r+1; GTK) }
Reinstall GTK 4
○
Enc1gtk{ GroupData(. . . ) } 5
○
Figure 7: Key reinstallation attack against the group key handshake, when the authenticator (AP) immediately in-stalls the GTK after sending a Group Message 1 to all clients.
4.3
Attacking Delayed Key Installation
Attacking the group key handshake when the AP installs the GTK in a delayed fashion is more tedious. Note that the previous attack would fail because the broadcast frame transmitted in stage 3 of Figure 7 would still be encrypted under the old group key. Indeed, at this point the AP did not yet receive group message 2 from the client, meaning it is still using the old group key. This is problematic because group message 1 (re)installs the new group key, and hence cannot be abused to reset the replay counter of the old group key. One way to deal with this problem is illustrated in Figure 8. The irst two stages of this attack are similar to the previous one. That is, the AP generates a new group key, transports it to the victim, and the adversary blocks group message 2 from arriving at the AP. This makes the AP retransmit group message 1 using an incremented EAPOL replay counter ofr+1. In stage 3 of the attack, however, we forward the older group message 2 with replay counter valuer to the AP. Interestingly, the AP should accept this message even though it does not use the latest replay counter value [1, ğ12.7.7.3]:
On reception of [group] message 2, the AP veriies that the Key Replay Counter ield value matches one it has used in the group key handshake.
Supplicant (victim) Adversary (MitM) Authenticator
initial 4-way or FT handshake
Refresh GTK
Encxptk{ Group1(r; GTK) } Encxptk{ Group1(r; GTK) }
Install GTK 1
○
Encyptk{ Group2(r) }
Encx+1
ptk{ Group1(r+1; GTK) }
2 ○
Encyptk{ Group2(r) }
Install GTK 3
○
Enc1gtk{ GroupData(. . . ) } Enc1gtk{ GroupData(. . . ) }
4 ○
Encx+1
ptk{ Group1(r+1; GTK) }
Reinstall GTK 5
○
Enc1gtk{ GroupData(. . . ) } 6
○
Figure 8: Key reinstallation against the group key hand-shake, when the AP installs the GTK after accepting replies with a non-yet-received replay counter from all clients.
new group key. From this point on, the attack proceeds in a similar fashion as the previous one. That is, we wait until a broadcast frame is transmitted, perform the group key reinstallation in stage 5 of the attack, and then replay the broadcast frame in stage 6.
Again it is essential that the broadcast frame we want to replay is sent before the retransmission of group message 1. Otherwise it includes the updated replay counter of the group key.
We tested this attack against APs that install the GTK in a delayed fashion, and that accept replay counters it has used in a message to the client, but did not yet receive in a reply (recall Table 2 column 2). Note that we already know that all Wi-Fi clients reset the replay counter when reinstalling a GTK, and hence are all vulnerable. Finally, an OpenBSD AP is not vulnerable because it installs the GTK in a delayed fashion, and only accepts the latest replay counter.
5
ATTACKING THE 802.11R FT HANDSHAKE
In this section we introduce the Fast BSS Transition (FT) handshake, and show that implementations of it are also afected by our key reinstallation attack.
5.1
The Fast BSS Transition (FT) Handshake
Amendment 802.11r added the Fast Basic Service Set (BSS) Transi-tion (FT) handshake to 802.11 [5]. Its goal is to reduce the roaming time when a client moves from one AP, to another one of the same protected network (i.e. of the same Basic Service Set). Traditionally,
this required a handshake that includes a new 802.1x and 4-way handshake (recall Figure 2). However, because the FT handshake relies on master keys derived during a previous connection with the network, a new 802.1x handshake is not required. Additionally, it embeds the 4-way handshake stage in the authentication and reassociation frames.
A normal FT handshake is shown in stage 1 of Figure 9. Observe that unlike the 4-way handshake, the FT handshake is initiated by the supplicant. The irst two messages are an Authentication Request (AuthReq), and an Authentication Response (AuthResp). They are functionality equivalent to Message 1 and 2 of the 4-way handshake, respectively, and carry randomly generated nonces that will be used to derive a fresh session key. After this, the client sends a Reassociation Request (ReassoReq), and the AP replies with a Reassociaton Response (ReassoResp). They are similar in functionality to Message 3 and 4 of the 4-way handshake, inalize the FT handshake, and transport the GTK to the client.
Only the two reassociation messages are authenticated using a MIC (see Figure 9). Additionally, none of the messages in the FT handshake contain a replay counter. Instead, the FT handshake re-lies on the random SNonce and ANonce to provide replay protection between diferent invocations of the handshake [1, ğ13.5.2].
According to the standard, the PTK must be installed after the authentication response is sent or received [1, ğ13.9]. This is illus-trated by the gray boxes in stage 1 of Figure 9. Additionally, the 802.1x logical port is only opened after sending or receiving the reas-sociation request. This assures that, even though the PTK is already installed while the handshake is still in progress, the AP and client only transmit and accept data frames once the handshake com-pleted. Combined, this implies that the FT handshake, as deined in the 802.11r amendment, is not vulnerable to a key reinstallation attack. However, through experiments and code inspections, we found that most implementations actually install the PTK, as well as the GTK, after sending or receiving the reassociation response. This behaviour is illustrated by the black boxes in stage 1 of Figure 9. As a result, in practice most implementations of the FT handshakeare vulnerable to a key reinstallation attack.
5.2
A Key Reinstallation Attack against the AP
Since the AP installs the PTK in response to a reassociation request, our goal will be to replay this frame. We remark that, in practice, APs must accept retransmissions of reassociation requests. This is because the reassociation response of the AP may be lost due to background noise, making the client send a new request.
Supplicant (client) Adversary Authenticator (victim)
AuthReq(SNonce)
AuthResp(ANonce, SNonce)
Install PTK ? Install PTK ?
ReassoReq(ANonce, SNonce, MIC)
ReassoResp(ANonce, SNonce, MIC; GTK)
Install PTK & GTK Install PTK
1 ○
Enc1ptk{ Data(. . . ) } 2
○
ReassoResp(A/Snonce, MIC; GTK)
ReassoResp(ANonce, SNonce, MIC; GTK)
Reinstall PTK 3
○
next transmitted frame(s) will reuse nonces
Enc1ptk{ Data(. . . ) } 4
○
Figure 9: Key reinstallation attack against the Fast BSS Tran-sition (FT) handshake. Note that a MitM poTran-sition is not re-quired, only the ability to eavesdrop and replay frames.
reinstallation attacks, this also enables an attacker to replay old data frames sent by the client to the AP. We remark that our attack is particularly devastating against the FT handshake because its messages do not contain replay counters. This enables an adver-sary to replay the reassociation request continuously, each time resetting both the nonce and replay counter used by the AP.
We tested this attack against all our three APs supporting 802.11r. The irst is the open sourcehostapdimplementation, the second is MediaTek’s implementation for home routers running on a Linksys RE7000, and the third is a professional Aerohive AP. All three were vulnerable to the above key reinstallation attack.
Note that if the reassociation response is lost due to background noise, the client will retransmit the reassociation request sponta-neously, causing the AP to reinstall the key. That is, without an adversary being present, APs may already be reusing nonces.
Note that messages in the FT handshake never undergo (addi-tional) protection using a data-conidentiality protocol. In particular, Management Frame Protection (MFP) does not protect authentica-tion and reassociaauthentica-tion frames [1, ğ12.6.19]. Hence, key reinstallaauthentica-tion attacks against the FT handshake are trivial even if MFP is enabled.
5.3
Abusing BSS Transition Requests
An FT handshake is only performed when a station roams from one AP to another. This limits when an attack can take place. However, we can force a victim to perform an FT handshake as follows. First, assume a client is connected to an AP of a network that supports
802.11r. Then, if no other AP of this network is within range of the client, we clone a real AP of this network next to the client using a wormhole attack [41]. This makes the client think another AP of the targeted network is nearby. Finally, we send a BSS Tran-sition Management Request to the client. This frame is used for load balancing [1, 11.24.7] and commands the client to roam to another AP. It is an unauthenticated management frame, and hence can be forged by an adversary. Consequently, the client accepts this frame, and roams to the (wormholed) AP using an FT handshake. We tested this against clients supporting 802.11r. This conirmed thatwpa_supplicant, iOS [8], and Windows 10 [52] accept the transition request, and roam to another AP using an FT handshake.
6
EVALUATION AND DISCUSSION
In this section we evaluate the impact of nonce reuse for the data-conidentiality protocols of 802.11, present example attack scenar-ios, discuss implementation speciic vulnerabilities, explain why security proofs missed our attacks, and present countermeasures.
6.1
Impact of Nonce Reuse in 802.11
The precise impact of nonce reuse caused by our attacks depends on the data-conidentiality protocol being used. Recall that this can be either TKIP, CCMP, or GCMP. All three protocol use a stream cipher to encrypt frames. Therefore, reuse of a nonce always implies reuse of the keystream. This can be used to decrypt packets. We remark that in our attack the replay counter of the victim is also reseted. Therefore, all three protocols are also vulnerable to replay attacks. When TKIP is used, we can also recover the MIC key as follows. First, we abuse nonce reuse to decrypt a full TKIP packet, including its MIC ield. Then we attack the weak Michael algorithm: given the plaintext frame and its decrypted MIC value, we can recover the MIC key [66]. Because TKIP uses a diferent MIC key for each communication direction (recall Section 2.4), this allows us to forge frames in one speciic direction. The origin of this direction is the device targeted by the key reinstallation attack. Table 3 summarizes this under the rows mentioning TKIP.
When CCMP is used, practical attacks are restricted to replay and decryption of packets. Although there is some work that discusses message forging attacks when nonces are repeated, the attacks are theoretic and cannot be used to forge arbitrary messages [31].
Table 3: Impact of our key reinstallation attack against the 4-way, FT, and group key handshake, in function of the data-conidentiality protocol used. Each cell shows in which di-rection frames can be replayed, decrypted, or forged.
Replayc Decrypta Forge
4-way impact
TKIP AP→client client→AP client→APb CCMP AP→client client→AP
GCMP AP→client client→AP client↔APb FT impact
TKIP client→AP AP→client AP→client CCMP client→AP AP→client
GCMP client→AP AP→client AP↔clientb Group impact
any AP→clientc
aWith this ability, we can hijack TCP connections to/from an
Internet endpoint and inject data into them.
bWith this ability, we can use the AP as a gateway to inject packets
towardsanydevice connected to the network.
cThis denotes in which direction we can replay unicast and
addressed frames. For the group key handshake, only group-addressed frames can be replayed.
forge packets in the reverse directions. Table 3 in the Appendix summarizes this, taking into account the handshake being attacked. Finally, in various cases we can forge messages from the client towards the AP (see Table 3). Interestingly, the AP is generally not the inal destination of a frame, and instead will forward the frame to its real destination. This means we can forge packets towards any device connected to the network. Depending on the AP, it is even possible to send a frame that is relected back to the client.
6.2
Example Attack Scenarios
Among other things, our key reinstallation attacks allow an ad-versary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data [37]. This enables one of the most common attacks over Wi-Fi networks: injecting malicious data into an unencrypted HTTP connection.
The ability to replay broadcast and multicast frames, i.e., group frames, is also a clear security violation. To illustrate how this could impact real systems, consider the Network Time Protocol (NTP) operating in broadcast mode. In this mode, the client irst goes through an initialization process, and then synchronizes its clock by listening to authenticated broadcast NTP packets [53]. Malho-tra and Goldberg have shown that if these broadcast frames are replayed, victims get stuck at a particular time forever [48]. Using our group key attack, we can replay these frames even if they are sent over a protected Wi-Fi network. Note that manipulating the time in this manner undermines the security of, for example, TLS certiicates [44, 54, 61], DNSSEC [47], Kerberos authentication [47], and bitcoin [25]. Another example is the xAP and xPL home au-tomation protocol. These generally use broadcast UDP packets to
send commands to devices [40]. We conjecture that our key rein-stallation attack allows us to replay these commands. All combined, these examples illustrate that the impact of replaying broadcast or multicast frames should not be underestimated.
6.3
All-Zero Encryption Key Vulnerability
Our key reinstallation attack against the 4-way handshake uncov-ered special behavior inwpa_supplicant. First, version 2.3 and lower are vulnerable to our attacks without unexpected side-efects. However, we found that version 2.4 and 2.5 install an all-zero en-cryption key (TK) when receiving a retransmitted message 3. This vulnerability appears to be caused by a remark in the 802.11 stan-dard that indirectly suggests to clear the TK from memory once it has been installed [1, ğ12.7.6.6]. Version 2.6 ixed this bug by only installing the TK when receiving message 3 for the irst 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 ofwpa_supplicantreinstall 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 modiied version of wpa_supplicant, it is also afected by these attacks. In particu-lar, we inspected the oicial source code repository of Android’s 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 diferentwpa_supplicantversion 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]. Finally, we also empirically conirmed that Chromium is vulnerable to the all-zero encryption key vulnerability [68].
6.4
Limitations of the Security Proofs
Interestingly, our attacks do not violate the security properties proven in formal analysis of the 4-way and group key handshake. First, He et al. proved that the 4-way handshake provides key secrecy and session authentication [39]. Key secrecy states that only the authenticator and supplicant will posses the PTK. Since we do not recover the PTK, this properly still holds. Session au-thentication was proven using the standard notion of matching conversations [39]. Intuitively, this says a protocol is secure if the only way that an adversary can get a party to complete the proto-col is by faithfully relaying messages [12]. Our attacks, including the channel-based MitM position we employ, do not violate this property: we can only make endpoints complete the handshake by forwarding (retransmitted) messages.
However, the proofs do not model key installation. Put diferently, they do not state when the key is installed for use by the data-conidentiality protocol. In practice, this means the same key can be installed multiple times, thereby resetting associated nonces and/or replay counters used by the data-conidentiality protocol.
6.5
Countermeasures
Key reinstallation attacks can be mitigated at two layers. First, the entity implementing the data-conidentiality protocol should check whether an already-in-use key is being installed. If so, it should not reset associated nonces and replay counters. This prevents our attacks, at least if an adversary cannot temporarily trick an imple-mentation into installing a diferent (old) key before reinstalling the current one. In particular, when using this countermeasure it is essential that the replay counter of received group key handshake messages only increases. Otherwise, an adversary can use an old group message 1 to make a victim temporarily install an old (difer-ent) key, to subsequently reinstall the current group key using a more recent group message 1.
A second solution is to assure that a particular key is only in-stalled once into the entity implementing the data-conidentiality protocol during a handshake execution. For example, the generated session key in a 4-way handshake should only be installed once. When the client receives a retransmitted message 3, it should reply, but not reinstall the session key. This can be accomplished by adding a boolean variable to the state machine of Figure 3. It is initialized to false, and set to true when generating a fresh PTK in PTK-START. If the boolean is true when entering PTK-DONE, the PTK is installed and the boolean is set to false. If the boolean is false when entering PTK-DONE, installation of the PTK is skipped. Note that this is precisely what version 2.6 and higher ofwpa_supplicantis doing.
Proving the correctness of the above countermeasure is straight-forward: we modeled the modiied state machine in NuSMV [23], and used this model to prove that two key installations are always separated by the generation of a fresh PTK. This implies the same key is never installed twice. Note that key secrecy and session authentication was already proven in other works [39].
We are currently notifying vendors about the vulnerabilities we discovered, such that they can implement these countermeasures. A full list of vendors that are known to be afected by some variant of our attacks will be made available at [22].
6.6
Discussion
There are some important lessons that can be learned from our results. First, the speciication of a protocol should be suiciently precise and explicit. For example, when attacking the 4-way hand-shake in Section 3.3, we observed that the 802.11 standard is am-biguous as to which replay counter values should be accepted. A more precise or formal speciication would avoid any such potential incorrect interpretations.
Second, it is not because a protocol has been formally proven secure, that implementations of it are also secure. In our case, the model of the 4-way handshake used in formal proofs did not fully relect reality. This is because it did not deine when the negotiated session key should be installed. As a result, there was no guarantee that a session key is installed just once. Only by reading real code
did we realize the formal model did not match reality, and that keys may be reinstalled. In this regard, formal proofs may in fact be coun-terproductive: once a protocol is formally veriied, the community may become less interested in auditing actual implementations.
Interestingly, the observation that a model may be wrong, and therefore does not accurately relect reality, also applies to the proof of our own countermeasure. Put diferently, it is not because we modeled the countermeasure in NuSMV, that all implementations are now suddenly secure. In reality, our formal state machine may not accurately relect certain implementations, patches of vendors may be lawed, or a vendor may be afected by as-of-yet unknown variants of the attack. As a result, it is critical to keep auditing and testing actual implementations.
Another lesson is that the data-conidentiality protocol should provide some protection against nonce reuse. For example, with GCMP the authentication key can be recovered in case of nonce recuse, while this is not so for CCMP. More generally, a nonce misuse-resistant encryption scheme should be used, examples being AES-SIV, GCM-SIV, or HS1-SIV [16]. These reduce the impact of nonce reuse, and hence also the impact of key reinstallation attacks.
7
RELATED WORK
In this section we explore the history of key reinstallation attacks, and give an overview of other Wi-Fi and protocol security works.
7.1
Key Reinstallation Attacks
We are not aware of prior work on key reinstallation attacks. This lack of prior work is likely one of the reasons why the cryptographic Wi-Fi handshakes we investigated were still vulnerable to these attacks. For example, only now did we discover that the 14-year-old 4-way handshake is vulnerable to key reinstallation attacks. Moreover, this law is not just present in implementations, but in the protocol speciication (standard) itself.
One somewhat related scenario that also leads to nonce reuse are power failures. Here, after a power failure, the key is restored from non-violate memory on boot, but the nonce will be reset to its initial value. Suggested solutions to this problem are given by Zenner [76]. However, unlike key reinstallation attacks, triggering power failures cannot be done remotely over a network. Instead, this requires physical access to the device being attacked. Moreover, power failures do not afect the security of the protocols we studied, since these handshakes are precisely used to avoid maintaining state between old and new connections.
In [16], Bock et al. discovered that some TLS servers were using static nonces. This was caused by a faulty implementation of the TLS record layer protocol. That is, it was not caused by a reinstallation of an already-in-use key. Additionally, some servers used randomly generated nonces, which means in practice nonce reuse is likely to occur due to the birthday paradox. In contrast, key reinstallation attacks allow an adversary to force nonce reuse on demand by replaying handshake message(s), and are caused by laws in the speciication (or implementation) of the handshake protocol.
