Archive for the ‘IEEE’ Category

TKIP security is not “Gone in 60 Seconds”

Friday, August 28th, 2009

On the train home last night, I read the paper by Ohigashi and Morii that made the news yesterday, and resulted in a good number of electrons being spilled yesterday afternoon.

Before I get started, the key point here is:

If you have concerns about wireless security, JUST USE CCMP.

(CCMP is often referred to as WPA2, but that’s a nomenclature point that I’d rather not get into here.)

I enjoyed reading the paper because the attack is clever, and nicely builds on some work from a year ago by Eric Tews and Martin Beck. Both the Ohigashi/Morii paper and the Tews/Beck paper describe attacks against the TKIP integrity check. Notably, neither attack is able to recover the keys used by TKIP to encrypt frames.

The most important thing to understand about TKIP is that it was intended to be an interim measure. When design work on TKIP started in 2001, there was a two-pronged approach to developing wireless security protocols. The first prong was updating the much-maligned WEP to improve security, but that effort was circumscribed because the design that emerged was constrained by the need to be hardware-compatible with the millions of devices which had already been sold with WEP support. (In technical terms, that restricted TKIP to be based on the RC4 cipher, and prevented development of a message integrity check with significant computational requirements.)

In essence, TKIP is a set of “seat belts” that keep the most vulnerable parts of WEP from being thrown through the windshield or impaled on the steering column. (One of my favorite papers about the weaknesses in WEP is IEEE 802.11 document 11-00/0362, titled Unsafe at Any Key Length, which is where the metaphor comes from.)

I’m not terribly surprised by the increasing number of papers written about flaws in TKIP. Given the severe design constraints, TKIP was a stopgap solution intended to buy time to give wireless LAN users the breathing space to move to the eventual AES-based protocol in development. TKIP had a “design lifetime” of five years, meaning that the intent was to resist cryptanalytic attacks for that length of time. The TKIP specification had matured by 2003, so it is not a surprise that flaws began to be identified last year.

Last year, the Tews/Beck paper exposed a subtle flaw in TKIP’s integrity checking. The attack described in last year’s paper required that a network have quality of service extensions enabled. Ohigashi and Morii did away with that constraint by showing that an attacker clever enough to insinuate himself into the conversation between the network and a client device can perform a similar attack.

The technical impact of this attack is small. Tews and Beck showed that a network with WMM could be subject to attacks against the TKIP integrity check. Ohigashi and Morii have generalized that work to networks in which the attacker does not need WMM to be enabled, but the trade is that the attacker must have a situation in which the victim is outside the range of the AP without relaying. Many vendors developed workarounds a year ago which continue to provide protection against this attack.

What this perceptive paper should do is heighten the disquiet regarding continued use of TKIP. Initial papers on WEP showed flaws that were not fatal, but the accretion of cryptanalytic expertise over time resulted in a complete break of the protocol which enables attackers to swiftly recover encryption keys. TKIP has not suffered this fate yet, but it is difficult to know how far off that day is. The best advice is to start using CCMP today, and make plans to move away from TKIP.

TKIP was intended for use as a stopgap, and it was optimized for use with the existing protocol features at the time of its design. It has not been extended to protect the extended headers defined by 802.11n, which is why the Wi-Fi Alliance has defined tests to prevent the use of TKIP with its 11n certification. It will never provide protection for 802.11 management frames. (To learn more about management frame protection, see the summary video for a talk I’ve submitted to the RSA conference next year.)

The future of wireless LAN security is CCMP. Let’s bury TKIP, and move away from it before it becomes absolutely necessary.

Stick a fork in 802.11n, it’s almost done!

Monday, July 20th, 2009

Last week, the IEEE 802.11 working group met in San Francisco. Activity on the long-awaited 802.11n standard has been slowly moving through the process for several meetings now. On Friday, we took what is likely to be the final step as the 802.11 working group. We held our final approval vote, requesting that higher layers of the IEEE 802 group approve 11n for publication.

The vote felt somewhat anti-climactic. In a lightly discussed and debated motion to send the 802.11n draft onward, 53 members (including your correspondent) voted in favor, 1 voted against , and 6 abstained.

Following the working group’s approval, the IEEE 802 executive committee voted unanimously (14 for, none against or abstaining) to send 802.11n to “RevCom,” the IEEE Standards Board Review Committee. The IEEE Standards Board next meets on September 11, 2009.

In an interesting twist, September 11 is a date relevant to the history of 802.11n. Bruce Kraemer, the long-time chair of Task Group N and the current chair of the 802.11 working group, noted that the first meeting of the “High Throughput Study Group,” the precursor to TGn, was September 11, 2002.

If approved, the 802.11n effort will have taken exactly seven years, at least by one measure. We are a long way from the first time 802.11n passed the 75% threshold.

The 802.11 working group is already working on the next step. Two task groups (TGac and TGad) are researching and debating methods to create gigabit-capable physical layers.