4  RC4在四次握手中的应用

在这一节，我们会展示一种使用降级攻击的方法来攻击4次握手。结果，RC4是用来在握手机制中加密敏感信息的算法。我们展示两种在握手机制中使用RC4加密的攻击方法，并说明它是如何允许攻击者获取组密钥的。我们也设计出了一种攻击方法，并提出了应对措施。

4.1  降级攻击

在监测图2 中4次握手机制时，我们可以看到在客户端验证AP的 Ies之前，AP会发送组秘钥(GTK)到客户端。回想一下，这些字段包含AP支持的密码套件，它们以明文信标进行通知。换句话说，在AP在第三次握手发送组秘钥之后，客户端才能检测到出现了一个降级攻击。这就产生了问题，因为如果多个加密算法可以用来保护握手机制，则攻击者可以尝试进行降级攻击，以使AP使用弱密码来加密和传输组密钥。

有趣的是，四次握手机制真的可以用多种加密机制来保护[21, x11.6.2]，这就意味着降级攻击是可以实现的。更具体地说，握手机制中使用到的加密算法是由客户端关联请求中的两个设置决定（参见图2）。

表 1: 四路握手中用到的加密算法

尤其是，当请求支持快速网络传输时，四次握手机制会采用AES-CMAC 和 NIST AES加密算法。否则，用来加密握手机制的算法是根据成对秘钥来决定，在成功通过握手机制后，这个加密算法会被用来加密常用的数据帧。如果要使用CCMP，四次握手协议使用HMACSHA1

NIST密钥算法。更麻烦的是，如果采用TKIP协议，HMAC-MD5和RC4算法会分别用来认证和加密数据，这个选择过程的概述见表1。

我们现在打算搭建一个流氓AP，在公告的时候只支持TKIP加密。因此受害者如果想连接到AP上就会使用TKIP协议，反过来在四次握手传输密钥将使用RC4加密。这是因为客户端只在接收Msg3后才能检测到降级攻击。但是，要使AP发送Msg3，它必须首先接收并成功验证Msg2的完整性。如果无法通过协商的会话密钥验证其完整性，AP将无法继续握手。由于会话密钥与客户端和AP的MAC地址有关，这意味着我们必须创建一个与真实AP的MAC地址相同的流氓AP。

庆幸的是，通过执行一个基于频道的中间人攻击（46），这是有可能实现的。本质上，攻击者在不同的频带上克隆AP，并将包转发到真实AP。不修改转发帧中的MAC地址。这保证了站点和AP将生成相同的会话密钥，这意味着在AP中将成功地验证第二次握手的真实性。中间人这个位置允许攻击者能可靠的抓取数据包。尤其是，它会利用这一地位修改信标和探测响应，使AP看起来只支持（WPA-） TKIP加密 。因此，客户端将被迫选择TKIP，导致AP使用RC4加。            

         我们测试了一下用这个降级的方式攻击一个广播报文支持TKIP和CCMP协议的网络。.因为流氓AP只支持TKIP协议，受害者就会选选择TKIP协议。然后，我们就可以确保AP只会使用RC4加密组秘钥，客户端只有在第三次握手之后才会检测到已经受到攻击。

有趣的是，四次握手机制使用RC4加密的方式十分独特[22, x8.5.2j]。每个消息RC4密钥是16个字节的初始化向量（IV）的级联和16字节的密钥加密密钥（KEK）。此外，初始的256个密码流字节也减少了。这个结构和在WEP中的有点类似，假设IV再长一点，初始的密码流字节就会更少。使用更长的IV似乎会减弱每个消息的秘钥长度[28, 36]，而减少的初始密码流字节恰恰是应该加强的东西。在接下来的两节中，我们分析了这种特殊组合的影响。

4.2 恢复Key Encryption Key

我们首先检查是否可以执行类似于那些WEP上的密钥恢复攻击[11, 42]。一般来说，这些攻击是适用于IV被附加到一个固定的秘钥上的情况。这个符合在四次握手机制中每个消息的秘钥K的数据结构，这个秘钥中公共16字节的IV是附在静态的16字节KEK秘钥上。每个秘钥的构造如下所示：

K = IV||KEK

虽然RC4的前256密码流字节被简化了，Mantin表示这并不能预防秘钥恢复攻击[28]。我们采用Mantin的方法攻击四次握手，研究在实际上这种攻击方法是否可行。

