Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2

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.

所有被保护的无线连接都用了4次握手来对一个新连接生成一个全新会话密钥。至今为止，这个长达14年的握手过程至今仍然被认为是安全的，可靠的，并可以免受恶意攻击。但是，如今我们已经证明它对密钥重放攻击的方式是存在漏洞的。在这种情况下，攻击者可以诱使受害者安装一个已经使用过的密钥。攻击者便由此可以通过操控和重新执行握手信息来实现。当重放密钥之后，类似于增量传递包数（nonce）和接收包数（重新计数）相关的参数将会被设置成初始值。我们的重放攻击实验同时破坏了对等密钥、组密钥、快速BSS传输（FT）握手。所受到的威胁主要依赖于被攻击的握手过程，使用的数据加密协议。简单而言，为了对抗AES-CCMP，攻击者可以简单地重新发布并解密（但不丢弃）数据包。这就可以让攻击者有机会劫持TCP流量并将恶意信息注入进流量。攻击WPATKIP和GCMP的后果是相当危险的：数据包可以被重复发送、解密和丢弃。因为GCMP使用相同的认证密钥来加密数据交流的两端，它会很容易受到影响。

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.

最终，我们在实践中证实了我们的发现。并发现所有WiFi设备都会受到上述变种攻击的影响。值得注意的是，我们的攻击意外的让安卓6.0系统崩溃了：它强制客户端使用一个可预见的全零加密密钥。

KEYWORDS

关键词

security protocols; network security; attacks; key reinstallation; WPA2; nonce reuse; handshake; packet number; initialization vector

安全协议；网络安全；攻击；密钥重放；WPA2；随机数重用；握手；包数；初始化向量

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 work, we present design flaws in the 4-way handshake, and in related handshakes. Becausewe target these handshakes, both WPA and WPA2-certified products are affected by our attacks.

所有受保护的WiFi网络都是用了WiFi保护连接协议的某种版本（WP/2）。另外，现在甚至许多的公共热点可以因为Hotspot 2.0程序使用能够使用受认证的加密协议。所有的科技都依赖于在802.11的修订协议802.11i中提供的4次握手协议。在这项工作中，我们展示了4次握手协议的工作流程和相关我手流程。因为攻击的是这些握手方式，WPA和WPA2认证的产品都会受到我们的攻击影响。

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 atacks. 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.

四次握手协议提供了双方认证流程和会话密钥统一协定。和（AES）-CCMP一道——一种数据加密和整合协议——他成为了8022.11i修正案的基础。自2003年第一提出以来，WPA的名义下，目前已知的802.11i的威胁是在（WPA-）TKIP中。这种数据加密协议是对已经攻破的WEP协议的短期解决方案。另外，TKIP从来没有设计成长期的安全解决方案。然后，最几年，我们都发现了针对受保护的WiFi网络被攻击的现象，但是他们都没有破解802.11i的数据流。攻击者破解了WiFi受保护设置（WPS）、驱动、随机数生成器等模块。而在CCMP和4次握手协议当中并没有找到主要的弱点用来攻击。这并不奇怪。基于这些研究，这两种技术都被证明是安全的。正是由于这种情况，我们可能会认为4次握手协议的设计确实是安全的。

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.

尽管在历史上和安全测试上证明了它的作用，我们发现4次握手协议对密钥重放攻击是相当脆弱的。另外，我们还在其他的WiFi握手协议上发现了类似的问题。这说明，我们同样可以攻击对等密钥握手协议，组密钥握手协议和快速切换传输握手协议。

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.

我们的发现并非是无意义的后知后觉。我们可以通过下文来逐步总结概括。当客户端开始加入网路的时候，他开始进行4次握手协议获得一个新的会话密钥。他会在握手的第三个阶段来把这个密钥安装在系统里。一旦密钥安装到系统里，他会使用一种数据加密协议来用于加密普通的数据框架。然而，由于数据很容易被丢失或者丢弃，热点会在客户端没有正确返回第三个阶段的信息的时候重新发送消息3。也就是说，客户端可能会多次收到消息3。每一次他接收到消息3，他都会将其重新安装到系统里，同时通过数据加密协议重新设置累积传输包数（目前数）和接收的重计数。我们发现攻击者可以通过收集和重放消息3的重新传输来强制重置这些现时值。通过这种方法来获得现时值，加密协议就很容易被攻击。比如，包会被重放，解密或者被丢弃。在组密钥、对等密钥和快速切换传输握手协议都容易被这种方式攻击到。

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 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.

当4次握手协议和快速切换传输握手协议被攻击的时候，最精确的影响便是所使用的加密协议受到威胁。如果计数器模式密码块链消息完整码协议被使用了，任何数据包都会被解密。同样的，他可以解密TCP-SYN数据包，和挟持TCP连接。比如说，攻击者可以插入任何恶意信息到没有解密的HTTP连接中。如果临时秘钥完整性协议和伽罗瓦/反模式协议被使用了，攻击者可以随意解密和插入数据包。尽管伽罗瓦/反模式协议是最近被加入到无线网络的，在之后的几年里仍然有很高几率被破解掉。最终，如果组密钥握手协议被破解，攻击者可以重新更改组地址框架，比如广播框架和多播框架。

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].

我们的攻击对一种应用于Linux上的Wifi客户端wpa_supplicant 2.4和2.5版本特别有效。在这个案例中，客户端将会安装全零加密密钥而不是原来的加密密钥。这个问题造成可能是因为802.11规范中建议的将从内存中一次性安装的会话密钥进行部分清空的触发机制所导致的。因为安卓使用了一个修改版本的wpa_supplicant，因此安卓6.0和Android Wear 2.0同样有这个问题。因此，目前31.2%的安卓设备对于这种攻击是毫无防御能力的。

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.

有趣的是，我们的攻击并没有违反4次握手协议和组密钥协议之前正式分析的安全特性。特别的，这些证明了协商密钥依旧是私有的，客户端和热点的身份都是确定的。我们的攻击并没有泄漏会话密钥。另外，尽管如果我们使用了TKIP和GCMP，正常的数据框架可以被丢弃，攻击者不能丢弃EAPOL信息，并不能在握手阶段冒充客户端和热点。而且，我们的问题主要在于不是在模仿密钥重放。也就是说，他们的模型并不会在协商密钥应该安装的时候展示出来。实际上，这说明相同的密钥可以安装多次，并由此通过数据加密算法协议来重置随机数和重放计数。

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.

我们还评估了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.

文章接下来是这样组织的。第二部分介绍了802.11的相关知识点。第三部分介绍了四次握手和对点密钥握手攻击的内容。第四部分则介绍了组密钥握手攻击的相关信息。第五部分则介绍了快速基本服务设置转换握手协议的攻击情况。第六部分我们介绍了攻击的影响，现在的应对措施，协议失败的原因，并由此应该借鉴的地方。最终，我们在第七章会列出相关的研究，并在第八章做个总结。

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.

这一部分中，我们会介绍一下802.11i的修正案，当无线网络连接的时候所用到的各种消息和握手协议，还有802.11的数据加密协议和完整性检测。

The 802.11i Amendment

820.11i修正案

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.

当有效等价保密被证明是危险了的时候，IEEE为802.11的修正文档802.11i中提供了更加健壮的解决方案。这个解决方案定义了4次握手协议，和两个数据加密协议和完整性测试协议，分别为（WPA-）TKIP和（AES-）CCMP。当802.11i修正标准还在制定当中的时候，无线网络组织就已经开始使用802.11i的第三个草案版本来验证设备。这个验证程序叫作无线保护链接协议（WPA）。当802.11i的第九个草案版本被制定出来以后，WPA2认证标准就以此为基础进行验证。因为WPA和WPA2都是基于802.11i协议，他们都认为是同一个技术层面的解决方案。WPA2与WPA的主要区别在于，WPA2支持更加安全的CCMP，只允许TKIP。反之，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.

4次握手协议都使用在受保护的无线连接网络上，均被WPA和WPA2所要求使用。而且，企业级网络同样依赖于4次握手协议。因此，所有受保护的无线网络都会受到我们的攻击的影响。

The 4-way handshake, group key handshake, and CCMP protocol, have formally been analyzed and proven to be secure [39, 42].

四次握手协议，组密钥握手和CCMP协议都被分析过，并正式证明是安全的。

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).

当客户端想连接到无线网络，他需要手动地认证和联系无线热点。在数据二中，他介绍了握手的连接部分。然而，当第一次连接到网络的时候，在连接的时候没有任何的认证阶段。相反的，使用的是开放系统认证，这可以让任何设备进行认证。真正的认证阶段实在4次握手的时候。当同一个网络中使用快速切换传输握手的两个无线热点切换的时候，才会有真正的认证过程。

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

4次握手

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.

四次握手协议使用了基于一种叫做配对主密钥（PMK）的共享密钥双向认证机制，并提供了一种叫做配对传输密钥（PTK）来传输新的会话。在握手期间，客户端被称作请求者，热点被称为认证者（我们用的是同义词）。PMK通过在个人网络中使用一个事先声明的密码来生成，在企业网络中则使用了802.1x中的认证阶段来交流。PTK是通过PMK生成的，认证随机数(ANonce)，请求随机数（SNonce）和MAC地址既是请求者又是认证者。一旦生成，PTK会被分解成密钥验证密钥（KCK）和密钥加密密钥（KEK）和临时密钥（TK）。KCK和KEK都用来保护握手信息，TK则用于保护使用了数据传输协议传输的普通加密框架。如果使用了WPA2，四次握手协议同样会传输当时的组临时密钥（GTK）给请求者上。

Every message in the 4-way handshake is defined using EAPOL frames. We will briefly discuss the layout and most important fields of these frames (see Figure 1). First, the header defines which message in the handshake a particular EAPOL frame represents.We will use the notation message n and MsgN to refer to the n-th message of the 4-way handshake. The replay counter field 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 field 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 field, which is encrypted using the KEK. Finally, the authenticity of the frame is protected using the KCK with a Message Integrity Check (MIC).

