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

[Alexander Wetzel <alexander@wetzel-home.de>]

> 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