Forgot your password?
typodupeerror
Security Wireless Networking Hardware

The Real Story On WPA's Flaw 67

Posted by kdawson
from the calm-down dept.
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."
This discussion has been archived. No new comments can be posted.

The Real Story On WPA's Flaw

Comments Filter:
  • vocabulary (Score:3, Funny)

    by Anonymous Coward on Friday November 07, 2008 @09:19AM (#25674445)
    Use really long words.
  • by flajann (658201) <flajann AT linuxbloke DOT com> on Friday November 07, 2008 @09:20AM (#25674453) Homepage Journal
    Well, really, these stories should be checked out more throughly before publication!!!!
    • by Thanshin (1188877)

      > Well, really, these stories should be checked out more throughly before publication!!!!

      Or:

      "Well, these stories should probably be checked moro thoroughly before publication. But I'm no expert on the matter of story publication so they might have been checked as thoroughly as necessary, under the circumstances.
      Furthermore, this is just my humble opinion. I'm no expert on checking news either, so this entire paragraph may be unprecise.
      Also, I may or may not be a government agent paid to spread misinforma

    • by MasterOfMagic (151058) on Friday November 07, 2008 @09:39AM (#25674625) Journal

      This is exactly why the trend of waiting to release news at security conventions is a bad idea. By announcing that there's an exploit but withholding the details, real harm can be done. I understand that security researcher is not a glamorous position (being one myself), and I understand the desire to keep certain details of an exploit under wraps until a vendor fixes them. Ultimately, if you want to wait until the vendor fixes the problem, you do not publish. It's that simple.

      Otherwise you end up with, "omg the sky is falling!11!!!11!1! TKIP sux lol may just use open wifi".

      • Re: (Score:3, Insightful)

        by flajann (658201)

        This is exactly why the trend of waiting to release news at security conventions is a bad idea. By announcing that there's an exploit but withholding the details, real harm can be done. I understand that security researcher is not a glamorous position (being one myself), and I understand the desire to keep certain details of an exploit under wraps until a vendor fixes them. Ultimately, if you want to wait until the vendor fixes the problem, you do not publish. It's that simple.

        Otherwise you end up with, "omg the sky is falling!11!!!11!1! TKIP sux lol may just use open wifi".

        As a user of the technology, and as a technologist who is geared to support the firms I work for, I want the news of a potential exploit that may affect me or my organizations to be presented as soon as possible, so I can take measures before the vendor releases a fix.

        Get the news out on a real exploit out immediately, but make sure it's real.

        • by hal9000(jr) (316943) on Friday November 07, 2008 @10:05AM (#25674849)
          I want the news of a potential exploit that may affect me or my organizations to be presented as soon as possible, so I can take measures before the vendor releases a fix.

          In many cases, knowing about an exploitable vulnerability doesn't mean you can do anything about it. That is the very heart of the full disclosure/responsible disclosure debate.
          • by flajann (658201) <flajann AT linuxbloke DOT com> on Friday November 07, 2008 @10:42AM (#25675243) Homepage Journal

            I want the news of a potential exploit that may affect me or my organizations to be presented as soon as possible, so I can take measures before the vendor releases a fix. In many cases, knowing about an exploitable vulnerability doesn't mean you can do anything about it. That is the very heart of the full disclosure/responsible disclosure debate.

            There's always something you can do about it -- even if it's a matter of policy vs. technology. Or sometimes there's creative solutions that can be put in place. For instance, if WPA encryption were found to have an actual exploit, you could add an additional encryption layer via VPN or even simply an SSH tunnel. I actually do the latter over the really insecure WEP connections.

          • by Cowmonaut (989226) on Friday November 07, 2008 @10:42AM (#25675245)

            An unknown attack vector is far worse than a known one. If you know where an attack is going to be coming from you have a far better chance of either A) preventing or B) reacting to an attack.

            Knowing is a LOT better than having no idea your system is vulnerable and it getting compromised. Particularly if your job is knowing all you can about security and securing your company's system...

          • Re: (Score:3, Interesting)

            by jonaskoelker (922170)

            full disclosure/responsible disclosure

            Can we please not use loaded language to describe the two positions?

            If limited disclosure is, according to a reasoned interpretation of factual evidence, the only responsible thing to do, why is there still a debate? Are people that blinded by dogma?

            Isn't it irresponsible to keep people in the dark and let them continue using insecure technology? Especially when there for most people is a very simple, acceptable solution: plug in the wire if you want security, or don't if you don't.

            I can see the value of

          • Pull the power cord out of the wall.

        • I said that I understood the argument for keeping vulnerabilities under wraps until they are fixed by the vendor. I didn't say that I agreed with it.

          You are right, there are many ways you can mitigate vulnerabilities that aren't fixed yet - you can take vulnerable machines offline, you can disable the vulnerable service, you can switch to another piece of software without that vulnerability, or you can do nothing. Only the user of the software knows which course of action is right for them because they're

    • Well, even the Internet Storm Center (ISC [sans.org]) wrote about it [sans.org].

      Usually one could assume that the ISC would not write about it if it was not true as one of their handlers is Joshua Wright [willhackforsushi.com], my favourite wireless enthusiast. Not only do I dare saying that he is one of the world greatest wifi researchers but he also has close ties to many other wifi experts. I would be surprised if he does not know Martin Beck (the author of aircrack-ng) in person.

      BTW, Josh, if you happen to read this, I would love to here a comment

  • by ChrisCampbell47 (181542) on Friday November 07, 2008 @09:23AM (#25674471)

    OK, that settles it. Ars Technica for the win!

    They've been doing a great job on technical analysis for a long time now ...

    • by andrewd18 (989408)
      I agree - Ars is great. On the other hand, I wish they had more quantity to go with their quality.
    • by Anonymous Coward

      They have people 'reporting' for them that have no degrees in the computer sciences, nor even certifications in the art & sciences of computing, let alone years to decades of hands on experience in computers in the trenches actually doing the job. Jeremy Reimer being a prime example thereof in fact. This makes them good? I know not. Anyone can re-report what has already been posted up from other sources after all. That does not take brains, nor is it indicative of quality original work either.

  • by RagManX (258563) <ragmanx@@@gamerdemos...com> on Friday November 07, 2008 @09:40AM (#25674627) Homepage Journal

    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.

    • I only know enough about networks to be dangerous but, experts correct me if I'm wrong, this has the potential to allow DNS query responses to be spoofed sending the victim to either a hostile website or through a hostile proxy? Also, I guess, by injecting fake ARP packets you could deny someone access to their own wireless network?

    • by jonaskoelker (922170) <jonaskoelker@ g n u .org> on Friday November 07, 2008 @10:58AM (#25675441) Homepage

      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.

  • by petard (117521) on Friday November 07, 2008 @10:06AM (#25674853) Homepage

    Attacks only get better, not worse. The right thing to do, IMO, is treat this as a warning. We need to stop trying to concoct schemes that are specific to wifi and just treat wireless media as untrusted. Harden the clients. Don't let them act like they're on a trusted local network until they're on your VPN. Besides getting more thoroughly vetted crypto, this leaves your road warriors in a much better position when they sign on in coffee houses, airports and hotels.

    • Re: (Score:3, Insightful)

      by sumdumass (711423)

      Finally, some common sense I can agree with.

    • by Hatta (162192)

      Why is an encrypted VPN fundamentally more secure than an encrypted wireless network? If they can crack one, can't they crack the other?

      • by petard (117521)

        I don't know that I'd say the difference is exactly fundamental. Sure, if you're talking about weaknesses a cipher, a general attack on might apply to any protocol that uses that particular algorithm. It's not just a cipher algorithm, though; getting secure key exchange right is a hard problem. You want the protocol you've selected for doing so to have been vetted by as many people for as long a time as possible. VPNs have been around for a great deal longer than these new wireless schemes, and more people

        • by jroysdon (201893)

          Or use OpenSSH to a LAN host with the -D option ( -D 8080 ) and point your proxy to localhost:8080 for SOCKS.

    • We need to stop trying to concoct schemes that are specific to wifi and just treat all media as untrusted.

      There, fixed that for you. What makes you think wired networking is secure?

      • by petard (117521)

        We need to stop trying to concoct schemes that are specific to wifi and just treat all media as untrusted.

        There, fixed that for you. What makes you think wired networking is secure?

        Men with guns, usually ;-). But I agree with your point, and don't generally consider the condition of being wired sufficient access control.

  • A crack (Score:5, Insightful)

    by ledow (319597) on Friday November 07, 2008 @10:11AM (#25674905) Homepage

    Yes, it's only a crack, not a collapse. But a crack into which can be inserted the crowbar of, in this case, ARP or DNS spoofing. Enough to force quite a large hole into a wireless network which relies on TKIP. AES is safe, yes, but if your router allows TKIP, this could be quite a large hole... enough to poke a user on the other side to start sending their private traffic across the Internet, other wireless networks, etc. to a third-party IP.

    And it won't be long before that crack becomes a hole big enough to slap the user through. It's not "the sky is falling" but it's a wake up call to people who thought TKIP/WPA was "safe enough" to instead make sure they are using AES with strong keys. Personally, even the school wireless routers that I manage have WPA2, AES with PSK's in the range of 512bytes each. Doing that from the first has bought me a lot of time in which to be secure. However, if I had started slightly earlier with WEP equipment, moved onto WPA as a compatability measure, etc. I might now be in the position where I would need to move again.

    It's right to make a fuss of this. It's wrong to suggest the WPA (or, by unsaid extension) WPA2 are "broken". Even if they were, we have no viable alternative just yet, anyway, so you're stuffed. :-)

    • Re:A crack (Score:5, Insightful)

      by MadMidnightBomber (894759) on Friday November 07, 2008 @10:26AM (#25675057)

      It's right to make a fuss of this. It's wrong to suggest the WPA (or, by unsaid extension) WPA2 are "broken". Even if they were, we have no viable alternative just yet, anyway, so you're stuffed. :-)

      Er, they have found a weakness in TKIP in WPA1 which is not present when using WPA2/AES. It covers all this in the Ars Technica article.

      • Re: (Score:3, Informative)

        In the 802.11 spec, WPA (a marketing term) is called a TSN. CCMP (WPA2) is called an RSN.

        T stands for Transitional.
        R stands for Robust.

        TKIP was known to be at risk of cryptographic attack at the time of its creation and was created for use on older hardware. Hence the name. We were supposed to transition to newer hardware which could implement an RSN.

        If we had followed the spec, we would have transitioned to AES/CCMP/WPA2 and future attacks on TKIP would be moot.

    • And it won't be long before that crack becomes a hole big enough to slap the user through.

      Heh.

      Personally, even the school wireless routers that I manage have WPA2, AES with PSK's in the range of 512bytes each.

      Seriously? You use a 512 character password? :)

      Assuming you meant that you use the full 64 hex characters (512 bits), did you realize that the PSK is hashed down to 256 bits anyway?

      • by jroysdon (201893)

        I use the max 63 character passphrase length. My key actually has in it something such as "NO-UNAUTHORIZED-USE-PRIVATE-SYSTEM".

  • by Karpe (1147) on Friday November 07, 2008 @11:42AM (#25676077) Homepage

    Still using WEP here. ;)

  • I'm always amazed at how much emphasis is placed on it. 5 years ago you saw few encrypted AP's and now, every cafe you visit encrypts (usually with the password printed out at the counter) their hotspot that is intended for the public anyway. Far more valuable for Grandpa than WPA would be if he developed good habits when using the Internet..

    I mean were talking physical proximity VS. the entire Internet!

  • by RedLeg (22564) on Friday November 07, 2008 @06:10PM (#25682065) Journal

    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....

Real programs don't eat cache.

Working...