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.