Antarctica Starts Here.

Just when you thought it was safe to raise an antenna and go wireless again, along comes another attack to make you think twice. A pair of security researchers, Erik Tews and Martin Beck, will present a new attack against WPA (Wi-Fi Protected Access) at the PacSec conference next week. If you're not up on wireless network technologies, WPA is the system developed to secure wireless network traffic after WEP was found to be too insecure. The basic purpose of WPA is to encrypt all data traffic between a wireless client and an access point (modulo the control packets, of course) in as transparent a manner as possible to the user to minimize the possibility that a passive attacker will be able to make sense of any recorded traffic. Part of WPA is a protocol called TKIP, the Temporal Key Integrity Protocol, which is designed to renegotiate the session key of every client/AP link on a periodic basis (once every wallclock hour or so). The reason for this is so that an exceptionally lucky attacker, if they manage to crack one of the temporal keys, will only be able to decrypt the traffic for that hour rather than the entire length of time a client is associated with the AP.

Ordinarily, the only feasible attack under such circumstances is a brute-force attack, which is when you try every possible combination of characters to see which one will reveal usable information rather than garbage. While this will work if you throw enough processing power at it, it could potentially take thousands of years to be successful. Beck and Tews say that they've found a vulnerability in the protocol which will reveal one of the keys used in WPA (of which there are several on each side of a link) inside of 15 wallclock minutes. From this description it sounds as if they've figured out a way to predict the constantly changing keys used to encrypt traffic from the base station to a wireless client, though not decrypt traffic from the client back to the AP or any of the recorded traffic to some arbitrary yet recent point in time. The relatively thin description in the article suggests that the recording and analysis of a volume of AP-to-client traffic is required, which seems to support this hypothesis. Now, there are three directions in which this scenario could potentially go: one, this attack winds up being so limited in utility that it's little more than an interesting curiosity, sort of like piecing together bits of a packet by recording the LEDs flashing on the front panel of a switch or router. Two, this winds up being an interesting attack but nothing to start sweating over until someone farther down the line figures out a real showstopper using this vulnerability as a starting point. Or three, this winds up being as bad as WEP being cracked about a half-decade ago, rocks fall, we all die. However, all is not lost - TKIP is only one way of protecting wireless traffic. Most if not all 802.11g-capable wireless devices (you'll have a difficult time finding pure 802.11b hardware these days) also support AES-CCMP in addition to TKIP. AES-CCMP isn't anything to sneeze at, either - sure, you'll lose backwards compatibility for some older hardware, and it'll take more horsepower to run (AES in counter mode with key sizes of 128, 196, or 256 bits, plus multiple rounds of encryption) but you'll also gain a bit more security in that some data link layer information will be encrypted as well. While it would be highly difficult for large organizations to migrate all of their wireless gear over to AES-CCMP en masse, it should still be a viable option (unless there are unsuspected aspects to the vulnerability that aren't even speculated on in the articles). At the other end of the spectrum, home users should be able to do the same thing with relatively little trouble. A major drawbacck to AES-CCMP, however, is that there is no key rotation functionality; what you get from your sysadmin is it. Also, older gear, like many PDAs and wireless cards simply won't work anymore.

Unfortunately, all of the articles published to date about this vulnerability have been short on facts. Without more hard information the best I can do is speculate on this particular vulnerability. It's possible that Tews and Beck have found a novel way of manipulating some features of TKIP to expose bits of the transient cryptokey, such as finding more weak initialization vectors than were previously known in the RC-4 algorithm (which forms the crypto engine of TKIP), or at least IVs that are weak in a practical sense when considered within the context of TKIP. Another possibility is that they found a way to force many-but-possibly-not-all access points to fall back on using the "broadcast to all connected clients" TKIP key rather than the per-link key for a particular client. A potential downside of such an attack, however, requires the attacker to already be associated with the wireless access point to have access to that key so we can probably rule that out. Arguably, it would be a better use of an attacker's time to compromise a machine on the other side of the AP (on the hardwired network) and sniff the traffic from all of the associated wireless clients. Yet another possibility could be that the attack involves wireless networks that use pre-shared keys (i.e., passphrases) rather than another form of authentication, like 802.1X. Generally speaking, PSK is the rule and not the exception due to the hardware, cost, and difficulty involved in setting up 802.1X. Suffice it to say that you'll really only find such a setup as part of a large corporate network and not a home office or even your run of the mill office network. If you go even farther out into the weeds there's a chance that they've found a bug in the system which derives the per-packet crypto keys. Perhaps some bits from the next couple of possible keys are echoed or suggested in the encrypted packets that come before them. Maybe they've found a way of inferring bits of the transient AP-to-client key by replaying packets recorded earlier without setting the "duplicate frame" bit.

Only time will tell.