WPA2密钥重装攻击原理分析

这两天最火爆的莫过 “WPA2被破解” 这一条大新闻了。我对其原理非常感兴趣，苦于没有找到的文献，所以就整理这么一篇，方便自己和大家理解。主要是根据目前发布的文章以及一些相关资料。

壹、WPA2的机制

无线通信协议有很多，例如WEP，WPA等都已经被证明不安全，还有TKIP机制也有大量文献说明其缺陷。WPA2协议是WIFI联盟一直力推的协议，被广泛运用在现在的无线互联网络当中；CCMP(Counter Mode CBC-MAC Protocol ）我之前也被推行过很长一段时间，现在有新的GCMP，不过都是基于计数器CTR的，都类似。我下面会以WPA2和CCMP为例解释此次事件。

在WPA2中运用了丰富的密码手段，原因是无线信道的开放性必须有加密措施来保证传输过程的安全。握手协议则是通信双方互相进行一个身份确认的过程。WPA2的四次握手协议是EAPOL（EAP on LAN,即 Extensible Authentication Protocol on LAN）的四次握手协议的落地，，所有的数据包都是使用EAPOL帧进行封装的，EAPOL数据帧的格式可以参考下图：

图1：EAPOL帧结构，来源Mathy Vanhoef团队论文(https://papers.mathyvanhoef.com/ccs2017.pdf)

关于EAP协议：之前在西电上课刚接触到的时候就理解了好一会，因为它不像TCP/IP一样是直接落地的协议。它是一个密码协议，用到相同的密码手段的地方都可以使用它，然后再在不同场景转化为落地的东西，所以一定意义上可以理解成是“指导协议的协议”。所以我看来，这次四次握手出现的问题，也很有可能在其他用到类似密码手段的地方重新出现。这里涉及到很多密码学通用的概念，因此尊重作者，下文将AP（wifi接入点）称为认证方（Authenticator），待接入的STATION称为请求方（Supplicant）。

该帧中关键的点有如下几个

header部分标志了该帧的用途。

replay-counter是一个计数器，用于防止重放攻击：认证方下发认证请求时，设置该值，请求方在回应认证要求时，使用相同的值；在一系列会话中，该计数器递增。

nonce 部分存放之后生成密钥要使用到的值。注意，这里的nonce不是我们后面会话中的nonce。

MIC 作为完整性校验部分，可选。

KeyData 部分未来存放group key用，这里不展开。

那么接下来还是看一下WPA2的4次握手的过程：

图2：来源wikipedia

握手之前会有一些无线发现的过程；WPA2 的4次握手，目标是完成身份认证，建立会话密钥；握手之后是组密钥协商过程，此次事件在这里也发现有问题。

这里很重要，我阐述一遍四次握手的过程。

①、由认证方发起，下发一个握手请求，并且发送了认证方随机生成的nonce值ANonce。

②、申请方收到ANonce之后，也随机生成一个SNonce发还给认证方，同时附加MIC值。

双方在具备两个nonce之后，就可以开始分别计算PTK（Pairwise Transient Key）了。PTK的计算方法可以看作是计算（PMK，ANonce，SNonce，认证方的MAC地址，请求方的MAC地址）这样一个5元组的哈希值。这里的PMK（Pairwise Master Key）则可以看作是ssid和口令(就是平常的wifi密码，不过这里实际是先又口令生成PSK，再到这里）的哈希值。

MIC值是PTK的前16个字节。这里如果双方的MIC一致，说明PMK生成的一致，则说明双方拥有的口令一致（即输对了wifi密码），那么认证方就认可请求方的身份了。

③、认证方生成并发放组会话密钥，同时下发另一个MIC。

④、最后请求方回应一个Ack完成会话。

之后通信双方就可以使用PTK中的各种密钥进行安全的通信了。

贰、问题所在

佩服他们的想法，他们意识到一点，在收到握手包③之后，请求方就会认为生成的PTK是正确的，而不清楚也没有办法验证认证方是否收到了握手包④，安装PTK并开始进行使用其派生的密钥作为CCMP的会话密钥，通过802.1x进行通信了。

而且，在协议的实现上有规定：1、每次生成PTK之后，都要重设CCMP的计数器的值。（有关计数器后面再说）2、处在已经安装PTK状态下的请求方要处理重传的握手包①和③

而对于认证方而言，则不会安装PTK。如果认证方收不到握手包④就会重传握手包③，同时递增其中的replay-counter值来使其有效。这样就出现问题了，一个显而易见的攻击方法是：

攻击者可以事先在申请者和认证者之间占据一个中间人的位置。然后通过阻断握手包④到达认证方来时认证方发送新的握手包③。这样就导致申请方会重新安装PTK，这样，就能够重设CCMP中的计数器。而且基于不同的会话加密协议，可以实现如重放、解密、伪造等能力略有不同。

如何实现中间人：不能简单做中继因为PTK的计算使用到了双方的MAC地址。Mathy Vanhoef团队的方案是使用基于信道不同的AP克隆，同时也保持MAC地址一致。

一个基础的攻击模型如下：

在第一阶段，阻断了回传的握手包④。然后截获了加密的数据报文。然后再下一次认证方发起重传时，再转发之，实现密钥重安装，之后又得到一份计数器被重用之后的密文。如下图，CTR模式下面，密钥流和计数器是关联的，计数器重用就相当于密钥流复用了，在密码学上就标志这短明文沦陷了。而且可以通过重复握手过程来多次实施该攻击。

图4、CTR模式的加密图解（来源wikipedia）

虽然计数器重用以后离恢复明文还有一些密码学上面的路要走，但是该团队还发现了很多有意思的协议实现上面的BUG，导致这个攻击能够相当有威力。就比如视频中演示到的，linux和Android重安装之后的加密密钥变为了空；还有对重传replay字段校验不严格等等也导致了有意思的错误。

叁、最后说两句

至此，基本这个漏洞如何产生的已经基本解释清楚。但是本人其实还有不少问题：

例如视频中，STATION实现上有bug使用的是空加密密钥，AP能够承认并接受这些数据包？

AP未收到握手包④时，STATION发过来的正常通信的数据包是否丢弃，是否会造成网络质量下降或者STATION断网的假像？

……

落笔就发现很多问题Mathy Vanhoef团队披露还不够清楚，也可能是之前对这个协议了解与实现不够，这些模糊的地方也正是研究人员他们花费心力研究的地方。

感觉这个漏洞不全是路由器等认证方一方的问题，请求方也有实现上的缺陷。

个人学习的结果，有什么不对的大家及时指出来。

这次事件还是告诉我，很多以前信任的底层组件，密码协议实现上也许并没有那么健壮。

最后给一些身边非安全相关朋友的建议：

跟紧更新

这个不是蹭网用的，所以不要屯8187啦。

改密码也没有用，控制自家wifi功率，减小一点覆盖范围倒是不错的选择。