IEEE Approves 802.11i 302
Dozix007 writes "IEEE has approved a
new wireless security protocol dubbed 802.11i, intended to finally
provide sufficient security for wireless connections that users don't
need to rely on alternate security layers. The new specification works
by using AES encryption
in the transceiver itself, encrypting data directly at the level just
above the actual radio pulses themselves. That makes it transparent for
applications sending data through the radio, so legacy programs running
on new 802.11i-compliant hardware will automatically get the benefits
of the new protocol without the need for modification."
Sure but does it require new equipment (Score:4, Interesting)
$$$$ Dude.
Re:Sure but does it require new equipment (Score:5, Informative)
Well, since encryption only involves standard processing, a firmware upgrade should be all that's required. Don't see any reason why a device would need to be created specifically for 802.11i. This is also interesting (taken from here [dailywireless.org]):
Cisco, one of the largest providers of enterprise APs, said AES is supported in hardware on the IEEE 802.11g versions of AP models 1100, 1200, and the newly announced 1300 outdoor AP/bridge. However, a software upgrade for those devices will be required. Software upgrades will also be available for 802.11a, b and g card-bus and NIC cards.
Although they don't state it explicitly, it's a pretty fair bet that firmware upgrades for Linksys APs will be available at some point.
Re:Sure but does it require new equipment (Score:5, Insightful)
Ah, that would be because corporations are greedy. Sure they could give you a firmware upgrade, but they could also peddle a completely new product that costs you money.
Re:Sure but does it require new equipment (Score:3, Interesting)
OSS to the rescue(?) (Score:4, Interesting)
The HostAP [epitest.fi] driver does encryption in software.
My home server is (among other things) a wireless access point. The card I have is a few years old and doesn't support WEP at all, but thanks to this driver it does! In fact it also supports a bunch of other security features for encryption and authentication, which I have not delved into.
That said, it sounds like this new encryption may be at a lower level, which for all I know may necessitate new firmware.
Re:But Linksys has a history of good updates (Score:3, Informative)
Linksys usually keeps their products updated to the latest capabilities within two years, and past that they still provide bug fixes.
This new encryption thing might be different and/or it might require new hardware
Re:But Linksys has a history of good updates (Score:3, Interesting)
Bullshit. They drop support just about as soon as they can. I've got a first-gen WPA11 for which linksys never released a single firmware update and which never had a reliable driver. I've also got a WAP11 that's in the same boat. You may be confused by the fact that linksys generally keeps the same name when they change the chipset on their products. So they have upda
Re:Sure but does it require new equipment (Score:2)
Security advice for the non-technical: http://besphere.blogspot.com
Re:Sure but does it require new equipment (Score:5, Insightful)
1) It's not likely that the 200MHz CPU in that thing is going to handle 54Mbit worth of traffic. AES is not the easiest to calculate...
2) Even so, it's highly likely that a firmware update could *possibly* add this. Will Cisco? My guess is no: they are not incented to make your current device more useful. They'd rather sell a new device.
3) The beauty of OpenSource is that you can add whatever features you want... [seattlewireless.net]
Re:Sure but does it require new equipment (Score:2)
On x86, AES can be done in under 25 clock cycles per byte, so if that is an x86, a 200 MHz CPU could handle 54 mbit/second, although it wouldn't leave much for other stuff.
Re:Sure but does it require new equipment (Score:5, Insightful)
In other words, assuming *zero* processing overhead, we're 25 MIPS short for wire-speed encryption.
These are very rough numbers, but think of it this way: do you think Cisco (or whoever) spec'ed a processor substantially faster than what they needed? From my peronal experience, embedded processors do not usually have more than a few percent more performance than they need: rarely do they have even 30% more performance than they need. Even if they design a system with a way-fast processor, one of two things happen: their code bloats to use that speed (or they quit optimizing because they don't need to), or they end up buying a lower-cost, slower processor for production!
In short, it's highly unlikely that the Wrt54g will have anywhere near the CPU power to do wire(less)-speed AES at 54Mbit. Half that? Maybe, but not all of it.
Re:Sure but does it require new equipment (Score:2)
Re:Sure but does it require new equipment (Score:2)
Synopsis: All new kit to have embedded encryption co-processors, available September. Throw the old stuff away.
Re:Sure but does it require new equipment (Score:3, Informative)
I've answered my own question.
For those wondering what I'm rambling about with WPA and TKIP, you can read this [mobilizedsoftware.com]. It explains the relationship between WPA and 802.11i, as well as what TKIP is and why TKIP will work on any processor that can handle RC4.
Watch your Head! (Score:2, Funny)
Ah Finally! (Score:4, Insightful)
Re:Ah Finally! (Score:5, Funny)
Re:Ah Finally! (Score:5, Funny)
I'd say your spelling problems provide enough encryption at the user level.
Re:Ah Finally! (Score:2)
-N
Long Time Until it Replaces B/G (Score:2, Interesting)
Does anyone have any figures on how long between products get rolled out until inception in the digital world? I would be curious to see the timeliens of some products such as: 3.0megapixel cameras, DSL/Cable, 802.11b/g, etc.
GroupShares Inc. [groupshares.com] - A Free and Interactive Investment Community
Lack of equipment or how it's supposed to work? (Score:4, Insightful)
If I'm remembering that right, then what you're experiencing may not be a lack of standards uptake -- you could be connecting to a ton of 802.11g stations, but somebody's got a B card running.
No (Score:4, Informative)
Maybe some routers do this, honestly I wouldnt be surprised, but I'm just letting you know that mine doesn't.
Re:No (Score:4, Informative)
The actual issue is that some of the 802.11 protocol has to be done at speeds that all possible connecting units can understand. What this amounts to is that 'handshaking' is done at B speeds to allow B units to communicate, while the actual data transfer for G units is done at G speeds.
This causes some slowdown for G units. If an access point has proper settings, you should be able to make it do G only, thereby speeding up all G units at the expense of disallowing B units from connecting at all.
At least, the 802.11 protocol allows this, don't know if APs do or not.
Re:Lack of equipment or how it's supposed to work? (Score:2)
I don't think the chipset is as widely used as it's 802.11b counterpart, the Prism 2 though.
Re:Long Time Until it Replaces B/G (Score:3, Insightful)
thats probably because for most purposes B is fine. i mean who is going to spend more on G when typical internet speeds never even reach 11Mps? G maybe is fine for the office or home where you are talking to local servers or other clients, but starbucks doesnt need more than a B.
Re:Long Time Until it Replaces B/G (Score:2)
That's why you make a G signal.
For internet access spots, B should do fine.
The idea is to get a more recent standard such that when it gets widely adopted, you are ready for it, rather than having to upgrade or add cards when it does become popular.
Re:Long Time Until it Replaces B/G (Score:2)
G recently became rather affordable. Just a few days ago I bought a wireless router using G. It was only $10 more expensive than B. I figured what the hell?
I doubt you'll find G at public places, though. Little need for it since it isn't so popular to do transfers that require the megabits range.
Re:Long Time Until it Replaces B/G (Score:3, Funny)
=)
It's about time... (Score:5, Interesting)
Now if only I can convince my employer so I can use Trillian to get me through those boring meetings.
MAC encryption (Score:2, Informative)
Thus it will still not encrypt ESSID (used as a clue for what encryption credentials you need, NOT as a security measure) or the MAC address of the systems using it. (Page 29 of the above referenced article).
It's designed to address two of the three of the CIA principles, those being confidentiality and integrity of your data. Not to hide who is on the wireless network.
Suspicious (Score:5, Funny)
Get out the tin foil hats boys, this is a big one.
Re:Suspicious (Score:2, Funny)
This one calls for a freaking tin foil *bodysuit*.
Re:Suspicious (Score:2)
The Bush Administration flew them out of the country back to Saudi Arabia.
This is either going to be modded really high or really low. Unless no one saw Fahrenheit 9/11, in which case I'm screwed.
Some fool... (Score:2, Funny)
awesome (Score:5, Insightful)
i hope the guys at best buy are up to speed to direct the consumers!
Re:awesome (Score:2, Funny)
I could care less about
Re:awesome (Score:2)
don't worry (Score:2)
it'll be you explaining the differences and doing the troubleshooting
enjoy
802.11h? (Score:5, Funny)
Re:802.11h? (Score:2)
Pinging www.slashdot.org via 802.11horse...
Response received in 32 days, 4 hours, 7 minutes, 5
The i stands for... (Score:4, Funny)
Hey, if you don't think anyone makes that spelling mistake, check out this link! [google.com]
Re:The i stands for... (Score:3, Funny)
Firmware (Score:4, Interesting)
If thats the case, running a VPN over the wireless may still be the best option.
Re:Firmware (Score:2)
Re:Firmware (Score:2)
Having actually implemented the AES algorithm, I would guess it is possible if the code were carefully optimized. It would peg the CPU completely, though. And what are we talking about when you say "general purpose CPU?" A Pentium 4? Or a 200 MHz MIPS chip?
AES isn't a very complicated cipher (from an implementation standpoint).
Is this really a good thing? (Score:5, Insightful)
Re:Is this really a good thing? (Score:2, Insightful)
Re:Is this really a good thing? (Score:3, Funny)
Hee hee.
Re:Is this really a good thing? (Score:5, Interesting)
The parent should be modded up. I'd add that you should be suspicious of key management carried out below the application layer. Even the submitter emphasizes the wrong point, IMNSHO, when he/she says that AES will be used to secure the connection. The choice of encryption algorithm is almost inconsequential because the world has plenty of good encryption algorithms, but the key management is the really difficult part. Designing a protocol is moderately difficult too (read Peter Gutmann's VPN rant to see some examples of poor protocols).
Change hardware *again*? No thanks (Score:4, Insightful)
And exactly 0% of the hardware will be backwards compatible. Who trusts data privacy flying across a network anyway? Isnt that what we have VPN, SSH, HTTPS, etc. for? IMHO we have more things to concern ourselves with, like interference countermeasures, signal efficiency, etc. Who is going to switch to a new hardware platform just because it offers a different (read: not necessarily better) encryption method?
Re:Change hardware *again*? No thanks (Score:2)
Re:Change hardware *again*? No thanks (Score:2)
This is terrible news (Score:5, Funny)
Need I say more.
Re:This is terrible news (Score:2, Funny)
Let's hope 802.11 stops soon (Score:4, Funny)
Sample tech support eamil exchange
"I'm having problems with my 802.11l wireless router"
"Did you say 802.111?"
"No, 802.11l"
"That's what I said"
"No, you said 802.111, that's not due out til next month according to
"Sorry sir, so you have our 802.11/. router?"
Re:Let's hope 802.11 stops soon (Score:2)
Re:Let's hope 802.11 stops soon (Score:2)
Remember the old electric typewriters that didn't have a '1' (one) or a '0' (zero) key? You had to use letters instead.
Re:Let's hope 802.11 stops soon (Score:2)
Too many goddamn wireless standards. (Score:2)
Re:Too many goddamn wireless standards. (Score:3, Insightful)
That's essentially what's happening already. They settle on a standard, people adopt it. The trouble comes with the "go from there" part. Whenever you "go" anywhere new with a standard, the old stuff is non-compliant, thus requiring a new standard.
Better than IPSec over wi-fi... (Score:2)
Re:Better than IPSec over wi-fi... (Score:4, Insightful)
Besides, there are *many* issues regarding security aside from the wire protocol. As one other posted mentioned, key management is one of these issues. How does 802.11i deal with this? I know IPSec has many different solutions available for key management, meaning I can make it fit into my network infrastructure. How does 802.11i fit into this picture?
Re:Better than IPSec over wi-fi... (Score:2)
IPSEC means encrypted end-to-end, not just over the wireless segment of the network.
All this faffing with wireless-specific encryption is just a stopgap until we get broad adoption of IPSEC or similar.
Re:Better than IPSec over wi-fi... (Score:2)
The downside of broad adoption of encryption technologies is that it makes the job of protocol analysis (when finding bugs) nearly impossible.
There are several occasions when I've had to take tcpdumps to identify a bug in a vendor's product (IBM WebSphere! Shoddy! well, getting better now). When the traffic's encrypted, the games a bogey, unless application-layer tools exist to dump the protocol details.
Re:Better than IPSec over wi-fi... (Score:2)
Umm... no. IPSec just means encryption between two IP route points. So, for example, the plan for my wireless network involves an IPSec connection between any wireless end-points and my IPSec-enabled firewall.
Poor Starbucks (Score:4, Funny)
Key Management (Score:5, Interesting)
Is they key negotiated as part of the protocol? How is that exchange authenticated? How is access control done? Can anyone enter the network?
Does it use a pre-placed key? How do you make sure the AP has every clients key? Can you access the AP without encryption? Do users have to type keys in?
Re:Key Management (Score:3, Interesting)
I fearlessly predict that some of those passphrases will be chosen poorly.
Security advice for your Aunt Tillie and Cousin Homebuilder: http://besphere.blogspot.com.
Re:Key Management (Score:3, Insightful)
This means I'd bet someone $20 that it'll use a single shared key across the entire network, and client machines will obtain it from a user-entered password.
But since it uses AES, all sorts of people will get excited and believe it's secure.
So I see this as little more than a marketing ploy.
Is it more secure than WEP and WPA? Yes. Yes, it's more secure, because in order to get t
Re:Key Management (Score:4, Insightful)
If you rely on encryption that behaves like that, you're foolish and will have problems.
If you believe this is better than what has come before, you are more likely to rely on it.
Therefore, I actually think this will in practice cause more harm than good with regard to actual security.
IMHO, we need totally wide-open unencrypted wireless, with IPSec and nothing else running on top of that, with secure apps running on top of that. I think any crypto at this layer is essentially smoke and mirrors.
Re:Key Management (Score:5, Informative)
Re:Key Management (Score:3, Informative)
This PDF http://www.wi-fi.org/opensection/pdf/whitepaper_w i -fi_security4-29-03.pdf [wi-fi.org] from the WIFI alliance talks about WPA2 near the very end of the document. According to this, WPA2 will use the same 802.1x authentication current used by WPA in enterprise deployments or the PSK mode currently used in home deployments of WPA.
This PDF http://jcbserver.uwaterloo.ca/cs436/handouts/misce llaneous/Intel_Wireless_3.pdf [uwaterloo.ca] has some interesting tech
FW Upgrades for non-router 802.11x equipment? (Score:2, Interesting)
Does this finally solve the *other* major problem? (Score:3, Interesting)
I personally think a HUB is still a bad idea, even if the main transports are encrypted to the outside. The insider doesn't need to be able to see anyones traffic unless it's repeated to the target. It would be great if it was encrypted and acted like a switch.
I would still use my VPN with this.
Re:Does this finally solve the *other* major probl (Score:3, Interesting)
i'm not trolling here, i'm really wondering.
Re:Does this finally solve the *other* major probl (Score:3, Informative)
I can't help but think that you don't know what you're talking about. The whole nature of RF is that if one person can receive the radio waves, so can several other people. You can't just select a single point to broadcast to. Sure, you can make sure that those RF waves are encrypted, and that's what this standard does. However, it's physically impossible to keep other parties from receiving the encrypted wav
Re:Does this finally solve the *other* major probl (Score:3, Informative)
The key is negotiated at authentication time and is valid only for the given client and sesion. Without the client's authentication credential (certificate or otherwise), you can't get a hold of the key.
OK, but how does it actually work (Score:5, Insightful)
How do the nodes generate and exchange a shared session key? Or do you have to enter an AES key manually before you even hook up? That would certainly lock down the node!
It would be nice if someone posted a link explaining at a medium level how it actually works. I don't want to just go read a draft of the standard, but I wouldn't mind reading a few of the important details.
MM
--
Re:OK, but how does it actually work (Score:5, Informative)
802.11i uses AES for privacy, HMAC-SHA1 for integrity, and it defines its own protocol for establishing transient unicast and group session keys. You can use it with a pre-shared master key (derived from a simple passphrase), or you can use it conjunction with 802.1X and get per-user pairwise master keys derived from the authentication service.
The Wi-Fi Alliance (I'm told) is calling 802.11i by the name WPA2. If you have hardware that supports the AES variant of WPA, then your vendor should be able to supply a firmware upgrade soon that will support WPA2.
Re:OK, but how does it actually work (Score:2)
You would not have to ask this question if you had even a basic understanding of cryptography.
The Diffie-Hellman [postdiluvian.org] key agreement protocol is well known and very secure.
Alternatively, it could be done how SSL does it: use a public-key method to exchange the symmetric-key cipher keys. You didn't actually think SSL sent all the data through a public-key cryptosystem, did you?
P
In related news... (Score:5, Funny)
Now I'm confused. (Score:2, Insightful)
While this clearly means that now no one can sniff the SSID, is this going to be any better for those who leave it at the default? And without any kind of MAC authentication or network protection at upper levels, would knowing the SSID the only difficult imposed against abuse of the netwo
Re:Now I'm confused. (Score:4, Interesting)
IEEE 802.11i uses AES, which is not a public key algorithm, but it does provide for a key exchange process which can be based on public key cryptography (but doesn't have to be).
As for hiding the SSID, I question the accuracy of tha article. It doesn't tally with what I've read about 802.11i over the last year. I don't think 802.11i provides for encryption of the entire frame any more than WEP or WPA does, and AFAIK it doesn't provide any security for management frames, so the SSID should still be in the open.
MAC-based authentication is useless for deterring a serious attacker, but 802.11i provides for 802.1x port-based authentication, which typically will operate at the user level.
Although 802.11i provides for generating the master key on-the-fly, I suspect that many installations (expecially home networks) will use pre-shared keys, which are usually hashed passwords and thus vulnerable to dictionary attacks.
I doubt that the block cipher was the problem (Score:2)
The hard part in practical cryptography is not the block ciphers (there are plenty of those to choose from, off the shelf, that are good--AES, RC4, Twofish, Serpent, triple DES, etc). The hard part is using them properly--picking an appropriate mode, key management, padding, and stuff like that.
Re:I doubt that the block cipher was the problem (Score:2)
With better protocol design, the problem would have been avoided, but the fact is that there WAS an exploitable weakness in the ciper that was used.
By the way, RC4 is a stream ciper, not a block cipher.
hardware-level encryption = crap (Score:2, Interesting)
Putting encryption at this level is useless because secure communication with e.g. a webserver still requires that I encrypt over HTTPS, since my link to the server goes over more than just the wireless link. Thus, hardware AES only duplicates functionality. This is one of the premises of the end-to-end argument: put functionality at the highest layer possible to avoid duplication.
The argument that this is useful to keep "baddies" out of your network is weak,
Re:hardware-level encryption = crap (Score:3, Informative)
Suppose you've got a really good placement (what a climber would call a "bomber" anchor) and you're sure it will hold. Do you place another, potentially less secure anchor in parallel, given the opportunity? Of course you do. You never pass up the chance to add a layer of protection. Even if you don't think it will be needed, and especially even if you don't think it wi
Re:hardware-level encryption = crap (Score:2)
I wonder if the data transmitted will feel more secure with a bad protection and will avoid being eavesdropped
not to contradict you, but making analogies isn't always a good idea
Re:hardware-level encryption = crap (Score:4, Informative)
Presto, you're screwed? What keeps a "baddie" from sniffing your traffic, waiting until you're not on, then changing his MAC address to be the same as yours? Oh, gee... I guess that doesn't buy you very much, either.
Even if it did, that still doesn't keep them from *sniffing* your network. Any data you transmit, they have. Just checked your email? Chances are they have your password. And all of those pictures that your girlfriend sent to you in those pictures. And those are just benign examples.
Putting encryption at this level is useless because secure communication with e.g. a webserver still requires that I encrypt over HTTPS
Until *every* protocol that goes over your network has reliable encryption, then this is still useful.
steve
wait for 802.11n (Score:2, Informative)
How long until APs are $80 and cards $40? (Score:2)
How long until the AP is $80 at Fry's (like current models), and cards are also cheap?
Re:802******* and beyond (Score:3, Informative)
Re:Key Exchange (Score:2)
-l
Re:Actually secure? (Score:5, Insightful)
However, you do have to remember that a lot of classified information that would result in really major problems for many governments travels, encrypted, over the airwaves, on a regular basis. A cryptosystem isn't called secure unless it can't be broken in a reasonable amount of time, even if the bad guy knows your algorythm, and even if the bad guy is able to observe your transmissions.
Basicly, what the entire WEP debacle has shown is that when you are transmitting over the airwaves, the importance of secure encryption increases. And that if you are going to make a widespread standard for encryption, you had better check it out with some folks who know encryption first.
Re:Now we can start waiting for a total break of A (Score:3, Informative)
While this doesn't guarantee the security, it certainly improves the chances of it being as secure as possible. AFAIK, DES/3DES, a 20+ year old algorithm is still only vulnerable to brute force attacks.
The real fea
Re:Now we can start waiting for a total break of A (Score:5, Informative)
Although it is correct that it was not invented by Americans, the term "Rijndael" is not a foreign word. It is simply a contraction of the names of the two inventors: Vincent Rijmen and Joan Daemen.
Some people still care about efficiency (Score:2)
I am all for encryption. In fact I have sent a few letters to my congressmen about the issues surrounding it; However, some things just don't need to be secure. Encryption takes time and to be quite honest If I am downloading, say, the Slackware-10 distribution the last thing I want to have to wait for is each of a bajillion packets to be encoded and then decoded. Especially when I couldn't care less who gets a hold of said packets.
In most cases only specific sensitive pieces of information need to be encr
Adds strong authentication though (Score:2)
Not the end of wardriving, just the beginning! (Score:2)
Re:Is this the end? (Score:2)