每一条经过4次握手的数据都使用了EAPOL框架来定义。我们将简单地讨论这个应用和这些框架的最重要区域。首先，头部定义了在一个特定的EAPOL框架中展示的握手消息。我们将使用记号N和MsgN来标记第N个四次握手协议的数据。重放数据域用于检测重放框架。认证端通常在传送了一次认证以后用自增的方式来增加重放数。请求端回复认证端的EAPOL框架，他用了相同的EAPOL框架数。随机数域用于传输认证端和请求端产生新的会话密钥的随机数。接着，在EAPOL框架传输组密钥的时候，接收组计数（RSC）会包含这个密钥的起始包数。组密钥自己将存储密钥数据域，这用来使用KEK加密。最后使用消息完整性的KCK来保护认证端的数据。

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 of r , and with the given nonce (if present). All parameters after the semicolon are stored in the key data field, and hence are encrypted using the KEK (recall Figure 1).

他代表了四次握手协议的消息N，有一个重放计数r，和一个（可能被提供的）随机数。所有在分号后面的变量都在密钥数据域中存储，并且接着就使用KEK进行加密。

The authenticator initiates the 4-way handshake by sending message 1. It contains the ANonce, and is the only EAPOL message that is not protected by a MIC. On reception of this message, the supplicant 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 finalize 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 first 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.

认证端发送消息1来启动四次握手协议。它包括了ANonce和并没有使用消息完整性保护的EAPOL消息。在回复这条信息的时候，客户端返回SNonce并从配对传输密钥获取（比如会话密钥）。客户端接着将SNonce通过消息2发送到认证端。当认证端接收到SNonce的时候，他也会生成配对传输密钥，然后发送组密钥（GTK）给客户端。最后在结束握手的时候，服务端发送消息4，并安装PTK和GTK。接收完信息以后，认证端同样会安装PTK（GTK会在热点启动的时候安装上）。也就是说，第一二阶段的消息使用随机数传输的，最后两个阶段使用的是组密钥，这可以用来防止降维攻击。

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-confidentiality protocol using the current PTK (we rely on this in Section 3.4).

需要注意的是，在一个已经存在的连接中，PTK可以通过一个新的四次握手协议的初始化而更新。这个阶段，所有的四次握手协议的信息都会使用现在的PTK加密的数据加密协议进行加密。

2.4 Confidentiality and Integrity Protocols

加密协议和整体性检测协议

The 802.11i amendment defines two data-confidentiality protocols. The first is called the Temporal Key Integrity Protocol (TKIP). However, nowadays TKIP is deprecated due to security concerns [74]. The second protocol is commonly called (AES-)CCMP, and is currently the most widely-used data-confidentiality protocol [69]. In 2012, the 802.11ad amendment added a new data-confidentiality protocol called the Galios/Counter Mode Protocol (GCMP) [3]. This 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].

802.11i修正案规定了两种数据加密协议。第一种叫做临时密钥完整性协议（TKIP）。然而，现在TKIP已经因为安全原因弃用。第二个协议就是通常说的（AES-）CCMP协议，并且实现在最为常用的数据加密协议。在2012年，802.11ad修正案中加上了一个伽黎欧思/计数模式协议（Galios/Counter Mode Protocol GCMP）。这个修正案同时加上了在60GHz频道上需要用GCM快速解密的短距离通信的支持。现在802.11ad同样支持无线G级传输(WiGig)，并有望在最近几年内快速应用。最终，802.11ac修正案通过支持256为加密来扩展了GCMP的使用。

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 first 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 incremented 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. Unfortunately, Michael is trivial to invert: given plaintext data and its MIC value, one can efficiently recover the MIC key [66, 69].

当TKIP使用了之后，会话密钥（PTK）中的临时密钥部分会进一步分成128位的加密密钥和两个64位的信息完整检查密钥（MIC）。第一个MIC密钥会被用于热点到客户端的交流，第二个密钥则用于客户端到热点这个阶段的交流。RC4被用来加密，是由128位加密密钥、发送者的MAC地址和递增的48位随机数所组成的独特的对点加密密钥。这个随机数在传输一个框架以后自动增加，接收者将其用作重放计数，在安装TK信息的时候会被初始化成1.消息的认证是通过玛奇尔算法验证。不幸的是，玛奇尔算法被证实很容易破解：只要知道文本数据和他的MIC值，攻击者很容易算出MIC密钥。

The CCMP protocol is based on the AES cipher operating in CCM mode (counter mode with CBC-MAC). It is an Authenticated Encryption with Associated Data (AEAD) algorithm, and secure as long as no Initialization Vector (IV) is repeated under a particular key1. In CCMP, the IV is the concatenation of the sender MAC address, a 48-bit nonce, and some additional flags 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.

CCMP协议是基于CCM模式（CBC-MAC的计数模式）操作的AES加密方式。这是通过关联数据认证加密（Authenticated Encryption with Associated Data, AEAD）算法，并与非初始化向量（IV）一样安全，并不断发送一个固定的密钥。在CCMP中，IV被整合进发送者的MAC地址中，是一个48位的随机数，并通过传输框架生成一些额外的标志。随机数同时被接收者作为重放计数使用，在发送给任何一个框架之前会自增1，在开始安装成TK的时候被设定为0。这似乎是假定了IV是不会被重放的。另外，这样的机制会允许TK在双方通信的时候可以直接使用。

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 directions. If a nonce is ever repeated, it is possible to reconstruct the authentication key used by the GHASH function [43].

GCMP协议基于AES-GCM，这也就意味着它使用了计数模式来加密数据，使用了GHASH函数在验证的时候请求加密文本数据。类似于CCMP，他是AEAD加密，因为在任何协议的时候都没有任何初始向量被重复使用，所以都是安全的。GCMP的时候，初始化向量是发送者的MAC地址和48位随机数的组合。随机数同时被接收者用作重放计数，在发送之前都会自增1，而在安装到TK中时初始化为0。这个通常只用一次。CCMP一起使用的时候，TK被直接用于发送端和接收端。如果随机数从不反复，GHASH函数就有可能会重新恢复。

To denote that a frame is encrypted and authenticated using a data-confidentiality protocol, we use the following notation:

为了说明被加密协议验证加密的框架，我们使用以下记号：

$$En{c}_k^n\{\cdot \}$$

Here n denotes the nonce being used (and thus also the replay counter). The parameter k denotes the key, which is the PTK (session key) for unicast traffic. For group-addressed traffic, i.e., broadcast and multicast frames, this is the GTK (group key). Finally, the two notations

这里n标记的时候已经使用的随机数（因此也是重放计数）。变量k表示的是密钥，统一广播流量的PTK（会话密钥）。相对于组地址流量，比如广播和多播框架，这就是组密钥。最后，下面两个标记：

$$Data(payload)$$
$$GroupData(payload)$$

are used to represent an ordinary unicast or group-addressed data frame, respectively, with the given payload.

用来分别表示一个普通的统一广播或组地址数据框架对应的攻击载荷。

2.4 The Group Key Handshake

组密钥握手协议

The authenticator periodically refreshes the group key, and distributes this new group key to all clients using the group key handshake. 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 replying with group message 2. Depending 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 field (see Figure 1).

认证端周期性更新组密钥，并将新生成的组密钥通过组密钥握手过程分发给所有的客户端。这个握手过程已经被证明是安全的，并在数据2的最后阶段进行了说明。认证端通过发送一个组信息1给所有客户端来初始化握手过程。接收端回复组信息2来告诉新的组密钥片段已经被接收。基于这个过程，认证端便会在发送完组信息1或者接受了所有连接客户端的回复后将GTK安装上。最后组信息1同样包含了在RSC域中当前接收组密钥的重放计数。

Both messages in the group key handshake are defined 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 field, 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-confidentiality protocol.

组密钥中的握手信息都被定义使用EAPOL框架，在数据2中使用了组1和组2.注意到组1在密钥数据域中存储了新的组密钥，因此使用了KEK来加密。一旦在这一步PTK被安装上，整个EAPOL框架都会被同一个加密协议所加密。

Finally, if a client transmits a broadcast or multicast frame, she first sends it as a unicast frame to the AP. The AP then encrypts 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 describing 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 simplified description of this state machine.

802.11i修正案并没有提出一个正式的状态机来描述4次握手协议如何实现。他只是提供了伪代码来描述如何进行四次握手协议，却没有说明什么时候进行。幸运的是，802.11r则扩展了4次握手协议，并提供了一个详细的客户端状态机。

When first connecting to a network and starting the 4-way handshake, 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 happen when connecting to a network for the first 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 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-confidentiality 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.

当客户端第一连接到网络并开始四次握手协议，客户端便到了PTK-INIT阶段。在这里，他初始化了配对主密钥（PMK）。当街收到了消息一，他便转换到PTK-START阶段。这会在第一次连入网络的时候出现，或者是当会话密钥在之前一次完整的4次握手协议执行结束以后发生。当进入PTK-START阶段，客户机生成了一个他的SN随机数，通过消息2发送给验证端。接着认证端就会发送消息3，表明MIC和重放计数都是有效的，并且已经接受了。那么，接下来便会转到PTK-NEGOTIATING的状态，他会将TPTK标记为有效的，并用他签署PTK变量，然后将消息4发送给认证端。接着他立刻会变成PTK-DONE状态，PTK和GTK都会使用原始的MLME-SETKEYS请求并通过数据加密协议进行加密。最终，他打开802.1x端口让客户端可以接收和发送普通的数据框架。需要注意的是状态机如果在认证端没有接收到消息2或消息4的情况下，会分别显式的将消息1或消息3进行重新传输。这些重传会使用一个自增的EAPOL重放计数。

