Gone in 120 seconds: cracking Wi-Fi security

Can't it be stopped by filtering and/or rate limiting ARP packets?

Erik Tews: If you ratelimit ARP packets, it will just slow down the attack. We think the attack can be modified to work with other traffic than ARP. ARP was just the easiest method to implement and it works very well in a real world environment, because everybody uses ARP.

Can it work in a passive way?

Erik Tews: I will now go a little bit into detail. What we need to perform the attack are a lot of packets where we know the IV (this is transmitted in plaintext) and we need to know a certain part of the keystream. If you know the plaintext of the packet, you can get it by just xoring the plaintext with the ciphertext in the packet.

For an ARP request or response, the first 16 bytes of the plaintext are known, which gives you the first 16 bytes of the keystream.

If X = X[0] || ... || X[k] is a keystream, and you are going to attack an i BYTE long WEP key, you should know the keystream from X[2] to X[i+1]. It is still sufficient if you've got a method to guess the keystream correct with a high probability, the attack still works if some keystreams were guessed incorrectly. So if somebody writes some code which guesses the plaintext/keystream of usual ip-traffic right, or guesses more parts of the keystream in most of the cases, it would work with longer keys or in a passive way.

Would using WEPplus be better?

Erik Tews: No. WEPplus was originally designed to defend against the so-called FMS attack, an attack on RC4 which was published in 2001. The FMS attack works a little bit differently to our attack. For FMS the IV needs to fulfill a special condition, which is for a 104 bit WEP environment: first byte must be 16 (decimal) and the second one must be 255 (decimal). The third byte doesn't matter. This is sometimes called the "resolved property".

WEPplus skips all IVs that match that condition. This makes the original FMS attack impossible. There are some modified versions of the FMS attack which even work if these IVs are skipped.

Our attack is different to the FMS attack. Or attack doesn't care about this "resolved property", so filtering out all these IVs shouldn't change anything. This make WEPplus as attackable as normal WEP.

Your paper states that Linux avoids weak IV and doing so slows your success rate by less than five per cent.

Erik Tews: What we were trying to say was the following. In an old attack on WEP, some "weak IVs" where used. Our attack does not profit from these "weak IVs", so skipping them won't protect you.

There is almost no slowdown. If you look at the plot, both lines, the one with the randomly chosen IVs and the IVs chosen by the Linux generator, are nearly identical. Additionally, the Linux generator doesn't choose IVs randomly and skips the weak IVs, it generates the IVs using a counter.

This results in minor differences, but there is nearly no slowdown if the Linux IV generator is used.

In all previous pages, we assumed that IVs are randomly chosen. We tried to show that this attack even works if IVs are not randomly chosen.

If we have hardware that can't be upgraded to support WPA, what is the best way to configure it?

Erik Tews: We think that WEP is DEAD now, there isn't much left to fix. If your hardware cannot speak WPA and you need wireless security, you should replace your hardare (which costs money) or alternatively configure any kind of VPN.

WPA still uses RC4. Is there any type of attack that could take advantage of your speedup to successfully crack WPA?

Ralf-Philipp Weinmann: Before anybody jumps to conclusions: although TKIP is also based on RC4, keys change per packet (!) for this protocol. From my current understanding one would have to be able to efficiently guess a large part if not all of the per-packet keys with a high probability for multiple packets to invert the key hash and obtain the temporal key [there is work by Havard Raddum on this subject].

Furthermore, the Michael integrity protection, together with the strictly monotonous counter IV in the header, will successfully foil re-injection attacks. While WEP can be seen as an glaring example of how _not_ to design a crypto system, the design of TKIP is sound and was done by actual cryptographers. This doesn't mean it's infallible, but it's a lot better.

TLS and SSH also use RC4 but aren't affected by Klein's attack either. Klein's attack needs multiple key streams encrypted generated by "similar" keys. By similar I mean that keys share a common prefix or suffix. This, however, isn't the case with these protocols. Both use a hash function (yes, they actually use two, MD5 and SHA1) to generate the session key under which the data is encrypted under. Again, to successfully attack these protocols, you'd need an attack on RC4 that recovered the key for single key stream.

Please note however that RC4 should not be used in future designs. RC4 is a weak algorithm. Distinguishers exist that allow any contiguous RC4 output stream to be distinguished from random [see Golic's work]. Although these attacks are not practical, remember the old proverb: attacks only get better. ®

Federico Biancuzzi is freelancer who writes for SecurityFocus, ONLamp, LinuxDevCenter, and NewsForge.