Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Wireless Networking Hardware

The Real Story On WPA's Flaw 67

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:
  • Re:vocabulary (Score:3, Informative)

    by mpeskett ( 1221084 ) on Friday November 07, 2008 @02:18PM (#25677955)
    Get Firefox Portable and you can add whatever add-ons you want to it.
  • Re:A crack (Score:4, Informative)

    by ledow ( 319597 ) on Friday November 07, 2008 @02:31PM (#25678233) Homepage

    Someone didn't RTFA.

    WPA isn't broken. TKIP (and *ONLY* TKIP) has a flaw which means it is susceptible for small packets, assuming that people are able to send unlimited amounts of data at the router and have it respond to that data - this might even be fixable in firmware by implementing the same time limits as WPA2 uses for such things.

    TKIP is an *option* in the standard, the alternative being the still-secure AES. So one (little-used) protocol out of two (or more) possible protocols in an ageing standard that has been superceded in all practically available hardware by WPA2, has a flaw in that an attacker who can send unlimited data and recieved unlimited responses to that data may, after lots of analysis be able to craft a *small* packet (which is admittedly no worse or better than being able to generate any packet). It's a crack, yes, but you can:

    Use AES instead of TKIP
    Wait for the manufacturers to put out an updated firmware
    Use WPA2 (which is probably the default already)

    It isn't the end of the world, but the horsemen of the Apocalypse might well be getting their horses some nice new shoes ready...

  • Re:A crack (Score:3, Informative)

    by TechyImmigrant ( 175943 ) * on Friday November 07, 2008 @02:33PM (#25678263) Homepage Journal

    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.

  • Re:A crack (Score:3, Informative)

    by RiotingPacifist ( 1228016 ) on Saturday November 08, 2008 @01:47PM (#25688415)

    that will teach me to get board of TFA (hey too much maths and its the weekend),
    stopping qos isn't enough, as the attacker can simply replace you in the network for the duration of the attack

    Even if the network does not support the IEEE 802.11e QoS features, the attack still
    seems to be possible. Here, the attacker needs to prevent the client from receiving the
    data packet he chooses for the chopchop attack, and must disconnect the client from
    the access point for the time of the attack, so that the TSC counter is not increased
    by the packet or following packets. After the attacker has successfully executed the
    chopchop attack, he can send a single data packet to the client. However, we did not
    implement this attack mode.

    the countermeasure the attackers suggest is rekeying every 2 minutes

    5.1 Countermeasures
    To prevent this attack, we suggest using a very short rekeying time, for example 120
    seconds or less. In 120 seconds, the attacker can only decrypt parts of the ICV value
    at the end of a packet. Alternatively disabling the sending of MIC failure report
    frame frames on the clients would also prevent the attack. The best solution would
    be disabling TKIP and using a CCMP only network.

The last person that quit or was fired will be held responsible for everything that goes wrong -- until the next person quits or is fired.

Working...