We confirmed that the state machine in 802.11r matches the original state machine, that was “defined” in 802.11i using textual descriptions scattered throughout the amendment. Most importantly, we verified 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 handle 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.

我们已经确认了，在802.11r中定义的状态机跟在802.11i修正案中用文字描述的状态机是一样的。更重要的是，我们验证了在重放攻击中非常重要的两个性质。第一，802.11i说热点会在没接收返回信息的情况下重传消息1或消息3。因此，客户端必须客户端必须处理消息1或消息3的反复传输，以确保正确处理802.11r中定义的情况。另外，802.11i要求客户机需要在处理和接收消息3的时候安装PTK，这也和802.11r中定义的状态机完全一致。

3.2 The Key Reinstallation Attack

密钥重放攻击

Our key reinstallation attack is now easy to spot: because the supplicant 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 first establish a man-in-the-middle (MitM) position 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-confidentiality 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-confidentiality protocol.

我们的这种密钥重放攻击很容易被发现：因为客户端仍然在接收反复发送的消息3，即使客户端在PTK-DONE状态下，我们可以强制将PTK重新安装上。更进一步地，我们第一次在客户端和验证端之间实施了一次中间人攻击（MITM）。我们使用中间人攻击来防止验证端接收消息4，并让消息3一直重新发送。因此，这会让消息3总是不停地发送，这会让客户端一直安装已经使用过的PTK。这也就是说，他开始通过数据加密协议重设随机数。基于所使用的协议，这会让攻击者重放、解密甚至放弃数据包。第6.1部分我们将分析各个数据加密协议对这种攻击的具体影响。

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 message 3 (see Table 1 column 2). This violates the 802.11 standard. As a result, these implementations are not vulnerable to our key reinstallation attack against the 4-way handshake. Unfortunately, from a defenders perspective, both iOS and Windows are still vulnerable 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).

实际上，当我们进行实际上的攻击的时候，情况变得异常复杂。首先，不是所有的WiFi客户端会正确地实现状态机。特别的，Windows和iOS不会接受重新发送的消息3。这违背了802.11的标准。因此，这些实现对我们的四次握手协议的密钥重放攻击免疫。很遗憾的是，对于受害者而言，iOS和Windows仍然在组密钥状态下受到了重放攻击的影响。另外，因为所有操作系统支持802.11r，所以在FT握手的时候，通过重放攻击热点的方式间接攻击这些客户端的话，还是存在一定可能性的。

A second minor obstacle is that we must obtain a MitM position between the client and AP. This is not possible by setting up a rouge AP with a different 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 different key, causing the handshake and attack to fail. Instead, we employ a channel-based MitM attack [70], where the AP is cloned on a different channel with the same MAC address as the targeted AP. This assures the client and AP derive the same session key.

第二个小困难是我们必须在客户端和热点之间找到中间人攻击者的位置。我们不可能设置一个具有不同MAC地址的未经企业许可而私自接入企业网络中的无线路由器，然后来获取真实热点和客户端之间的信息。回顾2.3部分我们就会知道，会话密钥是基于MAC地址的，这会导致握手和攻击失败。所以，我们实施的是基于频道的中间人攻击方式，这种方式将攻击的热点的MAC地址克隆到另一个频道的热点上。这确保了客户端和热点使用了一样的会话密钥。

The third obstacle is that certain implementations only accept frames protected using the data-confidentiality 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).

第三个障碍就是具体的实现只接受那些一旦用PTK安装的数据加密协议保护的框架。这对于我们的攻击是很成问题的，因为认证端会不断地发送没有加密的消息3,。这也就意味着重新发送的信息会被客户端所忽略。尽管这似乎会让我们的攻击失效，但是我们已经找到一种方式去绕过这个问题实现攻击。

In the next two Sections, we will describe in detail how to execute our key reinstallation attack against the 4-way handshake under various conditions. More precisely, we first explain our attack when the client (victim) accepts plaintext retransmissions of message 3 (see Table 1 column 3). Then we demonstrate the attack when the victim only accepts encrypted retransmissions of message 3 (see Table 1 column 4). Table 1 column 6 summarizes which devices are vulnerable to some variant of the key reinstallation attack against the 4-way handshake. We remark that the behaviour of a device depends both on the operating system, and the wireless NIC being used. For example, although Linux accepts plaintext retransmissions of message 3, the Wi-Fi NICs used in several Android devices reject them. However, Android phones with a different wireless NIC may in fact accept plaintext retransmissions of message 3.

在接下来的两个部分，我们将描述该如何在各种各样的条件下对四次握手协议的密钥重放攻击。更细致的说明，我们第一步要在客户端（受害者）接收到消息三的时候解释一下我们的密钥重放攻击。接着我们要在受害者只接受重放的加密消息三数据的时候来说明攻击的情况。表格1第6栏总结了当通过密钥重放方式共计四次握手协议时的情况。我们指出了，设备的行为方式因设备不同和操作系统不同而异，以及无线NIC的使用方式不同。例如，所有的Linux系统接受重传的消息三，而一些Anroid设备则会拒绝无线NIC发送的数据。然而，如果Android使用的是不同的无线NIC方式可能在事实上会接受重传的消息三。

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 straightforward. 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 first data frame uses a nonce value of 1 in the data-confidentiality 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 retransmitted 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-confidentiality 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-confidentiality protocol 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.

如果受害者的设备在安装完会话密钥后一直接收着消息三的文本，我们的攻击便能成功。第一步，攻击者要建立一个基于频道的中间人攻击，这样攻击者可以控制握手信息。接着，他要阻止消息四被认证端接收。这就是表格4的第一阶段。发送了消息四，客户端便会将PTK和GTK安装到系统上。与此同时，客户端也打开了802.11x端口，然后开始传送普通的数据框架。需要注意的是，客户端第一次安装的时候，会用数据加密协议传输，随机数是1。接着在第三阶段，认证端会反复传输消息三，因为他没有接受到消息四。攻击者就会将消息三重新返回给客户端，使客户端重新安装PTK和GTK。因此他就会重设随机数并重放数据加密协议中的计数。不过，攻击者不能重放以前的消息三，因为它的EAPOL的重计数不是最新的。我们来看看攻击的第四阶段。最后，受害者传输了他的下一个数据框架，数据加密协议重用了随机计数。需要注意的是，攻击者可以在任何时候截留消息三，并随意控制攻击时间，并随时发送给受害者。因此我们可以控制获得的随机数的数量。并且，攻击者可以强制让设备取消认证，然后让设备重新连接wifi，并开始一个新的四次握手协议。

Figure 4 also shows that our key reinstallation attack occurs spontaneously if message 4 is lost due to background noise. Put differently, clients that accept plaintext retransmissions of message 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.

图像4同时说明了我们的密钥重放攻击在消息四背景噪音的情况下丢失的情况下会同时发生。也就是说，接收重放普通文本信息的消息三的客户端会在攻击者发动攻击之前都会重新使用随机数。通过这次的发现，攻击者可以发送无意义的消息四，发动一次无声息的攻击。与随机地背景干预无差别的攻击。

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. And since the authenticator did not yet install the PTK, it will normally reject this encrypted message 4. However, a careful inspection of the 802.11 standard reveals that the authenticator may accept any replay counter that was used in the 4-way handshake, not only the latest one [1, §12.7.6.5]:

现在我们回到攻击的第四阶段。这个阶段的目标是在认证端进行完整的认证。这是无效的，因为客户端已经完成了PTK的安装过程，意味着最后一个消息4已经加密了。并且，如果验证端并没有安装PTK，她通常会拒绝接受这个加密的消息四。然而对802.11进行细致分析以后，我们发现认证端会接受四次握手所有重用的随机数，而不仅仅是最后一个。

“On reception of message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-way handshake.”
“在接收到消息四的时候，验证端会验证密钥重放计数域的值是否是曾用于4次握手协议的。”

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 counter r + 1 in Figure 4. As a result, these AP will install the PTK, and will start sending encrypted unicast data frames to the client.

实际上，我们发现部分热点确实接收了就得重放计数。更准确的说，一些热点接收了发送给客户端的重放计数，但却没有用到客户端返回的重放计数。这些热点将会接收之前没有加密的消息四，也就是那些重放计数r+1的消息。因此，热点就会安装PTK，并用这个密钥发送加密的多播数据框架给客户端。

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.

尽管图四只是说明了在数据框架下通过客户端发送了重用的随机数，攻击者可以让我们重新发送框架。第一步，在客户端重新安装攻击步骤阶段三的GTK时，通过热点发送重新发送消息三的广播和多播数据集就会重放。这是因为当安装密钥的时候，重放计数都会被重置。第二，如果我们能让热点安装PTK，我们就能重放从热点发送到客户端的多播数据集。

We confirmed that the attack shown in Figure 4 works against MediaTek’s implementation of the Wi-Fi client, and against certain versions of wpa_supplicant (see Section 6.3). How we attacked other implementations is explained in the next section.

我们已经确认了，图4的攻击方式可以在MediaTek实现的无线客户端上实现，而且可以攻击特定版本的WPA支持设备。我们如何进行其他攻击将会在下一小节作解释。

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-confidentiality protocol.

现在，我们就来谈谈我们如何攻击客户端。当他们安装好GTK之后，就只能让他们接收消息三的加密的重传数据。为了能实现这一步骤，我们通过在实体进行四次握手和实体实现数据加密协议之间加一个一个内部竞争条件的方法来攻击。

As a warm-up, we first attack Android’s implementation of the supplicant. Here we found that Android accepts plaintext retransmissions of message 3 when they are sent immediately after the original message 3 (see column 4 of Table 1). Figure 5 shows why this happens, and how it can be exploited. Note that the AP is not drawn in this figure: its actions are clear from context. In our attack, we first let the client and AP exchange Message 1 and 2. However, we do not forward the first 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-confidentiality 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 first 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.

