Jouni Malinen wrote: > On Tue, May 08, 2012 at 08:28:33AM +0200, Andreas Hartmann wrote: >>> The main requirements: >>> - support CCMP encryption/decryption of unicast robust management frames >>> (subset of Action frames, Deauthentication, Disassociation) >> >> I tested WPA-EAP-SHA256 with group key ccmp. > > The key point here is to test whether at least one of those management > frames gets encrypted and decrypted correctly. Deauthentication frames > may be easiest for that purpose and you can request the station to > disconnect to test AP's capability of receiving the frame and then use > hostapd_cli deauthenticate <addr> command on the AP to request the > station to be disconnected. Deauth works fine as long as both ralink devices (AP and STA) use nowhwcrypt (or both are using hwcrypt - but this does not work with ath9k STA e.g.). If one of both runs hwencryption, it doesn't work any more - exactly the same as with BA session requests. >> The IGTK is a single key (shared key). There are a maximum of 4 shared >> keys designated in rt2x00mac.c for each BSS for use with hw encryption. > > BIP uses key indexes 4 and 5 (i.e., the 5th and 6th index).. Anyway, > this would most likely be handled in software so the main point here is > to prevent hardware from doing anything additional to the frames. > >> Since rt2800usb is working fine with nohwcrypt=1 (but not with >> encryption done in hw), I assume, that there is no differentiation >> between the encryption / decryption of different frame types. If hw >> encryption is turned on, all types of frames are encrypted / decrypted >> by hardware and vice versa. > > BIP is kind of special since it doesn't actually even set the Protected > field in the frame header which may make this easier.. The frames are > not actually encrypted, i.e., BIP protects only authenticity of the > frames. Thanks for this explanation! >> I'm not sure how BIP is secured if hw encryption is enabled. BIP is >> implemented in mac80211 as part of decryption. Is BIP done during hw >> encryption, too? Or is it done by mac80211 w/ enabled hw encryption, too? > > With most drivers, yes, I would expect mac80211 to handle both TX and RX > side. The driver should just return -EOPNOTSUPP in the set_key() handler > for WLAN_CIPHER_SUITE_AES_CMAC to leave BIP for mac80211 and CCMP for > hwardware. So, this is lower priority for me at the moment :-). >> This means for rt2x00: to get 11w working with hw encryption enabled, >> there needs to be some differentiation for the encryption of management >> frames: if management frame, let mac80211 do the job - all other frames >> should be encrypted by hw. >> Correct? > > Well, if you are saying that the issues shows up with unicast robust > management frames, too, and not just BIP (group addressed robust > management frames), Yes. My primary problem at the moment is the handling of the unicast robust management frames. > then you are in problems.. yes - that's why I am here :-) > With good luck, you could > be able to make the hardware not mess up with unicast robust management > frames and handle them in mac80211. This may be easier for TX, How do I exactly recognize this situation? The unicast robust management frames aren't decrypted with WLAN_CIPHER_SUITE_AES_CMAC. Could they be given back to mac80211 because of the fact they are management frames? > but RX > can be a bit complex. This seems to be my problem here, too. Sending the deauth from AP (nohwcrypt=1) can't be handled by STA with hwcrypt enabled. > It may go to the point of having to use the > driver to workaround the mess that hardware did (i.e., re-encrypted the > frame in incorrect way to get back to the correctly encrypted form and > then sent that to mac80211).. All this depends on the exact behavior of > the hardware with a frame that was designed after the hardware was, so > good luck figuring that out ;-). Thank you! Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
