这究竟是个什么样的漏洞，可以用来蹭网吗？

华强北估计很关注本地漏洞 PoC，毕竟涉及到新一波的“破解王”生意啊。不过很遗憾地说，这次的 KRACK 攻击是无法破解出采用 WPA2 加密无线网络的 WiFi 密码的，所以蹭网想都别想了；家里的 WiFi 密码什么的，也不用改了。有一定网络工程基础的同学可能会觉得奇怪，既然连 WiFi 密码都破解不出来，攻击又如何窃听用户的无线传输数据呢？因为无线传输数据都是经过加密的，攻击者拦截到之后就是一堆乱码而已，解密理论上需要 WiFi 密码。在 WiFi 密码不可知的情况下，这些数据也能破解出来？

在说漏洞之前还是照例说些背景知识。客户端（比如你的手机）接入 WiFi 网络的时候，WiFi 热点（下文称为 AP）会首先对你进行身份认证，对我们普通用户而言，身份认证最直接的表现就是需要我们输入 WiFi 密码。在随后的过程中，对于 WPA 而言，客户端需要和 AP 首先进行所谓的“4 次握手”，双方建立起关系才能继续互通消息。4 次握手完成后，你的手机才能上网。客户端与 AP 四次握手的方式如下图所示（4-way handshake 阶段）：

说简单点，就是客户端和 AP 之间来回发 4 则消息（图中的 Msg1、2、3、4，上图的 r 是 replay 计数器）。四次握手的过程中，双方会协商一个 PTK 会话密钥（注意这个 PTK，这里我们不讨论 GTK 群组密钥的情况）。客户端在接收到 Msg3 之后，就会安装双方协商好的 PTK 密钥（并给 AP 回传 Msg4）——如上所述，此后，客户端和 AP 之间的普通数据传输就会利用密钥来加密，这才保证了空气中数据交流的安全性。

但由于无线网络的不稳定性，Msg3 在传输过程中可能会丢失。考虑到这一点，802.11i 标准要求，如果 AP 发出 Msg3 之后，没有收到客户端的响应，就会认为 Msg3 可能没送到，于是就会再次发出 Msg3（或 Msg1）。这样一来，AP 可能多次发出 Msg3，客户端也有可能多次收到 Msg3。客户端每次收到 Msg3 都会重新安装一次 PTK 密钥，重置增量传输包数（随机数）和接收 replay 计数器（客户端必须处理再度收到的 Msg1 或 Msg3 是 802.11r 规定的）。

问题的症结就在这里，攻击者可以在此扮演中间人的角色，恶意拦截并阻止 AP 收到 Msg4（如下图中间列所示）。这样一来，AP 一直收不到客户端发出的 Msg4，AP 就会给客户端反复发送 Msg3。原本客户端在收到 Msg3 之后安装密钥，并传出 Msg4。此后，客户端就认为四次握手已经结束了，所以开始用协商好的密钥进行常规数据通讯。但这个时候再度收到 Msg3，唯有再度重装相同 PTK 密钥，重置随机数。

加入中间人角色，此图仅考虑客户端在安装 PTK 密钥后，仍接收明文 Msg3 的情况

说这么多，感觉挺装（kan）逼（bu）的（dong），其实这里的核心在于客户端反复收到 Msg3，并反复重装 PTK 密钥。这个过程会重置相应数据保密性协议的随机数——记住这个随机数。攻击者因此也就可以控制该随机数重复使用，在掌握一定已知条件（比如你事先就知道某个数据包本身的内容，根据 paper 的描述，这个已知条件并不难造）的情况下，就可以解密，甚至伪造数据包了（伪造数据包的方法还涉及到解密 TCP SYN 包，攻击者需要获取某个连接的 TCP 序列号，并劫持 TCP 连接）。控制了这个随机数有什么价值？为什么就能解密数据包？如果你关心这个问题，请继续往下看。

在此之前，我们来看个更有趣的发现：有个东西叫 wpa_supplicant，这是 Linux 系统中普遍使用的一个 Wi-Fi 客户端。在研究人员研究 KRACK 攻击的过程中发现，wpa_supplicant 2.4/2.5 版本在收到重新传送的 Msg3 之后，会安装“全零（all-zero）”加密密钥（TK，注意这个 TK 密钥，TK 密钥是真正用于加密常规传输的数据的）。这太不可思议了，已经算是非常大型的加密漏洞——但听起来像是实施层面的漏洞。然而这种方案似乎也是遵循 802.11 标准指导的结果，“802.11 标准间接地建议，在 TK 密钥安装后就将其从内存中清除”（实施层面的理解错误？）。wpa_supplicant 2.6 虽然已经尝试修复该问题（仅在首次收到 Msg3 后才安装 TK 密钥），但由于考虑得仍然不够周到，所以攻击者仍然有办法迫使客户端安装全零密钥。

