Linux Wlan-四次握手(eapol)框架流程
协议基础基于 IEEE 802.1X 标准实现的协议
抓包基础
使用上一章文章的TPLINK wn722n v1网卡在2.4G 频段抓包（v2、v3是不支持混杂模式的）
eapol的四个交互流程
https://i-blog.csdnimg.cn/direct/ef681d37a06c46cfbf0303d638f0316e.png
[*]根据不同的认证模式不同，两者的Auth流程有所不同，但是握手流程基本相似
https://i-blog.csdnimg.cn/direct/713019930b854e17b5f6efac4ed27a4e.png
这个可以作为背面的文章方向，这里暂时不做拓展，当前只思量PSK模式下的eapol
流程梳理前我们先须要流程图，不然看完照旧忘
https://i-blog.csdnimg.cn/direct/5411e0d061cf48379174f2487120f18b.png
[*]粉色填充为说明
[*]蓝色填充为流程
[*]紫色填充为密钥生成与安装
四次握手（eapol）流程
[*] message 1
https://i-blog.csdnimg.cn/direct/309f8ef2135144e6a06a40be0ff84a76.png
四次握手的第一条消息，由AP发送给客户端，携带AP生成的ANonce
此帧的核心作用：通报AP的ANonce
[*] message 2
https://i-blog.csdnimg.cn/direct/3671051f538047d79b0e656844ee3496.png
客户端收到AP的ANonce后，结合本身的SNonce和PMK计算出PTK，并用KCK生成MIC
此帧的核心作用:通报客户端的SNonce和MIC，完成PTK的协商
[*] message 3
https://i-blog.csdnimg.cn/direct/6db9bc7c118445ac909c1e24a6212de0.png
验证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
https://i-blog.csdnimg.cn/direct/0b8f3d52de2446829182dd7eeeb52071.png
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流程会在第几个流程报错？
抓包分析：
https://i-blog.csdnimg.cn/direct/92942ab10d81493fa3a7ab118df77cf0.png
只有这两个流程，并未触发mesg 3
错误缘故原由
密码错误 → 客户端计算的PMK与AP的PMK不同 → 派生出的PTK不一致 → MIC校验失败
所以只有一二阶段，无法正常举行第三次握手
[*]为什么二三四的握手包，里面的MIC值都不一样？
https://i-blog.csdnimg.cn/direct/b3e1cae539854092b5fd42cbc1705add.png
https://i-blog.csdnimg.cn/direct/aea2c5e1911f468ba44c583ace577282.png
https://i-blog.csdnimg.cn/direct/12e2fcc5374e413594e13494c60e7ca6.png
缘故原由分析：MIC 值不同是因为每条消息的内容和用途不同,使用PTK的子密钥 KCK（Key Confirmation Key） 对帧内容生成哈希,所以值会不同
[*]用户态和内核态在eapol中起的作用是什么？
1)EAPOL 流程控制主要在 wpa_supplicant（用户态），负责协议逻辑和密钥管理
2)驱动（内核态）仅负责执行硬件操作（如安装密钥、收发帧）
https://i-blog.csdnimg.cn/direct/8538a17727e54d0fa67de9c1bf6d0a8c.jpeg
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]