14

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
cYrus
  • 21,379
  • 8
  • 74
  • 79
  • It can't.. it must be decrypting because it has all four, or you are connected to the wifi network and that is decrypting the packets – Paul Apr 17 '12 at 05:22
  • I'm (obviously) talking about packets captured in RFMON mode. – cYrus Apr 17 '12 at 13:17
  • @Paul: I've edited the question; can you reply? – cYrus Apr 19 '12 at 09:28
  • I wish I could. If you follow the EAPOL sequence, the client has the PTK after only the first packet (the anonce is passed). The AP knows the PTK after the second packet (snonce). If you observe these two, and know the MACs, which of course you do, and the ssid+psk, then this should be all you need. The third packet is just GTK for broadcast and multicast, and the fourth is just an ACK. If you are decrypting unicast (which the arp-reply is) then the first two packets should be enough. I can't help but think I am missing something as everything says you need all four. – Paul Apr 19 '12 at 11:00
  • Did you get any further with this? – Paul Apr 23 '12 at 05:18
  • All that you've said make sense, especially for what concerns unicast traffic; but unfortunately this is an issue strictly bound to Wireshark, and I can't find info other than the link I posted. – cYrus Apr 23 '12 at 09:41
  • PS: I'm stuck with Wireshark because I don't know any other software/library that implements WPA decryption (`airdecap` simply doesn't work). If you can suggest me some good alternatives your're welcome. – cYrus Apr 23 '12 at 09:48
  • Well there are clearly only three EAPOL packets in the capture and it is clearly decrypting unicast. My guess is that this issue is more one of documentation (perhaps it should be stating only three packets are required for unicast and four for broadcast as well). – Paul Apr 23 '12 at 11:01
  • True, what I'd like to know is if this approach is reliable or not i.e. will not work in certain circumstances/ciphers (even with unicast traffic). I guess I should report this to the Wireshark's guys. – cYrus Apr 23 '12 at 12:10
  • Yeah, that would be good. Make sure you put the answer here if you get one so it can be upvoted! How did you come across this, was it staged or did you just miss a packet in the capture (ie is it repeatable)? – Paul Apr 23 '12 at 13:51
  • It's a manually "mutilated" 4-way handshake, so yes, is it repeatable. I've tried with (1, 2, 3) too but without success, and that's even weirder since the fourth is just an ACK (as you said). It's clearly some kind of _check_ performed by Wireshark's decryption algorithm IMHO. Stay tuned... – cYrus Apr 23 '12 at 18:09
  • I've posted a message in the Wireshark mailing list some days ago but got no answer, I guess the only solution now is digging in the source code. – cYrus Apr 30 '12 at 09:39

4 Answers4

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.

BatchyX
  • 2,346
  • 16
  • 12
1

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.

YLearn
  • 1,858
  • 11
  • 20
0

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.

Old Pro
  • 2,348
  • 1
  • 17
  • 26
  • Seems to me that packet 4 isn't *necessary* either right - it is just designed to wait for it. – Paul Apr 29 '12 at 12:02
  • @Paul, that's sort of like saying "resume" isn't _necessary_ after a "pause". – Old Pro Apr 29 '12 at 16:02
  • @OldPro, I'm not sure that waiting for 4° is a good idea, packets captured tend to get lost especially when they travel through the air. – cYrus Apr 29 '12 at 18:14
  • @cYrus, waiting for 4 is essential, as encryption keys have to be changed simultaneously on both sides. If the client doesn't receive 4, it doesn't know that the base received 3. If the client doesn't receive 4, it sends 3 again (which triggers a resend of 4) until it either receives 4 or gives up trying to create the connection. – Old Pro Apr 29 '12 at 18:20
  • @OldPro: I'm not talking about the protocol. Both sides can receive all the packets, but they might be dropped or not captured by the entity that passively captures the traffic. – cYrus Apr 29 '12 at 18:27
  • @cYrus, if you are a 3rd party intercepting the traffic, then you are mounting a network attack (even if it's your network with your permission) and WireShark is quite reasonable in limiting the functionality of their tool to make it less helpful in mounting that sort of attack. The legitimate use case is where you have WireShark on the computer running one half of the session and are only listening into your own conversation. To make it work when 3 and 4 are missing you have to implement a lot of testing of "which key are we using now?" which is work I wouldn't expect WireShark to do. – Old Pro Apr 29 '12 at 18:52
  • @OldPro: I don't think that Wireshark implemented that to discourage such attacks. Anyway, packets arrive already decrypted to Wireshark when capturing your own traffic. Yep, maybe it's just a matter of performances. – cYrus Apr 29 '12 at 19:40
  • I don't see how the fourth packet would eliminate or require additional "what key checks"? – Paul Apr 29 '12 at 23:23
0

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.
sybind
  • 181
  • 3