☰

测试用例

tag-icon • tag-icon wireshark wpa decryption
测试用例

从此维基页面：

WPA 和 WPA2 使用从 EAPOL 握手中派生的密钥来加密流量。除非全部四个如果您尝试解密的会话中存在握手数据包，Wireshark 将无法解密流量。您可以使用显示过滤器 eapol 来查找捕获中的 EAPOL 数据包。

我注意到解密对 (1, 2, 4) 也有效，但对 (1, 2, 3) 无效。据我所知，前两个数据包就足够了，至少对于单播流量而言。有人能解释一下 Wireshark 是如何处理这个问题的吗？换句话说，为什么只有前一个序列有效，而第四个数据包只是确认？此外，当 (1, 2, 3, 4) 有效时，是否保证 (1, 2, 4) 也始终有效？

测试用例

这是经过 gzip 压缩的握手（1、2、4）和加密数据ARP包（SSID：，SSID密码：），其编码password如下base64：

H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj/n4GhHkhfXNHr37KQgWEqAwQzMAgx
6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4+RmSH+H0MngwLUZMarj4Rn
S8vInf5yfO7mgrMyr9g/Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn
ITk1gBnJkeX/GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz+VGLl+snrF7j2EnHQy3JjDKPb9
3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ
9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT+0/J3LP
gie59HFL+5RDIdmZ8rGMEldN5s668eb/tp8vQ+7OrT9jPj/B7425QIGJI3Pft72dLxav8BefvcGU
7+kfABxJX+SjAgAA

解码：

$ base64 -d | gunzip > handshake.cap

运行tshark看看它是否正确解密数据ARP包：

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

它应该打印：

  1 0.000000 D-Link_a7:8e:b4 -> HonHaiPr_22:09:b0 EAPOL 密钥
  2 0.006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL 密钥
  3 0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL 密钥
  4 0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP 192.168.1.1 位于 00:a0:c5:68:3a:e4

答案1

EAPOL 交换也用于更新临时密钥。新密钥在请求方发送 4/4 后安装在请求方，在验证方收到 4/4[1] 后安装在验证方。如果 Wireshark 必须正确处理重新密钥，则它必须在读取帧中的 4/4 数据包后才使用密钥，因为在重新密钥期间数据包可能仍在流动（即使在由于缓冲而不应该流动的情况下也是如此）

对于前 4WHS，不等待 4/4 是可能的，但他们懒得去实现这一点也是完全可以理解的。3/4 仍然是必要的，因为它包含组密​​钥（即使您对它们不感兴趣，但要知道您不会看到来自 AP 或您不属于其 4WHS 的客户端的 ARP 请求）和管理密钥。您也可以跳过 3/4，但这样您就无法确认交换是否成功，因为 3/4 用于验证身份验证器是否知道 PMK。

[1] 请注意，在当前方案中，如果 4/4 消息丢失，则请求者开始使用新密钥，而认证者仍使用旧密钥，重新发送使用旧密钥加密的 3/4 消息也无济于事。此问题以及 WPA2 的许多其他问题在最新的 802.11 2012 标准中通过并行保留两个密钥得到解决。

答案2

构建 PTK 所需的所有信息都在步骤 1 和 2 中交换。这足以解密单播流量。

如果没有步骤 3，您将不会拥有 GTK，因此无法解密多播/广播。

步骤 4 并非解密捕获流量的必需步骤，但如果没有步骤 4，客户端/AP 将不会开始使用加密。Wireshark 可能会在尝试解密数据之前关闭此步骤。

答案3

嗯，显然 WireShark 文档是错误的。:-)

脱离文档这里：

  • 在 EAPOL 1 和 2 之后，双方都知道将用于解密流量的临时密钥。
  • 第三条消息证明双方都知道临时密钥，并表明验证器（基站）已准备好开始使用临时密钥。
  • 第四条消息触发从 EAPOL 之前设置的 PMK 切换到 EAPOL 中派生的临时密钥

因此，这样做是有道理的。WireShark 不需要消息 3 来做任何事情。它知道消息 1 和 2 之后的密钥，但它要等到收到消息 4 之后才开始使用它们来解密流量。

生活中没有任何事物能够保证万无一失，尤其是免费软件的行为，但可以合理地假设，WireShark 解密会话时不需要出现消息 3。

答案4

这并不能解释原因，但引用 airdecap-ng文档无论如何，

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets.

相关内容