This is my last question I want to ask.
I finally got time to learn how WPA2 encryption works.
so there is per station key (temporal key), and one multicast key (group
key). TK is derived from PSK by throwing together macs or both ends, two
random numbers, and PMK (whick in case of wpa personal == PSK
This means kernel can't automatically decrypt other stations traffic.
But I could arrange small program that listens to device in monitor or
maybe even just promisc mode, and records WPA handshakes. For every
handshake it could install the key in kernel driver, so it would use it
for decryption, and show the traffic on device in promisc mode. Is it
possible to do today? I guess not.
All this program has to know is the PSK.
(I could even arrange WPA supplicant to do this job - it knows all keys
already)
Best regards,
Maxim Levitsky
On Tue, 2009-04-07 at 07:59 +0300, Kalle Valo wrote:
> Maxim Levitsky <[email protected]> writes:
>
> > This means kernel can't automatically decrypt other stations traffic.
> > But I could arrange small program that listens to device in monitor or
> > maybe even just promisc mode, and records WPA handshakes. For every
> > handshake it could install the key in kernel driver, so it would use
> > it for decryption, and show the traffic on device in promisc mode. Is
> > it possible to do today? I guess not. All this program has to know is
> > the PSK. (I could even arrange WPA supplicant to do this job - it
> > knows all keys already)
>
> I think wireshark does something like this. You can enter the PSK in the
> settings and it will decrypt the traffic. I only tried it once and it
> was a long time ago, though.
>
Exactly.
But for this I have to use monitor, which means that each time I want to
see only network traffic I have to filter by essid, filter out beacons,
etc.
it would be nicer to use promisc mode, and receive decrypted the
ethernet frames.
So can this be done?
Best regards,
Maxim Levitsky
On Tue, 2009-04-07 at 23:19 +0300, Maxim Levitsky wrote:
> But then maybe its better not to show unencryped frames at all on
> promisc interface?
turn off hw crypto.
johannes
Maxim Levitsky <[email protected]> writes:
> This means kernel can't automatically decrypt other stations traffic.
> But I could arrange small program that listens to device in monitor or
> maybe even just promisc mode, and records WPA handshakes. For every
> handshake it could install the key in kernel driver, so it would use
> it for decryption, and show the traffic on device in promisc mode. Is
> it possible to do today? I guess not. All this program has to know is
> the PSK. (I could even arrange WPA supplicant to do this job - it
> knows all keys already)
I think wireshark does something like this. You can enter the PSK in the
settings and it will decrypt the traffic. I only tried it once and it
was a long time ago, though.
--
Kalle Valo
On Tue, Apr 07, 2009 at 03:15:52AM +0300, Maxim Levitsky wrote:
> But I could arrange small program that listens to device in monitor or
> maybe even just promisc mode, and records WPA handshakes. For every
> handshake it could install the key in kernel driver, so it would use it
> for decryption, and show the traffic on device in promisc mode. Is it
> possible to do today? I guess not.
No, and I don't see why this should ever end up in the kernel.. It is
better done in userspace for such a special case. The key configuration
interface does not support configuring different keys based on the
receiver address and most hardware acceleration designs would not
support matching the key in this way, so the standard mechanism used for
decrypting packets to the STA in normal case does not really suit this
type of need.
> All this program has to know is the PSK.
> (I could even arrange WPA supplicant to do this job - it knows all keys
> already)
Sure, you could figure out the PTK for each STA when using WPA-Personal
(but not so for WPA-Enterprise/EAP), but that is only one part of the
task. The problem comes from decrypting packets that were not designed
to be decrypted (unicast frames to other STAs).
--
Jouni Malinen PGP id EFC895FA
On Tue, Apr 07, 2009 at 11:19:52PM +0300, Maxim Levitsky wrote:
> I mostly agree.
> But then maybe its better not to show unencryped frames at all on
> promisc interface?
I was assuming you were talking about some kind of monitor mode, but if
this is FIF_PROMISC_IN_BSS on a station interface, I would agree that it
would be better not to show some corrupted data frames in the data
interface (I'm assuming here that you mean un-decrypted encrypted frames
to other STAs in BSS). What kind of frames are you seeing in this case?
Which driver are you using?
> Exactly. this why I thought it would be nice if kernel could do that and
> present a virtual promisc mode.
> Userspace helper could do all the job figuring the keys, and kernel
> would just use keys to decrypt the traffic.
> I could even hack the wpa_supplicant on all systems that belong to my
> network to exchange the keys.
I think that I continue to say that this should not be in the kernel or
well, at least not in the upstream kernel. If the current implementation
shows some bogus frames when wlan0 (i.e., non-monitor mode interface) is
set to promisc mode when WPA (or even dynamic WEP) is used, the proper
fix would be to filter those frames out. If someone wants to see all the
frames decrypted, that would be a task for a userspace program (e.g.,
wireshark) and an interface in monitor mode. I've done that in the past
by modifying the AP to send all keys to the sniffer host, but sure, this
could also be done by the supplicant side.
--
Jouni Malinen PGP id EFC895FA
On Tue, 2009-04-07 at 19:17 +0300, Jouni Malinen wrote:
> On Tue, Apr 07, 2009 at 03:15:52AM +0300, Maxim Levitsky wrote:
>
> > But I could arrange small program that listens to device in monitor or
> > maybe even just promisc mode, and records WPA handshakes. For every
> > handshake it could install the key in kernel driver, so it would use it
> > for decryption, and show the traffic on device in promisc mode. Is it
> > possible to do today? I guess not.
>
> No, and I don't see why this should ever end up in the kernel.. It is
> better done in userspace for such a special case. The key configuration
> interface does not support configuring different keys based on the
> receiver address and most hardware acceleration designs would not
> support matching the key in this way, so the standard mechanism used for
> decrypting packets to the STA in normal case does not really suit this
> type of need.
>
I mostly agree.
But then maybe its better not to show unencryped frames at all on
promisc interface?
> > All this program has to know is the PSK.
> > (I could even arrange WPA supplicant to do this job - it knows all keys
> > already)
>
> Sure, you could figure out the PTK for each STA when using WPA-Personal
> (but not so for WPA-Enterprise/EAP), but that is only one part of the
> task. The problem comes from decrypting packets that were not designed
> to be decrypted (unicast frames to other STAs).
Exactly. this why I thought it would be nice if kernel could do that and
present a virtual promisc mode.
Userspace helper could do all the job figuring the keys, and kernel
would just use keys to decrypt the traffic.
I could even hack the wpa_supplicant on all systems that belong to my
network to exchange the keys.
Anyway, thanks,
Best regards,
Maxim Levitsky