WPA2密鑰重裝攻擊原理分析

這兩天最火爆的莫過」WPA2被破解「這一條大新聞了。我對其原理非常感興趣，苦於沒有找到的文獻，所以就整理這麼一篇，方便自己和大家理解。主要是根據目前發布的文章https://papers.mathyvanhoef.com/ccs2017.pdf以及一些相關資料。

壹、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功率，減小一點覆蓋範圍倒是不錯的選擇。