802.11 decryption doesn’t always work, even with the full EAPOL handshake

Question

This is a complex question and I don't expect an answer, but I thought I'd throw it out there for ideas.

I live in a fairly dense wifi area (7-12 APs visible). I'm using a TP-Link TL-WN722N USB plug in monitor mode. I am using a capture-filter on only my BSSID which reduces the capture by more than an order of magnitude:

dumpcap -i $IF -f "(wlan addr1 $BSS_LQ63F && dir tods) || (wlan addr2 $BSS_LQ63F && dir fromds)" -w bssid.cap

This works fine and I hope to add to it for more filtering. Note that I do not filter frames with no tods/fromds bits (capture keyword "nods") because that increases the traffic considerably (probe, beacon, etc.) 802.11 is fairly noisy.

I'm testing WPA password recovery by injecting deauth packets (5 at a time) to a STA and collecting the 4-way EAPOL handshake. I do this until the entire EAPOL handshake is captured. After this I can decode the STA-AP session (using the WPA PSK.) Usually.

But sometimes when I capture the entire handshake, I cannot decode the session. I compare the frames with a successful decode and there is no significant difference.

I notice this occurs generally at night when there's more streaming traffic so I suspect the card is dropping something. But if I capture all four messages in the EAPOL handshake and it looks similar to a handshake for a successful decode, it SHOULD decode. Is there something more?

Accepted Answer

I downloaded both files that @dturvene posted on Google drive. When comparing the WPA Key Nonce field between EAP message #1 and EAP message #3, the following is observed:

bssid-tofrom-good.cap = both WPA Key Nonce values are the same between EAPOL message #1 and message #3, as expected
bssid-tofrom-nodecode.cap = the WPA Key Nonce values differ in the last byte between EAPOL message #1 and EAPOL message #3. In message #1, the last byte is b5, but in message #3 the last byte is b6.

Since the AP is acting as the Authenticator, the WPA Key Nonce is referred to as the Authenticator Nonce (ANonce for short) when the AP sends an EAPOL frame. For EAPOL message #1 and #3, the AP is sending these frames and the WPA Key Nonce is therefore referred to as ANonce. In IEEE-2012 specification, sections 11.6.6.2 and 11.6.6.4 provide the expected values of each field. The ANonce value must be the same between EAP message #1 and EAP message #3. Also the Nonce value is used to generate the encryption keys! Since the ANonce differs within the same capture, decryption fails.

Also, it is interesting to note that the ANonce is the same in message #1 for both files. This is highly unusually since the AP will generate a new Nonce value for each 4-Way Handshake instance.

Answer 2

2

In the nodecode trace I can see a different WPA Key Nonce between EAPOL Message (1 of 4) and (3 of 4).

In the other traces I can see, that this information is always the same.

But I do not know if this information is important for this question.

answered 06 May '15, 15:32

Christian_R
1.8k●2●6●25
accept rate: 16%

Yes, that seems to be the smoking gun: last octet of the nonce are different. I would have never caught that. Additionally, tshark decodes only the first 24 octets of the 32 octet nonce so I wouldn't have seen it anyway (I prefer not to use the wireshark GUI.)

Having said that, I cannot recreate the inter-handshake nonce problem at this time. I think I need to wait until there's more traffic on my net. But I will more thoroughly set up injection tests for the AP and see how it handles the nonces.

@Amato_C: thanks for the clarification in your comment below! I suggest you move it to an "answer" and I will upgrade and add points.

(08 May '15, 08:20) dturvene

Answer 3

0

The problem was that the capture probably contained EAPOL messages from other WLAN's on the same channel. Wireshark will use the first EAP message to try to decode. So if the EAP message does not belong to the capture of interest, it will not decode.

answered 06 May '15, 08:22

Amato_C
1.1k●14●20●32
accept rate: 14%

I send a series of five deauth frames to the device MAC every minute until I see the auth handshake, associate handshake and the four-way eapol handshake. The auth handshake, association handshake and eapol handshake have the MAC of the router, MAC of the device and BSSID of the router.

(06 May '15, 09:44) dturvene

And another great catch by @Christian_R! I downloaded both files that @dturvene posted on Google drive. When comparing the WPA Key Nonce field between EAP message #1 and EAP message #3, the following is observed: 1) bssid_tofrom_good.cap = both WPA Key Nonce values are the same between EAPOL message #1 and message #3, as expected 2) bssid_tofrom_nodecode.cap = the WPA Key Nonce values differ in the last byte between EAPOL message #1 and EAPOL message #3. In message #1, the last byte is b5, but in message #3 the last byte is b6.

Since the AP is acting as the Authenticator, the WPA Key Nonce is referred to as the Authenticator Nonce (ANonce for short) when the AP sends an EAPOL frame. Since the AP is sending EAPOL message #1 and #3, the WPA Key Nonce is the ANonce. Referring to IEEE-2012 specification, section 11.6.6.2 and section 11.6.6.4 provide the expected values of each field. The ANonce value must be the same between EAP message #1 and EAP message #3. Also the Nonce value is used to generate the keys! Since the ANonce differs within the same capture, decryption fails.

Also, it is interesting the ANonce is the same in message #1 for both files. This is highly unusually since the AP will generate a new Nonce value for each 4-Way Handshake instance.

It appears to the ActionTec wireless router is using the same Nonce value between different 4-Way Handshake instances. But then changes that value in the middle of the handshake. Strange behavior from the AP.

(06 May '15, 16:10) Amato_C