WEP (Shared Key Authentication), how is the 136 byte challenge response formed?

Question

I am playing around with WEP(Shared key authentication) challenge/response mechanism at the moment and I hope someone could help me out.

1. The AP sends a challenge text to the STA. The challenge text is 128 bytes
2. The STA encrypts the challenge and sends it back to the AP. This is 136 bytes (data) in wireshark.

My Question:

Can someone tell me the make-up of the 136 byte data challenge response and why it is this size.

Why is it not Enc([challengetext (128)] + [icv(4)]) = 132 bytes?

Thanks.

Answer 1

You forgot the 4 bytes of the IV in the beginning.

Answer 2

I'm not an expert and I'm using personal experience to confirm the answer to the question. Feel free to edit eventual wrong terms.

TL;DR

Encrypted frame send by the STA contains:

• 802.11 parameters (24 bytes)
• WEP parameters (clear IV + key index) (4 bytes)
• management headers (encrypted) (8 bytes)
• data (encrypted) (128 bytes)
• ICV (encrypted) (4 bytes)

Total is 168 bytes, total of encrypted data without ICV is 136 bytes.

The encrypted data shown by Wireshark and Cie is 8 bytes longer than clear text challenge because it also carries the management headers (encrypted but predictable).

---

What does the AP send?

Clear text challenge frame sent by the AP is 160 bytes long, and the encrypted challenge response frame is 168 bytes long. That is not the question, but let's make things clear.

In the clear text AP messages, the management headers are also clear text:

• Authentication algorithm (2 bytes)
• Authentication SEQ (2 bytes)
• status code (2 bytes)
• tag number (1 byte)
• tag length (1 byte)
• (challenge) ('tag length' bytes)

The management header are 8 bytes long.

---

What does the STA send?

In the STA encrypted message, everything over 802.11 layer is considered as "data" as this is encrypted gibberish. Before this data, you can find (part of the 802.11 layer) the WEP parameters: IV (3 bytes) and key index (1 bytes). This is clear text. You also have the ICV, the very last 4 bytes of the frame. Those are 8 bytes that appear in all WEP encrypted frames.

The "data" section contains the encrypted challenge and the encrypted management headers (that's what answers your question).

---

Your question

If you have 8 more bytes in the WEP frame that actually seem to compensate the 8 bytes management headers, then why your encrypted challenge data is 8 bytes longer?

This is not because of IV or ICV, as we saw before, as they are not part of the challenge data. Those 8 bytes are actually from the management headers, that are encrypted within the "data" section. The frame containing the encrypted challenge is also a management frame, but you can't see the headers as they are encrypted. Those are your 8 mysterious bytes (see simplified frame skeletons below)

I will finish on the fact that those shared key authentications permit you to do offline dictionnary or bruteforce attacks on WEP authentication captures without any IV (except the one used to encrypt the challenge of course). The fact that the first 8 encrypted bytes are management headers makes them predictable (it's always the same). So in a bruteforce implementation, you can just RC4 the first 4 or 8 bytes of the frame, instead of the whole 136 bytes, which leads to way better performance on huge dictionnary/full bruteforce attacks.

---

Authentication frames skeleton

Management frame with cleartext challenge

--------------------------------------------------------------
(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

---

Encrypted frame with predictable encrypted management headers

--------------------------------------------------------------
(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)

The only thing that changes from the previous one in the management headers of the encrypted frame is the SEQ number.