Search Linux Wireless

Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'll take a look, but a trace-cmd recording would be more interesting
than the monitor interface, as it also tells us when what key was
installed etc.

I've just uploaded better captures also including traces to the same location. Everything relevant for this mail is in the folder
iwlwifi-debug here:
https://www.awhome.eu/index.php/s/AJJXBLsZmzHdxpX

The old traces have been moved to top dir "old", if you still are interested in them, but I think the new ones should be better.

1) Both AP and the STA are now running wt-2019-04-10 *without* the not merged patches from the Extended Key ID series. (I've only enabled Ext_Key_ID for mvm and dvm on top and added some printk's. The patches for that are also available via the link above but really boring...

2) the files with the same prefix (in the format HH:MM) show the same communication. The AP files are of course from the AP, STA from the client station and Sniff from my Netgear 7800 used as a OTA sniffer. With the AP literally sitting on top of it.
The "Sniff" files can be decoded with the WPA Password "ExtKeyTestAP".

My "Hack" patch to wireshark to allow it to decode keyID 1 is also uploaded. (The hack just allows decoding of keyID 1 at the price of no longer decoding frames encrypted with gtk keyid 1.)

3) the AP is using a AC 3168NGW and the STA a AC 8265. The two devices are roughly 2m apart with a direct line of sight on a channel with next to no other traffic on it. (You see what's there in the Sniff captures, these are all totally unfiltered.)

4) I also tried running a trace on the STA. But I could not reproduce the issue when a trace was running on the STA. (That's probably coincidence, through, I just gave it three tries and the first without a trace on the STA worked.)

5) The files in the "broken" folder are showing the issue and the ones in "working" (seem) to be ok at a first glance.

I can run more tests and also try catch the problem with a STA trace, too, if you want. But that may not be necessary:

It looks like we only have a problem when we get frames with the "new" keyID and then again some with the "old" keyID. Of course we also could have multiple problems, too... But in that case I would say let's first look at this one. The problematic frames are encrypted with the correct "old" key, according to wireshark.

But on the STA they are scrambled and therefor probably have been decrypted with the - in this case - wrong new key.

And as it happens there is also a really good looking first suspect why this may have happened: According to the STA captures the broken frames came in one A-MPDU which started with keyID 1 and then "appended" the older keyID 0 frames at the end. (The OTA sniffer seems to be miss the A-MPDU details, see the STA capture...)

Now it really looks like the mvm cards are trusting the standard and decode all MPDUs within one A-MPDU with the same key while at the same time allow mixing different keyIDs in a-MPDU.

The so far mostly theoretical question how far mac80211 should support the driver (e.g. key ID border signal) or if we want to let the drivers/card handle that would become much more pressing...

Ideally the card/firmware would be able to detect that and start a new A-MPDU. But for my understanding the driver could also set A-MPDU to only one frame, forcing the firmware to flush all A-MPDUs under construction and then set it back to the normal value. (Or that is how I've planned to test that in that way with your tips in the past and what's documented of the mvm/dvm firmware API.)


Please do review the privacy notes there at the end of the page if you
do this, you should probably send the files to me/us directly rather
than post publicly. They do contain the keys of your (test) network to
some extent - at least of course the PTK(s)/GTK(s), but usually also the
KEK/KCK.

Thanks for the reminder.
I'll definitely will remember the option, I was not aware that there was a more private way:-)

So far I can accept the risk - as I understand it - or even some short term intruders in my test network.

For my understanding the previous captures (without the PSK in the mail) only allows brute forcing the PSK due to the 4-way handshakes. Providing a valid handshake allows anyone to crack the PSK, without the challenge to capture it himself.

But risk of providing eapol frames of your network changed last year, the handshake is no longer required to crack the password. Anyone able to talk to the AP can get equivalent information by a simple query. So I assume sharing captures with the eapol handshakes is not impacting the security of my (test) Wlan in any relevant way. So I'm only giving everyone a small peak in my normally encrypted wlan, correct?

Here a link to the vulnerability discovered last year:
https://blog.avira.com/cracking-your-wpa2-wi-fi-password-just-became-easier/

But I've changed the PSK already for my test Wlan again from the ones used in the provided captures. The "real" Wlan is using EAP-TLS, the one I had the ptk rekey freezes some years ago:-)

Alexander



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux