Wireless LAN Encryption Standard Broken
doug13 writes: "A Rice University student cracks 802.11x encryption protocol in a week. Here is how he did it." We mentioned the cryptographic paper that underlies this attack a few days ago.
← Back to Stories (view on slashdot.org)
No, you are not correct on the CSS crack. Orginally the key was needed to decrypt the stream. However, further analysis of CSS revealed that it was possible to predict the bytes in a decryption key in a fashion similar that described in this article. It is now known that it is possible to solve the decryption functions for CSS mathematically in such a way that the key table of hexadecimal byte codes is no longer required (factored out) hence the DeCSS descrambler written with seven lines of PERL.
Too bad this is old news fellas. A group from UC-Berkeley has done an even more in-depth research project about the (in)security of wep, and can be viewed here:
Wep (in)Security
One of the important things to point out is that in the paper done by this group of people is that the also included active attacks, which is a pretty neat tool. I won't elaborate too much on this, but it is possible for a hacker (bad context) to act like a man-in-the-middle attack, sniffing your packets off the air, then doing whatever to them, then sending them to you (as if nothing every happened).
The sad thing is that most people don't even know that encryption is available on some of these models.
One other important thing to point out with wireless LANs is the new thing with war driving (similar to war dialing). What this consists mainly of is someone sitting outside in your parking lot and just surfing the net for free. There are also more complex stuff that is done out there, specifically in San Franscisco where the whole city was marked out by the http://www.dis.org guys, containing all the wireless LANs available as well as their SSID's (think of identification).
Here are some links on wardriving:
Mobile Wardriving
San Fran War Driving
General War Driving Info
One last thing to point out is that new technology that is coming out allows you to make a mobile sniffer device just using a Compaq iPaq, a Lucent wireless LAN PC Card, and a few other items (depending how sophisticated you want to get), and all of this can be done for under 1000 US dollars.
God bless Al Gore for creating the Internet.
We built 802.11 gear, marketed that gear, and ate our own dogfood. Renegade 802.11 access points became a major issue. Our folks walked around the campus with a WinCE device and network card negotiating to internal networks in (almost) all buildings.
But that wasn't the incident to drive the issue home.
It seems some non-employees were using the light rail to go to work the day after attending some networking convention. They had bought some of our wireless NICs and happened to have them in their laptops when, suddenly, they found themselves on someones network. Ours. Since they knew some of our guys, they sent an email pointing this out. That email made the rounds fairly quickly.
The joke that not only do we provide equipment for the Internet, but also public access to it? More gallows humor. I'm not sure if it was appreciated by management.
802.11x hardware is gonna be real cheap now. If you're in the situation where you're not worried about people snooping your traffic then this could soon become a real cheap network solution - particularly with all of these paranoid companies throwing their 802.11x cards out in the rubbish.
This appears to do a MITM attack w/ARP poisoning and such.
Wired Equivalent Privacy (WEP) isn't. The protocol's problems are a result of misunderstanding of some cryptographic primitives and therefore combining them in insecure ways. These attacks point to the importance of inviting public review from people with expertise in cryptographic protocol design; had this been done, the problems stated here would have surely been avoided.
What a great summation!
The stream has original material, no? For example, this post, travelling over a WEP encrypted connection, which I assume will keep others from reading what I am typing, is protected under the DMCA.
You are forcably removing the copyright protection (the encryption wrapper) and pirating my intellectual property. You have not paid me to view it, I have not granted you a license, you are a pirate.
Scary, isn't it??
.sig: Now legally binding!
The point isn't people reading your email. The point is that POP passwords and simple HTTP based authentication not via SSL are sent in the clear. If someone can sniff your network, grab your password, and crack your network merely by extracting a WEP key, then we're all doomed. Of course, sensible folk are using SSH tunneling (I'm about to get this set up, once I read all the man pges) or SSL-based email (Eudora and MS Outlook both support it, as does sendmail and Exchange), and SSH terminal software and so forth. (The related story isn't that WEP was cracked, but rather that thousands of open, free and for-fee 802.11b networks are being deployed, and those don't even have WEP on them. Sit at Starbucks, transmit your POP password in the clear, and find your mailbox ransacked later, etc., etc.) Anyone could read my email; how boring. But I'd rather that everyone not crack my accounts.
Freelance tech journalist for the Economist, MIT Technology Review, Macworld, and others
First, lets go over why 3DES and RSA haven't been cracked. DES was developed by IBM, for use as a commercial product. The original design was developed by a pretty bright guy, who, among other things, had attended a few NSA sponsered talks, and knew about some nifty new things (like S-Boxes). When IBM decided to turn his cipher (Lucifer) into a product, they got worried that if it was broken, they'd be mega-liable. Therefore they busted their asses trying to break it. In the process they (re)discovered many types of attacks, include differential attacks (a type of chosen plaintext attack). Somebody noticed that NIST had asked for ciphers and nobody had a good submission, so IBM submitted Lucifer. BUT they were still worried about it, and spent more time refining it. The NSA didn't want free crypto going loose, and offered to give it their seal of approval if IBM would cooperate fully. IBM didn't want to be liable if Lucifer had a small flaw, so they agreed. The NSA then also joined the groups of people attacking Lucifer, and helped the IBM team avoid differential attacks (which they had already done, but NSA offered refinements). The only bad thing the NSA did was cut the key length. Lucifer was submitted, and became DES.
Now, the whole point of this is that it took a long time and many many manhours of very bright people attacking the cipher, and coming up with design principles to help avoid the attacks, because IBM DID NOT want to release a cipher without doing it's damndest to guaruntee it was secure. They invited outsiders from all over (including the NSA) to attack and comment on it. A lot of work was put into it initially.
If DES had an easy attack against it, it would have been found, the design principles would have been revised, and hopefully the entire class of attacks would be taken care of.
RSA was similar. R and S came up with ciphers, and tried to break them. When they thought they had something good, they'd hand it over to A, who would then break it (supposedly he broke the first 31 attempts without any trouble). This is the same cycle IBM did: a team designs it, submits to others who will attack it, they get feedback and refine it. After the original RSA was OK'ed by R S and A, they gave it to colleages to try and break. Who failed.
My point is that all successful ciphers have gone through extensive work. Many many ciphers developed in the course of coming up with good ones are scraped. Only a few are secure. The best ciphers have been analysed by many people for a long time before they even see the light of day.
CSS was not put through such a process. They developed it, and never submitted it to the glare of public scrutiny. It contains glaring design flaws, that even a small amount of competitive attacking would have found. But it was never submitted to such, and therefore deployed before it was proved secure. The PDF security model (which Dmitry broke) was also not given a public vetting before release. (BTW, Dmitry didn't break crypto, he broke the protocol. However, many of the encryption schemes used in eBooks are proprietary designs that haven't been put to public scrutiny, and are therefore likely weak) I haven't chewed through the details of the 802.11 break, but 802.11, while it has been submitted to public scrutiny, hasn't been there very long.
It isn't that the codes are bad, but that most codes developed are crap. If you want a good code, take a code, and try as hard as you can to break it. Ask your friends/hire independant consultants to break it. Then, release it to the public to break it. Only then can you have any confidence that it is secure. And at that, if a new code hasn't been around for a while, it's probably crap. Most codes are easily broken. Scrutiny breaks the easily broken ones, leaving the strong ones for wider use.
The NSA didn't explain anything unnecessary to IBM. They also forbid IBM from discussing the reasoning behind IBM's own design changes, or even the design itself. The world has the algorithm, and any idea of why it works is up to ppl to figure out themselves.
The general feeling is that the NSA did not do anything to purposely weaken DES's basic algorithm. First off, nobody has found any truly effective attacks against DES. Bruteforce, of course, but that isn't basic to the algorithm, and besides, 3DES provides more than adequate protection. DES is also slightly vulnerable to differential (know plaintext) attacks. Differential attacks were (re)discovered by IBM, and they changed DES to prevent against it. The NSA knew about such attacks (and kept the knowledge to itself) for some unknown long time, probably before Lucifer was even somebody's dream. While the NSA did change the S-Boxes, the changes strengthened DES against some differential attacks, rather than weakening it.
Besides a lack of evidence, it was/is probably beyond the ability of even the NSA to weaken DES and get away with it. Such a weakening would have to masquarade as a strengthening, or else IBM wouldn't accept it, would have to be so subtle that it wouldn't be caught, and still leave DES strong against any other concievable attack. Making a strong code is hard enough. Making a code that seems strong, that you do not have 100% control over, and leaving one but only one subtle hole in it is probably impossible even today.
Overall, the NSA probably honestly tried to make the basic algorithm strong. The changes they made to the S-Boxes were probably geared towards differntial attacks, which the IBM'ers had only just discovered, and probably didn't understand some subtle point of. They did, however, weaken the key. 56 bits was probably low enough that they could brute force an intercept if they really really needed it, but high enough to lock out everybody else, with the possible exception of the KGB. But of course anything that the KGB would want badly enough to brute force in such a manner probably wouldn't be encrypted with DES, but with a stronger secret cipher. If the S-Boxes were weak, however, and an enemy discovered the NSA's trap door, then the enemy could decrypt everything, and sift through for tidbits later.
Bullcrap.
ettercap can sniff the log/pass out of an SSH session in REALTIME on a switched network, let alone a share media (eg AIR) segment.
Throw in some promiscuous mode drivers on your wireless card and fsck some shite up.
Not that Im advocating that of course :)
Without this example hanging over their heads, dozens of companies and tens of thousands of individuals would be running insecure networks who could be exploited by people who really are criminals.
Now that this kid has punched a hole in the standard... and he wasn't even the one to punch the hole, just the first to exploit it in a public manner... These comapnies will be forced to sit up and see that they're not safe.
Of course, we tried to use this same argument on the MPAA, and they responded by trying to sue every hacker in the U.S.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
i'm not very well versed in encryption schemes, but why is it that the encryption schemes in DeCSS, Adobe PDF, and now 802.11 are so 'easily' broken, as opposed to 3DES or RSA that are being used in SSH & SSL? why aren't these algorithms being applied in 802.11?
reech bee-yond ur clip-0n
Any static scheme will be broken eventually.
It seems to me that low volume wireless LANs are pretty safe, and can be completely safe if they rekey on a regular basis.
The original paper estimates that on average either 1 million or 4 million packets need to be sniffed in order to discover a 40-bit key depending on how the IVs were generated. Adam Stubblefield's paper found that it seemed to require 5 to 6 million packets to discover a 40-bit key. That's actually quite a lot of packets for many LANs, and a huge number for a typical home LAN. Adam had to run a flood ping for several hours to collect enough packets.
Add to that the fact that the complexity scales linearly with key size. This means that, on average, discovering a 128-bit key will require somewhere between 3 million and 18 million packets.
I just checked the statistics on my home 802.11b AP and found that I average somewhere around 100,000 packets per day. That means that someone would have to continuously monitor my network for between one and six months in order to gather enough packets to determine my key, assuming I use good keys (I do).
So, as long as I'm careful to rekey every couple of weeks, I should be safe.
Obviously, if your wireless LAN pushes a couple million packets per day (20 people streaming 192Kbps MP3s for 12 hours) you'd have to rekey daily, which would be a major pain if it wasn't automated.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
My understanding of 802.1x is that it only provides a more secure authentication system. After the initial authentication, it utilises WEP for the remainder of the session.
Can someone clear me up re. this?