Wireshark WPA 4-way handshake

decryptionwiresharkwpa

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

Best Answer

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.

Related Question