IBM To Unveil Secure Open Wireless At Black Hat 91
Trailrunner7 writes "Researchers from IBM's ISS X-Force plan to unveil a new system for running an open wireless network in a secure mode at the Black Hat conference here this week. The system mimics the way that Web sites browsers use digital certificates to establish a trusted connection with one another. X-Force researchers have been working on the system for a while now and the company plans to demonstrate the technology on Thursday during the conference. One of the main problems with public wireless networks is that they're susceptible to a number of simple attacks, including passive sniffing and man-in-the-middle. The X-Force system is designed to get around these problems by using a digital certificate to assure users that they are communicating with the wireless hotspot that they think they are."
I could be wrong but... (Score:1)
Re: (Score:2)
Re: (Score:2)
Now at least hotels, cafes etc can make a reasonable effort at providing some security for their guests/users.
I hope there's an "SSH-style" option, so we don't all have to pay CAs every year or so.
Re: (Score:3, Interesting)
Which defeats the whole point of it being "open" wireless. Yes, if you make the hotspot private it can't be accessed by the public. Wow, you're sooo smart! Except that the point if this is to make it open and public.
Re:I could be wrong but... (Score:5, Informative)
Re: (Score:2)
Yeah, there are even tools like essid_jack ("Proof of concept so people will stop calling an ssid a password.") that automate the process by trying to force connected clients to reconnect, revealing the SSID.
Re:I could be wrong but... (Score:5, Interesting)
The idea here is that you can have an open, public, wireless system that is not vulnerable to sniffers or MITM attacks. It's not for keeping your private wireless secure. As it stands right now, when I use the wireless in Starbucks I need to be careful. I need to make sure that all connections are HTTPS, or otherwise encrypted less I inadvertently give username or password information to anyone sniffing packets on the air; or setting up a rogue access point claiming to be Starbucks, but really on someone's laptop. With this technology you have a signed digital certificate and an encrypted connection. The one protects against rogue access points or MITM attacks, the latter again sniffers.
It's a clever use of a known paradigm (chain of trust) to protect something that hasn't previously been very safe. The trick will be adoption, and setting up a chain of trust. I imagine the existing CAs could issue the certificates to handle the chin of trust issues, but adoption will require some cooperation from industry. Hardware and software vendors will have to create WAPs and clients to use this tech; and companies like Starbucks and even mom and pop cafes will have to invest in the new WAPs and deploy them.
Re: (Score:3)
Re: (Score:2)
Well of course. Nothing is a magic bullet, but this is buttoning down one of the more seriously vulnerable parts of the chain. It's possible but unlikely that a router or other device in my path could be compromised or run by bad actors. It's much more likely that the guy with laptop open on the other side of the cafe is using Firesheep.
Re: (Score:2)
chin of trust
That would be Dudley Doright's.
Re: (Score:2)
First of all, the MITM issue will always exist. Nobody is prevented from setting up their own hotspot named Starbcuks, getting a certificate for it and sniffing whatever passes.
The first issue is, how are we managing the certificates and that is the same problem with using SSL certificates for 'identity' verification (IT'S NOT PEOPLE). How can we be sure the CA hasn't revoked the certificate if we can't connect to anything? Does it mean we have to pay big bucks for each hotspot to a Verisign-type place so w
Re: (Score:3)
Re: (Score:1)
Re: (Score:1)
So how do I know... (Score:4, Interesting)
One of the main problems with public wireless networks is that they're susceptible to a number of simple attacks, including passive sniffing and man-in-the-middle. The X-Force system is designed to get around these problems by using a digital certificate to assure users that they are communicating with the wireless hotspot that they think they are.
So... How do I get the digital certificate of the wireless hotspot that I think I'm communicating with? How do I even know which hotspot I am communicating with?
Re:So how do I know... (Score:4, Informative)
Re: (Score:3, Funny)
But... that would have required reading the article.
Re: (Score:3)
Epic.
Fail.
PKI's aren't good security, really...especially for something of this nature.
10 Risks of PKI [schneier.com]
TLS Renegotiation Attack [cupfighter.net]
MD5 Considered Harmful [phreedom.org]
And the list goes on and on and on...
Re: (Score:2)
Epic. Didn't RTFA.
Re: (Score:2)
If you're using Certs, you're using PKI- that's part of that framework.
Re: (Score:2)
Re: (Score:1, Flamebait)
Re: (Score:3)
If only we had a massive infrastructure of public entities that existed almost entirely to provide a chain of trust on digital certificates. We could call them Certificate Authorities or something.
Re: (Score:2)
Re: (Score:2)
Because your system has a hardcoded list of certificates for trusted certification authorities. These root certificates are then used by the certification authorities to sign the intermediate certificates which are used to sign the certificates issued to end user services. This is just the same as how things already work for https.
It's not a perfect system mainly because the CAs may not be as trustworthy as they should be but it should be enough to keep the low level criminals under control.
Re: (Score:2)
Someone will offer you a USB stick, and you let Windows Autorun do the rest. Perfectly secure!
VPN? (Score:2)
I assume "open, but secure" means that anyone can join, but no one can see anyone else's traffic. Isn't this trivial to achieve by giving each connection a VPN back to the wifi router?
Re: (Score:3)
But what if the Man in the Middle hosts the VPN and simply forwards your traffic to the VPN on the wifi router?
Re: (Score:2)
You're also forgetting that its simple for geeky types to use their own VPN. Its less simple for someone like my mom to use a VPN.
What about the hotel scenario? The hotel wants an open network and should have secure network. They could host a VPN, but then you have to dork around with logins and maintain it. This isn't something the hotel wants to pay for.
What IBM is trying to do is have something that is as simple as clicking on the wireless icon, finding an open or the right named network, and having it b
What the title really should read (Score:2)
"IBM To Unveil Open Wireless that is more secure than what's currently available At Black Hat"
Any wireless network is vulnerable to sniffing. It may be very much harder to attack but it's still vulnerable. As far as man-in-the-middle attacks, I'd have to read a lot more on the actual implementation to see how they address this. Digital certificates can be forged. How easy that is depends on the implementation of the certificate.
I have no doubt this is a more secure network. But security is a relative t
Re: (Score:2)
Re:What the title really should read (Score:4, Interesting)
True story. I was working on some avionics systems back in the day and there was a team running a test on a transponder in a Faraday cage in the lab. For some reason they were picking up clear transmissions from a digital radar system. Sure enough, the team on the other side of the lab was running some tests inside their own Faraday cage. Come to find out that the two cages had a common ground so they ended up transmitting between each other. If you tap into the cage ground, the cage becomes a perfect antenna. So I wonder if a Faraday cage can truly make a wireless network completely secure.
As an alternative, you could implement an additive cipher using a sufficient length one-time-use key made from truly random data each time you send a packet. I seem to remember that encryption like that was mathematically proven to be uncrackable. It's been many years since I worked on encryption systems so my memory has faded so please feel free to correct me if I have that wrong. The trouble with implementing that system though is how cumbersome it is to exchange the keys. You certainly can't do it over the network you're using. While systems like that are alright for certain applications, the key handling makes it impractical for a general purpose network. Then again, a Faraday cage makes the network less than useful too.
Re: (Score:2)
Encryption is itself vulnerable to attack too. A properly run man-in-the-middle can render your encryption completely worthless, even with public key systems that are "very hard" to crack without the private key. And there's more than one way to attack encryption. Sure, it will slow down someone. And for relatively worthless information, it is secure because no one will devote the resources to cracking it. But as the value of the information goes up, so does the willingness of someone to devote the res
Re: (Score:1)
If you were familiar at all with cryptography, you would already be aware of the fact that key strength scales exponentially. It is easy to use keys that would take millions of years to brute-force even when considering Moore's Law.
So, yeah, millions of years "will slow down" anyone. Permanently. Making your entire argument completely baseless.
Re: (Score:2)
I am familiar with cryptography. Enough to know there's more than one way to skin a cat. There's more than one way to break encryption. It's not always hard to find someone on the inside who can get access to the private key and get it out to you. All that takes is time and money. And various encryption methods over the years have been cracked by mathematicians doing some clever things to reduce the scale of a brute force attack. Is it hard? Yes. Impossible? No.
Re: (Score:2)
Not a security expert here, but this is how I think the trick is done.
Breif on public private key encryption, skip at your leisure... Most ssl connections are using a form of public private key encryption (I think). When your ssl connection requests a cert from a web page (example ibm.com), your browser pulls a copy of ibm.coms public key, encrypts the traffic, and sends it on it's way. The only one that can then decrypt the transmission would be someone that possesses the private ibm.com key.
The idea be
Re: (Score:2)
I'm certainly no expert either but I have worked on cryptographic systems a little over the years. I'm sure the system IBM developed is far more complex. There has to be additional process for the encryption beyond general public key encryption and digital certificates. Those are vulnerable to attack. I'm sure IBM did a lot to improve on things but the details were lacking in TFA. I'm curious to learn how they're doing it.
Re: (Score:2)
Re: (Score:2)
Each layer of security counters equal level of determination from the attacker. This is likely more about countering firesheep and similar script kiddie pranks at the local starbucks then defending state and corporate secrets against spies.
Secure networks (Score:2)
<sarcasm>because we all know that ethernet based networks are completely immune to this kinds of attacks</sarcasm>
Routing for whole subnets have been hijacked in the past! The solution is wide deployment of DNSSEC and HTTPS, not making inherently insecure networks secure, that is not possible in the Internet.
Re: (Score:2)
That solution is like solution to the spam problem: they need cooperation from everyone (in this case, every webserver needs to set up HTTPS), so it's almost impossible to get there.
This offers reasonable protection from common threats without requiring cooperation from everyone.
Wait (Score:2)
"For example, IBM could set up an open wireless network with the SSID 'ibm.com.' When you connect, our access point would send down a digital certificate for 'ibm.com,' and your wireless client would establish an encrypted connection with us, knowing that because the name in the certificate is the same as the SSID, the network you are connecting to must be run by IBM.
For serious? Because the SSID is ibm.com and that matches the certificate, you know its run by IBM? Isn't it more than possible to to simply name your SSID whatever the hell you want (i.e. ibm.com) and relatively easy to obtain the digital certificate to match? Simply by connecting to a real ibm.com served AP. That's prevented on the Internet because typing in www.ibm.com directs you to ibm.com, presuming your DNS can be trusted. But WiFi SSID? Absolutely nothing certifies that "ibm.com", as an SSID,
Re:Wait (Score:4, Informative)
But if you're at IBM's headquarters, and they have a big sign saying "Our public wifi network is "IBM.com" and is digitally signed" then you can be reasonably sure that you're OK. Not perfectly sure, but much more so than with current implementations. So Starbucks hangs a little sign that says "Join SSID Starbucks.com for free wifi!" Is it still possible that someone sets up a "storbucks.com" SSID and catches a few fish? Sure, but it's a Hell of a lot better than nothing. If you pay a little attention you should be much more secure than you would be otherwise.
Re: (Score:1)
Didn't read TFA, per Slashdot tradition, but the system is likely protected by the use of public key crypto.
This system is secure because you can't feasibly obtain IBM's private key. Sure, you can provide an IBM certificate, but you can't complete a key exchange or any other communications if I send it to you encrypted with IBM's public key. Likewise, in theory you can't obtain a new certificate that says that you are IBM with a public/private key that you know from a certificate authority. In practice, obt
I can probably get PublicIBMWireless.com (Score:2)
If Verisign won't do it, some other "reputable" (i.e. trusted by Microsoft OS) CA will sign it. How many users will see that and think "maybe it isn't really IBM".
To make it worse, IBM's IT probably won't want their private key on every hotspot so they will use something like publicwireless.ibm.com. I didn't read the article, so maybe they have a way to handle authentication from a central location (e.g. the ibm.com web server) rather than at each hotspot.
Re: (Score:2)
I read it as you will need to go through the same process of acquiring and utilizing key/certs from an authority. Obtaining signed certs from an authority without good proof should be very difficult. At least I hope that is the case.
Re: (Score:3)
Here's an engraved picture of Benjamin Franklin to attest to my identity. If you still doubt me, here's a picture of his brother.
Obtaining a valid certificate from one of the hundreds that are no doubt polluting your trusted root certificate store is not much harder than that.
Self signed certs? (Score:2)
I wonder who will be the first to make a soho wireless router with self signed certs.
torture test (Score:4, Insightful)
It'll be interesting to see how long their shiny new system survives in the "most hostile wireless networking environment on the planet"
Really!? (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Take it down or take it over?
Down is easy.
Pwn is NP-hard.
Original proposal (Score:1)
One additional thing the article doesn't mention - Open Secure Wireless was originally an idea proposed by Christopher Byrd, who is helping to demonstrate the technology along with IBM at Black Hat. More information about the proposal including additional details is available at http://riosec.com/open-secure-wireless [riosec.com]
Original submission (Score:1)
http://slashdot.org/submission/1241738/Open-Secure-Wireless-for-Hotspots [slashdot.org]
Why is IBM there? (Score:2)
IBM is not, in fact is the antithesis, of who I think of when I think of who might be attending a Black Hat convention.
Seriously. Just who thinks they're all badass and rebellious when they're hiring the Empire to hook up their wi-fi?
A thought (Score:1)
What if you used proper WPA2 wifi but gave dhcp subnets of like 255.255.255.255 and then specifically set it such that you couldn't get routed between users. Should be pretty secure then?
Re: (Score:2)
Well, first, the purpose of this system is to enable secure connections in passwordless networks, so setting up WPA2 defeats that.
And second, DHCP is irrelevant, sniffers aren't bound to routing rules, they capture anything that is sent. In fact, they don't even have to connect to the AP, they can just put the card in Monitor mode and capture everything in a certain channel.
Re: (Score:1)
As far as I understand WPA2 actually has a mechanism that disallows reading what is sent between each user and you need to rely on broadcasts and such to manage.
Re: (Score:2)
I don't think that exists for WPA-PSK, and using EAP requires per user credentials.
Re: (Score:1)
A device in promiscuous mode could still listen to the broadcasts, routed to them or not, also you're thinking of 255.255.255.252 (/30) netmask for point to point links, 255 would mean that there are no bits left over for the host address
Re: (Score:2)
It would make more sense to use a separate WPA2 key for each connection, but I don't see how you'd do it without using some kind of PKI.
End-to-end? (Score:2)
Why not devise better (realistic) solutions for end-to-end encryption. If I have authenticated/encrypted traffic to an end-point, then there's a limit to what information can be sniffed from an open wifi connection. If you come up with easier wifi encryption, then you still don't know what's happening once your traffic has been received by the wireless access point.
Or am I missing the point?
This technology is more than 3 years old (Score:1)
I've been running secure open WiFi networks for the past three years. Using hostapd and a patched radius server to ignore the password. I.e. the user asks for a connection, gets the certificate from the radius server through EAP, then the user is prompted for a username/password. The user is allowed to enter *any* username and *any* password, the "authentication" proceeds and simply grants access.
Presto, open WiFi, with private WPA2 encryption per client, and an SSL certificate from the access point whic
While you're at it, solve the whole problem! (Score:2)
Adoption? (Score:1)
Seems like a reasonable technical approach, but the problem is clearly with adoption.
AFAIK, IBM does not make wireless access points, and it's probably going to be hard to get the IEEE to adopt the mechanism (esp. if patented and restricted) as part of the 802.11x standards.
Looks like the team there recognizes this as a key challenge. See the bottom of this post: A new solution to wireless security issues [iss.net]