Wireshark WPA 4-way handshake

Question

From this wiki page:

WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture.

I've noticed that the decryption works with (1, 2, 4) too, but not with (1, 2, 3). As far as I know the first two packets are enough, at least for what concern unicast traffic. Can someone please explain exactly how does Wireshark deal with that, in other words why does only the former sequence work, given that the fourth packet is just an acknowledgement? Also, is it guaranteed that the (1, 2, 4) will always work when (1, 2, 3, 4) works?

Test case

This is the gzipped handshake (1, 2, 4) and an ecrypted ARP packet (SSID: SSID, password: password) in base64 encoding:

H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj/n4GhHkhfXNHr37KQgWEqAwQzMAgx
6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4+RmSH+H0MngwLUZMarj4Rn
S8vInf5yfO7mgrMyr9g/Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn
ITk1gBnJkeX/GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz+VGLl+snrF7j2EnHQy3JjDKPb9
3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ
9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT+0/J3LP
gie59HFL+5RDIdmZ8rGMEldN5s668eb/tp8vQ+7OrT9jPj/B7425QIGJI3Pft72dLxav8BefvcGU
7+kfABxJX+SjAgAA

Decode with:

$ base64 -d | gunzip > handshake.cap

Run tshark to see if it correctly decrypt the ARP packet:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

It should print:

  1   0.000000 D-Link_a7:8e:b4 -> HonHaiPr_22:09:b0 EAPOL Key
  2   0.006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  3   0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  4   0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP 192.168.1.1 is at 00:a0:c5:68:3a:e4

Answer 1

EAPOL exchanges are also used to renew the temporal keys. The new keys are installed on the Supplicant after it sends 4/4, and are installed on the Authenticator when it receives 4/4[1]. If Wireshark must handle rekeying correctly, it must only use the keys after reading the 4/4 packet in the frame, because packets may still be flowing during the rekeying (even in case where they should not, because of buffering)

For the first 4WHS, not waiting for 4/4 is possible, but it's perfectly understandable that they were just lazy to implement it. 3/4 is still necessary as it contains group keys (even if you are not interested in them, but know that you will not see ARP requests from the AP or a client for which you have no part of its 4WHS) and management keys. You may skip 3/4 too, but then you have no confirmation that the exchange was successful, because 3/4 is used to verify that the Authenticator knows the PMK.

[1] Note that with the current scheme, if the 4/4 message is lost, then the supplicant started using the new key, and the authenticator still uses the old key, and resending 3/4 encrypted with the old key will not help. This problem, among many others with WPA2, is addressed in the latest 802.11 2012 standard by keeping two keys in parallel.

Answer 2

All the information necessary to construct the PTK is exchanged in steps 1 and 2. This should be enough to decrypt unicast traffic.

Without step 3, you won't have the GTK, so decrypting multicast/broadcast won't be possible.

Step 4 isn't really necessary to decrypt capture traffic, but if there isn't a step 4, the client/AP won't start using encryption. Wireshark may key off of this before it tries to decrypt data as well.

Answer 3

Well, obviously the WireShark documentation is wrong. :-)

Going off the documentation here:

• After EAPOL 1 and 2 both sides know the temporal key that will be used to decrypt the traffic.
• The third message is proof that both sides know the temporal key and indicates that the Authenticator (the base station) is ready to start using the temporal key.
• The fourth message triggers the switch from the PMK set up before the EAPOL to the temporal key derived in the EAPOL

So with that, it makes sense. WireShark doesn't need message 3 for anything. It knows the keys after messages 1 and 2, but it waits to start using them to decrypt traffic until after it receives message 4.

There are no guarantees to anything in life, especially the behavior of free software, but it's a reasonable bet that there won't be a requirement for message 3 to be present for WireShark to decrypt the session.

Answer 4

This doesn't explain why, but quoting from the airdecap-ng documentation anyways,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets.