WEP（共享密钥认证），如何形成136字节质询响应？

时间：2013-08-21 14:28:09

标签： rc4-cipher wep

我正在玩WEP（共享密钥身份验证）质询/响应机制，我希望有人可以帮助我。

  1. AP向STA发送质询文本。挑战文本是128字节
  2. STA加密挑战并将其发送回AP。这是wireshark中的136个字节（数据）。

    3. 我的问题：

    有人可以告诉我136字节数据质询响应的构成以及为什么这么大。

    为什么不是Enc（[challengetext（128）] + [icv（4）]）= 132字节？

    感谢。

2 个答案:

答案 0 :(得分：1)

你在开始时忘记了IV的4个字节。

答案 1 :(得分：0)

我不是专家，我正在使用个人经验来确认问题的答案。随时编辑错误的条款。

TL; DR

STA发送的加密帧包含：

  • 802.11 parameters（24 bytes）
  • WEP parameters（清除IV +键索引）（4 bytes）
  • management headers（已加密）（8 bytes）
  • data（已加密）（128 bytes）
  • ICV（已加密）（4 bytes）

总数为168 bytes，没有ICV的加密数据总数 为136 bytes。

Wireshark和Cie显示的加密数据比明文质询长8个字节，因为它还带有管理标头（已加密但可预测）。

AP发送什么？

AP发送的明文质询帧长160字节，加密的质询响应帧长168字节。这不是问题，但让我们弄清楚。

在明文AP消息中，管理标头也是明文：

  • 身份验证算法（2 bytes）
  • 身份验证SEQ（2 bytes）
  • 状态码（2 bytes）
  • 标签号（1 byte）
  • 标签长度（1 byte）
  • （挑战）（'tag length' bytes）

管理标头长8个字节。

STA发送什么？

在STA加密的消息中，802.11层上的所有内容都被视为“数据”，因为这是加密的乱码。在获取此数据之前，您可以找到（属于802.11层的）WEP参数：IV (3 bytes)和key index (1 bytes)。这是明文。您还拥有ICV，即框架的最后一个4 bytes。那些8 bytes出现在所有WEP加密帧中。

“数据”部分包含加密的质询和加密的管理标头（这就是回答您的问题的原因）。

您的问题

如果WEP帧中有8个更多个字节实际上似乎在补偿8个字节的管理标头，那么为什么加密的质询数据要长8个字节？

这不是因为IV或ICV，正如我们之前看到的那样，因为它们不是挑战数据的一部分。 这8个字节实际上来自管理标头，并在“数据”部分中进行了加密。包含加密质询的帧也是一个管理帧，但是您看不到标头，因为标头已加密。那是您的8个神秘字节（请参见下面的简化帧框架）

我将结束这些事实，即这些共享密钥身份验证允许您对WEP身份验证捕获进行离线字典或蛮力攻击，而无需任何IV（当然用于加密挑战的密码除外）。前8个加密字节是管理标头的事实使它们可预测（始终相同）。因此，在暴力破解实施中，您可以仅在帧的前4或8个字节中RC4，而不是整个136字节，从而在大型字典/完全暴力破解中获得更好的性能。

认证框架骨架

具有明文质询的管理框架

--------------------------------------------------------------
(ieee 802.11 headers) -> 24 bytes
--------------------------------------------------------------
---------------- 8 bytes management headers ------------------

ieee 802.11 Wireless Management:

[0][1] == Authentication algo (int16) == 0x0100 (Shared Key)
[2][3] == Authentication SEQ  (int16) == 0x0002
[4][5] == Status code         (int16) == 0x0000 (Successful)
[6]    == Tag Number          (int8)  == 0x10   (Challenge text)
[7]    == Tag length          (int8)  == 0x80   (128 bytes long challenge)
--------------------------------------------------------------
---------------------- 128 bytes data ------------------------

[0:128]== Challenge text
--------------------------------------------------------------

24 + 8 + 128 = 160 bytes frame

具有可预测的加密管理标头的加密帧

--------------------------------------------------------------
(ieee 802.11 headers) -> 24 bytes
--------------------------------------------------------------
------------------ 4 bytes WEP parameters --------------------

[0][1][2] == IV (3 bytes, clear text)
[3]       == key index (int8) (should be 0)
--------------------------------------------------------------
---------------- 8 bytes management headers ------------------

From here, everything is encrypted

[0][1] == Authentication algo (int16) == 0x0100 (Shared Key)
[2][3] == Authentication SEQ  (int16) == 0x0003 (incremented since last frame)
[4][5] == Status code         (int16) == 0x0000 (Successful)
[6]    == Tag Number          (int8)  == 0x10   (Challenge text)
[7]    == Tag length          (int8)  == 0x80   (128 bytes long challenge)
--------------------------------------------------------------
---------------------- 128 bytes data ------------------------

[0:128]== Encrypted data challenge
--------------------------------------------------------------
---------------------- 4 bytes ICV ---------------------------

[0:4]  == WEP ICV
--------------------------------------------------------------

24 + 4 + 8 + 128 + 4 = 168 bytes frame
8  + 128 = 136 bytes "data" (as wireshark interprets it)

与加密帧的管理标头中的前一个唯一不同的是SEQ号。

相关问题
最新问题