 | 1 | initial version |
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
[...cut...]
The version for this set is 3; for the successful run, and what I typically see, the value is 2. From 802.11-2012, 11.6.6.2 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 '3' is valid at least to the specification (does not mean the hosts are using it in the correct way). Looking at Wireshark source (dangerous, I'm not a developer) in https://github.com/wireshark/wireshark/blob/master/epan/crypt/dot11decrypt.c
/**
* EAPOL Key Descriptor Version 1, used for all EAPOL-Key frames to and
* from a STA when neither the group nor pairwise ciphers are CCMP for
* Key Descriptor 1.
* @note
* Defined in 802.11i-2004, page 78
*/
#define DOT11DECRYPT_WPA_KEY_VER_NOT_CCMP 1
/**
* EAPOL Key Descriptor Version 2, used for all EAPOL-Key frames to and
* from a STA when either the pairwise or the group cipher is AES-CCMP
* for Key Descriptor 2.
* /note
* Defined in 802.11i-2004, page 78
*/
#define DOT11DECRYPT_WPA_KEY_VER_AES_CCMP 2
Looks like they define values 1 and 2, but not 3. This is a bad sign and leads me to believe that when a 3, it is not a covered case. Anyway, perhaps someone who works in this code could dig a little deeper and see if this is why this particular 4-way handshake is rejected.