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
