Email Delivery

Receive new posts as email.

Email address

Syndicate this site

RSS | Atom


About This Site
Contact Us
Privacy Policy


November 2010
Sun Mon Tues Wed Thurs Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Stories by Category

Basics :: Basics
Casting :: Casting Listen In Podcasts Videocasts
Culture :: Culture Hacking
Deals :: Deals
Future :: Future
Hardware :: Hardware Adapters Appliances Chips Consumer Electronics Gaming Home Entertainment Music Photography Video Gadgets Mesh Monitoring and Testing PDAs Phones Smartphones
Industry :: Industry Conferences Financial Free Health Legal Research Vendor analysis
International :: International
Media :: Media Locally cached Streaming
Metro-Scale Networks :: Metro-Scale Networks Community Networking Municipal
Network Types :: Network Types Broadband Wireless Cellular 2.5G and 3G 4G Power Line Satellite
News :: News Mainstream Media
Politics :: Politics Regulation Sock Puppets
Schedules :: Schedules
Security :: Security 802.1X
Site Specific :: Site Specific Administrative Detail April Fool's Blogging Book review Cluelessness Guest Commentary History Humor Self-Promotion Unique Wee-Fi Who's Hot Today?
Software :: Software Open Source
Spectrum :: Spectrum 60 GHz
Standards :: Standards 802.11a 802.11ac 802.11ad 802.11e 802.11g 802.11n 802.20 Bluetooth MIMO UWB WiGig WiMAX ZigBee
Transportation and Lodging :: Transportation and Lodging Air Travel Aquatic Commuting Hotels Rails
Unclassified :: Unclassified
Vertical Markets :: Vertical Markets Academia Enterprise WLAN Switches Home Hot Spot Aggregators Hot Spot Advertising Road Warrior Roaming Libraries Location Medical Public Safety Residential Rural SOHO Small-Medium Sized Business Universities Utilities wISP
Voice :: Voice


November 2010 | October 2010 | September 2010 | August 2010 | July 2010 | June 2010 | May 2010 | April 2010 | March 2010 | February 2010 | January 2010 | December 2009 | November 2009 | October 2009 | September 2009 | August 2009 | July 2009 | June 2009 | May 2009 | April 2009 | March 2009 | February 2009 | January 2009 | December 2008 | November 2008 | October 2008 | September 2008 | August 2008 | July 2008 | June 2008 | May 2008 | April 2008 | March 2008 | February 2008 | January 2008 | December 2007 | November 2007 | October 2007 | September 2007 | August 2007 | July 2007 | June 2007 | May 2007 | April 2007 | March 2007 | February 2007 | January 2007 | December 2006 | November 2006 | October 2006 | September 2006 | August 2006 | July 2006 | June 2006 | May 2006 | April 2006 | March 2006 | February 2006 | January 2006 | December 2005 | November 2005 | October 2005 | September 2005 | August 2005 | July 2005 | June 2005 | May 2005 | April 2005 | March 2005 | February 2005 | January 2005 | December 2004 | November 2004 | October 2004 | September 2004 | August 2004 | July 2004 | June 2004 | May 2004 | April 2004 | March 2004 | February 2004 | January 2004 | December 2003 | November 2003 | October 2003 | September 2003 | August 2003 | July 2003 | June 2003 | May 2003 | April 2003 | March 2003 | February 2003 | January 2003 | December 2002 | November 2002 | October 2002 | September 2002 | August 2002 | July 2002 | June 2002 | May 2002 | April 2002 | March 2002 | February 2002 | January 2002 | December 2001 | November 2001 | October 2001 | September 2001 | August 2001 | July 2001 | June 2001 | May 2001 | April 2001 |

Recent Entries

In-Flight Wi-Fi and In-Flight Bombs
Can WPA Protect against Firesheep on Same Network?
Southwest Sets In-Flight Wi-Fi at $5
Eye-Fi Adds a View for Web Access
Firesheep Makes Sidejacking Easy
Wi-Fi Direct Certification Starts
Decaf on the Starbucks Digital Network
Google Did Snag Passwords
WiMax and LTE Not Technically 4G by ITU Standards
AT&T Wi-Fi Connections Keep High Growth with Free Service

Site Philosophy

This site operates as an independent editorial operation. Advertising, sponsorships, and other non-editorial materials represent the opinions and messages of their respective origins, and not of the site operator. Part of the FM Tech advertising network.


Entire site and all contents except otherwise noted © Copyright 2001-2010 by Glenn Fleishman. Some images ©2006 Jupiterimages Corporation. All rights reserved. Please contact us for reprint rights. Linking is, of course, free and encouraged.

Powered by
Movable Type

« Snow Leopard's Wi-Fi Improvements | Main | Interest High in Providing Service for New York Railroads »

August 27, 2009

New WPA with TKIP Exploit Presented in Paper

Japanese researchers develop improved version of last year's WPA with TKIP exploit: (PDF) The researchers build on the work of Eric Tews and Martin Beck, in which those two German grad students figured out how to falsify short packets when the TKIP method of encryption was employed. Their method didn't crack a TKIP key, but relied on a weakness of TKIP's backwards compatibility with the thoroughly broken WEP security. For a thorough rundown of the Beck and Tews approach, see my Ars Technica article, Battered but Not Broken, and an article on this site, Don't Panic over WPA Flaw, But Do Pay Attention (both from Nov-2008).

