Michael MIC failures in AP mode?

Hello,

Now that AP mode works in mac80211 I want to use it to test Michael MIC failures in a wlan driver. Any recommendations, or tips, how to easily create them with mac80211 and hostapd?

Kalle Valo

Inject frames maybe? Easiest is probably to disable hw crypto, then you'll see the fully encrypted frames on a new monitor interface and can inject them again.

johannes

There used to be test code for this in mac80211 that allowed testing of more or less all TKIP error cases (MIC error on TX/RX, ICV error on TX/RX, replay), but it looks like that has been mostly "cleaned up" be removal.. You might be able to find it from some old version..

Anyway, if you just want to test Michael MIC error processing on a client, force mac80211 to do software encryption and modify ieee80211_tx_h_michael_mic_add() in net/mac80211/wpa.c to insert an incorrect MIC (e.g., add mic[0]++; after the michael_mic() call). You will probably need a trigger mechanisms (say debugfs write) to enable this for a single TX frame in order to allow proper client testing.

Once I have some time, I could take a look at recovering the old design with a debugfs interface (it used to use private ioctl). It is useful to be able to test this type of things during development/system validation.

Jouni Malinen                                            PGP id EFC895FA

Ok, I'll try to find it.

Thanks, this is very helpful.

It sure is. I think I'm going to start using hostapd/mac80211 combo for all my development, a simple configuration file and proper logs are very handy compared to some crappy web interface. And having test cases like artificial Michael MIC failure makes the system even better.

I really hope that John can push the AP support to mainline during next merge window :)

Kalle Valo

On that matter, should we put a debugfs control knob in place to completely disable HW encryption in mac80211, so we don't need this override in all drivers?

johannes

Good idea.

Also, we might want to auto-disable HW encryption on a PHY that has one of the following configurations:
-both station and AP interfaces on a single PHY with different encryption on the station and the AP (do we already do this?) -only a monitor interface present
-(possibly) multiple monitor interfaces on the same PHY

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Yes, that would probably be a good idea. There are going to be number of cases when some combinations are not going to work (e.g., when IEEE 802.11w is added, I would expect to see some breakage..) and being able to force software encryption per device could end up being quite useful.

Jouni Malinen                                            PGP id EFC895FA

I think there's a need for this and we should do it. Just look at this commit from earlier this week:

commit 05e6eb6f607cc3623c50b2a7c62b29ba6707a316

Author: Bob Copeland <[email protected]>
Date:   Wed Oct 29 08:30:54 2008 -0400

ath5k: enable hardware encryption for WEP

This change re-enables hardware encryption for ath5k after setting up mac80211 to handle the initialization vectors which happens to make it work. Add a module param (nohwcrypt) to optionally turn it off.

Having a support in mac80211 would make it easier both for the driver developers and users.

Kalle Valo