作為一個隻喜歡紙上談兵的傢伙， 最近曝出 WPA/WPA2 協議存在漏洞（可被 KRACK 金鑰重裝攻擊）的時候， 我還是有那麼點小激動的——畢竟這麼多年了，
三年前， 我們曾經寫過一篇蹭鄰居家 WiFi 網的文章， 作為“駭客入門（一）”系列的開篇之後就再也沒有下文了。 這篇文章現在看來雖有諸多值得商榷之處， 不過卻很明確地提到， 無線網路的資料傳輸就在空氣中進行， 遭遇資料劫持的情況比有線肯定要嚴重得多。 想想， 我們在星巴克上個 WiFi， 有個駭客和你一起坐在店裡， 從空氣中劫持你的資料——他知道你在做什麼， 你下單買個東西， 他連銀行卡密碼都知道了， 這不是很恐怖麼？所以說無線傳輸最基本的訴求就是資料加密，
所以在 WEP 加密年代， 華強北銷售的“破解王”們才能如此猖獗地讓你蹭鄰居家的網， 因為由於加密機制缺陷， 那時候的 WiFi 密碼破解太簡單了。
不過可能事情並沒有這麼嚴重， 至少就這次的漏洞來看， 上面說的這些可能都不會發生。
這是協議層面的一連串漏洞做安全生意的人， 以及安全研究人員都喜歡將某個漏洞或缺陷的危害無限放大， 並告訴你：我最近發現了一個超級牛逼的漏洞，
協議漏洞是什麼意思？平常我們聽到的不少漏洞， 比如 Windows、Linux 被曝出漏洞， 都是可以由廠商修復的；其中有一些比較嚴重的漏洞， 比如說 TCP 連接利用漏洞（CVE-2016-5696）[1]， 還有各種 3G 網路可被竊聽， 資料可被解密的漏洞， 雖然和協議似乎還挺有關係， 但大部分都是具體實施層面（implemention）的漏洞。 即這些漏洞都算不上是協議本身的漏洞， 而是某些廠商， 在遵循該協定具體應用到實際軟體或硬體產品的過程中，
而且就當代的實際情況來看， 標準設立都越來越注重安全性， 這和早年很不一樣。 比如 2G 通訊時代， GSM 的資料加密演算法 A5 很多年前就被曝出安全問題[2]；加上 2G 身份認證機制缺陷， 偽基站、電信詐騙都顯得相當稀鬆平常。 到 3G/4G 時代， 尤其 LTE 標準的安全性讓大部分駭客都知難而退， 選擇主攻運營商或終端設備實施層面的漏洞。
實施層面的漏洞，絕大部分是可以通過打補丁來修復的（雖然對某些領域而言，情況可能會比較複雜，比如醫療領域的 IoT 設備，修復漏洞的成本就相當高）。而協議層面的漏洞是怎樣一副面貌呢？好比 GSM A5 加密本身的安全問題，以 GSM 通訊在世界上的實施廣度，這樣的安全問題是幾乎沒有機會得到解決的。
再比如前兩個月，趨勢科技的研究人員發現 CAN 協議漏洞 [3]。CAN 是汽車網路各部分元件進行通訊的協定，問題出在 CAN 標準的資訊系統中，設備讀取 CAN 資訊的特定值時會生成錯誤消息——利用這些錯誤消息的處理流程，攻擊者就能讓系統超載，讓汽車元件進入 Bus Off 狀態。比如說可以因此關閉安全氣囊之類的關鍵系統。這樣的漏洞是無法通過固件升級修復的，需要修改 CAN 標準才行——就已經生產的汽車而言，幾乎是個無解的存在。
而這次打破 WPA2 安全性的 KRACK 攻擊，涉及到的是一連串漏洞，CVE 漏洞編號 CVE-2017-13077/13078/13079……13088，幾乎都可以認為是協議層面的漏洞。不過這些漏洞並非組合起來的一條攻擊鏈，而是不同金鑰方案中 4 次握手的金鑰重裝漏洞（或者接受請求重傳漏洞）。這麼說來，是協議漏洞，且既然這個星球上這麼多人都在用 WiFi，那人類安全性豈不全面完蛋了？你家的路由器，你的蘋果手機，你的 ThinkPad 筆記本，還有你的銀行帳號…問題是，以 CVE-2017-13077 漏洞為例，其基本情況如下：
這個漏洞在 NVD 漏洞庫的危害程度定義為“Medium”（危害程度有 Low、Medium、High 和 Critical 四檔），且攻擊難度略“High”（後續可能會有調整）。What？不是說好了協議漏洞都很牛掰嗎？
這究竟是個什麼樣的漏洞，可以用來蹭網嗎？華強北估計很關注本地漏洞 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]。
為什麼說這個漏洞危害程度有限？在實際攻擊中，有兩個例子很有趣，即 iOS 和 Windows 系統，它們不接受 Msg3 資訊的重傳（如下圖第二列 Re.Msg3 所示）。這樣一來，上面提到的 KRACK 攻擊豈不是無效了？因為不接受 Msg3 重傳，也就幾乎破壞了 KRACK 攻擊的立足點。不過這篇 paper 依舊花篇幅介紹了 802.11R Fast BSS Transistion（FT） 握手過程中，針對 AP 的 KRACK 攻擊，也能令 iOS 和 Windows 投降（802.11R FT 是為了減少用戶端從相同網路下的一個 AP 漫遊到另一個 AP 的切換時間而設的）。這麼看來，就針對 iOS 和 Windows 的攻擊，KRACK 還是比較受限的（不過似乎也受到 GTK 群組金鑰握手攻擊的影響）。
等一等，不是說所有 WiFi 設備都受影響嗎？怎麼還會存在不接受 Msg3 重傳的奇葩？不是 802.11 規定的嗎？的確，iOS 和 Windows 這部分的具體實施方案違反了 802.11 標準。從這個角度來看，在某些更細緻的實施方案中，違反標準的存在也並不奇怪。
針對具體實施方案差異導致的不同後果，除了 iOS 這類特例，還有個例子。在進行 KRACK 攻擊的過程中，攻擊者作為中間人，致使 AP 收不到用戶端發出的 Msg4。在攻擊階段性完成後，攻擊者仍然需要將 Msg4 再轉發給 AP（因為要進行後續通訊資訊的竊聽，就需要完成四次握手，回看本文的第二張表格，階段 4），從我們的常識來判斷，這個轉發過程其實是會遇到困難的，因為轉發的 replay 計數器可能不是最新的。
但 802.11 標準中提到，AP 可以接受四次握手過程中的任意 replay 計數，不需要是最新的（此外，802.11 標準中還提到，初始四次握手的 Msg4 需要以明文發送，但幾乎所有用戶端都會採用加密方式發送）。上面這張表格的第二列，列出了不同產品在 replay 技術檢查方面是否要求最新 replay 計數。
這些例子其實是為了說明，針對 802.11i 的具體實施方案存在各種差別。所以我們才說，在這次的安全事件中，Android 在消費用戶中顯然更容易被攻擊。但也因為這些實施方案差別，不同產品應對 KRACK 攻擊時的耐受性各不相同，如 macOS 的攻擊條件就相對苛刻。也因為實施方案差異，各廠商都以很快的速度推出了自己的補丁，修復了可能被 KRACK 攻擊的情況。
針對 KRACK 攻擊的緩解方案，研究人員的建議主要在於，資料保密性協定的實施方案，要求檢查金鑰是否已經安裝——如果已經安裝則不再重置相應亂數和 replay 計數器，金鑰僅安裝一次。所以即便是協議漏洞，這次的安全問題不算太大。
值得一提的是，漏洞的存在性是一回事，攻擊難度又是另外一回事。比如資訊安全領域具有奇幻色彩的邊通道（side-channel）攻擊，在實驗室中可以不計成本的方式，用電子探針獲取電、磁、熱特性實施攻擊，但這種攻擊方式很多情況下的成本之高，是一般駭客根本無力承擔的；再比如理論上一直都存在針對存儲介質的比特位元翻轉攻擊，在普通人看來都只能是天方夜譚。
KRACK 攻擊在解決安全研究者提到的諸多實際操作問題後，在“解密資料”和“竊取敏感資訊”的問題上，還面臨很大的挑戰。比如說現如今大量 web 和 App 連接採用 HTTPS 加密的方式，其加密的層級和 WPA/WPA2 不一樣，也就是說即便解開了 WPA2 加密，還有另外層級的加密等著攻擊者去解——即便的確有繞過 HTTPS 實施方案的先例，這就又得費一番功夫了，更何況如果加上 VPN 的加持呢…要說竊取支付寶密碼這件事，僅靠 KRACK 攻擊，恐怕還差得非常遠。
而在更具體的攻擊過程中，研究人員還提到，利用其攻擊 PoC 腳本的可靠性是存在空間上的限制的：
“如果受害者離真實網路（也就是 AP）非常近，那麼腳本可能會不起作用，因為受害人此時直接和真實網路進行通訊。”
畢竟研究人員提出，“中間人攻擊”的方案主要還是依託于建立一個惡意 AP 來欺騙受害者連接的。敢情到要攻擊你家 WiFi，還得首先闖進你家去才行啊。在此可考慮的攻擊場景：你的某個朋友最近行為舉止怪異，穿著打扮黑暗，印堂發黑，經常在螢幕前碼代碼，某一天他去你家，口袋裡還裝個古怪的小玩意兒，也不告訴你要幹嘛——別懷疑，他正在進行 KRACK 攻擊。作為一個紙上談兵的人，本文純粹為喜好探尋原理的人準備。
不過最後還是要說：當代網路攻擊通常都是以組合拳的方式進行的，KRACK 即便對攻擊條件有一定的要求，卻也可以作為全套攻擊方案中的一個環節——作為攻擊鏈中的一部分存在後，還可以產生更大的危害。不過其存在價值在我看來，可能更偏重於針對明確目標的竊聽攻擊，以竊取資訊為目的（比如針對企業）；或配合其他攻擊產生危害。一個實際可行的攻擊場景：比如說廣播模式下的 NTP（網路時間協定），在此模式下，用戶端初始化後監聽廣播 NTP 包來同步時鐘。KRACK 攻擊在此可以讓用戶端的時間凝固（對 NTP 廣播幀進行 replay），這樣一來可進一步對 TLS 證書、DNSSEC、Kerberos 認證、比特幣等造成影響。
無論如何，為安全考慮，任何實際存在的安全問題，而且是已經被證明行之有效的攻擊方案，都應該得到重視。所以蘋果、穀歌、微軟之類的廠商都以較快的速度為終端產品推出了修復 KRACK 攻擊的補丁，所有用戶都應該第一時間打上補丁——至於 AP 端，家中的無線路由器、WiFi 放大器等 AP 設備也都應該第一時間安裝廠商所推的新版固件，比如 360 似乎在漏洞出現的 2 天內就為路由器和擴展器產品推了專門的固件補丁。另外，老生常談的那幾樣，不明來源的 WiFi 不要連接，使用公共 WiFi 時也需要謹慎。
據說 WiFi 聯盟對此已經有了測試計畫。他們打算在其全球認證實驗室網路中對漏洞進行測試，為 WiFi 聯盟成員提供漏洞檢測工具，向設備製造商通告漏洞細節，告知用戶安裝最新安全補丁的重要性。有趣的是，這份 paper 的作者早在 7 月份將漏洞上報給 OpenBSD，OpenBSD 最早發佈補丁，而且是在所有人都不知道的情況下默默發佈的 [5]。
WPA2 有漏洞並不可怕，數字世界的任何位置理論上都存在缺陷。判斷某個系統安全與否的標準在於：攻擊某資產，所需耗費的成本，已經超過資產本身的價值；或攻擊不具有簡單可複製性（如大部分攻擊都是首次攻擊投入成本大，後續攻擊成本越來越小或幾乎零成本，如 iOS 越獄），我們就可以認為這個系統是安全的。
[1]Linux 設備 TCP 連接的有趣漏洞：傳說中的 Off-Path 劫持, http://www.freebuf.com/column/133862.html
[2]Hacking GSM A5 crypto algorithm by using commodity hardware, http://securityaffairs.co/wordpress/52666/hacking/gsm-crypto-hacking.html
[3]The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard, http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/
[4]Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, https://papers.mathyvanhoef.com/ccs2017.pdf
[5 ]OpenBSD Errata: August 30th, 2017, https://marc.info/?l=openbsd-announce&m=150410604407872&w=2
實施層面的漏洞，絕大部分是可以通過打補丁來修復的（雖然對某些領域而言，情況可能會比較複雜，比如醫療領域的 IoT 設備，修復漏洞的成本就相當高）。而協議層面的漏洞是怎樣一副面貌呢？好比 GSM A5 加密本身的安全問題，以 GSM 通訊在世界上的實施廣度，這樣的安全問題是幾乎沒有機會得到解決的。
再比如前兩個月，趨勢科技的研究人員發現 CAN 協議漏洞 [3]。CAN 是汽車網路各部分元件進行通訊的協定，問題出在 CAN 標準的資訊系統中，設備讀取 CAN 資訊的特定值時會生成錯誤消息——利用這些錯誤消息的處理流程，攻擊者就能讓系統超載，讓汽車元件進入 Bus Off 狀態。比如說可以因此關閉安全氣囊之類的關鍵系統。這樣的漏洞是無法通過固件升級修復的，需要修改 CAN 標準才行——就已經生產的汽車而言，幾乎是個無解的存在。
而這次打破 WPA2 安全性的 KRACK 攻擊，涉及到的是一連串漏洞，CVE 漏洞編號 CVE-2017-13077/13078/13079……13088，幾乎都可以認為是協議層面的漏洞。不過這些漏洞並非組合起來的一條攻擊鏈，而是不同金鑰方案中 4 次握手的金鑰重裝漏洞（或者接受請求重傳漏洞）。這麼說來，是協議漏洞，且既然這個星球上這麼多人都在用 WiFi，那人類安全性豈不全面完蛋了？你家的路由器，你的蘋果手機，你的 ThinkPad 筆記本，還有你的銀行帳號…問題是，以 CVE-2017-13077 漏洞為例，其基本情況如下：
這個漏洞在 NVD 漏洞庫的危害程度定義為“Medium”（危害程度有 Low、Medium、High 和 Critical 四檔），且攻擊難度略“High”（後續可能會有調整）。What？不是說好了協議漏洞都很牛掰嗎？
這究竟是個什麼樣的漏洞，可以用來蹭網嗎？華強北估計很關注本地漏洞 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]。
為什麼說這個漏洞危害程度有限？在實際攻擊中，有兩個例子很有趣，即 iOS 和 Windows 系統，它們不接受 Msg3 資訊的重傳（如下圖第二列 Re.Msg3 所示）。這樣一來，上面提到的 KRACK 攻擊豈不是無效了？因為不接受 Msg3 重傳，也就幾乎破壞了 KRACK 攻擊的立足點。不過這篇 paper 依舊花篇幅介紹了 802.11R Fast BSS Transistion（FT） 握手過程中，針對 AP 的 KRACK 攻擊，也能令 iOS 和 Windows 投降（802.11R FT 是為了減少用戶端從相同網路下的一個 AP 漫遊到另一個 AP 的切換時間而設的）。這麼看來，就針對 iOS 和 Windows 的攻擊，KRACK 還是比較受限的（不過似乎也受到 GTK 群組金鑰握手攻擊的影響）。
等一等，不是說所有 WiFi 設備都受影響嗎？怎麼還會存在不接受 Msg3 重傳的奇葩？不是 802.11 規定的嗎？的確，iOS 和 Windows 這部分的具體實施方案違反了 802.11 標準。從這個角度來看，在某些更細緻的實施方案中，違反標準的存在也並不奇怪。
針對具體實施方案差異導致的不同後果，除了 iOS 這類特例，還有個例子。在進行 KRACK 攻擊的過程中，攻擊者作為中間人，致使 AP 收不到用戶端發出的 Msg4。在攻擊階段性完成後，攻擊者仍然需要將 Msg4 再轉發給 AP（因為要進行後續通訊資訊的竊聽，就需要完成四次握手，回看本文的第二張表格，階段 4），從我們的常識來判斷，這個轉發過程其實是會遇到困難的，因為轉發的 replay 計數器可能不是最新的。
但 802.11 標準中提到，AP 可以接受四次握手過程中的任意 replay 計數，不需要是最新的（此外，802.11 標準中還提到，初始四次握手的 Msg4 需要以明文發送，但幾乎所有用戶端都會採用加密方式發送）。上面這張表格的第二列，列出了不同產品在 replay 技術檢查方面是否要求最新 replay 計數。
這些例子其實是為了說明，針對 802.11i 的具體實施方案存在各種差別。所以我們才說，在這次的安全事件中，Android 在消費用戶中顯然更容易被攻擊。但也因為這些實施方案差別，不同產品應對 KRACK 攻擊時的耐受性各不相同，如 macOS 的攻擊條件就相對苛刻。也因為實施方案差異，各廠商都以很快的速度推出了自己的補丁，修復了可能被 KRACK 攻擊的情況。
針對 KRACK 攻擊的緩解方案，研究人員的建議主要在於，資料保密性協定的實施方案，要求檢查金鑰是否已經安裝——如果已經安裝則不再重置相應亂數和 replay 計數器，金鑰僅安裝一次。所以即便是協議漏洞，這次的安全問題不算太大。
值得一提的是，漏洞的存在性是一回事，攻擊難度又是另外一回事。比如資訊安全領域具有奇幻色彩的邊通道（side-channel）攻擊，在實驗室中可以不計成本的方式，用電子探針獲取電、磁、熱特性實施攻擊，但這種攻擊方式很多情況下的成本之高，是一般駭客根本無力承擔的；再比如理論上一直都存在針對存儲介質的比特位元翻轉攻擊，在普通人看來都只能是天方夜譚。
KRACK 攻擊在解決安全研究者提到的諸多實際操作問題後，在“解密資料”和“竊取敏感資訊”的問題上，還面臨很大的挑戰。比如說現如今大量 web 和 App 連接採用 HTTPS 加密的方式，其加密的層級和 WPA/WPA2 不一樣，也就是說即便解開了 WPA2 加密，還有另外層級的加密等著攻擊者去解——即便的確有繞過 HTTPS 實施方案的先例，這就又得費一番功夫了，更何況如果加上 VPN 的加持呢…要說竊取支付寶密碼這件事，僅靠 KRACK 攻擊，恐怕還差得非常遠。
而在更具體的攻擊過程中，研究人員還提到，利用其攻擊 PoC 腳本的可靠性是存在空間上的限制的：
“如果受害者離真實網路（也就是 AP）非常近，那麼腳本可能會不起作用，因為受害人此時直接和真實網路進行通訊。”
畢竟研究人員提出，“中間人攻擊”的方案主要還是依託于建立一個惡意 AP 來欺騙受害者連接的。敢情到要攻擊你家 WiFi，還得首先闖進你家去才行啊。在此可考慮的攻擊場景：你的某個朋友最近行為舉止怪異，穿著打扮黑暗，印堂發黑，經常在螢幕前碼代碼，某一天他去你家，口袋裡還裝個古怪的小玩意兒，也不告訴你要幹嘛——別懷疑，他正在進行 KRACK 攻擊。作為一個紙上談兵的人，本文純粹為喜好探尋原理的人準備。
不過最後還是要說：當代網路攻擊通常都是以組合拳的方式進行的，KRACK 即便對攻擊條件有一定的要求，卻也可以作為全套攻擊方案中的一個環節——作為攻擊鏈中的一部分存在後，還可以產生更大的危害。不過其存在價值在我看來，可能更偏重於針對明確目標的竊聽攻擊，以竊取資訊為目的（比如針對企業）；或配合其他攻擊產生危害。一個實際可行的攻擊場景：比如說廣播模式下的 NTP（網路時間協定），在此模式下，用戶端初始化後監聽廣播 NTP 包來同步時鐘。KRACK 攻擊在此可以讓用戶端的時間凝固（對 NTP 廣播幀進行 replay），這樣一來可進一步對 TLS 證書、DNSSEC、Kerberos 認證、比特幣等造成影響。
無論如何，為安全考慮，任何實際存在的安全問題，而且是已經被證明行之有效的攻擊方案，都應該得到重視。所以蘋果、穀歌、微軟之類的廠商都以較快的速度為終端產品推出了修復 KRACK 攻擊的補丁，所有用戶都應該第一時間打上補丁——至於 AP 端，家中的無線路由器、WiFi 放大器等 AP 設備也都應該第一時間安裝廠商所推的新版固件，比如 360 似乎在漏洞出現的 2 天內就為路由器和擴展器產品推了專門的固件補丁。另外，老生常談的那幾樣，不明來源的 WiFi 不要連接，使用公共 WiFi 時也需要謹慎。
據說 WiFi 聯盟對此已經有了測試計畫。他們打算在其全球認證實驗室網路中對漏洞進行測試，為 WiFi 聯盟成員提供漏洞檢測工具，向設備製造商通告漏洞細節，告知用戶安裝最新安全補丁的重要性。有趣的是，這份 paper 的作者早在 7 月份將漏洞上報給 OpenBSD，OpenBSD 最早發佈補丁，而且是在所有人都不知道的情況下默默發佈的 [5]。
WPA2 有漏洞並不可怕，數字世界的任何位置理論上都存在缺陷。判斷某個系統安全與否的標準在於：攻擊某資產，所需耗費的成本，已經超過資產本身的價值；或攻擊不具有簡單可複製性（如大部分攻擊都是首次攻擊投入成本大，後續攻擊成本越來越小或幾乎零成本，如 iOS 越獄），我們就可以認為這個系統是安全的。
[1]Linux 設備 TCP 連接的有趣漏洞：傳說中的 Off-Path 劫持, http://www.freebuf.com/column/133862.html
[2]Hacking GSM A5 crypto algorithm by using commodity hardware, http://securityaffairs.co/wordpress/52666/hacking/gsm-crypto-hacking.html
[3]The Crisis of Connected Cars: When Vulnerabilities Affect the CAN Standard, http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/
[4]Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, https://papers.mathyvanhoef.com/ccs2017.pdf
[5 ]OpenBSD Errata: August 30th, 2017, https://marc.info/?l=openbsd-announce&m=150410604407872&w=2