I've had a chance to absorb the paper, A Practical Message Falsification Attack on WPA, by Toshihiro Ohigashi and Masakatu Morii, and I'm not convinced of its efficacy as an attack vector, but it's darned clever. It's been reported as WPA broken in under a minute! by some news sources. In fact, it requires a lot of pieces to be in the right places, and doesn't allow recovery of a WPA encryption passphrase.

The following gets reasonably technical, but I'll give you the conclusion upfront: if you have any concerns about network integrity, move to AES-CCMP, which requires WPA2 Personal for home and small office networks or WPA2 Enterprise for larger networks. Using AES-CCMP requires that all network equipment be from 2003 or later, more or less. Earlier equipment, if still in use, should either be upgraded to newer Wi-Fi adapters, switched to Ethernet only, or retired.

Now the technical bits.

In brief, Beck and Tews rely on a weakness from WEP that lets them substitute bytes in very short, well-known payloads, such as ARP (address resolution protocol) messages by testing changes in the checksum to first solve for the existing bytes, and then sending a falsified packet. Their method relies on 802.11e (Quality of Service), because that protocol establishes separate queues that can duplicate the sequence used in the initialization vector (IV) that's part of the cryptographic process. Clients (or stations) reject lower-numbered IVs than the current point in the sequence.

Ohigahi and Morii use a physical man-in-the-middle (MitM) as part of their solution. Instead of relying on QoS, the Japanese academics employ a directional antenna that lets them intercept and reuse an IV: the station only receives the falsified packet, and thus doesn't receive an out-of-sequence number. This mostly likely requires a directional antenna which can overpower the broadcast of the access point for a given client; it might also work with a distant omnidirectional access point if the attacker had a more powerful omni. The attacker typically acts as a signal repeater; most data is relayed with no changes, as in the classic MitM approach.

The 802.11 security protocols combined with a secure EAP flavor (such as PEAP) only defend against an MitM attack in which a malicious party is attempting to establish encrypted connections masquerading as a client to an access point and an access point to a client. With third-party certificates, that's impossible. However, a station that relays packets without being part of the encryption chain should work perfectly well.

The Ohiagi/Morii approach has other refinements, such as monitoring the network for periods of low usage and then switching from the pure repeater mode into a key recover mode in which the malicious party attempts to recover the encrypted checksum, blocking communication between the station and access point during this time, which then eliminates the incremental IV problem because the intermediate IVs aren't sent, and thus the QoS queues aren't needed.

They reduce the time necessary for a crack by making additional assumptions about ARP packets that let them solve for the checksum about 37 percent of the time, and check whether they've recovered the key. This reduces the time for what they call a communication blackout--no AP to client transmissions--to about a minute. If they fail to recover the checksum key, they don't send a falsified packet, and thus don't start triggering the checksum key reset.

By reducing the time necessary for an attack to succeed on average and eliminating the requirement of QoS being enabled, the researchers have made this process less academic and far more real. But it's important to remember that:

  • This is an exploit just for TKIP, and doesn't have applications for AES-CCMP.
  • This is not TKIP key recover, but recovery for the MIC checksum used for packet integrity.
  • So far, because of MIC key reset algorithms, this is still applicable only to short packets with mostly known data, such as ARP messages.

ARP forgery could allow an attacker to convince a client to use it as a gateway and perform DNS resolution through addresses that the attacker provides. Poisoning DNS would allow redirection, phishing, and some forms of interception.

However, the primary issue with this attack is that it requires close proximity and the right circumstances to intercept and relay communications. That makes it hard to generalize, and hard to apply in more than a limited fashion. We'll see how this continued hammering on TKIP continues, and whether further weaknesses enable an even simpler or faster approach.

No TrackBacks

TrackBack URL:


It irritates me how the nomenclature is often confused when it is so simple.

WPA is often equated with TKIP and WPA2 with CCMP, but this is wrong...
A wireless access point advertising WPA may offer TKIP or CCMP or both at the same time. The same is true with WPA2.

TKIP is RC4 based.

CCMP is AES based.

How is this hard to understand or explain? And more importantly, and worse!, why do manufacturers get it wrong?

I suspect that the Wi-Fi Alliance has been so effective at advertising the WPA/WPA2 labels as shorthand for security, that it's easy to become lazy with them.

WPA devices could include AES-CCMP, but the alliance only certified WPA2 devices if they contained both TKIP and AES-CCMP.

Of course you're absolutely right about certification!

Quite a few manufacturers, however, implemented CCMP support in advance of IEEE 802.11i-2004 being finalised, so I feel the distinction needs to be made. (This isn't one of those hypothetical academic-only issues.)

Do any of these attacks and vulnerabilities apply if you're using the enterprise mode of WPA or WPA2?

If you're using a TKIP key with WPA Enterprise or WPA2 Enterprise, then yes. This is a generic key-recovery attack on the TKIP method's packet integrity protocol, MIC. Because the key is set per packet, the recovery has nothing to do with the uniqueness of keys assigned to stations through a secured EAP process.

With the Tews/Beck method, setting a rekey interval to 300 seconds or fewer defeated the attack. The new method requires physical insertion, which is difficult in an enterprise environment that has a dense access point deployment. Any such network that has intrusion detection enabled would recognize the rogue access point. The timing and such required to make the Japanese academics' approach work is tricky.

Moving to AES-CCMP solves the problem, and I'm sure enterprises that support TKIP do so only because of legacy equipment issues.

Leave a comment