The New Attack on WPA/TKIP: Much Ado About Nothing?


The recently announced improved version of the original Beck-Tews attack on WPA/TKIP appears to have put the wireless security community in a tizzy again.  In this post, I argue that the new attack is neither groundbreaking in academic terms, nor is it more worrying in practical terms.

The proposed attack assumes (somewhat unrealistically) that the AP and client cannot hear each other but the attacker can hear both (and can thus act as a man-in-the-middle).  In terms of attack speed as well, it is actually slower than the original attack under its stated assumptions.

The Beck-Tews Attack

The Beck-Tews attack works by using the well-known chopchop attack on the ICV computation in WEP (that is also used in TKIP) to first decrypt the last 12 bytes of a sniffed ARP packet. Assuming that only the last bytes of the two IP addresses in the ARP packet are unknown, the attacker can then recover both the Michael key for the session as well as the entire key stream for the sniffed packet.  The attack is brilliantly conceived in that it uses the MIC failure report packet, which was intended to protect against malicious replays, to verify that its guess for the byte being decrypted is correct.  The attack gets around the “no TSC reuse” restriction of TKIP by injecting frames in the unused QoS streams.  To ensure that rekeying does not get triggered, the attacker cannot decrypt more than one byte per minute.

Once the attacker has derived the Michael key and the key stream for the sniffed packet, it can then inject up to 7 packets of its choice (one in each of the unused QoS streams) that will be accepted as legitimate by the client.  To inject more packets, it needs to sniff another ARP packet and again decrypt its ICV in order to find the key stream for another TSC.  This time around though, only the last 4 bytes need to be decrypted since the Michael key is already known.

Thus, once the Michael key has been recovered, the attacker can inject up to 7 packets every four minutes with almost guaranteed success.

The New Attack

The improvements suggested by Ohigashi and Morii essentially trade the requirement of QoS use with an even more stringent one – that the attacker be in a physical position to act as a man-in-the-middle between the AP and the client.  That is, the new attack requires that the AP and client cannot hear each other but can both hear and be heard by the attacker.  This removes the QoS requirement because the attacker can prevent the packets transmitted by the AP from reaching the client when it wants.  In my opinion though, this makes the attack rather less practical than more – while QoS is widely supported by the hardware available today, placing the attacker in an advantageous position with respect to the AP and client as required is, in practice, easier said than done!

The other contribution of this proposal is that the new attack needs to decrypt only one byte of the ICV rather than all four (once 12 bytes of an initial packet have been decrypted to obtain the Michael key).  This means that after the initial boot time of 12 minutes, the attack can be slightly faster – a distinct key stream can be obtained every minute rather than once every four minutes.  This improvement however comes at a cost.  If the attacker decrypts all four bytes of the ICV, the correct key stream is obtained with nearly 100% success while if only one byte is decrypted, the success rate drops to about 37%.  The bottom line is that while the original attack can inject seven packets every four minutes with almost 100% probability, the new attack can inject one packet every minute but with only about 37% chance of success.  The astute reader will note that this will make the attack slower and not faster, on an average, than the original attack.  Of course, if QoS is also assumed, the new attack can inject 7 packets every minute with 37% chance of success which means that it will be, on an average, about 1.5 times faster than the original attack (and not four times faster).


The original Beck-Tews attack was truly path breaking in that it revealed the very first chink in the WPA/TKIP armor. In my view, the new attack is just a slightly different angle on the original work, and does not advance the state of the art in exploiting WPA/TKIP vulnerabilities in a significant manner.

Deepak Gupta

Deepak Gupta is the Director of Product Architecture at AirTight Networks. He brings a unique blend of academic research and product engineering experience. Prior to joining AirTight, Deepak was an Associate Professor in the Computer Science Department at IIT Kanpur. He holds BTech and PhD degrees in Computer Science, both from IIT Kanpur.


  1. Mark B says

    Very well stated. Unfortunately I don’t think your well reasoned post will stop tech news sites from posting that WPA can now be broken in “under a minute”.

  2. HC says

    Wouldn’t it be possible to increase the success probability from 37% to 100% by transmitting multiple guesses. For example, if some instance turns up two guesses, instead of throwing that instance away, what if attacker transmits both guesses with hope that the correct one among them will cause the desired damage.

  3. Deepak Gupta says

    That is indeed correct and I have been hoping that someone would point that out! If there happen to be two feasible values of the unknown data byte that results in the correct known ICV byte, the attacker will have two candidate key streams one of which is correct. If he now injects his attack packet twice, encrypted once with each of the two candidates, the ICV for the wrong candidate will most likely be wrong and hence one of the two packets will be harmless discarded while the other will be accepted as legitimate. Similarly, if there are three or more feasible guesses, the attack packet can be injected that many times with an almost 100% guarantee that the packet encrypted with the key stream corresponding to the correct guess will be accepted while the others will be harmlessly discarded.

    By the way, if you are interested, the probability of two feasible guesses is also about 37%, for three it is 18%, 6% for 4, and then it goes downhill pretty fast. So the bottom line is that in most cases, the attacker will not have more than 5 feasible guesses, and can increase his attack success probability to almost 100% by injecting a few more packets each time.

    Having said that, the fact remains that WPA/TKIP is far from being “cracked in under a minute” by this attack because:

    1. The requirement of the attacker being in a position to play “man in the middle” is not easy to meet.

    2. 12 minutes are still required to crack the Michael key. This is the same as in the original Beck-Tews attack.

    Comments welcome!

  4. HC says

    If more than one wrong packet is sent, can it trigger MIC failure in undesirable way? If so, then sending more than two guesses is out of question, right.

  5. Deepak Gupta says

    A MIC failure will be triggered only if the ICV is correct but the MIC is not. For an incorrect guess, the ICV should be wrong with a very high probability. With a small probability it is possible that the ICV turns out OK but the MIC is not. If that happens for more than one packet in less than a minute, the association will get rekeyed. The chances that it will happen for TWO attack packets should be pretty small.

    • Vinicius Borba says

      I’m wondering a lot about that without answer friend…

      Ok, the MIC failure will be sent only when the ICV is correct and the MIC is not.
      But, how the attack can know the ICV was guessed correct (supposing the attack start from the end to begin of the packet, I think it happens this way) if it only changed the last byte (ICV) and the MIC continue being right??? So we don’t have answer from the victim system when we send the correct last byte (ICV).

      So what is cracked first, MIC or ICV?

      Please, explain it to me. It leading me crazy!!!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>