TKIP attack

Miles mileshwu
Tue Nov 11 19:50:02 PST 2008

Thank your reply, but I checked and found following(version 0.4.8):
??? if (now > hapd->michael_mic_failure + 60) {
??? ??? hapd->michael_mic_failures = 1;
??? } else {
??? ??? hapd->michael_mic_failures++;
??? ??? if (hapd->michael_mic_failures > 1)
??? ??? ??? ieee80211_tkip_countermeasures_start(hapd);
??? }

It will wait until the second MIC error and then go to countermeasure.

Even hostapd will go to countermeasure mode for every single MIC error, is it too expensive to kick out all clients? How about we just  rekey or deauth the client who cause it.

Thank you!

--- On Tue, 11/11/08, Jouni Malinen <j at> wrote:
From: Jouni Malinen <j at>
Subject: Re: TKIP attack
To: hostap at
Date: Tuesday, November 11, 2008, 1:41 PM

On Tue, Nov 11, 2008 at 12:54:55PM -0800, Miles wrote:

> Have we implemented any code to prevent TKIP attack in hostapd? 

hostapd forces rekeying of PTK on the first Michael MIC failure report
(i.e., it does not wait for TKIP countermeasures to be started on the
second failure). This limits this particular chopchop attack to only a
single octet and as such, the attack cannot be used to determine the
Michael MIC key or full ARC4 stream for pairwise packets. As far as
group packets are concerned, the attack might be feasible, but that can
be mitigated by setting the GTK rekeying to happen relatively frequently
(e.g., wpa_group_rekey=600 which is the default value in hostapd or even
a smaller value to make the attack more default at the cost of more
frequent key updates).

Jouni Malinen                                            PGP id EFC895FA
HostAP mailing list
HostAP at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Hostap mailing list