Slashdot Mirror
A Look at the State of Wireless Security
An anonymous reader brings us a whitepaper from Codenomicon which discusses the state and future of wireless security. They examine Bluetooth and Wi-Fi, and also take a preliminary look at WiMAX. The results are almost universally dismal; vulnerabilities were found in 90% of the tested devices[PDF]. The paper also looks at methods for vendors to preemptively block some types of threats. Quoting:
"Despite boasts of hardened security measures, security researchers and black-hat hackers keep humiliating vendors. Security assessment of software by source code auditing is expensive and laborious. There are only a few methods for security analysis without access to the source code, and they are usually limited in scope. This may be one reason why many major software vendors have been stuck randomly fixing vulnerabilities that have been found and providing countless patches to their clients to keep the systems protected."
... when you don't do anything that needs to be secure, over it.
IS that what this is saying?
What we need is a strong, coordinated, open-source effort to create new standards for networking devices, rather than rely totally on proprietary software.
I agree that any attempts for security by proxy will always have vulnerabilities. If you haven't checked the code yourself, you can never trust it 100%. If no one can check the code but crackers with fuzzing tools, then you can't trust it at all.
For most of readers here it will no doubt be obvious, but sadly this is lost on many people who buy software, even those who buy software for large companies.
My little Linux and tech blog
If you meet a skilled hacker, no matter what you throw at him/her they will be able to beat it. However most security holes aren't a huge deal because as long as there isn't a .exe that Joe Script-Kiddy can execute its not going to be exploited.
.exe .exe
You are missing the vital link here.
1. Skilled Cracker will find your security hole.
2. Skilled Cracker will then brag about it on a forum and provide example code.
3. Not-so-skilled cracker-wanabee will fill it out and package it as a
4. Joe Script-Kiddy executes the
On the Web, this cycle does not take very long. Imagine 1+2 happens on Friday, by the time you come back to work on Monday your server is being accessed.
My little Linux and tech blog
If you RTFA, you'll see that there are lots of wireless holes. It's a constant battle to keep things patched-- when the vendors elect to issue one. It's also a company that's done a lot of work, and is now looking for more work to do. It reminds me a bit of Symantec's Macintosh threat PR.
This doesn't excuse the rotten wireless security we have today, it nonetheless doesn't provide models for improvements or other advice or recommendations on how security can be improved.
---- Teach Peace. It's Cheaper Than War.
You're right. Why is there no VPN and SSL in wireless? I hear that those things are pretty secure.
What?
Ironclad Security only exists when you have Chuck Norris on the shift. Do we really have to discuss this? (Plutonite)
Bzzt! Wrong! I really hope you aren't a wireless hardware designer.
Encryption algorithms (especially the "unbreakable" algorithms you allude to) take time/computing power to encrypt and decrypt at each end of the wireless link. The level of encryption used is always a practical trade-off between security and transfer rate/hardware complexity. If people demand more encryption, suppliers will give it to them, but it comes at a cost and no wireless designer is going to put their product at a competitive disadvantage by using encryption that's stronger than what's "good enough" for most users.
"Simply share the onetime pad between the computer and access point over a wired connection"
If you have a wired connection, you don't need wireless.
Ah, but, you say, you just download a big enough file that you won't need to update it.
But my wireless connection is around 5 megabytes per second, so to support that much traffic with a one-time pad, you'd need every pad to be 900 megabytes. For every three minutes you're using the network.
Which is a metric fuck-load of data to have to carry around just in case you might want to connect to one particular network for one specific three minute period. I'll let you work out how big it would be if you had to be able to connect at any time during a period of several days.
- You need to prevent a `man in the middle' attack, in which I bring up a rogue base station in the area and have everyone bind to me. Your solution doesn't provide even for a shared secret which I expect the base station to know, so there's nothing to stop this from working. So we're going to need something which a base station can use to prove that it's my base station. What? Certificates? Shared Secrets? All the problems we already have, in fact.
- The fine article is mostly about implementation problems, not protocol problems. Both SSH and SSL have been prey to plenty of implementation problems which allow suitably crafted clients to crash, hijack and otherwise mess with servers. You've got all those problems.
- And most catastrophically, generating `random keys' in small embedded devices is really, really hard. Getting hold of enough entropy is a small SME router to produce strong keys on a regular basis is difficult. Making sure that initialisation vectors are suitable chosen is hard.
Here's a thought experiment for all `simple' solutions. Imagine I have a router in my lab, the same model as the one I'm attacking. I capture the packets the supplicant sends to initiate an association, and I play them into my captive router. I have the clock on the captive router set an appropriate distance behind the clock of the router I am attacking, and the MAC address set the same and ideally the serial number (they're usually helpfully printed on the outside). What magic is it that makes the key my captive router generates be something other than the key the router I'm attacking generates?ian
The fact that I'm piggybacking off of an unprotected wireless network right now might serve your point.
I'd guess that the vendors don't want to put in either faster CPUs or crypto codecs to keep performance from falling apart. But you'd think that's exactly what they would do, embed SSL encryption into the layer 2 transport, or at least make it a (default) option. Most 802.11 implementations are more likely for "convenience" wireless and not for high performance anyway, so I would imagine that some kind of default good cypto wouldn't be noticed by the 99% of WAP users.