类似于原始的FMS攻击[11]，Mantin使用了一个迭代的过程来恢复密钥K[28]。也就是说每次的迭代假设前x字节的K是已知的，并试图恢复下一个字节K[x]。Mantin新的迭代攻击方式第一步，是在SKSA条件下，收集IV

我们将这些称为可用的Ivs，这些可用的IVS会泄露秘钥的K[x]字节，通过下列关系[28]:

利用这些关系，通过一个简单的表决机制就可以恢复K[x]。每一个IV通过等式（1）都会生成一个确定的值。在所有的IVS通过计算，出现最多的那个数字就可以假定为K[x]的值。这样做不好的一个方面就是任何一个字节算错意味着整个K秘钥都算错了。为了减少这种情况，我们用C来代表每个字节最可能是的值，我们得出C16计算值作为K秘钥，每个计算值可以根据抓取到的Ivs和相关的密码流进行验证。我们模拟攻击四次握手机制，目标是看恢复KEK秘钥需要抓取多少可用的IVS。模拟的结果如图5所示。

图5：找到16字节KEK的概率和给出可用IVs数量的关系

为了获得80%的成功几率，大概需要收集221组可用的Ivs .注意，执行这次攻击，我们必须确定z257的值。庆幸的是，这个值可以根据可预测的IEs确定，IES位于EAPOL秘钥中数据域的起始位置，这意味着我们可以从这些起始位置的秘钥流中导出。

我们先看看收集到需要的IVs需要多大的精力。首先我们注意到，SKSAx-1 [1]=x满足条件，最有可能的方式是当X的值和在KSA循环1的位置1交换（回顾表格4）。或者更准确地说，j1 = x。因为K[x]在第一次循环似乎没有修改。事实上，如果J=1其他15个循环只改变位置1。假设使用一个随意的初始IV，就不会出现（255/256)15= 0:94。在等式1，j1 = K[0]+1+K[1]（我们假设K[0]≠1，出现这个值的概率很高）。因此，在概率很高的情况下，当k [ 0 ] +k [ 1 ]＝x-1时，IV是适用的。

802.11标准规定，一个站点启动时必须生成一个初始的随机IV，并在消息中使用它后增加IV。换句话说，IV可以看成是一个计数器。然而，它并没有具体说明是否使用大端或者小端计数器。按照以往的经验，这里应该是将IV作为一个大端计数器。从一个防御者的角度，收集到足够数量的可用IV需要很长的时间。假设K[0]+K[1] = x ，也就是说为了满足N个可用IVS来迭代，需要抓取256*n个数据包。

然而可以通过强行中断客户端连接的方法就可获得许多次握手连接的数据包，新的握手连接将使用不同的KEK秘钥。因为我的攻击是假设KEK是固定的，所以这个方法不可用。为了让AP每次在握手机制中使用相同的KEK加密，我们找到唯一的方法是让AP重新发送直到KEK相同为止。

注意，每次发送都会使用新的IV。不幸的是，在AP放弃和终止握手之前，只发送了很少的信息。在下一节，我们会展示一种可以容忍KEK频繁变化的攻击方法。总之，802.11协议中的握手机制对于密码恢复攻击是十分脆弱的。然而，这样的攻击方法似乎也很难普及。

4.3 恢复明文攻击

我们现在把注意力转向明文恢复攻击，攻击者的目标信息，多次在不同RC4密钥加密。先前对RC4的分析已经表明，对TLS和TKIP的攻击在实际应用中已经十分边缘化了，所以这些类型的攻击很容易成功。尤其是，Paterson et al. [37]攻击WPA-TKIP的方式和我们的很像。他们表明，wpa-tkip的RC4密钥中，每个消息的RC4秘钥中，公共的3个字节的前缀生成一个和前缀有关的重定向，并指向RC4秘钥流。  攻击者可以预先计算这些前缀相关的重定向，针对RC4加密的前几个字节准备一次有效的明文恢复攻击。这也促使我们研究一下，是否在四次握手机制中的公共16位IV是否也引用到了IV相关的重定向。因此，我们检查了EAPOL帧中的公共IV是否有重定向，然后，通过模拟演示看这些是否可用于恢复组密钥。