全零加密密钥漏洞可以用来干嘛？在加密密钥已知的情况下，解密数据还是难事吗？不过接下来才是最关键的，Android 系统就采用 wpa_supplicant（修改版）：Android 6.0 及更早版本就存在这个“全零加密密钥漏洞”。实际上，Chromium 也存在此漏洞（还有 Android Wear 2.0）。对普通终端用户而言，这个意外发现的漏洞应该是目前 KRACK 攻击最大的影响所在，Android 才是本次漏洞的最大受害者（不知道国内早前是否有手机制造商修改了 Android 原生的 wpa_supplicant）。

在这部分的最后，装逼又要开始了，咱来聊聊上面提到控制 Msg3 重传来重复使用随机数这件事究竟有什么价值。如果你对这部分的原理细节不感兴趣，那么请直接跳过到下一小标题。

WPA 的数据保密协议主要有 TKIP、（AES-）CCMP、GCMP。这三种协议都采用流密码来加密数据帧，随机数的重复使用基本就意味着密钥流的重复使用，最终就可以进行数据包的解密。这里还需要对更多 WPA2 涉及的密钥做解释。

对任何加密协议而言，密钥都不可能只有一个。首先，在四次握手的过程中，握手数据就需要加密，所以握手期间最先有了 PMK 密钥（PMK 密钥源于共享 WiFi 密码）。如上所述，握手阶段会协商出 PTK 密钥（即所谓的会话密钥）。这个 PTK 密钥是怎么来的呢？它的来源包含了 PMK 密钥、ANonce（AP 随机数）、SNonce（客户端随机数），以及 AP 和客户端的 MAC 地址。PTK 密钥生成之后还会进行切分，切分成 KCK（密钥确认密钥）、KEK（密钥加密密钥）和 TK 密钥。KCK 与 KEK 密钥是专门用来保护握手信息的，TK 密钥则如前文所述用于对普通数据进行加密。

这里以 TKIP 数据保密协议为例（虽然这个协议已经逐渐被抛弃），如果我们选择 TKIP 为数据保密协议。承接上一段，随后 TK 密钥部分还会再行切分，切分为 1 个 128 位加密密钥，和两个 64 位 MIC 密钥。其中一个 MIC 密钥用于 AP 到客户端的通讯加密，而另一个密钥则用于客户端到 AP 的通讯加密。加密采用 RC4 算法，每个数据包的密钥，都混合了 128 位加密密钥、发送方 MAC 地址和一个增量 48 位随机数。这里的随机数在传出一帧之后就会增加，作为接收方的 replay 计数器——在安装 TK 时会重置为 1。

802.11 标准下的 4 次握手状态机（State Machine）

又是好枯燥的几段话啊，总之就是随机数在其中扮演重要作用。我们的目标是破解 MIC 密钥（就是用于双方通讯加密的密钥）。对 TKIP 而言，获得 MIC 密钥大致上是这么做的：攻击过程首先利用随机数的重复使用，来解密一个完整的 TKIP 包，这个包包含了 MIC 字段。由于此间消息可靠性采用 Michael 算法，利用 Michael 算法的弱点（给定明文帧和解密 MIC 值的情况下就能）获得 MIC 密钥。

这也基本解释了为什么，KRACK 攻击可以解密数据包，监听无线传输，但却无法获得 WiFi 密码（也无法还原完整的 PTK 密钥），也就没有办法蹭网的原因。不过我们在此探讨得非常理论，整个过程还面临很多实际问题，比如说攻击者这个“中间人”的位置究竟该怎么建（建立一个恶意 AP，在真正的 AP 和客户端之间转发数据包）；还有更麻烦的，比如在某些具体实施方案中，客户端如果在一次收到 Msg3 之后安装 PTK 密钥，就只接受加密信息了，忽略 AP 重新传出的未加密 Msg3，这怎么办？

实际上整个攻击过程面临的实际问题还非常多，有兴趣的可以去仔细研究下原 paper[4]。