Cracking TKIP: The New Menace

As you will see in the following Defense chapters, 802.11i TKIP eliminates the vulnerabilities of WEP we have described and is considered to be practically uncrackable, or is it? When the TKIP keys are generated, distributed, and rotated using 802.1x and RADIUS, a cracker won't get far trying to crack the keys. Instead, he or she will probably choose a more lateral approach, trying to attack the 801.1x itself. However, if 802.1x cannot be used, a preshared key (PSK) will substitute it as a key establishment method. Although each client host can have its own PSK, at the moment the only real-world implementation of the PSK available is a single PSK per ESSID, just like WEP was. However, the PSK is not used to encrypt data like WEP. Instead, it is employed to generate pairwise transient keys (PTK) for each TKIP-protected connection. These keys are distributed by a four-way handshake and, apart from the PSK, use two nonces from the two first packets of the handshake and two MAC addresses of the involved hosts. Because the handshake packets and the MAC addresses are easy to sniff out, once you know the PSK, you can easily produce all the PTKs you need and the network is yours to take. As usual, the handshake can be initiated by a DoS attack deassociating a client host from the AP. This already eliminates the advantage of TKIP preventing the "nosey employee attack" (users on the same WLAN sniffing each other's traffic). Such an attack can be mitigated by users not knowing the PSK, which creates additional load on the system administrator, who is now also responsible for entering the key on every user's box.

But can an outside attacker obtain the PSK and take over the WLAN? With some luck he or she can. In a four-way handshake, the PTK is used to hash the frames. Because we know both nonces and both MACs, all we need to derive the PSK from the PTK is to crack the hash. Offline hash cracking is neither new nor hard to perform. We deal with it in this chapter, too, in a section devoted to attacks against EAP-LEAP. A PSK is 256 bits long; this is a significantly large number. Although this is great from the cryptographic point of view, no user would ever remember or easily enter a password string that long. Thus, the PSK is generated from an ASCII passphrase in accordance with the following formula:

PMK = PBKDF2(passphrase, essid, essidLength, 4096, 256)

where PBKDF2 is a cryptographic method from the PKCS #5 v2.0 Password-based Cryptography Standard. In a nutshell, the string of the passphrase, the ESSID, and its length are hashed 4,096 times to generate a 256-bit key value. Interestingly, neither the length of the passphrase nor the length of the ESSID has a significant impact on the speed of hashing. As stated in the 802.11i standard, a typical passphrase has approximately 2.5 security bits per single character. The n bits passphrase should produce a key with 2.5*n + 12 security bits. In accordance with this formula (and the 802.11i standard), a key generated from a passphrase less than 20 characters in length is not sufficiently secure and can be cracked. Just how many users (or even system administrators) usually choose and remember passwords of 20 characters or more?

The practical attack against PSK-using TKIP would resemble an offline WEP cracking with WEPattack. The handshake frames capture can be done after deassociating a wireless host by one of the DoS attacks described in this chapter. Robert Moskowitz, who proposed this attack, considers it to be easier to execute than, for example, brute-forcing or running dictionary attacks against WEP. Although no ready tool to perform the offline TKIP cracking exists at the moment of writing, the bounty is too high and most likely by the time you buy this book, the cracking underground will come up with one. After all, we are talking about a hash-cracking tool similar to md5crack and a shell script to send deassociate frames and capture the handshake afterward to provide the feed for a hash cracker. Similar functionality is already implemented in a wireless attack tool, namely the Asleap-imp.

What would be the impact of such an attack? The wireless networks that do not use 802.1x for TKIP keys distribution and rotation are primarily the networks lacking a RADIUS server due to installation difficulties, price, or other reasons. The networks using legacy wireless hardware and firmware incapable of handling 802.1x also fall into this category. This means that SOHO networks and public hotspots (mind the users bringing "ancient" unupdated client cards) are the networks expected to be susceptible to offline TKIP cracking attacks. These are precisely the kind of networks on which users and administrators are likely to set simple, easy-to-crack passwords that can be found in a modest dictionary. This is clearly a case of Murphy's Law at work.