Posted
by
CmdrTaco
on Wednesday August 03, 2011 @11:41AM
from the does-it-pass-the-sniff-test dept.

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."

Yeah. It's about time we had tech like this. The WiFi vendors and standards bunch have just been screwing up for nearly a decade. Now IBM has hopefully brought WiFi up to today's standards (which aren't that great but still better than what those WiFi bunch have come up with).

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.

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.

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.

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.

yes, but on the other side of the starbucks gateway you are trusting every network that packet gets routed through anyway, every router. Unless one uses HTTPS. This is true on your private network too.

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.

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

Urm, no, one only needs the MAC address and channel. And one tends to be able to pull out the SSID out of the air even if it's hidden anyway. And can definitely pull out the MAC addresses and know what channel it's on.

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?

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.

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

"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

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.

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

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.

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.

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.

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.

Man in the middle attacks are still possible, SSL MITM attacks are possible so how could this be any more air tight. I liken this security to a bullet proof vest it will stop the small arms but when when the big guns get brought out the vest has no chance.

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.

"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,

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.

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

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.

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.

It sounds like they have chosen a reasonable venue for torture testing their new tech.
It'll be interesting to see how long their shiny new system survives in the "most hostile wireless networking environment on the planet"

Cue picture of IBM engineers scratching heads and saying "I thought you said this was secure". I hope they didn't have anything of value behind that network. Oh yeah.... their reputation. Might as well have put that in the DMZ for all the good it will do ya.

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]

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.

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

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.

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

Roaming is a pain. It' a pain to choose a closed network, a closed network with a well-known password, a passwordless open network or several passwordless networks that will redirect you to a captive portal that can ask you for different sums of money or your address and the number of your passport (true story). That is before you consider that anyone in your vicinity can configure your expected SSID and middle-man your password and everything else. Ask yourselves where you want mobile access to be in ten o