做为先导攻击，我们先对Android的无线协议实现进行了研究。我们发现，Android在原始的消息3之后立刻被发送出去了，然后接收到了消息3重传的明文文本。图5告诉我们如何产生这一过程，并说明了如何利用这一过程。注意到热点并没有在这个地方显示出来：他的存在在上下文中体现得非常明显。在我们的攻击当中，我们让客户端和热点互相传送消息一和消息二。然而，我们先不发送消息三到客户端上。我们让热点重新传送消息3。在攻击的第二步，我们同时发送两个消息3给客户端。无线网络接口卡是使用了数据加密协议的，但是他并没有安装PTK，因此同时到达了主CPU的数据接收队列里。应用了四次握手协议的主CPU回复了第一个消息三的信息并要求无线NIC安装PTK。在攻击的第四阶段，客户机抓取到了第二次接收到的消息三，并将它放入主CPU的接收队列中。尽管安卓和Linux都发现了这次接收到的消息三并没有加密，但是和两个系统都让EAPOL数据通过特殊的方式进入系统当中，所以主CPU又一次处理了消息三的内容。因为NIC仅仅只是安装了PTK，回复的数据会用随机地数据串1进行加密。之后他就会要求NIC重新安装PTK，也就说明下一次再发送同样信息的时候，他还是会用1来加密。

We now show how to attack OpenBSD, OS X, and macOS (see Table 1 column 5). These devices only accept encrypted retransmissions 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-confidentiality protocol.

我们也分析了在OpenBSD、OS X和macOS的攻击方式。这些设备只能接收已经加密过的重放消息三。和Android的攻击手段类似，我们同样对无线NIC和主CPU的竞争条件进行了恶意地使用。然而，我们现在主要关注的是一个会将PTK刷新的四次握手过程。回想起2.3小节，每一个消息都会用数据加密协议进行重新加密以后才会传输出去。

Figure 6 illustrates the details of the attack. Note that the AP is not draw in this figure: its actions are clear from context. Again the adversary uses a channel-based MitM position [70]. She then lets the victim and adversary execute the initial 4-way handshake, and waits until a second 4-way handshake is initiated to refresh the PTK. Even though she only sees encrypted frames, messages in the 4-way handshake can be detected by their unique length and destination. At this point, the attack is analogous to the Android case. That is, in stage 2 of the attack, the adversary does not instantly forward the first message 3. Instead, she waits until the AP retransmits message 3, and then forwards both messages right after one another to the victim (see Figure 6 stage 2). The wireless NIC will decrypt 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 first 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 confirmed this attack against OpenBSD 6.1, OS X 10.9.5, and macOS Sierra 10.12.

图六详细介绍了攻击的过程。值得注意的是，热点并没有在图中画出来，因为它在供给中扮演的角色在上下文中已经解释得十分清楚。与之前的攻击手段类似，我们使用的是基于信道的中间人攻击方法。这个方法让客户端和攻击者都能让四次握手协议返回到初始阶段并允许攻击者开始执行攻击步骤，而且，还可以一直等到第二次四次握手协议初始化后刷新PTK。尽管这个方法只能看到加密的数据集，但是四次握手协议的消息可以通过检测其独特的长度和目标设备来解密。在这一点上，这种攻击与Android端上的攻击是类似的。也就是说，在攻击的第二阶段，攻击者不会立刻发送第一个消息三。而是等到热点重新发送消息三后，将这两个消息同时发送给受害者。接着，无线NIC就会用当前的PTK对所接收到的信息进行解密，并将其传送至主CPU的接收消息队列中。在攻击的第三阶段，受害者的主CPU会 处理第一个消息三，然后返回信息，接着命令NIC安装新的PTK。在第四步，主CPU从接收队列中获得第二个消息三。当PTK已经安装了，OpenBSD、OS X和macOS（这里都称之为主CPU）强制将消息三加密。但是，他们却不去检查用什么密钥加密的数据。因此，即使消息使用了旧的PTK来解密，主CPU还是会处理信息三。所以消息四就被发送回验证端，并使用了全一的随机字符的PTK来加密。之后，主CPU就会要求NIC重新安装PTK，并将随机数和重放计数重新设置。最终受害者发送的数据集会被值为全一的PTK重新加密。我们已经确认了，在OpenBSD 6.1、OS X 10.9.5和macOS Sierra 10.12中都会受到攻击的影响。

OpenBSD is only vulnerable if encryption is offloaded to the wireless NIC. For example, the iwn driver and associated devices support hardware encryption, and therefore are vulnerable. However, the rum driver performs software encryption in the same entity as the 4-way handshake, and is not vulnerable (see Table 1 column 5).

在加密之后最终放置到无线NIC上时，OpenBSD是唯一会受到攻击的系统。比如说，iwn驱动和相关设备支持硬件加密，因此会受到攻击。然而，rum驱动在同一个四次握手协议状态下用的是软件加密，因此就不会受到攻击的威胁。

