Mathy Vanhoef
imec-DistriNet, KU Leuven
[email protected]
Frank Piessens
imec-DistriNet, KU Leuven
[email protected]
ABSTRACT
We introduce the key reinstallation attack. This attack abuses design
or implementation flaws 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 affected by the attack.
All protected Wi-Fi networks use the 4-way handshake to generate
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 reinstallation
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 parameters
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-confidentiality protocol
in use. Simplified, 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 WPATKIP
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 affected.
Finally, we confirmed our findings 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 defined 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 profit or commercial advantage and that copies bear this notice and the full citation
on the first 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 specific permission
and/or a fee. Request permissions from [email protected].
CCS’17, October 30–November 3, 2017, Dallas, TX, USA.
© 2017 Copyright held by the owner/author(s). Publication rights licensed to Association
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 flaws in the 4-way handshake, and in
related handshakes. Becausewe target these handshakes, bothWPAand
WPA2-certified products are affected by our attacks.
The 4-way handshake provides mutual authentication and session
key agreement. Together with (AES)-CCMP, a data-confidentiality
and integrity protocol, it forms the foundation of the 802.11i
amendment. Since its first 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-confidentiality protocol
was designed as a short-term solution to the broken WEP
protocol. In other words, TKIP was never intended to be a longterm
secure solution. Additionally, while several attacks against
protected Wi-Fi networks were discovered over the years, these did
not exploit flaws in 802.11i. Instead, attacks exploited flaws in Wi-Fi
Protected Setup (WPS) [73], flawed drivers [13, 20], flawed 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 surprising.
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 handshakes.
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-confidentiality 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 will reinstall the same session key, and
thereby reset the incremental transmit packet number (nonce) and
receive replay counter used by the data-confidentiality 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-confidentiality 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.
When the 4-way or fast BSS transition handshake is attacked,
the precise impact depends on the data-confidentiality protocol
being used. If CCMP is used, arbitrary packets can be decrypted.
In turn, this can be used to decrypt TCP SYN packets, and hijack
TCP connections. For example, an adversary can inject malicious
CCS’17, October 30–November 3, 2017, Dallas, TX, USA. Mathy Vanhoef and Frank Piessens
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 modified wpa_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 confirmed [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 differently, 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-confidentiality 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 practice.
This demonstrates that all implementations are vulnerable
to some variant of our attack.
• We evaluate the practical impact of nonce reuse for all dataconfidentiality
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 reinstallation
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, explain
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 network,
and the data-confidentiality 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 offered a more robust solution
in the 802.11i amendment of 802.11. This amendment defines
the 4-way handshake (see Section 2.3), and two data-confidentiality
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 certification program was called Wi-Fi
Protected Access (WPA). Once the final version D9.0 of 802.11i was
ratified, the WPA2 certification was created based on this officially
ratified version. Because both WPA and WPA2 are based on 802.11i,
they are almost identical on a technical level. The main difference
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 affected by our attacks.
The 4-way handshake, group key handshake, and CCMP protocol,
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 first 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 network.
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
The 4-way handshake provides mutual authentication based on a
shared secret called the Pairwise Master Key (PMK), and negotiates
a fresh session key called the Pairwise Transient Key (PTK). During
this handshake, the client is called the supplicant, and the AP is
called the authenticator (we use these terms as synonyms). The
PMK is derived from a pre-shared password in a personal network,
and is negotiated using an 802.1x authentication stage in an enterprise
network (see Figure 2). The PTK is derived from the PMK,
Authenticator Nonce (ANonce), Supplicant Nonce (SNonce), and
the MAC addresses of both the supplicant and authenticator. Once
generated, the PTK is split into a Key Confirmation Key (KCK), Key
Encryption Key (KEK), and Temporal Key (TK). The KCK and KEK
are used to protect handshake messages, while the TK is used to
protect normal data frames with a data-confidentiality protocol. If
WPA2 is used, the 4-way handshake also transports the current
Group Temporal Key (GTK) to the supplicant.