对每个可能有用的IV去计算是不可能实现的，因为这意味着需要计算2128个值。相反，我们根据随机抽取的四个IVS计算出一个详细的秘钥流。这就表明在秘钥流中有长的，与IV有关的重定向。根据这个结果，我们在初始化中将IV0都置0，然后观察IV中每个特定的位置，它们的值是怎么变的，并如何影响秘钥流的分配。我们将在X位置变化的值记成IV0[x] = y.生成所有的数据集需要13个CPU周期以上。

图6：RC4秘钥流中的重定向

图6A和6B分别展示了初始化向量IVa和IVB密钥分配

IVc 和 Ivd 的分配值看起来很像。它们的值是以Python形式随机生成的，如下：

IVa = 0x2fe931f824ef842bf262dbca357bb31c

IVb = 0x48d9859f9fa08bb1599744a20491dd49

IVc = 0x6c1924761b03faf8decc0dfc09dd3078

IVd = 0xe31257489cbe7d91e5365286c26f5023

这些秘钥流分配的每个IV使用245 RC4秘钥加密。为了对比图 6c 和图 9c展示了密钥流完全分配到随机16字节的秘钥中，大概使用了247 RC4生成的。我们观察到，初始化向量会生成许多重定向，可以从图中的直线看出来即使是在256位置之后。通过对比图6c分配到随机到16个字节的RC4秘钥中的重定向，我们可以确定重定向不是由特定的IV值引起的。相反，他们似乎与RC4同时生成的。

我们还生成了16个数据集，在每个数据集置0 的里特定位置的值都会发生变化。就是0 <x< 15在数据集中，我们设定IV0[x] = y ，y的范围是0-255之间。每个数据集是由243生成，产生了相当大的分配量。尽管如此，对这些数据集的检查证实了每一个IV都诱发了特定的重定向，在我们的图表中可以看到直线。关于这些偏见的更详细的讨论超出了范围，留给未来的工作。

现在，我们用与IV相关的重定向来恢复重复的明文，为了得到用恢复明文的攻击方式破解四次握手机制的效果。这是通过预先计算的密钥密文分布和抓取到的密文相结合，这是为了计算每个明文值出现的概率。真实的明文就应该是概率最高的那个值。因为我们的目标是评估

图7：解码一个字节的EAPOLKey Data 域成功的概率

因为我们的目标主要是评估产生的攻击的性能,我们参考以前关于这方面计算的学术。尤其是，我们实现了由 Paterson et al.提出的装箱算法，和Vanhoef 与Piessens提出的单字节候选生成算法。为了保证计算可行，我们假设抓取到的密文有一半是由IVa 生成，另一半是IVb生成的。针对Patersonetal提出的装箱算法，Figure7显示正确解密一个字节的概率。

对于单字节候选生成算法，会返回一序列字节的候选清单，我们首先需要确定组秘钥是被保存在EAPOL Key Data 域的哪一位置。组秘钥的位置是根据支持哪种加密算法决定的。如果RSN网络中只支持TKIP协议，那么它就是从位置30开始保存组秘钥。相反，如果网络支持TKIP和AES 协议，如果旧的WPA信息元素也被添加到RSN IEs3，组秘钥开始的位置就是62.对于其他的配置，组秘钥会被保存在介于30-62之间。

图8：恢复16字节秘钥的概率

在这些位置恢复一个16字节的秘钥，对于需要抓取的密文数量，如图8所示。我们注意到，如果组秘钥保存在从62开始的位置，利用Mantins 的ABSAB重定向 攻击这样的秘钥会很有效。这是这是因为位置62之前的字节是可预测的，因此可以启用破解TLS中的RC4攻击方法。最终，最后,原则上也可以攻击组密钥更新消息，因为802.11标准并没有指明这些消息应该被加密，并且使用成对秘钥[21, §11.6.7].

4.4 应对措施

为了防止受到降级攻击，AP应该取消支持WPA-TKIP。即使攻击者创建了一个流氓AP广播公告TKIP协议，真正的AP也会拒绝任何对TKIP的请求，因此永远不会在4次握手中使用RC4。相同地，客户端也不要连接WPA-TKIP网络

5 滥用组秘钥

在这一节，我们将展示组秘钥可以用来解码和注入攻击，攻击对象也包括单播通信。

5.1 注入单播帧