This attack technique requires us to wait until a rekey of the session key occurs. Several APs do this every hour [66], some examples being [24, 26]. In practice, clients can also request a rekey by sending an EAPOL frame to the AP with the Request and Pairwise bits set. Coincidently, Broadcom routers do not verify the authenticity (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.

攻击的关键之处是需要我们耐心的等待，直到会话密钥的重新加密得以实现之后才能发动攻击。一些热点一般每小时做一次，一些实验攻击显示出了这种情况。实际上，通过发送一个带有请求和配对字符设置集的EAPOL数据集给热点，客户端同样可以发出一个加密更新的请求。

3.5 Attacking the PeerKey Handshake

攻击PeerKey握手协议

The PeerKey handshake is related to the 4-way handshake, and used when two clients want to communicate with each other directly in a secure manner. It consists of two phases [1, §12.7.8]. In the first phase, a Station-To-Station Link (STSL) Master Key (SMK) handshake is performed. It negotiates a shared master secret between 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.

PeerKey握手协议与四次握手协议有关，并且用于两个客户端在安全状态下的相互通信。它包括两个阶段。第一阶段，连接执行了一个端对端的连接主密钥握手协议。他在两个客户端之间使用了一个共享的主密钥。在第二阶段，使用STSL传输密钥握手协议之后，一个新的会话密钥就会产生。这个会话密钥来自于主密钥。尽管该协议并没有得到广泛支持，他依然是重放技术的良好测试用例，对衡量我们的攻击的实际意义有非常棒的启发。

Unsurprisingly, the SKM handshake is not affected by our key reinstallation attack. After all, the master key negotiated in this handshake is not used by a data-confidentiality 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-confidentiality protocol. As a result, it can be attacked in precisely the same manner as the 4-way handshake. The resulting attack was tested against wpa_supplicant. To carry out the test, we modified another wpa_supplicant instance to send a second (retransmitted) message 3. This confirmed that an unmodified wpa_supplicant will reinstall the STK key when receiving a retransmitted message 3 of the STK handshake. However, we did not find other devices that support PeerKey. As a result, the impact of our attack against the PeerKey handshake is rather low.

并不意外的是，SKM握手对我们的密钥重放攻是免疫的。还有，在这个握手协议中使用的主密钥并没有用数据加密协议吉阿米果，这意味着并没有重放计数和随机数被重置。然而，STK握手是基于四次握手的，他确实在数据加密协议中用了一个密钥。这意味着我们的攻击是可以用来攻击WPA客户端的。为了达成我们的攻击，我们修改了其他的WPA客户端来发送一个重新传输的消息三数据。这说明没有进行修订的WPA客户端将会在接收到重放的STK消息三后，重装消息三。然而，我们并没有发现其他支持配对密钥的设备。因此，我们的攻击对配对密钥所造成的攻击效果十分有限。

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.

在这一部分中，我们将对组密钥握手协议进行攻击。我们发现所有的wifi客户端都是易受到攻击的，并且能够使攻击者重放广播和多播数据集。

4.1 Details of the Group Key Handshake

组密钥握手协议的细节

Networks periodically fresh the group key, to assure that only recently 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.

无线网会周期性的更新组密钥，来确保只有最新的认证客户端能够得到这个密钥。在很多的防御案例中，组密钥会在任何一个客户端离开的时候刷新一次。新的组密钥通过组密钥握手协议进行分发，而这种握手过程被正式证明是安全的。在热点发送组消息1给所有客户端的时候，握手协议被热点初始化。热点接着便会重传这个消息给那些没有正确回复消息的客户端。我们注意到，EAPOL中这些重传的消息里的重放计数总是加一的。在我们的攻击中，我们的目标是收集消息一的重传信息组，阻止它发送给客户端，并延后发送给客户端，这会让客户端在安装组密钥时重新初始化重放计数的值。

The first prerequisite of our attack, is that clients will reinitialize the replay counter when installing an already-in-use group key. Since clients also use the MLME-SETKEYS.request primitive to install the group key, this should be the case. We confirmed that in practice all Wi-Fi clients indeed reinitialize the replay counter of an already-in-use group key (see Table 1 column 7). Therefore, all Wi-Fi clients are vulnerable to our subsequent attacks.

我们的攻击需要满足以下条件：1、在已经安装了一个使用过的组密钥后，客户端要重新初始化重复计数的值。因为客户端也有可能使用MLEM-SETKEYS来请求新的原始值用以安装组密钥，所以这个也应该写在我们讨论的第一个情况内。本文已经确认了，所有无线客户端在实际情况下都会重新初始化已经用过的组密钥的重放计数的值。因此，所有的无线设备都会受到这种类型的攻击。

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 first 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.

第二个前提条件是，我们必须能够获得组消息一。客户端必须始终在接收这个消息一，并且这个消息一还要包含已经被热点使用的组密钥。这个前提条件实现是由热点开始接收新的组密钥的时间来决定的。实际上，热点可能会在第一次发送组消息一的时候便开始用新的组密钥，或者在所有客户端都用组消息二回复的之后才会安装组密钥。表格二第三栏总结了几个热点的行为。需要注意的是，标准要求的是，新的组密钥应该在所有客户端都返回组密钥消息二之后才能安装。比如GTK应该在延后的时间段中安装上去。当热点立刻将组密钥安装到自己的设备上的时候，我们的攻击便可以开始实施。然而如果热点是在延后的时间段将组密钥安装上去的话，我们的攻击便会变得非常复杂。我们将会在4.2和4.3两个部分中分别介绍这两种攻击情况。

Recall from Section 2.3 that only the AP will transmit real broad-cast and multicast 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.

在2.3节中说明，只有热点设备才会发送真正的广播和多播数据集，这些数据集都是由组密钥加密的。由于我们的攻击都是关注于客户端，这说明我们不能在加密的时候强迫重用随机数。然而，客户机会在重新安装组密钥的时候重置重放计数，这个重放计数可以在发送给客户端的时候可以被攻击者滥用。

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 flags Request and Group [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.

大多数热点每一个小时就会更新组密钥。有些网络甚至在客户端断开连接的时候就将组密钥更新了。另外，客户端会通过发送携带有请求和配对的EAPOL数据集来启动组密钥握手过程。同样的，Broadcom路由器设备不会验证这些消息的有效性，这也就意味着攻击者可以丢失验证信息，来达到更新组密钥的过程。综上所述，我们可以明白，大部分网络都可以进行组密钥更新，从而实现我们的攻击。

4.2 Attacking Immediate Key Installation

攻击实时安装密钥行为

Figure 7 illustrates our key reinstallation attack when the AP immediately 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-confidentiality 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 allows us to replay the broadcast data frame (see stage 5). The client accepts this frame because its replay counter was reinitialized.

图七向我们介绍了攻击当热点在向所有客户端发送完组消息一之时安装密钥的时候。需要注意的是，组密钥握手消息是用当前的PTK为密钥的数据加密算法来加密自身的。接收到组消息一， 客户端安装了新的GTK，并将消息二发送回去。攻击者会拦截消息二，并阻止他发送给热点。因此，热点会重传对应于攻击的第二阶段的消息一。我们会一直等到广播数据集被发送出去，并最后由受害者接收。下一步，我们便会重新传输第二阶段的组消息一给受害者。因此，受害者会重装GTK，然后重新初始化有关的重放计数。这也会让我们重新发送广播数据集。正因为计数被重新初始化，客户端会接受重放的计数。

It is essential that the broadcast frame we replay is sent before there transmission 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 confirmed this attack in practice for APs that immediately install the group key after sending group message 1 (see Table 2 column 3). Based on our experiments, all Wi-Fi clients are vulnerable to this attack when connected to an AP behaving in this manner.

可以确定的是，在发送组消息一后立刻安装组密钥对热点的攻击是有效的。实验表明，所有的无线客户端在热点执行这种行为的时候是很容易受到攻击的。

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.

当热点在使用延时安装的方式使用GTK时，攻击组密钥握手协议会变得非常困难。注意到在图像7中的第三阶段，之前所说的攻击方式会失败，因为这个时候，广播数据集会使用旧的密钥进行加密，在这一个阶段，热点还没有接收到来自客户端的组消息2，这说明他还用着原来的旧的组密钥。这就变得非常棘手，因为组消息一（重）安装了新的组密钥，因此就不能使用之前的方法，通过不正当使用的方法重设原来组密钥的重放计数。

One way to deal with this problem is illustrated in Figure 8. The first 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 of r + 1. In stage 3 of the attack, however, we forward the older group message 2 with replay counter value r 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]:

在图8中，我们提出了解决这个问题的一个方法。攻击的前两个阶段和之前提到的是一样的。也就说，热点生成了新的组密钥，然后发送给受害者，攻击者便阻止组消息2发送到热点上。这个方法让热点重新传输了一个新的组消息一，这个消息一使用的是自增的EAPOL，其重放计数的值r加了一。 然而，在攻击的第三阶段，我们将旧的组消息2发送给热点，其重放计数的值为r。非常有缺的是，热点接受了这个消息，尽管他用的不是最新的重放计数的值。

On reception of [group] message 2, the AP verifies that the Key Replay Counter field value matches one it has used in the group key handshake.

在组消息2的接收上，热点会进行验证，他会比较密钥重放计数域的值是否与之前它在组密钥握手协议中使用的值。

The standard does not require that the replay counter matches the latest one that the AP used. Instead, it must match one that was used in the group key handshake, that is, one used in any of the (re)transmitted group message 1’s. In practice we discovered that several implementations indeed accept this older not-yet-received replay counter (see Table 2 column 2). As a result, the AP installs the 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.

标准并没有要求重放计数要和热点已经使用过的相匹配，相反的是，他要求必须和组密钥中已经使用过的计数相同。也就是说，要和已经（或重）传输的组消息1一样。在实际情况下，我们确实发现了，许多标准实现的程序中接收了还没有接收的旧的重放计数。因此，热点安装了新的组密钥。由此，攻击者可以执行一个类似与之前方式的攻击。也就是说，我们可以一直等到广播数据集传输以后，在攻击的第五阶段实施组密钥的重放攻击。

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.

我们测试这种通过延时的方式来安装GTK，并攻击验证端。这种攻击方式会让验证端接收曾经发送给客户端中所包含却从未在回复中接收到的重放计数，注意到我们已经知道了所有的无线客户端都会在重安装GTK的时候重置重放计数，因此所有的客户端都是易受到攻击的。最后，只有一个基于OpenBSD的热点未受到攻击，因为它是通过延时方式来安装GTK的，并且只接受最新的重放计数。

5 ATTACKING THE 802.11R FT HANDSHAKE

攻击802.11R FT握手协议

In this section we introduce the Fast BSS Transition (FT) handshake, and show that implementations of it are also affected by our key reinstallation attack.

在这一部分中，我们介绍快速BSS传输握手协议，并介绍如何在这个协议上实现我们的密钥重放攻击。

5.1 The Fast BSS Transition (FT) Handshake

快速BSS传输协议

Amendment 802.11r added the Fast Basic Service Set (BSS) Transition (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.

802.11r修正案将快速BSS传输握手协议加入到802.11中。他的目的是为了减少客户端在热点之间移动所需要的漫游时间。从传统观点来看，这需要一个新的802.1x和四次握手协议。然而，因为快速传输协议依赖于之前连接网络的主密钥，新的802.1握手过程并不需要。另外，他嵌入在4次握手协议中的认证数据集中和重连接数据集中。

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 first 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, finalize the FT handshake, and transport the GTK to the client.

一次正常的FT握手在图9第一阶段。我们观察到，不像四次握手协议，FT握手协议由验证端初始化。前两条消息是认证请求（AuthReq）和认证回复（AuthResp）。他们分别对应了四次握手协议的消息一和消息二，携带了随机生成的随机数，这些随机数用来刷新会话密钥。接着，客户端发送重连接请求（ReassoReq）和热点回复的重连接回复（ReassoResp）。他们和四次握手协议的消息三和四类似，然后结束FT握手，开始传输GTK给客户端。

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 relies on the random SNonce and ANonce to provide replay protection between different invocations of the handshake [1, §13.5.2].

在使用了MIC的消息中，只有两次重连接消息时进行了验证。另外，FT握手协议中的消息都没有保留重放计数。相反，FT则是依赖于随机的SNonce和ANonce来保证不同握手之间的交互，以确保重连的安全。

According to the standard, the PTK must be installed after the authentication response is sent or received [1, §13.9]. This is illustrated by the gray boxes in stage 1 of Figure 9. Additionally, the 802.1x logical port is only opened after sending or receiving the reassociation 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 completed. Combined, this implies that the FT handshake, as defined 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 handshake are vulnerable to a key reinstallation attack.

根据协议标准，PTK必须在认证消息回复发送出去之后或接受之后就要安装至系统内。这个过程在图9的第一阶段的灰色方框内得意说明。另外的，802.1x的逻辑部分只有在发送或者接受到重连请求以后才能被打开。这也就意味着，我们是在假设，即使PTK已经安装了，握手协议仍在被执行，热点和客户端只能传输和接收数据集，这一过程一直持续到握手结束。综合情况来看，这也暗示，FT握手协议正如其在802.11r修正案中定义的那样，并不会被密钥重放的方式攻击到。然而，通过实验和代码审计的方式进行审查，我们发现许多实现方式确是在发送或者接收到重连请求后安装了PTK和GTK。这个行为确是是图9第一阶段的黑盒子中所描述的那样。因此，FT握手协议的大部分实际实现当中，设备仍然受密钥重放攻击。

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.

由于热点为了答复客户端的重连请求，热点会安装PTK，我们的目的就是要重放这个数据集。在实际攻击中，我们特别要注意，热点必须接受重连请求的反复传输。这是因为热点重连应答可能会因为背景噪声或者是客户端新的请求而忽略。

Figure 9 shows the resulting key reinstallation attack against the FT handshake. Note that we do not require a man-in-the-middle position. Instead, being able to eavesdrop and inject frames is sufficient. In the first stage of the attack, we let the client and AP execute a normal FT handshake. We then wait until the AP has transmitted one or more encrypted data frames. At this point, we replay the reassociation request to the AP. Because it does not contain a replay counter, and has a valid MIC, the AP will accept and process the replayed frame. As a result, the AP will reinstall the PTK in stage 3 of the attack, thereby resetting the associated nonce and replay counter. Finally, the next data frame sent by the AP will be encrypted using an already used nonce. Similar to our previous key 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 adversary to replay the reassociation request continuously, each time resetting both the nonce and replay counter used by the AP.

图9表示了针对FT握手协议的密钥重放协议攻击的结果。需要注意的是，我们并没有要求要实现中间人攻击。我们则是采用其他方法，比如窃听和注入数据集的方式，这些都是可行的。在攻击的第一阶段，我们让客户端和热点之间执行一次正常的FT握手过程。接着，我们就等着让热点传输多一点加密数据集。在这个时候，我们就重放重连至热点的请求。因为它并没有携带任何重放计数的信息并有一个合法的MIC，热点便会接收并处理这个重放数据集。因此，热点将会在攻击的第三阶段重新安装PTK，也就是重新设置相关的随机数和重放计数。这和我们之前的研究是一样的，攻击者可以在客户端到热点之间实施一次旧数据重放的攻击，将这个数据发送给热点。我们着重强调了对FT握手协议的攻击是因为FT协议没有包含重放计数。这种攻击方式会让攻击者持续发送重连接请求，每一次重连请求都会让热电使用的随机数和重放计数重置。

We tested this attack against all our three APs supporting 802.11r. The first is the open source hostapd implementation, 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.

我们测试了我们搭建的三个支持802.11r的热点。第一个使用的是开源hostapd实现，第二个是家用Linksys RE700，用MediaTek的实现方式，第三个是专业的Aerohive热点。对于之前提到的密钥重放攻击，三家设备都无法抵御。

Note that if the reassociation response is lost due to background noise, the client will retransmit the reassociation request spontaneously, 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 (additional) protection using a data-confdentiality protocol. In particular, Management Frame Protection (MFP) does not protect authentication and reassociation frames [1, §12.6.19]. Hence, key reinstallation attacks against the FT handshake are trivial even if MFP is enabled.

另外，FT握手协议中的消息在任何情况系都不会经过加密协议处理。特别的，数据集管理保护不会有效地保护认证和重连数据集。因此，对于FT协议而言，密钥重放攻击即使在MFP启用的情况依然有效。

5.3 Abusing BSS Transition Requests

遭滥用的BSS传输请求

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 Transition 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.

FT握手协议只会在设备穿梭于两个热点之中发出。这就限制了论文提及的攻击适用范围。然而，我们可以强制FT握手协议的连接。首先，我们先假设客户端已经连接到了热点上，这个热点是支持802.11r网络的。然后，如果在这个范围内没有其他的热点，我们就通过虫洞攻击的方式伪造出一个和真实热点一样的热点。这种攻击方式让客户端认为目标网络的另一个热点就在附近。最终，我们发送一个BSS传输管理请求给客户端。这个数据集便是将载荷平摊并命令客户端漫游到其他的热点上。这是未授权的管理数据集，因此可以被攻击者丢弃。因此，客户端便接受了这个数据集，并使用FT握手协议漫游至虫洞热点。

We tested this against clients supporting 802.11r. This confirmed that wpa_supplicant, iOS [8], and Windows 10 [52] accept the transition request, and roam to another AP using an FT handshake.

我们测试了支持802.11r的客户端。并且已经证实了，wap_supplicant、iOS和Windows 10都接收了这个传输请求，通过FT握手协议传输至其他热点

6 EVALUATION AND DISCUSSION

评估与讨论

In this section we evaluate the impact of nonce reuse for the data-confidentiality protocols of 802.11, present example attack scenarios, discuss implementation specific vulnerabilities, explain why security proofs missed our attacks, and present countermeasures.

本章节我们将评估802.11数据加密协议的随机数重用所带来的影响，复现漏洞的例子，讨论特定弱点的实现方式，解释在我们的攻击中所忽视的问题以及预防措施。

6.1 Impact of Nonce Reuse in 802.11

802.11的随机数重用影响

The precise impact of nonce reuse caused by our attacks depends on the data-confidentiality 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 key stream. 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.

我们对随机数重用攻击所造成的实际影响将由我们实际使用的加密协议所决定。这种攻击方式在TKIP、CCMP或者GCMP上都能实现，这三个协议都是用了流加密的方式加密数据集。因此随机数重用对于密钥流的重用使用影响的。它可以被用来解密数据包。我们同时认为在我们的攻击中，受害者的重放计数也被重置。因此，所有三个协议都会受重放攻击的影响。

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 field. 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 different MIC key for each communication direction (recall Section 2.4), this allows us to forge frames in one specific direction. The origin of this direction is the device targeted by the key reinstallation attack. Table 3 summarizes this under the rows mentioning TKIP.

TKIP使用了之后，我们就能通过以下方式将MIC密钥恢复出来。第一步，我们滥用随机重放功能来解密TKIP数据包，包括他的MIC域。接着，我们开始攻击脆弱的Micheal算法：通过给定明文数据集和已经解密的MIC值，我们就可以恢复MIC密钥。由于TKIP每次沟通的时候都会使用不同的MIC密钥，这让我们可以随意丢弃任意方向的数据集。在一开始，这种攻击方法的方向是受到密钥重放攻击的设备。

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].

如果我们使用的是CCMP，实际上，攻击只能影响到数据包的重放和解密。尽管当随机数重放时，我们从理论上来讲时可以讨论那些丢弃攻击的消息，但是，这种攻击其实是理论上的，并不能在随机丢弃的消息上使用。

When GCMP is used, the impact is catastrophic. First, it is possible to replay and decrypt packets. Additionally, it is possible to recover the authentication key [43], which in GCMP is used to protect both communication directions (recall Section 2.4). Therefore, unlike with TKIP, an adversary can forge packets in both directions. Given that GCMP is expected to be adopted at a high rate in the next few years under the WiGig name [58], this is a worrying situation.

当GCMP被利用，所受到的影响将是灾难性的。第一，这让重放数据包和解密成为了可能。另外，这样也有可能恢复授权密钥，这个密钥在GCMP的作用是保护各方通信。因此，不同于TKIP，这个协议会让攻击者丢弃双方的数据包。考虑到在接下来的一段时间，GCMP会在WiGig的名义下大面积部署，这个发现让GCMP面临比较危险的处境。

In general an adversary can always replay, decrypt, or forge packets in a specific communication direction. The concrete direction depends on the handshake being attacked. For example, because the 4-way handshake attacks the client, it can be used to: (1) replay unicast and broadcast/multicast frames towards the client; (2) decrypt frames sent by the client to the AP; and (3) forge frames from the client to the AP. However, against the FT handshake we attack the AP instead of the client, meaning we can replay, decrypt, and/or forge packets in the reverse directions. Table 3 in the Appendix summarizes this, taking into account the handshake being attacked.

通常情况下，攻击者可以在特定的传输方向上持续重放，解密、丢弃数据包。具体的方向决定于攻击的握手协议。例如，因为四次握手协议是攻击客户端的，它可以做到：1、重放统一播发和广播/多播至客户端的数据集；2、解密从客户端发送到热点的数据集；3、丢弃从客户端发送到热点的数据集。但是攻击FT握手协议，我们则可以攻击热点，而不是客户端，意味着我们可以重放、解密或者丢弃相反方向的数据集。附录的表格三则总结了各类握手协议情况下可以实现的攻击方式。

Finally, in various cases we can forge messages from the client towards the AP (see Table 3). Interestingly, the AP is generally not the final 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 reflected back to the client.

最终，我们可以在很多种情况下丢弃从客户端传输到热点的数据（查看表格三）。有意思的是，热点通常不是数据集的最终目的地，通常热点会将他传送到最终目的地。也就是说，我们可以将发送到任何位置的数据集都进行丢弃。根据热点的特点，我们设置可以将客户端发送给对方的数据集原样返回。

6.2 Example Attack Scenarios

攻击预演

Among other things, our key reinstallation attacks allow an adversary 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.

我们的密钥重放攻击除了可以让攻击者将TCP数据包解密，还能知道序列号、劫持TCP数据流并插入恶意数据。这就实现了无线网络中一种常见的攻击：在非加密的HTTP连接中插入恶意数据。

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 first goes through an initialization process, and then synchronizes its clock by listening to authenticated broadcast NTP packets [53]. Malhotra 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 certificates [44, 54, 61], DNSSEC [47], Kerberos authentication [47], and bitcoin [25]. Another example is the xAP and xPL home automation protocol. These generally use broadcast UDP packets to send commands to devices [40]. We conjecture that our key reinstallation 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.

能够重放广播数据集和多播数据集，例如组播数据集，同样是一种明显违反安全的行为。我们可以考虑网络时间协议（NTP）来说明这个行为是如何影响系统的。在这种模式下，客户端首先进行一个初始化进程，接着通过监听授权广播的NTP数据包同步它的时钟。Malhotra和Goldberg发现如果这些广播数据集被重放，受害者的机器时间会一直停留在某一刻上。运用我们的组密钥攻击方式，我可以重放这些数据集，即使他们是在一个受保护的无线网络中发送出去的。我们要注意到，控制了时间也就意味着摧毁了许多协议的安全性，诸如TLS认证、DNSSEC、Kerberos认证和bitcoin。另外的例子还有xAP和xPL家庭自动协议。这些协议通常使用的是UDP数据包来发送命令到设备上。我们猜测密钥重放攻击方法会重复发送这些命令。综合起来看，这些例子说明重放广播或多播数据集的影响不应该被低估。

6.3 All-Zero Encryption Key Vulnerability

全零加密密钥设计缺陷

Our key reinstallation attack against the 4-way handshake uncovered special behavior in wpa_supplicant. First, version 2.3 and lower 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 considered 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 receiving a retransmitted message 3, and are also vulnerable to the group key attack of Section 4.

我们针对四次握手协议的密钥重放攻击通过在wpa_supplicant加密协议中的特殊行为得以实现。首先，在2.3版本及以下版本，我们的攻击是没有任何意料之外的副作用。然而在2.4和2.5版本上，会在接收到一条重传的消息三时安装一个全零加密密钥（TK）。这是因为802.11标准中的修改，802.11标准要求在加密密钥安装以后应该将其清除。2.6版本通过只在接收消息三第一次的时候安装密钥的方式修正了这个问题。但是，这也导致修复完这个问题以后，只有在良好的条件下才能被接收，这样导致了消息三的重传，因为消息四会因为背景噪音而丢失。他们并没有考虑到攻击者可能会滥用这个缺陷来强制安装一个全零的密钥。因此，这个补丁并不能做为安全解决方案来处理，并不能解决之前版本的缺陷。由于这个缺陷，所有版本的wpa_supplicant都会在接收到消息三的时候重装组密钥，也就是说这个协议会受到组密钥第四阶段的攻击，并受到影响。

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 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 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]. Finally, we also empirically confirmed that Chromium is vulnerable to the all-zero encryption key vulnerability [68].

