"Fast Packet Keying" Improvements to WEP 88
Weedstock writes: "BBC Tech News has an article about the latest development in wireless networking security. It seems that RSA Security has improved the encryption system used by the protocol. Will this new update finally make wireless networking secure? You can also find a list of papers about wireless security issues here." RSA has a press release about their changes to WEP being accepted by the 802.11 committee.
Fast packet keying again ? (Score:4, Redundant)
Don't embed engryption.. (Score:3, Interesting)
This way you can be sure everything is encrypted consistently from the host machine all the way to the client, even when your packets pass through 'unknown' equipment.
The other advantage of this approach is that you can get all your hardware cheap on ebay because everyone else is abandoning them as 'not secure enough'
Re:Don't embed engryption.. (Score:1)
The last one I'm aware of was about 6mo ago, fairly difficult to exploit, and we patched for it the same day.
Reading back it appears the bigger issue is people driving by and stealing bandwidth, which just using SSH doesn't really solve. Put the access point on it's own network, set up so the only place you can connect from the unencrypted network is to your VPN server, that way both issues are addressed. Oh, except the windows implementation of PPTP is rather flawed too (you didn't provide a reference, so neither will I, but at least mine exists
The real problem is that people want to just plug the card in and have everything configure itself automagically. WEP gets closer to providing this while still being marginally secure. VPN's and stuff take some setting up.
Re: (Score:2)
Re:Don't embed engryption.. (Score:3, Interesting)
Re:Don't embed engryption.. (Score:1)
I know... (Score:3, Insightful)
Yes, I know, perhaps it's stupid of me, and I'm planning to set up some kind of security. But for many users out there - the people who wanna be able to check their email from the kitchen - weak security is just not a problem. Just so long as the spooks don't start wanting wireless access... :D
Re:I know... (Score:2, Insightful)
Dead end court (Score:2)
yawn (Score:3, Redundant)
Re:yawn (Score:1)
Been said many times, but.. (Score:2, Informative)
It is probably better to use your own encryption tools anyway, since built-in schemes will likely be obsoleted eventually.
IPSec *yawn* (Score:1, Informative)
To hell with WEP. (Score:1)
Old 486 laptop with broken screen + OpenBSD + some 802.11 card = "no kids breaking into your network via wireless" for under $100.
Re:To hell with WEP. (Score:2)
What I want to know is... (Score:2)
Re:What I want to know is... (Score:3, Interesting)
I'd like to know that too, but for my WaveLan cards. And if it can't be upgraded, I want a refund on the $20 extra per card I paid to get "128-bit" (yeah, as if) encryption.
2.4 GHz to 900 MHz Transverter for Wireless LAN (Score:1, Interesting)
here's the link [qsl.net]
Re:2.4 GHz to 900 MHz Transverter for Wireless LAN (Score:1)
I'm not saying it will not work, but if you are going to step on someone else's frequencies you may as well convert to other frequencies.
old news (Score:2, Redundant)
not that secure (Score:5, Informative)
1. the key-mixing technique was diluted in strength so that the overhead of firmware upgrades would be acceptable. The "improved" technique has been changed a few times as weaknesses were discovered. It is quite possible that the new WEP can be cracked as thoroughly as the original.
2. the key-mixing technique requires that a new temporal key be set up every 16K packets - a sign of weakness. The 802.1X procedures for setting up the temporal keys have not been finalized and contain weaknesses.
3. it is debateable whether the 802.1X temporal key procedures, once finalized, will be practical at higher PHY rates of 802.11g or 802.11a since the rate of temporal key updates must be greater than the lower rates needed for 11b.
It is more foolproof to rely on IPSEC as other posters observe. The argument against IPSEC and for wireless link crypto is based on the perceived overhead of forcing everything on an internal enterprise network to run IPSEC so that the wireless subnet can be secure. For SOHO setups this should not be an issue.
Re:not that secure (Score:5, Interesting)
Using IPSEC on the wireless network only requires the wireless stations and a gateway to run IPSEC. The IPSEC gateway acts like a normal router to the rest of the network. You can even do transparent gatewaying based on proxy-arp.
Our laptops use 802.11b cards without WEP and 2 Linux machines with Prism2 based cards operating in HostAP mode. One AP handles the encryption and allows handoff to the other via proxy-arp depending on which AP has the link to a particular station on their own wired subnet. The primary AP acts as a router to the rest of the unencrypted wired lan. All the stations on the wireless lan are configured to drop all but the IPSEC traffic. This not only protects against spoofing and hijacking on the wireless lan but also gives strong encryption to the traffic.
After the pleasant experience I had with Freeswan on the wireless network I'm considering bringing IPSEC to the rest of the wired network.
Re:not that secure (Score:3, Insightful)
All the stations on the wireless lan are configured to drop all but the IPSEC traffic.
Bravo! This is the absolutely crucial element that most people miss. If any of the wirelessly-connected stations accept any non-authenticated traffic, they're vulnerable to being compromised, which, in turn, compromises the entire network, wired and wireless.
Re:not that secure (Score:3, Insightful)
The "improved" technique has been changed a few times as weaknesses were discovered. It is quite possible that the new WEP can be cracked as thoroughly as the original.
Remember, it's a *good* thing that the new technique has been cracked a few times. Had serious (or even rudimentary) cryptanalysis been applied to the original protocol, we'd never have gotten into this mess. RSA Data knows how to create good cryptography, and wireless networking is important enough that many other people will take a hard look at this new protocol before it's implemented.
the key-mixing technique requires that a new temporal key be set up every 16K packets - a sign of weakness
Very possibly. It certainly seems not to leave a whole lot of margin for improvement in the face of any new attacks. However, I don't know how much conservatism is built into the 16K number.
It is more foolproof to rely on IPSEC as other posters observe.
Absolutely. As long as all hosts have firewalls that drop all non-IPSEC traffic. However, it's worth remembering that the original intent of WEP was to build something that approximated the security of a wired network. Although the first attempt failed utterly, if the upgraded protocol can just make all passive attacks infeasible and make active attacks fairly difficult then the original intent will have been achieved.
Had it been designed by knowledgeable cryptographers, WEP would have been as strong as IPSEC, which would have been great. As things are now, the patched system won't ever be as good as WEP could have been, but it probably will be as strong as it needs to.
Re:not that secure (Score:2)
IPsec instead of WEP (Score:1)
Of course, aside from the completely bone headed reuse of RC4 keystream, the actual Hard Problem is key distribution. Why the 802.11 guys want to revinvent this is a complete mystery to me. IPsec has IKE -- which is about to get a face lift in the form of either JFK, IKEv2 or most likley a combination of these proposals. IPsec also has KINK (Kerberized IPsec) which is about to go to last call. Eventually, I expect that AAA (DIAMETER) based IPsec keying will be formalized since they're already toeing that line in many areas.
Yet, the 802.11 folks still want to roll their own. Ick. How this will all play out with fast mobility (ie so you can run voip instead of circuit switched voice on CDMA/802.11 dual mode phones that will eventually appear) will be very interesting. My guess is that it won't until somebody takes an integrated look at security, quality of service, admission control, etc. I have some hope that the IETF protocols will eventually get this right, but the best I can hope for the L2 folks is that we can turn all of this krufty L2 wheel-reinvention off.
will it make it secure? (Score:3, Interesting)
They need to make this a part of the driver and make the driver force a firmware update and enable it by default if securing wireless is important. Otherwise this is only an expected feature of the new stuff that I'll buy in about 2-3 years.
Re:will it make it secure? (Score:1)
Credit where credit is due? (Score:3, Interesting)
I know RSA's the big name here, but I wonder whether they merely contributed the name, not the research.
-Billy
Re:Credit where credit is due? (Score:1, Informative)
See http://www.rsasecurity.com/rsalabs/technotes/wep-
Not the whole problem (Score:2, Interesting)
darn (Score:3, Funny)
Possible solution? (Score:2)
Problems... (Score:2, Insightful)
- every card knows every other card's public key, so the storage requirement grows polynomially with the size of the network (not good).
- key exchange is a non-trivial step; in order to have adequate security you need to protect against man-in-the-middle attacks.
- using fixed keys is probably not so smart, since recovering the device would mean that you could decode all messages previously sent to that device, and a device with a compromised key could never be used securely again.
Fast Packet Keying (Score:3, Interesting)
Not terribly acuurate. (Score:2)
Not true, we have a PS2, and we don't have a special remote, and we watched a movie on the conslole it last night using an ordinary dual shock controller that came with the system. It's also documented in the manual. I think this author may be thinking about the Xbox, but I don't have one of those.
My playstation may have a more recent firmware than the author's, we bought it this Christmas. I notice you can view version info when you boot it. Does anyone else have a PS2 that does this?
Re:Not terribly acuurate. (Score:1)
I think with the XBOX you do need to buy the DVD kit but not sure.
My ps2 has a menu that i can access with my ps2 controller, for ff, rewind, play, all the normal stuff.
The problem with WEP (Score:3, Interesting)
The real problem is that encryption is:
A. Optional.
B. Difficult to set up.
WEP isn't close to being "wire equivalent" because wires are, by default, pretty secure. You don't need to manually enable 'no-public-hub-ports-on-external-walls' mode with a wired Ethernet.
A wire isn't just a way to get the bits from A to B - it also acts as a user interface for associating machines with networks. I bet you didn't think of the patch panel in the server room as a user interface, right? Actually, it's a pretty good user interface. It's much more intuitive than any GUI and very reliable (ok, so it's a little messy, but so is my desktop
Here's an idea for how WEP could have been much closer to 'wired equivalent':
When you set up the device on your machine it scans for available networks and shows a list. You choose one. It then tells you to press a key at the same time as pressing a button on the access point.
If you have physical access to the access point you can do it yourself. Otherwise you call the admin on the phone and after checking your identity (usually it's just a matter of recognizing your voice) the admin tells you to press the key '...now!'. That's it. You're on the network, with securely configured strong encryption.
This can be much more secure that it appears - the key is exchanged using Diffie-Hellman key exchange so eavesdropping is not possible. Man-in-the-middle attacks are difficult in a shared medium such as wireless where everyone hears everyone else: if the two participants are careful they can detect such attacks. To prevent attempts to 'take a ride' and join the network at the same time as another machine the access point will verify that there are no other attempts to join the network within a certain period before or after the time window for 'simultaneous' button presses (actually within plus or minus a few hundred milliseconds).
Now, what are the chances of some company actually implementing this?
Re:The problem with WEP (Score:1)
I said pretty secure, which is enough for most people most of the time. Your scenario of a malicious visitor connecting wires is far less likely than a drive-by attack by a curious geek with a laptop. Just think about the chances of getting caught in each of these scenarios.
the complete recipe (Score:1)
Rather, it refers to a technique of using regular
'ol WEP to encipher each packet, but using a different key FOR EACH PACKET. These per-packet keys are computed on the fly using a hash function-like method that scrambles the real key and thus increases the difficulty of attacking the underlying RC4. This technique has been called "key mixing" - a better term than "fast packet rekeying" IMHO - because it avoids confusion with "rekeying" whereby key material is exchanged between endpoints. Rekeying every 16K packets is required in addition to key mixing in order to avoid the passive key recovery methods (airsnort).
By the way, the "real" problem with RC4/WEP is that WEP uses the initial 256 bytes of the RC4 cipherstream. The best "fix" for WEP would be to simply discard all the key flogging trickery, but that approach was rejected because of overhead and difficulty of retrofitting NIC cards that have dedicated RC4 hardware.
It should also be pointed out that spiffing up the WEP does not eliminate attacks whereby 3rd parties inject messages. The rest of the fixup work for WEP involves specifying a separate message authentication function that prevents imposters from sending messages. A good example of what can happen in the absence of authentication is the recent well-publicized weaknesses in Universal Plug and Play. One problem was that an unsolicited UPNP NOTIFY message, if bogus and accepted, initiated a bad chain of events.
Similarly, a rekeying procedure using something like 802.1X is vulnerable to hijacking if the rekey messages are not protected with an authentication function. The bad guy can, in theory, instruct the endpoints to switch to a new key. Of course it's not quite as easy as that because the messages may not be easily forgeable. But if there are ways to forge such messages and there is no authentication function, then the system is wide open.
There is a fair chance that 11b vendors will subset WEP updates in a manner that will may separate message authentication as a configurable option. The result will be a better WEP, but in a system context that can still be compromized although not as easily as before.