Solomon,
Thanks for the response. Yes, what you describe fits with what I'm
trying to do. I can catch the handshake and thus derive the PTK to
decode the packets. I guess I would see what I'm seeing today for
traffic for which I didn't see the handshake and properly decoded
packets for stations for which I did see it.
I'm not at all interested in cracking WPA but I would like to see the
packets decrypted properly so I can tell what's going on.
I'll take a look at the source and see how this is done for known WEP
keys today. If it's not too horrible looking I'll attempt to add
something for WPA-PSK.
Thanks,
Andrew
-----Original Message-----
From: Solomon Peachy [mailto:solomon@xxxxxxxxxxxxxx]
Sent: Friday, September 08, 2006 9:00 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] WPA decryption?
The problem with WPA/WPA2 is that it uses dynamic keys derived from a
hanshake sequence. If you don't have all of the information needed to
generate that dynamic keydata, then you won't be able to generate the
per-packet encryption key and decrypt the frame. Oh, and each pair of
communication stations use a unique keyset.
With WPA[2]-PSK, obtaining this dynamic key information is possible if
you sniffed the initial handshake and knew the PSK, but if they're using
WPA[2]-EAP, the "shared secret" is generated on either end using the
authentication credentials via a secure channel. While there are attack
vectors for this information... it's a monumental undertaking.
All that said, all you strictly need to decode TKIP or AES traffic is
the PTK (derived from the PMK/PSK+handshake data), so if you know that,
(presumably via AP or STA logs) decoding the payload is possible.
- Solomon
--
Solomon Peachy solomon@xxxxxxxxxxxxxx
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