由于安卓内部使用了一个简单修改过的wpa_supplicant版本，它同样会遭受到这些攻击。特别要指出的是，我们队官方安卓代码仓库中的wap_supplicant代码进行了分析，发现所有的安卓6.0版本都有全零加密密钥缺陷。Android Wear 2.0一样有这个问题。尽管第三方安卓厂商可能会使用一个不同的wpa_supplicant版本，我们还是有理由相信大多数安卓6.0版本都会受到攻击。也就是说多达31.2%的安卓智能手机易遭受到全零加密密钥攻击。最后，我们通过经验认为Chromimu的内核浏览器一样会遭受全零加密密钥攻击。

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 authentication 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 protocol 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.

首先，何等人证明了四次握手协议提供了密钥保密能力和会话认证方式。密钥保密能力表明只有授权者和接收方能够处理PTK。由于我们并没有去分析PTK，这个密钥仍然是合适的。会话验证是通过匹配对话的标准提示方式来证明其安全性。起初，这个验证方式声称如果攻击者只能通过可信转接消息来获得一个组从而攻击这个协议，那么这个协议就是安全的。我们的攻击包括了我们实施的基于信道的中间人攻击位置，然而，结果表明攻击并没有违反这个特性：我们只需要通过发送（重传的）消息方式来让终端实现握手协议即可。

