Ask Your Question

Can't decrypt WPA2-PSK even with passphrase and 4 EAPOL packets

asked 2018-05-30 23:24:52 +0000

J_Turner gravatar image

I am having trouble decrypting this Wireshark trace (C:\fakepath\sample ublox capture with tablet connect.pcapng). The AP is a ublox wifi module that is a part of an embedded system, and there are two clients. One is another one of the same ublox radios, and the other client is an Asus tablet. The tablet-AP link is decrypted without issue, but only a few of the ubloxClient-AP packets are decrypted.

tablet-AP link: All 4 EAPOL packets are captured (starts with packet 563) and the traffic is all decrypted.

ubloxClient-AP Link: All 4 EAPOL packets were captured (starts with packet 111), but the data isn't all decrypted. For example, packet 134 is encrypted, but packet 139 is decrypted.

Here is some more info:

  • SSID: testSSID
  • password: pass1234
  • BSSID: d4:ca:6e:70:39:07
  • A helpful filter I used: (wlan.addr == d4:ca:6e:70:39:07) && !(wlan.fc.type_subtype == 8)
  • I tried toggling the the "Enable decryption" checkbox under the IEEE 802.11 settings.
  • The messages that would decrypt are 1 Mbps, while the packets that wouldn't decrypt are 65 Mbps.
  • It was captured with an AirPcap Nx, but I have tried capturing with a Linksys AE3000 and got similar results.
  • I am using Wireshark Version 2.6.1 on Windows, but I have tried to decrypt the same trace on a Linux machine.
  • I tried using airdecap-ng but got the same results.
  • It seems like it may be a modulation related issue, but the adapter captured the packets, so I thought Wireshark would be able to decrypt them.

Any ideas on why I cannot get this trace to decrypt?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-05-31 11:58:53 +0000

Bob Jones gravatar image

I don't think this is a modulation issue; evidence suggests the problem lies with Wireshark not decoding the 4-way handshake for one of the cases. So for this host, no actual decryption is possible for either unicast or group traffic*.

I see two hosts with EAPOL key sequences:

Host 1 - NOK
wlan.addr[4:2] == 3f:34

Host 2 - OK
wlan.addr[4:2] == 38:86

For first test, export only packets for Host1 and open in Wireshark, but shutdown Wireshark first so all PTK/GTK keys are flushed. Nothing will decrypt for me. However, using the full trace we have access to both handshakes, and we observe what is described as 'partial' decryption.

The difference that you are seeing is that group traffic (i.e. multicast and broadcast) is decrypted; Host2's EAPOL handshake produces a proper group key which Wireshark can then use to decrypt all group traffic on that BSSID. If you look at an encrypted frame, you will see a CCMP field, for frame 134:

IEEE 802.11 QoS Data, Flags: .p.....TC
    Type/Subtype: QoS Data (0x0028)
    Frame Control Field: 0x8841
    .000 0000 0010 1000 = Duration: 40 microseconds
   [... cut ...]
    Qos Control: 0x0000
    CCMP parameters
        CCMP Ext. Initialization Vector: 0x000000000001
        Key Index: 0

The Key Index value indicates that it will use the unicast key for encryption/decryption. But looking at one of the frames that is decryptable, say 139, that has an index value of 1 so it will use the group key. Note that all traffic sent from a host/client to an AP (so called ToDS) is always sent as unicast; it will use key index 0. Only an AP will send true group traffic, and then could use either key index 1 or 2 (toggles) which would be the GTK. Unicast traffic from an AP to a host/client would use key index 0, which is the PTK.

I think this answers why 'some' traffic is decoded and not others. But why is the 4-way handshake invalid, according to your tools? There seems to be correlation to the Key Descriptor Version (in an EAPOL key frame):

802.1X Authentication
    Version: 802.1X-2001 (1)
    Type: Key (3)
    Length: 123
    Key Descriptor Type: EAPOL RSN Key (2)
    [Message number: 2]
    Key Information: 0x010b
        .... .... .... .011 = Key Descriptor Version: AES Cipher, AES-128-CMAC MIC (3)
        .... .... .... 1... = Key Type: Pairwise Key
        .... .... ..00 .... = Key Index: 0
        .... .... .0.. .... = Install: Not set
        .... .... 0... .... = Key ACK: Not set
        .... ...1 .... .... = Key MIC: Set
        .... ..0. .... .... = Secure: Not set
        .... .0.. .... .... = Error: Not set
        .... 0... .... .... = Request: Not set
        ...0 .... .... .... = Encrypted Key Data: Not set
        ..0. .... .... .... = SMK Message: Not set

The version for this set is 3; for the successful run, and what I typically see, the value is 2. From 802.11-2012, 4-Way Handshake Message 1, the valid values are:

Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC), in all other cases 0

So ... (more)

edit flag offensive delete link more


I agree with your analysis @Bob Jones. It seems the prospects of being able to decrypt this trace are bit bleak...

J_Turner gravatar imageJ_Turner ( 2018-05-31 19:29:52 +0000 )edit

Omnipeek would not decrypt this set, either.

Bob Jones gravatar imageBob Jones ( 2018-06-01 10:49:12 +0000 )edit

TamoSoft's 'CommView for Wifi' wouldn't decrypt it either.

J_Turner gravatar imageJ_Turner ( 2018-06-01 15:10:43 +0000 )edit

After talking with the manufacturer of the module, it seems this problem is caused by Protected Management Frames (802.11w). I was able to switch the PMF off and decrypt the traffic. Does Wireshark have support for 802.11w decryption?

J_Turner gravatar imageJ_Turner ( 2018-06-14 13:45:19 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-05-30 23:24:52 +0000

Seen: 40 times

Last updated: May 31