協議基礎
基于 IEEE 802.1X 標準實現的協議
抓包基礎
使用上一章文章的TPLINK wn722n v1網卡在2.4G 頻段抓包（v2、v3是不支持混雜模式的）
eapol的四個交互流程
- 根據不同的認證模式不同，兩者的Auth流程有所不同，但是握手流程基本相似
這個可以作為后面的文章方向，這里暫時不做拓展，當前只考慮PSK模式下的eapol
流程梳理前我們先需要流程圖，不然看完還是忘
- 粉色填充為說明
- 藍色填充為流程
- 紫色填充為密鑰生成與安裝
四次握手（eapol）流程
-
message 1
四次握手的第一條消息，由AP發送給客戶端，攜帶AP生成的ANonce
此幀的核心作用：傳遞AP的ANonce -
message 2
客戶端收到AP的ANonce后，結合自己的SNonce和PMK計算出PTK，并用KCK生成MIC
此幀的核心作用:傳遞客戶端的SNonce和MIC，完成PTK的協商 -
message 3
驗證MIC并生成GTK（組密鑰）
此幀的核心作用:要求客戶端安裝PTK（通過Install=1標志）和GTK，下發加密的GTK（組密鑰）供客戶端解密使用
GTK加密：使用PTK的子密鑰 KEK（Key Encryption Key） 加密GTK，確保組密鑰傳輸安全
客戶端收到Msg3后的流程：
1)驗證MIC
2)解密GTK（使用KEK）
3)安裝PTK和GTK
4)發送Msg4（確認幀）完成握手 -
message 4
AP收到Msg4后，確認握手完成，雙方開始使用PTK/GTK加密所有數據流量
此幀的核心作用:：通過MIC驗證Msg3的完整性，通知AP已成功安裝密鑰（PTK和GTK） -
客戶端回復Msg4后，雙方開始使用PTK/GTK加密所有流量
一個小的流程圖說明一下
完整的四次握手流程如下：
- Msg1：AP → 客戶端（ANonce）
- Msg2：客戶端 → AP（SNonce + MIC）
- Msg3：AP → 客戶端（GTK + MIC + 安裝指令）
- Msg4：客戶端 → AP（最終確認）
至此，WPA2-PSK認證流程全部完成，安全通信通道建立
疑問
- 當client把wifi密碼輸入錯誤，eapol流程會在第幾個流程報錯？
抓包分析：
只有這兩個流程，并未觸發mesg 3
錯誤原因
密碼錯誤 → 客戶端計算的PMK與AP的PMK不同 → 派生出的PTK不一致 → MIC校驗失敗
所以只有一二階段，無法正常進行第三次握手 - 為什么二三四的握手包，里面的MIC值都不一樣？
原因分析：MIC 值不同是因為每條消息的內容和用途不同,使用PTK的子密鑰 KCK（Key Confirmation Key） 對幀內容生成哈希,所以值會不同 - 用戶態和內核態在eapol中起的作用是什么？
1)EAPOL 流程控制主要在 wpa_supplicant（用戶態），負責協議邏輯和密鑰管理
2)驅動（內核態）僅負責執行硬件操作（如安裝密鑰、收發幀）
分析法)