我们先说明一下如何使用组秘钥注入单播数据帧。这个不是简单地使用组秘钥加密一个单播的数据帧就能实现的，并设置KeyID字段成组密钥使用的id。接收方总是使用成对密钥解密单播帧,并忽略KeyID值(回顾第 2.1节)。而且，,它是不可能来封装单播IP数据包到组寻址帧。事实上，RFC 1122上有说明：站应该丢弃广播或多播链路层地址上接收到的单播IP数据包[5,§3.3.6]。但是，此检查仅在数据包传递到IP层时执行。由于AP不在IP层上运行，但在mac层上，它不执行此检查。受到这一观察的启发，我们使用组密钥对单播IP包进行加密，并将其发送到AP。对于数据帧中的那三个域，我们使用了以下值：

addr1 = FF:FF:FF:FF:FF:FF

addr2 = Spoofed sender MAC address

addr3 = Spoofed destination MAC address

虽然在一个正常的网络AP中，从来不会去处理组寻址帧，我们发现可以通过强制Frame Control (FC)域中的ToDS，来强制Abs去处理我们注入的广播包。为了确保KeyID 域中的值是正确的，攻击者可以监听其他广播帧，或者强制这个值。AP就会用组秘钥来加密这个包。但我们发现数据包的目的地址(addr3)并不是我们的MAC地址，因此这个包会发送给真正的接受站点。如果接收点的MAC地址是另外一个无线站点，AP将使用协议好的成对密钥加密帧，并传输它。

因此，接收方将解密并处理转发的单播帧。如果目的地地址不是无线站，它将通过适当的以太网连接转发。这种技术可以使用组密钥注入IP包、ARP包等。

5.2解密所有的通信数据

因为单播帧会用协议好的成对秘钥加密，我们不能直接用组秘钥来加密单播帧。而且，这样会诱使站点会将所有额IP数据包发送到广播的这MAC地址上，也就是说这个组秘钥现在用来在这个通信中加密。这些流程只要ARP中毒就能实现。使用第5.1节中的技术注入恶意ARP数据包。

在我们的攻击中，我们入侵了客户端的ARP缓存，因为网关的IP地址与广播MAC地址相关联。同样地，在路由器上，客户端的IP地址也会和广播的地址先关联

由于本地网络中的IP地址通常是可预测的，攻击者的机器可以随意强制成客户端和路由器的IP地址。ARP中毒攻击后，客户端和路由器发送的所有IP数据包都使用组密钥进行加密。攻击者现在可以捕获和解密这些包。此外，他可以使用第5.1节的（单播）数据包注入技术将它们转发到真实的目的地，因此受害者不会注意到他受到攻击。

5.3实验验证

我们用一个Asus RT-AC51U路由器和一个windows 7 系统的笔记本测试了这个攻击方法。通过弱的随机数生成器（在第3.4.1节中讨论过）就可以获取组秘钥。

为了成功地执行对Windows的ARP中毒攻击，我们注入了恶意ARP请求。首先，我们能够使用组密钥成功地注入ARP数据包。这证实了组密钥可以用于注入单播数据包。一旦我们入侵了受害者和路由器的ARP缓存，他们就把所有的数据包发送给广播MAC地址。此时，我们能够使用组密钥成功地解密这些广播数据包，并读取受害者和路由器发送的单播IP数据包。

5.4 应对措施

如果网络在基础架构模式下运行，AP应该忽略所有具有广播或多播接收器地址的帧。这可以防止攻击者滥用AP向站点转发单播帧。另一个选项是禁用所有组通信。虽然这看起来有点过激，但对受保护但公共热点很有用。在这些环境中，连接的站彼此不授信，这意味着根本不应该使用组秘钥。有趣的是，即将到来的热点2.0标准在Downstream Group Addressed Forwarding (DGAF)选项下可以支持这一功能 [ 49 ]。如果DGAF功能被禁止，也就没有组秘钥生成，那么站点和AP就会忽略所有组寻址的WiFi通信帧。

6 针对802.11协议的一种新型RNG

在这一节我们写了一个随机数生成器，从Received Signal Strength Indicator(RSSI)信号强度值中随机提取。据具体来说，我们依赖于工具对802.11无线电的频谱扫描特性。这给我们大约每秒三百万个RSSI测量量，即使没有背景流量。

6.1频谱扫描特性

大部分WIFI扫描器，例如AR9280，用于高吞吐量（HT）ofdm4可以测量RSSI超过56个子载波。Atheros称这种特征频谱扫描。它符合解码htofdm调制帧的要求，其中信道分为64个子载波[ 21，18 ]。这些子载波中的八被用作保护以避免信道串扰，因此不进行采样，从而产生56个可用的子载波。因此，频谱扫描特性符合常用的ofdm解调要求相，也应该被其他厂商直接实现。扫描一个样本的时间大概是4µs，这些扫描可以在没有背景流量下进行。每个RSSI测量量以一个8字节的值作为输出。在做了一些优化后，我们可以让AR9280每秒大概生成50k的样本。由于每个样本包含56个RSSI值，所以总共每秒大约有三百万个测sada量值。

