Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security

WEP Gets A Bit Stronger 84

Posted by timothy from the still-not-for-the-nuclear-codes-please dept.
gmr2048 writes: "CNN is reporting that RSA has helped develop "Fast Packet Keying" to strengthen WEP security. More info can be found at the RSA page. Damn, and I'm still working on my Pringles can antenna."
This discussion has been archived. No new comments can be posted.

WEP Gets A Bit Stronger More

WEP Gets A Bit Stronger

Comments Filter:

  • RC4 (Score:3, Interesting)

    by Henry V .009 ( 518000 ) on Monday December 17, 2001 @04:45PM (#2716388) Journal
    They still use the RC4 algorithm, but now they claim to be implementing it right. Might actually keep the bad folk out if they can get the patches out to everybody.

    • Re:RC4 (Score:1, Interesting)

      by Anonymous Coward
      RC4 is cryptographically broken. it doesnt matter how good your implementation is -- its still a broken algorithm.

      • Re:RC4 (Score:2, Informative)

        by bob_jenkins ( 144606 )
        RC4 is broken? Oh really?

        I know the first 40 bytes have noticable correlations to the key. That's avoided by skipping the first 256 bytes. I know that if you see 2^^31 bytes of an RC4 stream you can distinguish it from random noise. That's not an interesting flaw at all, unless you're generating 2gig of data and you don't want anyone to know which encryption protocol you're using. Did you mean something more by saying "RC4 is broken"?

  • odd comment in similar article (Score:3, Redundant)

    by jeffy124 ( 453342 ) on Monday December 17, 2001 @04:46PM (#2716392) Homepage Journal
    literally just finished reading the cnet version [cnet.com] of this story, which included a statement like the following:

    "... does not address any new holes that might crop up"

    can I be the first to tell cnet "DUH!"

  • OT: pringle cans (Score:3, Interesting)

    by kwj8fty1 ( 225360 ) on Monday December 17, 2001 @04:48PM (#2716407) Homepage
    Speaking of pringles cans, we just built a ton of them at the last seattlewireless meeting. We're seeing a 10 to 13db gain from a $5-10 antenna.

    You can see pictures here:

    http://www.seattlewireless.net/index.cgi/DecemberM eetingPictures2001 [seattlewireless.net]

    • Im still working on my pringles can also. Im trying to setup a free wireless zone in Boulder, CO. Anyone have a pipe cutter I can borrow ;)
    • Alas, the local Quickie-Mart has already suffered from the slashdot effect - not a can of Pringles to be found :)
    • Okay, can someone PLEASE tell me how to hook up the antenna wire to the Orinoco Silver cards? I had always heard that Orinoco Gold cards came with an antenna plug, but my Orinoco Silver cards have nothing. If there's a way and a reason to pop off the little circle in the center of the outer edge, please enlighten me.

      These articles all say, "then just connect the antenna wire to your card." HOW? Thanks! :)
      • That little plastic circle is the cover for the plug. Pop it off with your fingernail, it comes off pretty easily.

        Then you can plug the antenna in.

  • Practical mathematics (Score:3, Interesting)

    by s20451 ( 410424 ) on Monday December 17, 2001 @04:48PM (#2716408) Journal

    From http://www.rsasecurity.com/rsalabs/index.html [rsasecurity.com]:

    Why is WEP Broken?
    The weakness in WEP stems back to a key derivation problem in the standard. ... While the WEP standard had specified using different keys for different data packets, the key derivation function (how to derive a key from a common starting point) was flawed.

    To all you undergrads doing math exams this week: yes, you really do have to know how to do this in the real world!

  • This is great news! (Score:2, Interesting)

    by IIOIOOIOO ( 517375 )
    Now they just need to improve things to the point that they can boldly advertise wireless security to the consumer public without having fear of getting burned. You've perhaps wondered why we've never heard any w-commerce commercials touting the security of wireless banking transactions? That's because they aren't, at least not yet. Heck, they still have trouble with the plain-ol' landlocked net.

  • Damn... (Score:5, Funny)

    by 4mn0t1337 ( 446316 ) on Monday December 17, 2001 @04:52PM (#2716429)
    This means I have to go back to just reading my own mail for the time being?

    Just when my neighbor's online affair was getting interesting. ;)

  • Why do packet-level encryption ? (Score:5, Interesting)

    by Rosco P. Coltrane ( 209368 ) on Monday December 17, 2001 @04:55PM (#2716442)
    Seems to me that the most secure way to do wireless networking is to set up encrypted tunnels :

    No bad guy will ever be able to use the network anyway.

    You have the choice of encryption policy you want to use and you're in control on how secure you want the network to be.

    The overhead of encrypting the packet headers is avoided (granted, the card is supposed to do that transparently, but still I have seen significant slowdowns in lag and throughput when playing with WEP).

    The only drawbacks I can think of with doing your own protocol-level encryption are :

    Bad guys can still see your bastion host or VPN gateway in clear and have a go at it (DoS or otherwise), and script kiddies might want to have a try because they think it's in clear, while when they see WEP in place they might not even try.

    You have to set up a VPN and the infrastructure that goes with it (duh) while you don't have to with WEP.

    It's a little harder for Windows users to use your service, if you use PPTP, or it's impossible altogether if you use something Windows doesn't understand, or it's costly because you have to buy third-party Windows VPN software (I don't deal with Windows users, thank God, so problem solved for me).

    • I see two main reasons why packet-level encryption is worthwhile (assuming it isn't totally broken, of course):

      • Having encryption in the network hardware means that it is more likely to be used and to become ubiquitous. Hardware people are MUCH better at interoperably supporting standards than software people (maybe because hardware people write tighter standards).
      • You can't (or won't) encrypt EVERY protocol. DNS, DHCP, ICMP? All of these aren't worth adding application-layer encryption, but do provide valuable data to an attacker.

      Personally, I'm happy to have working packet-level encryption because that adds one more layer. SSH over IPSec over WEP, anyone?

      • ou can't (or won't) encrypt EVERY protocol. DNS, DHCP, ICMP? All of these aren't worth adding application-layer encryption, but do provide valuable data to an attacker.

        IPsec for IPv6 (and I assume IPv4) is pretty flexible and can be used on UDP (DNS, DHCP), and I *think* ICMP (it would be useful for the "had to fragment, but couldn't" packets as well as redirects, but since it isn't required there it won't really help).

        That said there is very little wrong with packet level encryption, about the only two "wrong" things are fooling people into thinking they don't need session level encryption, and, um, fooling people into thinking they don't need session level encryption :-)

        • IPsec for IPv6 (and I assume IPv4) is pretty flexible and can be used on UDP (DNS, DHCP), and I *think* ICMP

          Well, yes and no. DNS, for example, works fine if you have LAN clients and your single LAN DNS server, but you won't be likely to set up IPSec SAs with many external servers.

          DHCP, no - how can you set up an SA when one of the endpoints has no IP address? (Not that DHCP is all that much worth protecting, but...)

          ICMP, same as DNS - how many remote systems are you going to have, or be able to negotiate, SAs with?

          Now, once IPv6 comes in, and IPSec becomes truly opportunistic, maybe - but in IPv4, it isn't really useful for "casual" encryption.

          • You set up an IPSEC tunnel to a trusted net, i.e.:

            [laptop] . . . . [Wireless AP]---[Linux+FreeS/WAN]--(the world)
            \-------tunnel-----------------/


            I'm writing a paper on this at the moment, it'll go up somewhere on my web page, some time.
    • This is a good thing! Know why? Because everyone who brought Orinico/Lucent OEM'ed 802.11b cards (such as my Dell TrueMobile one) will get a new firmware update! For some reason Dell is still back on the old 6.x firmware while lucent is up to 7.x. Unfortunately AFAIK the firmware installer hasn't been hacked yet to make it possible to flash Lucent/Orinico OEM'ed (cards without their labels) devices... Someone got a hack?

      In the meantime I'm waiting for Lucent to update the firmware and then Dell to repackage it for me!
    • * It's a little harder for Windows users to use your service, if you use PPTP

      Care to explain this comment? I'm actually using PPTP with the server running on a Linux box and a Win2k client system right now to "secure" my WLAN segment. The only other stuff allowed from that segment is IPSec to certain known systems and SSH directly to my linux box (with RSA keys, of course). No problems here.

      -- PhoneBoy

    • Seems to me that the most secure way to do wireless networking is to set up encrypted tunnels :

      Except that that's not enough.

      The problem is that all of the hosts on the wireless LAN have the keys used to set up the tunnels through the firewall, and their butts are hanging in the breeze. Sure, adding VPN-type tunnels adds an additional level of complexity to an attacker, and that's a good thing, but until you can ensure the security of all of the wirelessly-connected hosts, it's only an additional work factor *not* strong security.

      Each wireless host needs its own firewall that will reject any connections not coming through the secure tunnel. Whether or not running firewall software on the host being protected is good enough depends on your level of paranoia, I suppose.

    • There's another reason why packet-level is nice; tunneling doesn't survive putting your laptop to sleep for any length of time. We use an SSH-based VPN for work, and it works swell, but it means I tend to lug my laptop around the apartment with the clamshell open :(.

  • What about the other 12 'key contributors'? (Score:5, Informative)

    by Zeinfeld ( 263942 ) on Monday December 17, 2001 @05:13PM (#2716529) Homepage
    From the RSA press release:

    Fast Packet Keying," a new technology based on the RC4® algorithm, is designed to help organizations securely fix the WEP encryption standard. This new WEP solution, developed by RSA Security, Hifn and other members of the 802.11 committee, is designed to generate a unique RC4 key for each data packet sent over the wireless LAN.

    The fix to WEP was developed by a working group in which RSA was far from being the sole contributor. It is a bit off for RSA to try to claim the glory for the fix when a significant part of the WEP problem is due to a weakness in the keying scheme of RC4.

    The presentation lists as 'key contributors' Jessie Walker of Intel, Bob Beach and Clint Chaplin from Symbol, Ron Brockman of Intersil Nancy Cam-Winget of Atheros Greg Chesson, Atheros Niels Ferguson, MacFergus BV Marty Lefkowitz, TI Bob O'Hara, Blackstorm Networks Dorothy Stanley, Agere Doug Smith, Cisco Albert Young, 3COM

    So when RSA wants to get votes it has a dozen 'key contributors'. But when they want to take the credit there are two.

    The original algorithm was botched, in part it is claimed (by an informed source) because the original IEEE working group left the crypto to an NSA advisor. Failing to understand the specific weakness of using a stream cipher in general and the specific weaknesses of the RC4 key scheme are the major reasons for the failure of the WEP design.

    One could rightly blame the original working group for failing to read up on the litterature and avoid the known flaws of RC4, only RC4 was until recently a proprietary and secret algorithm of RSA. The key scheme flaws were only publicised after RC4 was reverse engineered without RSA approval, and resulted in considerable protest by RSA.

    This type of publicity grab is not good for open standards development. It encourages people to release their proposals to the press rather than to the working group.

  • More Secure, but not? (Score:3, Interesting)

    by SloppyElvis ( 450156 ) on Monday December 17, 2001 @05:31PM (#2716610)
    In reading the posted article and in reviewing some literature concerning WEP security here: CS at Berkeley [berkeley.edu] I was wondering if anyone out there had insight on the nature of the modifications that have been made.

    Please excuse my naivety in the field, but from the Berkeley article I gather that not only is the similarity of the packet keys a weakness of WEP (as RSA indicates), but also the use of a 24-bit space for the initialization vectors used to generate the RC4 packet keys.

    Now, is the 24-bit space limitation what RSA means by, "similarity of the packet keys", or are they referring to the fact that most boards start the IV at 0 and simply increment for each packet (the end result being numerous IV collisions)?

    The reason I wonder is because theoretically, at least, one could construct a table of all IV + key stream combinations in a decryption table (~15Gb according to Berkeley) and thereby gain himself the key to the city, so to speak. So, while limiting the number of IV collisions would certainly make decryption more difficult and certainly more time consuming, it wouldn't make WEP entirely secure. In the event that someone be so determined to monitor WLAN activity for enough time to construct such a table, could users of WEP be exposed?

    • Re:More Secure, but not? (Score:5, Informative)

      by Zeinfeld ( 263942 ) on Monday December 17, 2001 @06:08PM (#2716846) Homepage
      Now, is the 24-bit space limitation what RSA means by, "similarity of the packet keys", or are they referring to the fact that most boards start the IV at 0 and simply increment for each packet (the end result being numerous IV collisions)?

      RC4 has a specific design flaw whereby the cipherstream for k has similarities to the cipher stream for k+1. These allow an attacker with cipher text for k and k+1 to recover the plaintext of the messages and the key.

      One fix is to throw away the first 256 bytes or so of the cipherstream. Another solution is to make the probability of a collision very small which is what the fast keying scheme is doing.

      The main constraint on the solution is that it has to be deployable on cards that have already been manufactured and those are not particularly powerful CPU wise.

      The Berkely attack is certainly a concern, 24 bit encryption is not acceptably secure. But that is not the weakness being exploited by AirSnort. There are a bunch of mixing functions defined in the presentation I have seen but there is insufficient info to know if it does indeed do the right thing.

      Again, I am somewhat anoyed when cryptographic protocols are puffed in the press prematurely. I am not a member of the 802.11b group, however I will be reviewing their work product when they announce it is ready. I am not aware that this is currently the case. I would like something more than a powerpoint presentation to evaluate the protocol by.

    • Sure, you could still use the IV collision attack in this new system, but they have tried to make it harder to do. First, in the original WEP, you would only have to track one IV space per shared key (so, basically, per one network.) In this proposal, each sender uses a different key, so you would have to track the IV space per sender (i.e., if sender A uses one IV, and sender B uses that same IV, no information is revealed, whereas in the old system it was.)

      Plus, in their new specification, they say that IVs cannot be reused. Since the IV space is per sender now, each sender can just keep track of what their most recently used IV was, and increment it with each packet. Of course, you still have to change the shared secret when you run out of IV space, which seems really unreasonable, especially since the IV space is now only 2^16, instead of the 2^24 (the new spec changed it to get rid of a portion of really bad IVs).

  • Do gurus care? (Score:2, Interesting)

    by snarf_snarf ( 201620 )
    Have yall seen or heard or read (i.e. Wired this month- sorry) Duwayne Hendrickson. This mad cat is a former ham radio geek who now sits on the FCC advisory board concerning wireless spectrum/FCC part 15 issues. And he is WLANning major Indian reservations and foreign countries; using every trick in his bag. My ignorance notwithstanding, does he care about WEP? Wasn't mentioned in the article.

    My contention is this: Keep WEP as messy as swiss cheese. Let everyone have it right on Main St! More access is good access. Individuals with savvy will guard their own cookie jars.

    Keep encryption development as open as it can be, rely on the 'market' to force the security issue. The NSA can probably break it anyway. That's why its released for consumers.

    snarf liono.
  • erm, it's supposed to be "strengthen WEP security" not "strengthen WEB security". man, i just misspelled a three letter word.
  • They've improved WEP?
    I've been wating for years for a better Windows Entertainment Pack! I hope they've improved tetris!
  • My question is: Will all of us current wireless users have to buy new cards and access points, or will a firmware update do the job?

  • It's pretty ridiculous (Score:4, Insightful)

    by evilviper ( 135110 ) on Monday December 17, 2001 @07:15PM (#2717181) Journal
    I really have to laugh when I hear about people trying to 'improve' WEP. My favorite is Cisco's method of changing the key about every 10 minutes.

    The solution is to get rid of WEP all together (before someone REALLY breaks it!) and switch to something which works right. IPSec, SSH, SSL, PPTP all come to mind as protocols which could solve this problem, and never have to be upgraded. Now WEP is a cat and mouse game. Companies will continue to iimprovie it, and individuals will continue to find better ways to crack it. Personally, I'll just pass on an access point all together and get a Unix box with IPSec working as the router. Easy as 1, 2,3 and a hell of a lot more secure than any WEP solutions out there.
    • IPSec, SSH, SSL, PPTP all come to mind as protocols which could solve this problem, and never have to be upgraded.

      so, i suppose you're still using SSLv2 and SSH1? no? why not? perhaps because of the security flaws found in each of them?

      • There is nothing wrong with the SSL or SSH protocols at all. The SSH1 flaw is attributed only to the SSH.com client. All of us OpenSSH users can laugh at the problems commercial users have had.
        • It's interesting that you refer to WEP as being a "cat and mouse" game but don't want to admit that SSH1 was largely the same thing, as summed up in http://www.openssh.com/goals.html

          just why do you think we have ssh1 (1.3) and ssh1 (1.5) and, for that matter, ssh2? regardless of implementation details (and for that matter, nobody's perfect [ciac.org]) the ssh1 protocol had problems.

          Re SSLv2: ciphersuite rollback attack is bad news. read the background section of http://www.counterpane.com/ssl.html

          point being, sure WEP may have flaws, but then again, flaws have also been discovered in those other great "never need to upgrade" protocols you mention.
          • From OpenSSH's site you yourself linked to.
            There used to be a few other algorithms like RC4, but their implementations

            had security problems

            Indeed, it was the particular implementation used that was the problem. Of course, you read that too so I'm sure you realize that...


            Even if you want to believe that OpenSSH v1 was flawed, you still can't say it was even remotely as bas as WEP. WEP even in it's most secure implementations is easier to crack than the most insecure OpenSSH distribution out there. And secondly, the insecurity with SecSH v1 is merely theoretical. WEP can be decrypted and made into a useable form simply by running a simple program, and wating for WEP to get cracked.

            • truly we are in agreement. WEP is broken. i always tunnel my wireless traffic through (Open)SSH, just as i do with my wireline traffic on untrusted networks. i just wanted to point out that even some of our most trustworthy protocols need "upgrading" from time to time.
  • WEP might be usable again - once the vendors get their arses in gear.

    I spent GBP30 extra on each 128bit WEP card over cheaper WEP cards. I was particulary annoyed to find out 10 weeks later that the encryption was worthless.

    If FreeSWAN wasn't such a pain in the arse to compile and configure I'd be using that (I stopped relying on kernel patches after getting my fingers burnt over the international crypto patch - Just downloaded 2.4.16? - latest crypto patch is 2.4.3. Oh and it corrupts your data if you use non-relative block numbers), however now I've had to give up using my cards - I live in a flat, I can use a long piece of cat5.

    What I'm waiting for, is for Intel to sort out the problem. I don't care if they don't interoperate with other Wifi cards, I just want a cryptographically secure implementation of IVs with RC4 damn you!
    • FreeS/WAN can now be compiled as a module, and is therefore more likely to be resiliant across kernel versions.

      Unfortunately there is little or no chance of getting any real encryption into the kernel, due to various laws etc.

      Yes, FreeS/WAN is a pain. Quite quite braindamaged/damaging in places. Maybe OpenBSD's IPSEC implementation is better; I'm waiting for a new machine to test it on.

  • Why do they insist on RC4? (Score:1, Insightful)

    by Anonymous Coward
    - RC4 has been prooven to be vulnerable to a known plaintext attack (any revealed part will reveal any other part encrypted with the same key and using this info will bake it possible to extract more info about the keystream)

    - RC4 have a subclass of weak keys. (Only for "even" keysizes like 32, 64, 128, not 40, 56)

    - The Random number generator in RC4 have a statistical weakness making it crappy to use; but this can be overcome by generating N number of bytes (i.e. key dependent if one should wish).

    Instead of trying to fill out the holes in this swiss cheese - Why not go with AES?

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Close