Second, He et al. proved key ordering and key secrecy for the group key handshake [39]. Key ordering assures that supplicants do not install an old GTK. This remains true in our attack, since we reinstall the current group key. Additionally, we do not learn the group key, hence key secrecy is also not violated by our attacks.

第二，何等人对组密钥握手的密钥排序和密钥保密行为进行了验证。密钥排序保证接收方不会安装一个旧的GTK。由于我们安装的是当前的组密钥，所以密钥排序仍然是有效的。另外我们并没有分析组密钥的保密性为，因为密钥保密性为并没有违背我们的攻击方式。

However, the proofs do not model key installation. Put differently, they do not state when the key is installed for use by the data-confidentiality 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-confidentiality protocol.

然而，这个模型并没有验证密钥安装。也就是说，当数据加密协议需要时候密钥安装的情况并没有在证明中说明。实际上，这也研究表明同样的密钥可以被安装多次，由此便可以重置相关的随机数和（或者）加密协议的重放计数。

6.5 Countermeasures

应对措施

Key reinstallation attacks can be mitigated at two layers. First, the entity implementing the data-confidentiality 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 implementation into installing a different (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 (different) 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 installed once into the entity implementing the data-confidentiality 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 of wpa_supplicant is doing.

第二种解决方法是保证数据加密协议在握手阶段执行的时候，特定密钥只能安装一次。例如，在四次握手协议中生成的会话密钥只能被安装一次。当客户端接收到消息三的时候，他应该被重放，当不能重新安装好会话密钥。这个可以在消息三的状态击中通过增加一个boolean变量来解决这个问题。开始的时候，这个变量值为false，在PTK-START阶段生成了一个新的PTK后，应该立刻设置为true。如果变量为true并且进入了PTK-DONE阶段后，PTK就已经被安装了，变量也因该设置为false。如果boolean是false并进入了PTK-DONE，PTK的安装过程就应该跳过。注意到这也就是目前2.6以及更高版本的wpa_supplicant所做的事情。

Proving the correctness of the above countermeasure is straightforward: we modeled the modified 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].

要证明以上应对措施的有效性是非常容易的：我们在NuSMV应用了一个修改后的状态机，并使用这个模型来证明间隔一个新生成的PTK的情况下，两个相同密钥安装的安全性。这证明了同样的密钥永远不会被安装两次。特别地，密钥保密性和会话授权也被证明是安全的。

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 affected by some variant of our attacks will be made available at [22].

我们已经向我们的合作伙伴报告了我们发现缺陷，以及应对措施。我们在[22]处列出了所有已知受我们的攻击及其变式所影响到的合作伙伴。

6.6 Discussion

讨论

There are some important lessons that can be learned from our results. First, the specification of a protocol should be sufficiently precise and explicit. For example, when attacking the 4-way handshake in Section 3.3, we observed that the 802.11 standard is ambiguous as to which replay counter values should be accepted. A more precise or formal specification would avoid any such potential incorrect interpretations.

从我们的攻击结果来看，有许多功课需要去做。首先，我们所提及的这些协议必须非常精切和明确执行安全标准。例如，在3.3部分中提到的，当攻击四次握手协议的时候，我们发现802.11标准实际上对于接受哪个重放计数值是非常模棱两可的。还有一个标准便是应该避免此类不正确的协议执行。

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 reflect reality. This is because it did not define 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 counterproductive: once a protocol is formally verified, the community may become less interested in auditing actual implementations.

第二，不能认为因为协议被证明是安全的，就认为它的实现是安全的。在我们的实验中，四次握手协议在之前的证明中并没有完整地实现。这是因为他在会话密钥是否安装的问题上并没有进行定义。因此，会话密钥只被安装一次的情况是无法保证的。只有当我们看到到了源代码，我们才能知道之前的模型其实并没有符合实际预期，导致密钥被重装。在这种情况下，之前的安全协议证明反而适得其反：协议得到了安全性证明，由此社区就对协议实现的具体内容失去了兴趣，审查也就不那么仔细。

Interestingly, the observation that a model may be wrong, and therefore does not accurately reflect reality, also applies to the proof of our own countermeasure. Put differently, 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 reflect certain implementations, patches of vendors may be flawed, or a vendor may be affected by as-of-yet unknown variants of the attack. As a result, it is critical to keep auditing and testing actual implementations.

有趣的是，在研究的过程中发现，模型有可能是错误的，因此有可能并没有完全反映真实情况，同样这也对我们的应对措施造成影响。也就是说，不是因为我们在NuSMV中验证了应对措施，所有的协议实现现在都是安全的。实际上，我们之前的状态机并不能准确反映目前的实现，对漏洞进行的补丁也有可能有问题，或者目前的措施可能会因为这种攻击的变形而失效，对协议造成影响。因此，我们有必要继续保持对现有实现地审查和测试。

Another lesson is that the data-confidentiality 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.

另外的一个问题就是，数据加密协议应该对随机数重用进行必要的预防。例如，在GCMP中，授权密钥会在随机数重用的情况下恢复出来。这个方式在CCMP中是无效的。更一般的，随机数无用保持加密集应该用到协议上，例子有AES-SIV，GCM-SIV和HS1-SIV。这就减小了随机数重用的影响，也由此减小的密钥重放攻击的影响范围。

7 RELATEDWORK

相关研究

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 flaw is not just present in implementations, but in the protocol specification (standard) itself.

我们并没有在密钥重放攻击上对相关工作进行总结。因此，这也就解释了为什么我们研究的加密无线握手协议对这些攻击没有任何防护，这有可能是因为我们没有进行相关的工作所导致的。例如，我们直到现在才发现使用了14年的四次握手协议对密钥重放协议是没有任何抵御效果的。更为重要的是，这个缺陷不仅仅是在标准的实现上，在标准本身就是有问题的。

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 affect the security of the protocols we studied, since these handshakes are precisely used to avoid maintaining state between old and new connections.

还有一种场景同样会导致随机数重用的作用失效。在这种情况下，作用失效以后，密钥从启动中没有违反规则的内存中重新存储起来，但是随机数却被重设成最初值。Zenner提供了解决这个问题的一些建议。然而，不像密钥重放攻击，不能通过远程网络操作的方式触发电力失效。他需要物理接触要被攻击设备。更重要的是，电力失效并不会影响我们研究的这些协议，因为这些协议都非常精确地用来维护在旧连接和新连接直接的状态。

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 flaws in the specification (or implementation) of the handshake protocol.

在第16篇文献中，Bock等人发现有些TLS服务器使用了静态的随机数。这是因为他们所使用的软件对于TLS记录层协议的实现上存在错误。也就是说，他并不是因为重装了一个已经使用过的密钥而造成的。另外，一些服务器使用的是随机生成的随机数，这也就意味着在实际情况下，生日攻击的方法随机数重用的情况还是有可能出现的。

McGrew wrote a survey of best practices for generating IVs and nonces, and summarizes how they are generated and used in several protocols [51]. However, in the discussion of security risks, (variations of) key reinstallation attacks are not mentioned.

McGrew写了一个关于生成注入向量和随机数的最佳实践的调查，并总结了他们在协议里是如何生成和使用的方法。然而，在安全威胁的讨论当中，密钥重装攻击及其变式并没有提及。

Another somewhat related work is that of Beurdouche et al. [14] and that of de Ruiter and Poll [27]. They discovered that several TLS implementations contained faulty state machines. In particular, certain implementations wrongly allowed handshake messages to be repeated. However, they were unable to come up with example attacks that exploited the ability to repeat messages. We conjecture that an adversary can repeat certain messages to trick an endpoint into reinstalling the TLS session keys, i.e., a key reinstallation attack might be possible. We consider it interesting future work to determine whether this leads to practical attacks.