6.2 随机数生成器

对于随机数生成器，我们希望可以提取出每个RSSI测量量的随机数。因为我们的设备每秒可以生成大量的测量量，即使是在没有背景流量的情况下，所以我们需要一个快速的方法来处理这些数据。由于我们主要的目的是设计一个方式可以快速处理这些数据。然后输出结果可以作为输入到一个可以适当的提取和管理随机数的系统。(查看样本 Yarrow-160 [25], 或者Barak and Halevi的模型 [3] 还有证明 [9]). 换句话说，我们的目标只是设计一种快速处理RSSI测量值的方法，这种方法可以应用在Wi-Fi无线电中，并对结果输出的质量进行评估。

表2：在不同配置下随机数生成器的静态测试结果平均值

我们首先从每个RSSI测量值中获取一个位（可能是有偏差的）。在接下来的步骤中重定向就会被抑制。由于背景噪声的随机变化，其它站的传输，以及硬件、天线、和内部缺陷，我们猜想每个RSSI测量值都含有一定量的随机性。更准确地说，我们猜想每个RSSI测量值的地位含有大量的随机数。为了考虑到其他位，我们在8位RSSI测量中执行一次异或。即使其他位不是随机的，这只会增加整体的随机性。由于我们提取每个子载波的1位，我们称这个初始生成器为“每个子载波1位”配置。当在这个配置中运行dieharder统计测试程序[ 7 ]，我们看到了希望的结果（见表2）。Dieharder工具是一个重新实现Diehard 测试的方法，同时增加了一些NIST测试工具。虽然没有一个测试失败，平均2.8%的测试返回一个弱结果。然而，这只意味着生成的位没有任何明显的缺陷。一些狡猾的或小的重定向可能仍然存在，必须过滤掉。我们这样做是依靠大量的测量检测

们可以看到当N趋近于无穷大，他们两个的概率都接近于50%，这就意味着重定向能够得到有效的保护。而且在WIFI 无线通信中也应该用上异或操作。

最后，我们标记了在正常执行模式下的生成器，总共56*16 位是经行“或”运算。因此，即使攻击者可以以98%的几率正确预测每个子载波中的一个位，我们正常的执行模式仍可以输出一个格式相近的位。更具体地说，根据等式2和3，返回值得到相同结果的几率接近0:5 *(1-  2-52 )。因此，通过大量的监听工作，即使是一个很强的攻击者也不太可能预测出随机数生成器的结果。而且，这些位输出的速度大概是3125 bps.最后，最后，我们相信我们的技术可以在Wi-Fi芯片本身中有效地实现。在实践中，使用者可以查询Wi-Fi加密算法的随机数样本，并使用一个模型正确、安全地管理这些收集的随机数，如由Barak和Halevi [ 3 ]提出，或它的一个改进[ 9 ]。

7 总结

虽然针对生成802.11成对秘钥已经有了大量的研究，但是我们已经证明了对于组秘钥也是不一样的。对于许多设备，组密钥是很容易预测，这是由802.11标准中提出的错误随机数生成方法引起的。对于嵌入式设备中的Wi-Fi模块来说，这是问题特别严重，因为它们一般没有其他（标准化的）随机性来源。此外，我们已经证明了对四次握手进行降级攻击，会导致设备采用RC4加密算法来保护组密钥。攻击者可以滥用这一点以试图恢复组密钥。我们还发现了，组密钥可以用于注入任何类型的数据包，甚至可以用来解密网络中的所有Internet通信。再加上802.11的自由数生成器存在缺陷，这让攻击者很容易就绕过WPA-TKIP 和 AES-CCMP. 为了弥补其中的一些问题，我们还提出并实现了一个针对802.11个平台的强随机数生成器。

本文由  看雪翻译小组  南极小虾 翻译 

原文链接：https://lirias.kuleuven.be/bitstream/123456789/547640/1/usenix2016-wifi.pdf

阿里云助力开发者！2核2G 3M带宽不限流量！6.18限时价，开 发者可享99元/年，续费同价！