Wireless LAN Encryption Standard Broken 320
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.
802.11b, NOT 802.11x!! (Score:3, Informative)
Your data is probably still secure. (Score:2, Insightful)
There is a threat of abuse from people with serious resources (e.g., the governments of developed nations), but even that threat is small. For now.
Re:Your data is probably still secure. (Score:5, Informative)
Re:Your data is probably still secure. (Score:3, Interesting)
Bullcrap.
ettercap [sourceforge.net] 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 :)
Re:Your data is probably still secure. (Score:2)
Retake (Score:3, Funny)
Should read:
Your comments are DESpicable.
Why?
Because you have no IDEA how SSH works, but you assume you do.
You are a BLOWFISH.
Sorry, could not find a way to work in 3DES, RC4, or RSA into this picture...
Re:Your data is probably still secure. (Score:3, Interesting)
Re:Your data is probably still secure. (Score:2)
Re:Your data is probably still secure. (Score:2)
damn! (Score:5, Funny)
Stubblefield and SDMI (Score:5, Informative)
Scott A. Craver, Min Wu, Bede Liu, Adam Stubblefield, Ben Swartzlander, Dan S. Wallach, Drew Dean, and Edward W. Felten, Reading Between the Lines: Lessons from the HackSDMI Challenge, 10th Usenix Security Symposium (Washington, D.C.), August 2001, to appear, pending legal action.
Here's an original link:
http://www.cs.rice.edu/~dwallach/pubs.html [rice.edu]
Straight from Kuro5hin (Score:2, Troll)
Yesterday's article from Kuro5hin [kuro5hin.org] quoted below:
This [slashdot.org] recent Slashdot article has links to the technical details. (Inexplicably, that article didn't appear on the Slashdot's front page and awareness of this problem has lagged.) The hardware and resource requirements for this new attack are trivial: pretty much anyone with a wireless Ethernet card can compromise WEP.
Hmm, gaining a few leads from k5, huh Michael? Should have gotten it on the front page correctly the first time.
It would mean free access... (Score:4, Funny)
You probably already could (Score:2)
Much like Microsoft's security patches for IIS, wireless networking was and is only as secure as the sysadmin implementing it makes it.
Re:It would mean free access... (Score:2)
Re:It would mean free access... (Score:3, Funny)
Re:It would mean free access... (Score:2)
That's not "encryption", that's authentication. Since the Internet Cafe probably doesn't want to bother managing userIDs and password (or MAC listings) for all of its customers, they just let their base station accept all attempted connections (presumably using DHCP to assign IPs).
The problem is that the data from your friend's computer to the base station is basically in the clear, since WEP is a very easy encryption algorithm to crack.
-jon
Re:It would mean free access... (Score:4, Insightful)
Agreed, but what needs to be done to make an 802.11b connection secure is combining a base station with a proxy server running SSH, tunneling the most common protocols (HTTP, SSL, FTP, NNTP, NTP, Telnet for the masochists). If there's no proxy tunneling my SSL connection to www.buystuff.com, then my credit card number will go through the air, completely insecure.
A Unix box with an 802.11 card running sshd and natd/ipfw could solve this problem; thing is that it'll cost about 4x more than just the base station, and most people don't understand why it's so necessary.
-jon
Re:It would mean free access... (Score:3, Insightful)
I'm not sure you said what you meant. If it is an SSL connection to buystuff.com then your traffic is already encrypted. If you introduce a proxy into this you will break the SSL. The salient point about WEP that people tend to ignore is that it is not designed to provide security, only Wired Equivalent Privacy. And indeed, even with the recent announcements 802.11 is at least as secure as running Ethernet cables through your parking lot.
The problem of being able to access someone elses 802.11 network is totally different than the problems with WEP.
Re:It would mean free access... (Score:2)
On further reflection, this doesn't make any sense. The base station is just forwarding on any packets you have sent from the laptop to the remote server (as well as packets sent in the reverse direction); any SSL encoding would have been done on the laptop.
So yeah, SSL is safe. But a proxy server with ssh would be nice for the non-protected protocols.
-jon
Re:It would mean free access... (Score:3, Insightful)
Wrong. That wouldn't fix the 802.11b security problem at all.
The problem with this and all of the other recommendations about VPNs, SSH, etc. to "fix" the WEP problem is that they only work if every machine that uses the wireless LAN is secure. Because if one of them has an exploitable security hole, the whole network is compromised.
"But, but, those wirelessly-connected machines are outside the firewall," you say. Yeah, and they have all the keys, passwords, etc. required to slide right through that nice VPN connection and inside the network.
Face it: If you need security, and you need wireless, you have to have a firewall on every single wireless client as well as on the AP. Oh, and you'd better have a full-time admin for all of them as well, to keep up on the security patches.
This thing has already been done... (Score:5, Interesting)
Wep (in)Security [berkeley.edu]
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 [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 [bitshift.org]
San Fran War Driving [dis.org]
General War Driving Info [wardriving.com]
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.
Re:This thing has already been done... (Score:5, Informative)
The big problem with the 802.11b folk is that in the beginning they had no security people and now they only have a couple and won't actually let them do what needs to be done.
The original WEP protocol was secure as reviewed by the NSA, then they substituted a stream cipher for the block cipher for better performance, completely breaking the scheme. Truncated IVs are not a serious problem with DES, plenty of protocols use them. Truncating the IV utterly destroys the security of RC4.
The deeper problem is that WEP attempts to provide 'equivalent privacy' to ethernet. But a wired network does not just provide some privacy it provides authentication. The big problem with WEP 1 or 2 is that there is no way to stop a fired employee surfing from the car park.
At present the (sensible) companies that are deploying 802.11b on a large scale are wrapping IPSEC arround it.
The best way to solve the problem however is to fix the protocol itself, and use a different key for each card instead of the same key for every card in the network. The 802.11b chumps keep rejecting this idea because it prevents the use of broadcast - the idea of having a separate shared key for broadcast haveing not occurred.
In order to make a separate key for each device viable it would be necessary to use some public key technology. But this is pretty easy, manufacturers of cable modems are already installing private keys and certificates in each device. Use of a modern PKI interface such as XKMS means that the card does not need to be at all complex.
It would be a good plan to swap out the RC4 algorithm in favor of AES. The chips in the cards are not up to 3DES at 11Mbs but they should be up to AES.
Nothing I have described cannot be implemented as an upgrade to the firmware of existing hardware. The extra lines of code would be relatively small.
Interesting comment in the .pdf file (Score:2)
"The WEP standard uses RC4 IVs improperly, and the attack exploits this design failure."
I don't get it. This is a standard, so isn't it supposed to go through some rigorous testing? Aren't there supposed to be some rather smart people involved in the creation of a wireless networking standard? If so, how could all these brainies improperly implement encryption?
Why PDF? (Score:5, Informative)
The intro page is at http://www.cs.rice.edu/~astubble/wep/ [rice.edu] which points to the paper in PostScript [rice.edu], PDF [rice.edu], & HTML [rice.edu] formats.
Excellent Point (Score:3, Insightful)
That having been said, would the slashdot editors please change the link to point to the HTML version of the document? Boosting the clickthroughs to a proprietary format from an offensive company at the expense of clickthroughs to an open format (HTML) isn't helpful regardless
Just my 2 cents, of course.
WAP, IEEE, Lucent and others (Score:3, Informative)
The March 2001 Cryptogram http://www.cisco.com/warp/public/707/cisco-code-r
Michael's going to jail. (Score:2)
Just so you know, $50,000 is the going rate for bail.
Re:Michael's going to jail. (Score:2)
Just so you know, $50,000 is the going rate for bail.
It's about $250,000 on the West Coast (9th Federal Circuit), where it would probably be filed.
Naturally, the US constitution protects your right to publish such things, but they'll still jail you, sell your car, sell your house, and ruin your reputation before you get the appeal heard.
To quote the paper... (Score:2)
This is exactly while all security measures should be wide open to public observation before implementation. It is NOT safe to assume that if the spec is not released publicly, in its entirity, that someone can not reverse engineer it later and break it wide open. To rely on laws that make it illegal to discover these holes is fruitless because those who are interested in knowing how such things work could care less about what is illegal and what is not illegal.
Master Locks broken (Score:5, Funny)
Mr. Carnes goes on to proclaim "the storage building industry may as well give up. No one will want to trust leaving their old couches in those things now."
In a related story: All over the nation, garages equipped with the Microsoft IIS Garage Door Opener have been opening spontaniously for more than 2 weeks. The owners don't seem to mind, though, as they gave up trying to actually use the garages due to their being built only wide enough to hold a Microsoft car, and nothing else.
Summer Intern (Score:3, Funny)
So..what did you do last summer.
Hacked WEP and got arrested by the FBI all in one week.
Impressive..but I don't think that is Microsoft-material...
CmdrTaco arrested by FBI (Score:2)
AUGUST 9, 2001 -- Apple Computer, Inc., immediately ordered the FBI to arrest Slashdot's site administrator, affectionately known as CmdrTaco, for illegally publishing information on how to break the encryption on their not-so-popular "Airport" wireless networking standard. He is currently in custody, pending a trial sometime in 2005.
In response, thousands of "Slashdotters" immediately raised a protest, sending hundreds of electronic petitions to FBI headquarters and generally making a pointless nuisance of themselves. It is not known whether the DOS attack on the FBI Web site is related to the incident, but investigations are underway.
Re:CmdrTaco arrested by FBI (Score:2, Insightful)
Don't bother with encryption (Score:2)
In our IT department, for example, all connections from the internet go through one firewall box. But that's the only port between the inside and outside world. One box. We even put the mail server outside of the firewall, get it to filter the email, then push the email through to an exchange server.
And once again, I've got to argue, what can you possibly have on a home network that needs to be encrypted? I have no secrets to hide, and would seriously consider never using any kind of protection (except for a software firewall, so my machine isn't "borrowed" for a DoS attack).
Re:Don't bother with encryption (Score:2)
Besides, who uses GnuCash? :)
Montreal newspaper also exposed weaknesses ... (Score:2)
The article is in French, the title could be translated as "Piracy, wireless and cabriolet version". In short, the reporter and a security expert drove downtown Montreal with a 802.11b equipped laptop running NetStumbler and were able to sniff out packets from four office towers.
Hey, look on the bright side ... (Score:4, Interesting)
Solution to the last mile problem. (Score:2)
No more requirement to run cable all the way to the door. Set up community WLANs and share fast broadband connections to your ISP.
A week is too late (Score:5, Insightful)
the standard wasn't engineered to protect passwords from eventual decryption, etc. instead, it's a way that a network access point can enforce a security policy so that no traffic can get through on the lowest network layers until a client has sufficently authenticated to the access point. so a wireless hub (or even a wired hub) can say "hey, identify yourself!" and the client can say "hey, this is me!" and the hub will go to a authentication server (in Microsoft's case, they say a RADIUS server) and say "hey, is this (so and so)?" and if the authentication server says yes, then the hub will let the client's traffic through.
coupled with that is a protocol where access points can enforce a policy where clients must refresh their encryption keys on a hourly basis. so a network intruder must be able to crack these keys on an hourly basis to gain access to the network. a week is a joke... these 802.11x access points will be through several iterations of keys by the time one is cracked.
(interestingly enough, the protocol also includes provisions for someone who is wandering between wireless access points where one hub can vouch for the user and cause the newer hub to forward their traffic until authentication by the server is achieved, allowing for roaming without the 3 or so second delay that would be necessary for all of this to happen).
the point of all this is that it's not there to secure your cleartext POP password.. 802.11x is there because access points (be they wireless or ethernet or whatever) are becoming more prevalent in our society in public, physically insecure places, so a protocol has to be developed so that network admins can be sure that the right people are using it.
the protocol even allows (given 802.11x aware hardware) that user levels be granted based on the authentication server, so a guest might be allowed restricted gateway access to the Internet but their traffic may be physically restricted from reaching the LAN fileserver, whereas the admin is given the red carpet.
pretty sweet, from an admin perspective.
actions to take (Score:5, Informative)
Re:actions to take (Score:2)
Does anyone remember the article a while ago, I think in Wired, that detailed the escapades of a couple guys bombing around Silicon Valley with a directional antenna hooked to an 802.11 card? Hell, at that time most of the networks they checked weren't even using any encryption (I think Sun was the worst offender - not sure though).
Wireless Security Jokes (Score:3, Interesting)
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.
Re:actions to take (Score:2)
This ain't new people (Score:4, Redundant)
That pretty much convinced me it was junk. I'll stick to copper for anything I particularly care about, thanks.
Corroborating Evidence - kinda (Score:2)
Marketing began pushing wireless access points out in to the corporate business units (heavy discounts for the equipment). They began showing up on internal networks and home networks (that are, via ADSL and ISDN, connected to the internal LAN).
It was a nightmare.
Suddenly our internal network - a network we don't allow access to from the lobby, cafeterea, or other more-or-less external points - became accessable to anyone hanging out in the parking lot with a laptop (or PDA) and a wireless network card.
A lot of backpeddling had to be done. And thus began the new game of whack-a-rogue-access-point-mole.
Would I go in to detail about the company and specific internal policies? No. That wouldn't be right. But it was a big company with a big problem. Wireless.
Wireless Deployment (Score:2)
Corporate security structure tends to have a tough shell, with a nice creamy center. That is - security revolves around firewalls to protect the internal network with very little internal security (the logistics of internal security can be insane). A part of this security posture also relies on controlling physical access.
Wireless networking creates havoc with this model.
First, as in my previous example, you have the issue of rogue access points. The equipment tends to come as plug-in-and-go magic boxes. Which provides a functioning access point - but one that has had absolutely no security configuration. Unknowing employees, with the intent to get their laptops running in a conference room or even at the beach down the road (true story), suddenly expand the "internal" network to well beyond what was normally a physical boundry - the building itself.
This is not a minor issue. Before, rogue (and/or potentially dangerous) network equipment (and services) could be disabled with proper firewall rules. There is no such choke-point with wireless access points (heck - they're easier to set up than a MODEM).
It becomes a game of whack-a-mole as you try to hunt down and disable rogue access points. One of our guys built a script that did occasional nmap scans, looking for signigures of known wireless access point hardware. It provided a method to find access points and a step towards shutting them down. But it is far from perfect.
So now this leads to the current news. Network managers who were relying on the strength of WAP will have to reconsider their strategy. Many won't be aware of recent events.
I suspect a lucky few (who are knowledgable and either don't have to fight, or are successful at the political battle with their corporate user base) will be able to deploy sanctioned access points external to their network (on the "big bad internet" side of the firewall) and rely on some sort of VPN solution for internal access.
But that doesn't solve the issues of resource abuse or rogue access points.
Sure. Its all about deployment. But that's still a pretty sizable issue. And its one a lot of managers will have to tackle. Wireless networking technology IS very cool / empowering / usefull.
Read the paper people (Score:2)
Read the warrant, people (Score:3, Insightful)
Oh, like that will stop them from tossing him in the jail when they bust into his house.
Not.
From a news article in next week's paper: (Score:2)
Subsequently, the three researchers, the authors of linux-wlan-ng prism2, Tim Newsham (who wrote the diabolical WEP_password_cracker.ppt), and anyone who ever hosted a download site for tcpdump, were thrown in jail by the ever-vigilant FBI. Such is the punishment for those who would dare challenge our corporate economy's secrets. America is saved again from the evils of Open Source Communism!
Quoth Special Agent Luser: "I fucking hate geeks and I'm going to beat the crap out of every single one of them until they give me their lunch money." Go get 'em Agent Luser!
Watch out! (Score:2, Funny)
Latest WaveLAN Firmware randomizes IV (Score:3, Informative)
Attack didn't use that... (Score:2)
A weakness in the RC4 encryption algorithm, where the usage of certain weak keys can "leak" bits of the secret key.
Static bits in the ethernet frames. Since they are SNAP frames, the first byte of the frame is always 0xaa.
The scary part of the paper is that the attack didn't rely on the poort initialisation vector. So it will work on networks with the random IV feature being implemented in the latest lucent firmware.
Oh no ... (Score:4, Funny)
Re:Oh no ... (Score:2, Interesting)
Why isn't crypto module flash upgradable? (Score:3, Interesting)
Any static scheme will be broken eventually.
Why put crypto in the NIC at all? (Score:4, Insightful)
Re:Why isn't crypto module flash upgradable? (Score:2, Informative)
There's no reason it has to be OTA programmable; requiring that the user physically possess the device should be a reasonable level of security.
The problem is that on a large network, you have to get all of the equipment working with the same encryption scheme. As the number of nodes increases, it's tough to move everyone up to the new scheme at the right time. So you've basically reinvented the key management problems that the military has with their secure radios, for example. There are ways around this, but they're generally going to make the card more expensive and move it out of the range of your average business or college campus that's using 802.11b.
Re:Why isn't crypto module flash upgradable? (Score:2)
Leaving aside the key management problem - which is the real technical/cost issue - the problem with implmenting "wired" flashability, even if key management wasn't a problem, in a "non-wired" device is gonna be marketing.
Marketing, as in "We don't think it's a big enough selling point to justify the $5.00 worth of parts to put a USB/serial port in it, and the $50K upfront cost of writing and QA-ing a flash-updater for it."
(Yes, that's Marketese for "Fuck security, if it's insecure because the protocol's weak, and not because of our negligence, the user won't blame us and will simply buy another one when the protocol is cr4cked! We save $5.00 per unit today, and probably get another sale next year when they replace it!")
damnit (Score:4, Funny)
Re:damnit (Score:3, Interesting)
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??
might be a good thing (Score:5, Insightful)
Ouch.
-----
In all honesty though, this -could- be a good thing for us regarding laws. Here's an American graduate student that showed an immense weakness in a standard encryption protocol. Furthermore, he did it for no profit, without violating any copyrights, and while working with AT&T.
This could be very good. People (as in general society) would be a bit leary of Dmitry Skylarov because he is Russian and becuase it was a for-profit venture.
This student, OTOH, broke this w/o profit and without breaking any copyrights.
Hopefully (though I doubt it) this can hit at least semi-mainstream news, or, at a minimum, the ears of lawmakers and security analysts.
Re:might be a good thing (Score:2, Informative)
RRF!
Lovett 2000
Re:might be a good thing (Score:2)
It's spelled "Sklyarov."
Re:might be a good thing (Score:2, Funny)
No, the DMCA does not apply here. (Score:5, Informative)
If you're thinking about the DMCA, you're mistaken. Breaking encryption schemes is not illegal, even not under the DMCA. It's only breaking the encryption of "copy protection schemes" that is illegal, which Wireless Ethernet is not.
Sorry, this won't be a test case for the DMCA.
Re:No, the DMCA does not apply here. (Score:2, Informative)
Anyway, there is an exemption for encyrption research, so the DMCA is not applicable here anyway.
Re:No, the DMCA does not apply here. (Score:2)
Second in a row? (Score:4, Informative)
Re:Second in a row? (Score:2, Informative)
kinda sorta. that older article (which is very good, i used it for research i was doing on wireless security) talks specifically how one could attack WEP encryption. but the implementation is left as "an excercise for the reader". this, i believe, is merely an implementation of the attack.
Re:Second in a row? (Score:2)
They are listed as references at the end of the document.
Another bit of interesting text was in the acknowledgements:
"We informed Stuart Kerry, the 802.11 Working Group Chair, that we success-fully implemented the Fluhrer, et al. attack. Stuart replied that the 802.11 Working Group is in the process of revising the security, among other aspects, of the standard and appreciates this line of work as valuable input for developing robust technical specifications."
Nice to know that they let Mr Kerry know ahead of time and that they are already working on revising the standard, instead of taking the capitalistic approach of sending it to the courts.
Bravo to both parties.
Re:Second in a row? (Score:3, Informative)
You won't find any similarities. (Score:5, Informative)
The new attack is a whole different game. It's based on a RC4 specific attack published by Scott Fluhrer, Itsik Mantin, and Adi Shamir (the 'S' in 'RSA'). It's titled Weaknesses in the Key Scheduling Algorithm of RC4. I don't have a URL offhand. Basically, RC4 has a lot of weak keys. If one of these keys is being used, then knowledge of a few key bits and the output of the cipher lets you determine a little bit more about the key bits you don't know. They theorized that WEP could be attacked with their method.
The latest paper discusses implementation of the new RC4 attack. In a nutshell, they could take the knowledge of the IV (which is used as 24 bits of the key) and the first byte of output from the cipher (easy to determine since all the packets are 802.2 encapsulated SNAP packets making the first byte 0xAA in ALL packets) to determine if the key was likely to be a weak key. They would analyze the packets whose IV indicated it is probably a weak key, and use that to determine the most likely value for the 'secret' key bits.
This is a slick attack for two reasons: it scales linearly with the size of the key. So, a 128-bit key is only about 3 times as hard to crack as a 40-bit key. Ouch. Also, it requires no previous knowledge of the network and is completely passive. Just sniff the packets until you know the key. They found it usually took about five or six million packets.
So, the newest paper is really new. None of the content is related to the paper you link to. It's not just a rehash. That's the amazing thing about WEP. It doesn't just have problems, it has a lot of them. If I had been on the design team, I would be embarrased to admit it. Almost every aspect of the protocol is broken. Almost any part that hadn't been probably will be soon.
Re:Second in a row? (Score:2, Interesting)
What a great summation!
Call the FBI (Score:5, Funny)
Re:Call the FBI (Score:2)
Re:Call the FBI (Score:2)
Re:Call the FBI (Score:2)
Not a circumvention device, the primary purpose of WEP is not copy protection.
"
It's not to stop people outside your network copying data from inside your network then?
What is it used for then?
Perfect example of why the DMCA is flawed... (Score:3, Interesting)
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.
Re:Perfect example of why the DMCA is flawed... (Score:2)
According to dmca it is illegal to circumvent electronic copyright protection measurements. Since a lot of cryptography is used to protect something that is also copyrighted dmca is almost universally used as prosecution tool against encryption cracking hackers..
However, In this case there is no clear copyright violation involved, so applicability of dmca is more than questionable. The purpose of this encryption was not to protect specific copyrighted material.. that is, unless all the packet headers contain some copyrighted strings or something..
Re:Perfect example of why the DMCA is flawed... (Score:2)
Where did anyone mention anything about any actual violation of copyright in the Sklyarov case? According to the DMCA, it does not have to.
The basic problem here is that the Bern convention (which I really like for reasons below) extends copyright protections to all data unless that data is explicitly placed on the public domain. In essence this post is entitled to copyright protection. This is good in that it offers additional protections, however hard to enforce, to the general public as well as the large companies.
Now, the vast majority of information transmitted over encrypted connections is therefore subject to copyright law, and the encryption functions as an access control device (we are less concerned about people being able to copy the encrypte data than we are the ability of people to read or access it). The DMCA "protects" against devices which circumvent the access to such material.
In the 2600 case, the courts concern about DeCSS came not from the question over whether code == speech but rather what the practical componant of that speech contained. I see no reason why a white paper precisely defining such an attack would be treated any differently. It is not the kit who would need to be worried but rather the researchers who originally wrote the whitepaper. Currently it is not politically possible to attack them but that could change.
The the DMCA defines an illegal circumvention device as one which allows access to technologically protected copyrighted material and which has limited other use. So yes, it could be illegal.
Re:Perfect example of why the DMCA is flawed... (Score:2, Insightful)
Punching a hole in a standard is not illegal. Telling other people that you have punched a hole in a standard is not illegal. Demonstrating that you have punched a hole in a standard is not illegal. Telling others about how you punched that hole in a standard isn't illegal. Distributing the product that punches the hole in a manner reasonably calculated to advance the state of knowledge or development of encryption technology when engaged in a legitimate course of study and then providing the copyright owner with notice of the findings and documentation of the research is not illegal. Distributing the hack for noncommercial purposes is not criminally illegal.
Dmitry was allegedly selling a product designed primarily to commit illegal acts. That's why he was arrested, not because he demonstrated a security hole. He found it, then he tried to profit off of it by distributing it to people who paid him. Allegedly.
different encryptions (Score:4, Interesting)
Re:different encryptions (Score:2, Insightful)
> 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?
A very simple reason underlies all of this: cost.
You see, your PC has a whole lot more horsepower than a PC card, both in terms of CPU and in terms of memory. It can easily afford the memory space and CPU cycles to perform beefier algorithms. PC cards, on the other hand, are much more limited, due to the fact that in order to make any profit, they have to be made for as little money as possible (believe it or not, pretty much all 802.11 radios are sold with exceedingly low profit margins. You'll notice the cheaper ones have lesser or no WEP capabilities, for instance). A few things sacrificed to cost: CPU speed, FLASH space, and RAM size. This is an environment where 80MHz is a high-powered CPU, and 1MB is alot of storage capacity/memory space. WEP encryption is only one of many, many other options that have to fit in there. Now, one option is to put the encryption into its own hardware. That frees up CPU cycles, plus some RAM space and FLASH (though not all by a long shot). However, hardware encryption adds to the cost of the PC card. In other words, it's real hard to win in these situations. This is why all manufacturers of WiFi radios recommend using VPN over a wireless connection, and not relying on WEP. WEP is there to help (it'll at least stop the random script kiddie from setting their card to associate to "ANY", walking through your parking lot and hopping on your LAN), but it was never meant to be the end-all-be-all of security for wireless connections.
That being said, IEEE is working on further security standards that require a lot more pieces (e.g. authentication servers, etc), but those standards are not yet finalized, and even when they are, the radios, access points, and servers will all cost extra.
It all boils down to this: to get a more adequate security system implemented costs more money, and most people don't want to spend more money on 802.11 equipment. (At least, that's been my personal observation, based on conversations with friends and customers of 802.11 equipment).
-Freeptop
Re:different encryptions (Score:2)
Good design principles/the test of time. (Score:5, Interesting)
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.
NSA S-Box Mods (Score:2, Interesting)
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.
Re:Good design principles/the test of time. (Score:2)
Re:different encryptions (Score:5, Informative)
I don't know what encryption PDF uses, but I think it is pretty strong.
In both WEP and PDF, the problem is not with the algorithms, but with their implementation. WEP uses a pitifully bad IV generator, plus uses the key straight up, rather than hasing an ASCII string to a binary value.
PDF simply cannot be made secure since it relies on transfering the key to the users computer and decrypting the PDF with it. Once you get the key, you can decrypt it yourself.
DeCSS was cracked because Xing forgot to swizzle their key in the binary, and it was extracted. At that point, another weakness allowed the extraction of more keys -- I don't know if that was a protocol or algorithm problem.
The lesson here is that security is much harder than just encrypting things. SSL, SSH, PGP, etc. were all designed as secure protocols. That was their entire goal, and the designers knew a lot about security. DeCSS, PDF, and WEP were all designed as bullet-item features within other products, and no special attention was paid to the overall security of the system.
It is also a question of mentality. Encryption algorithms are designed by academic researchers or the like, who expect the algorithm to be publically examined by their peers for any possible weakness. Software (and hardware) engineers usually don't believe in their hearts that people will try very hard to break their products, or that it would be "practically impossible" without the necessary documentation.
PDF (Score:2, Informative)
Some PDF encryption is strong, some is weak. What was attacked by Dmitry was the plugin protocol, which is weak. Adobe itself isn't really in the market of encryption, but in a protocol that allows restricion of usage in certain ways. Many vendors provide plugins that use the protocol, and many of their plugins have cryptographic weaknesses. The plugins themselves are moot, however, as the protocol blows.
Re:different encryptions (Score:2)
Just for the record, DeCSS wasn't "cracked" in the usual sense. One of the DVD manufacturers didn't encrypt their key within a DVD player like they were supposed to, and some programmers discovered it.
If the key hadn't been discovered, DVDs would never be cracked (barring any new mathematical breakthroughs).
Re:different encryptions (Score:4, Interesting)
Re:different encryptions (Score:2)
But, I'm just making a semi-informed guess...
Re:different encryptions (Score:2)
The problem is that these protocols are expensive in CPU time. Sure sometimes the Not-Invented-Here syndrom bites them hard, but usually the problem is that theses protocols aren't fast enough. 2 seconds to encrypt an email is ok, but you need to encrypt 5Mb/s here, with just some little chips on your card.
jrst (Score:2, Insightful)
If there are control functions used by 802.11 nodes that depend on WEP for their integrity/privacy, the network could still be susceptible (even if your application data is secured end-to-end).
Would someone familiar with 802.11x internals shed some light on this? Thanks.
This is new?? (Score:2)
Workaround: Just rekey frequently (Score:4, Interesting)
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.
Re:Workaround: Just rekey frequently (Score:4, Informative)
Read the paper. It does not matter how often you rekey or whether you buy the 40bit or 128 bit cards. The algorithm used is a stream cipher and will XOR your plaintext with one of 2^24 ciphertext streams that are generated from your key.
The attacker can cause the gateway to act as an oracle for any given ciphertext stream.
If you rekeyed every hour you would be safe (ish). However the WEP protocol does not support rekeying and everyone in the network has to use the same key. So you would have to update all your machines manually constantly.
Re:Workaround: Just rekey frequently (Score:2)
The second set of papers have demolished the proposed fixes that nobody has implemented. I doubt that a workarround will be necessary since that set of proposals is now completely dead.
Time for the 'A-Team' to arrive and take over.
Re:Poor kid... (Score:2, Informative)