Beurdouche等人和de Ruiter和Poll也进行了相关工作。他们发现一些TLS的实现包含了错误的状态机模型。特别的，有一部分特定的实现错误地允许握手协议重复接收。然而，他们不能提供利用这种错误的攻击方式。我们推测攻击者可以通过重复具体的消息来欺骗终端重装TLS会话密钥，也就是说，密钥重放攻击还是有可能的。我们认为这会是未来的一个关注点，来研究是否真的有可能实现具体的攻击。

Reuse of IVs is also an issue in the broken WEP protocol [17, 18]. In particular, Borisov et al. discovered that certain wireless network cards initialized the WEP IV to zero each time they were (re)initialized. Consequently, key streams corresponding to small IVs are likely to be reused [18]. However, in contrast to key reinstallation attacks, these IV resets cannot be triggered remotely.

在一个受损的WEP协议中重用注入向量同样是一个问题。特别地，Borisov等人发现，特定的无线网络令牌将WEP注入向量初始化为零，在他们初始化和重新初始化的时候都会有这种情况。因此，基于小型注入向量的密钥流有可能会被重用。然而，相比于密钥重放攻击，这些注入向量的重设不能通过远程的方式触发。

7.2 Wi-Fi and Network Protocol Security

无线和网络协议的安全

In one of the first formal analysis of the 4-way handshake, He and Mitchell discovered a denial-of-service vulnerability [38, 55]. This led to the standardization of a slightly improved 4-way handshake [1]. In 2005, He et al. presented a formal correctness proof of both the 4-way handshake and the group key handshake [39]. However, they did not explicitly model cipher selection and downgrade protection. This enabled Vanhoef and Piessens to carry out a downgrade attack against the 4-way handshake [72]. In their attack, the AP is tricked into using RC4 to encrypt the group key when it is transported in message 3. This attack is only possible if the network supports WPA-TKIP, which was already known to be a weak cipher [66, 69]. Additionally, the models employed in [39] do not define when to install the negotiated session key or transported group key. However, we showed this timing is in fact essential, since otherwise key reinstallation attacks may be possible.

在对四次握手协议的第一批安全性测试中，He和Mitchell在一次实验中发现了一个拒绝服务攻击的弱点。这导致了一个轻量级的四次握手协议的标准修订。在2005年，He证明了四次握手协议和组秘钥协议的安全性。然而，他们并没有研究加密选择模型和版本降级的安全性。这导致Vanhoef和Piessens实施了一次对四次握手协议的版本降级攻击。在他们的攻击中，热点受到了欺骗，使用了RC4去加密组密钥，从而发送消息三。这种攻击只会在网络支持WPA-TKIP协议的时候才起作用，而且WPA-TKIP已经被证明是一个弱加密算法。另外的，当安装协调会话密钥和已传输的组密钥时，在第39份文献中部署的模型并没有进行分析。然而，我们证明现在这是需要去分析的时候，因为其他的密钥重放攻击是有可能实现的。

The FT handshake is based on the 4-way handshake [5], but there are no formal security analysis of it. Instead, existing works focus on the performance of the handshake, examples being [11, 46].

FT握手协议是基于四次握手协议的，然而目前并没有人能够证明它是安全的。相反，目前有工作正在研究FT握手协议的过程。相关例子在文献11和46中有提及。

Several works study authentication mechanisms which negotiate master keys (PMKs) [19, 21, 59, 75]. Some of these mechanisms rely on first establishing a secure TLS session [9]. As a result, recent attacks on TLS also affect these mechanisms, examples being [10, 14, 15, 27, 62]. In this paper we did not study mechanisms that negotiate master keys, but instead focused on handshakes that derive fresh session keys from such a negotiated or pre-shared master key.

已经有一些人正在研究验证机制，这种机制一般是就主密钥进行沟通。这些机制中有一部分依赖于先前建立的一个安全的TLS会话。因此，近期针对于TLS的攻击也会对这些机制产生影响，第10、14、15、27、62篇文献中介绍了几个例子。在这篇报告中，我们不会研究这个用主密钥进行沟通的机制，但是主要关注于在一个已经协商好的或者已经共享出来的主密钥中生成新的会话密钥的握手协议上。

Regarding data-confidentiality protocols, the first practical attack on WPA-TKIP was found by Beck and Tews [66]. They showed how to decrypt a small TKIP packet, recovered the MIC key, and subsequently forged packets. Their attack was further improved in several works [36, 67, 69, 70]. Researchers also attacked the weak per-packet key construction of TKIP by exploiting biases in RC4 [6, 57, 71]. Nowadays TKIP is deprecated by the Wi-Fi Alliance due to its security issues [74].

至于数据加密协议，Beck和Tews发现了在WPA-TKIP上的实际攻击。他们展示了如何解密一个简单的TKIP数据包，恢复MIC密钥，最后丢弃数据包。他们的攻击在之后的研究当中得到了提升。研究者们还可以通过攻击RC4中的别名来攻击TKIP中脆弱的每次生成密钥。现如今，TKIP已经因为WiFi联盟的安全因素考虑而遭到弃用。

Although CCMP received some criticism [60], it has been proven to provide security guarantees similar to modes such as OCB [42]. In [31], Fouque et al. discusses theoretic message forging attacks when nonces are repeated in CCMP.

尽管CCMP受到了批评，但是它依旧因为提供了类似于OCB的模型的安全防御措施从而证明是安全的。在第31篇文献中，Fouquen等人从理论上证明了，如果随机数在CCMP中得以重用，消息丢弃攻击还是有可能实现的。

The GCM cipher is known to be weak when short authentication tags are used [29], and when nonces are reused [43]. Böck et al. empirically investigate nonce reuse when GCM is used in TLS [16], and discovered several servers that reuse nonces. Our attack on GCMP in 802.11 is unique because we can control when an endpoint reuses a nonce, and because GCMP uses the same (authentication) key in both communication directions. Several cryptographers recently referred to GCM as fragile [35, 56].

当短认证标签使用在GCM加密和随机数重用的时候，GCM加密被认为是非常危险的。Bock等人从经验上调查GCM在TLS中使用时的随机数重用情况，发现有几台服务器是会重用随机数的。我们针对802.11上的GCMP攻击是相当独特的，因为在终端重用随机数的情况下，我们能够随心所欲地控制，同时GCMP在通信两端使用了相同的（认证）密钥。几位密码学专家已经将GCM标记成不安全。

Finally, other works highlighted security issues in either Wi-Fi implementations or surrounding technologies. For example, design flaws were discovered in Wi-Fi Protected Setup (WPS) [73], vulnerabilities were found in drivers [13, 20], routers were found to be using predictable pre-shared keys [45], and and so on.

最终，其他的研究则重点关注了WiFi的应用和衍生技术的安全性。例如，WiFi保护设置的设计缺陷，驱动的缺陷，路由则使用了可预见的预共享密钥等等。

8 CONCLUSION

结论

Despite the security proof of both the 4-way and group key handshake, we showed that they are vulnerable to key reinstallation attacks. These attacks do not violate the security properties of the formal proofs, but highlight limitations of the models employed by them. In particular, the models do not specify when a key should be installed for usage by the data-confidentiality protocol. Additionally, we showed that the PeerKey and fast BSS transition handshake are vulnerable to key reinstallation attacks.

尽管四次握手协议和组密钥握手协议都进行了安全认证，我们现在发现他们对于密钥重放攻击是有缺陷的。这些攻击并没有违反之前的安全验证措施，却发现了协议模型上根本存在的问题。特别的，在加密协议使用的安装密钥上，协议模型并没有指明是什么密钥。另外，我们发现PeerKey和快速BSS传输握手协议对于密钥重放攻击是一样有缺陷的。

All Wi-Fi clients we tested were vulnerable to our attack against the group key handshake. This enables an adversary to replay broadcast and multicast frames. When the 4-way or fast BSS transition handshake is attacked, the precise impact depends on the data-confidentiality protocol being used. In all cases though, it is possible to decrypt frames and thus hijack TCP connections. This enables the injection of data into unencrypted HTTP connections. Moreover, against Android 6.0 our attack triggered the installation of an all-zero key, completely voiding any security guarantees.

我们是用了组密钥协议对所有无线客户端进行了攻击，发现设备都存在缺陷。这就让攻击者能够重放广播和多播数据集。当四次握手协议和快速BSS传输握手协议被攻击的时候，具体的影响要看具体的数据加密协议使用。在目前研究所有的案例看来，解密数据集并劫持TCP连接是有可能的。这让注入到未被加密的HTTP连接数据中成为潜在的可能性。更重要的是，在Android 6.0上，我们的攻击会导致一个全零密钥的安装，这就导致之前所有的安全保证全部消失。

Rather worryingly, our key reinstallation attack even occurs spontaneously if certain handshake messages are lost due to background noise. This means that under certain conditions, implementations are reusing nonces without an adversary being present.

更为严重的是，如果具体的握手数据由于背景噪声的原因丢失了，我们的密钥重放攻击会自发产生。这也就是说，在某种具体的情况下，在没有攻击的时候，这些协议在实现的时候就有可能重用了随机数。

An interesting future research direction is to determine whether other protocol implementations are also vulnerable to key reinstallation attacks. Protocols that appear particularly vulnerable are those that must take into account that messages may be lost. After all, these protocols are explicitly designed to process retransmitted frames, and are possibly reinstalling keys while doing so.

在未来的研究中，一个值得关注的方向是确认其他的协议在实现上是否对密钥重放攻击同样有缺陷。协议之所以对密钥重放攻击有缺陷是因为他们没有考虑到消息可能会丢失的情况。最后，这些协议必须十分明确地去处理重传的数据集，并对在处理的过程中对可能的密钥重装情况进行恰当的操作。