Michael MIC failures in AP mode?

Michael MIC failures in AP mode?

[Kalle Valo]

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

Re: Michael MIC failures in AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Sat, 2008-11-01 at 16:31 +0200, Kalle Valo wrote:

> 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?

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Michael MIC failures in AP mode?

[Jouni Malinen]

On Sat, Nov 01, 2008 at 04:31:26PM +0200, Kalle Valo wrote:

> 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?

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

Re: Michael MIC failures in AP mode?

[Kalle Valo]

"ext Jouni Malinen" <j@w1.fi> writes:

> On Sat, Nov 01, 2008 at 04:31:26PM +0200, Kalle Valo wrote:
>
>> 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?
>
> 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..

Ok, I'll try to find it.

> 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.

Thanks, this is very helpful.

> 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.

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

Re: Michael MIC failures in AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

On Sat, 2008-11-01 at 17:19 +0200, Jouni Malinen wrote:

> Anyway, if you just want to test Michael MIC error processing on a
> client, force mac80211 to do software encryption

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Michael MIC failures in AP mode?

[Jouni Malinen]

On Sat, Nov 01, 2008 at 04:51:37PM +0100, Johannes Berg wrote:

> 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?

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

Re: Michael MIC failures in AP mode?

[Stefanik Gábor]

On Sat, Nov 1, 2008 at 4:51 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sat, 2008-11-01 at 17:19 +0200, Jouni Malinen wrote:
>
>> Anyway, if you just want to test Michael MIC error processing on a
>> client, force mac80211 to do software encryption
>
> 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. :-)

Re: Michael MIC failures in AP mode?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Sat, 2008-11-01 at 17:19 +0200, Jouni Malinen wrote:
>
>> Anyway, if you just want to test Michael MIC error processing on a
>> client, force mac80211 to do software encryption
>
> 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?

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 <me@bobcopeland.com>
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.
    
    Signed-off-by: Bob Copeland <me@bobcopeland.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

-- 
Kalle Valo