我正在用 wireshark 捕获 wpa2 握手,并且有一个类型值,03
我key
想知道这种类型对于 wpa2 握手是否是常量,还有其他类型的值,如果有的话,例如如果接入点使用它,01
或者02
会是什么样子?04
安装到底是做什么的?它仅在握手的第三种方式上由路由器发送,这意味着麦克风已确认并且客户端可以在其本地机器上安装密钥?
另外,在 wpa 四次握手(路由器发送)的第三次握手中,我看到了一些 wpa 密钥数据,这是用于加密/解密的数据吗?还是实际加密的数据?如果是加密的,它包含什么数据?
感谢到目前为止的所有答案,我找到了 wireshark 源代码此链接对于 eapol 数据包。它有这个对象,其中包含类型Key (3)
。我想知道是否使用了其他值EAP Packet
,例如,如果是,请举个例子?
static const value_string eapol_type_vals[] = {
{ EAP_PACKET, "EAP Packet" },
{ EAPOL_START, "Start" },
{ EAPOL_LOGOFF, "Logoff" },
{ EAPOL_KEY, "Key" },
{ EAPOL_ENCAP_ASF_ALERT, "Encapsulated ASF Alert" },
{ 0, NULL }
};
答案1
答案2
我建议您自己阅读相关标准;它们可用免费从 IEEE。
“WPA2”最初是在 802.11i 修正案中定义的,但在后续版本中已集成到 802.11 主文档中,因此您可以搜索原始 802.11i-2004 文档或完整802.11-2020(第 12 节“安全”)。
WPA/WPA2 建立在用于有线局域网身份验证的 802.1X 标准之上;请参阅802.1X-2020了解更多详细信息。
我正在用 wireshark 捕获 wpa2 握手,并且有类型值 03,它是一个键,我想知道这个类型对于 wpa2 握手是否是常量,其他类型的值也是如此,如果有的话,例如,如果接入点使用 01 或 02 或 04,它们会是什么样子?
IEEE 802.11i-2004(定义 RSN 又名“WPA2”)规定:
EAPOL-Key帧的各字段说明如下:
a)描述符类型。该字段为一个八位字节,具有由 IEEE P802.1X-REV 定义的值,用于标识 IEEE 802.11 关键描述符。
在 IEEE 802.1X-2010 中,表 11-5 定义了以下密钥类型:
任务 | 价值 |
---|---|
RC4 密钥描述符类型(已弃用) | 1 |
IEEE 802.11 密钥描述符类型 | 2 |
没有解释为什么 802.1X 标准中使用 RC4,但很有可能是“动态 WEP”或“WEP(802.1X)”机制,即 WPA-Enterprise 的前身,因为它确实使用 EAP(大概还有 EAPOL)来生成 RC4 WEP 密钥。
安装到底是做什么的?它仅在握手的第三种方式上由路由器发送,这意味着麦克风已确认并且客户端可以在其本地机器上安装密钥?
是的,这是客户端启用流量加密的地方。
IEEE 802.11i 在“8.5.3.7 四次握手分析(信息性)”一节中说:
消息 1 将 ANonce 传递给请求方并启动新 PTK 的协商。它将 AA 标识为请求方 STA 的对等 STA。如果攻击者修改了地址或 ANonce,则验证器将在消息 2 中验证 MIC 时检测到结果。消息 1 不携带 MIC,因为请求方不可能在不始终维护所有安全关联状态的情况下将此消息与重放消息区分开来(PMK 可能是静态密钥)。
消息 2 将 SNonce 传递给认证器,以便认证器可以派生 PTK。如果认证器随机选择了 ANonce,则消息 2 还会向认证器证明请求者处于活动状态、PTK 是最新的,并且不存在中间人攻击,因为 PTK 包含两者的 IEEE 802 MAC 地址。在 PTK 派生中包含 ANonce 还可以防止重放。MIC 可防止对消息 2 内容进行未被发现的修改。
消息 3 向请求者确认不存在中间人攻击。如果请求者随机选择了 SNonce,则还表明 PTK 是新鲜的,并且认证器处于活动状态。MIC 再次阻止了对消息 3 的未检测到的修改。
虽然消息 4 不具有加密用途,但它可以作为对消息 3 的确认。它需要确保可靠性,并告知认证者请求者已经安装了 PTK 和 GTK,因此可以接收加密帧。
另外,在 wpa 四次握手(路由器发送)的第三次握手中,我看到了一些 wpa 密钥数据,这是用于加密/解密的数据吗?还是实际加密的数据?如果是加密的,它包含什么数据?
同样来自 IEEE 802.11i,它包含:
密钥数据 = AP 的信标/探测响应帧的 RSN 信息元素,以及(可选)作为认证器成对密码套件分配的第二个 RSN 信息元素,以及(如果已协商组密码)封装的 GTK 和 GTK 的密钥标识符(参见 8.5.2)
实际加密流量不会在 EAPOL 帧中传输。