The Real Story On WPA's Flaw

Glenn Fleishman writes "The reports earlier today on WPA's TKIP key type being cracked were incorrect. I spoke at length with Erik Tews, the joint author of the paper that discloses a checksum weakness in TKIP that allows individual short packets to be decrypted without revealing the TKIP key. I wrote this up for Ars Technica with quite a bit of background on WEP and WPA. Tews's paper, co-written with Martin Beck, whom he credits as discovering and implementing a working crack (in aircrack-ng as a module), describes a way to use a backwards-compatible part of TKIP to exploit a weakness that remains from WEP. ARP packets and similarly short packets can be decoded. Longer packets are likely still safe, and TKIP hasn't been cracked. Don't believe the hype, but the exploit is still notable."

Comments

Big breaks start from small holes

[RagManX]

This is more interesting than I suspect most people will think it is. With any security system, researchers build on weaknesses found piece by piece. It might not seem a big deal that short packets can be decoded nor that a few additional packets can be injected into a wifi network data stream, but these small cracks almost always lead to methods of getting more information from the security system.

I've been watching WPA security studies for a while, and this seems the most significant flaw yet found. It will be very interesting to see if and how this exploit is grown into something more generally usable.

Re:Big breaks start from small holes

[jonaskoelker]

With any security system, researchers build on weaknesses found piece by piece.

If we're talking about crypto, that's not always true.

RSA is claimed to be secure, when used in the right way, against some number of scenarios (wikipoogle for IND-CCA2). For instance, if you give me two plaintexts and I encrypt one, you can't tell which one I encrypted (when RSA is used with OAEP). In particular, you can't learn any single bit of the plaintext behind the encryption. Add some more scenarios; then we have a "piece-by-piece" claim about the security of RSA (possibly even proofs that breaks can give us a factoring).

On the other hand, when we construct protocols that combine several pieces, we often do it in the Universal Composability model. That is, we describe in a black-box fashion how an ideal functionality should behave. Then we show that if we have implementations of each black box, our way of combining them yields something that acts like black-box design we were trying to implement. Thus: we have shown our construction secure, without looking at each attack one by one.

An example: "Secure Transfer"; boiled down, a user inputs a message. Later, the network delivers the message to the other user. The adversary, who can monitor the network, learns the length of the message.

Another example: Authenticated Transfer. The same, except the adversary learns the message.

You can build ST from AT: have the receiver first send a public key, then have the sender send the message encrypted with the public key. If we assume our cryptosystem to be secure, one can show that this implements ST.

I've omitted the details you need to show it in a formal sense, but it rings true, right? That's what cryptosystems do: obscure the message.

Not a flaw in i, but in e, and not much of one....

[RedLeg]

Well, the ARS writeup is much better that what dribbled out yesterday, and I actually understand what is going on here. I was one of the authors of IEEE 802.11i. The protection mechanism we built in to counter these type of attacks (TKIP Countermeasures triggered by two or more MIC failures within 60 seconds) is STILL present and functioning as designed. These guys figured out that the MIC counter is incremented separately for each QoS queue, so instead of one guess at the key per minute, you get LOTS more. The "flaw" then is in the interaction of 802.11i (the security enhancements) and 802.11e (QoS), not in 802.11i itself.

Remember that the key that is cracked is a per-frame temporal key, not the pairwise master key, and the scope of what you can do with this is severly limited. I am personally not at all convinced that that this attack or ones which build on it will improve. This attack is an active one, and it is detectable either by the AP under attack or by a wireless IDS. I can also predict that a simple change in the way MIC failures are tracked and rekeying the network when this attack is detected would defeat it, just as the original Michael MIC was designed to do.

Finally, remember that TKIP was intended to be a retrofit to band-aid the problem until the full AES based standard was finished. We published what became known as WPA more than 6 years ago, and didn't mandate the replacement of hardware to implement it.

Not to bad, in my humble opinion....