Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IBM To Unveil Secure Open Wireless At Black Hat

CmdrTaco posted more than 3 years ago | from the does-it-pass-the-sniff-test dept.

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

cancel ×

91 comments

Sorry! There are no comments related to the filter you selected.

Welcome to the early 90s (0)

Anonymous Coward | more than 3 years ago | (#36974182)

They've been working on a system for a while to mimic technology that already exists and can already be purchased Best Buy. Solid work IBM. Digital Certificates! Who would'a thought of that!

Re:Welcome to the early 90s (-1)

Anonymous Coward | more than 3 years ago | (#36974204)

Hey, cumstain. Go die in a fire.

I could be wrong but... (2)

dragon-file (2241656) | more than 3 years ago | (#36974222)

Isn't a non broadcasting SSID technically secure? I mean devices will still see the network, but without the SSID of the router, accessing it becomes impossible right?

Re:I could be wrong but... (2)

BlueMikey (1112869) | more than 3 years ago | (#36974290)

A public wireless hotspot isn't meant to be inaccessible.

Re:I could be wrong but... (1)

TheLink (130905) | more than 3 years ago | (#36974740)

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.

Re:I could be wrong but... (3, Interesting)

Desler (1608317) | more than 3 years ago | (#36974322)

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... (4, Informative)

TheRaven64 (641858) | more than 3 years ago | (#36974356)

No, not at all secure. You just need to sniff the traffic that nodes that know the SSID broadcast and you can connect.

Re:I could be wrong but... (1)

icebraining (1313345) | more than 3 years ago | (#36975300)

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... (4, Interesting)

DrgnDancer (137700) | more than 3 years ago | (#36974416)

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:I could be wrong but... (2)

ewanm89 (1052822) | more than 3 years ago | (#36974636)

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.

Re:I could be wrong but... (1)

DrgnDancer (137700) | more than 3 years ago | (#36974766)

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:I could be wrong but... (1)

Anomalyst (742352) | more than 3 years ago | (#36975746)

chin of trust

That would be Dudley Doright's.

Re:I could be wrong but... (1)

guruevi (827432) | more than 3 years ago | (#36977228)

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 we can assure our customers? If we want to roll our own, will clients be prevented or otherwise inconvenienced or scared away from connecting? When we have to start trusting CA's, how trustworthy are they to begin with and how trustworthy should they be? How can I trust any certificate or "open" wireless network being presented to me if I haven't been communicated the certificate or a password beforehand?

The second issue is, how are we sure any of the routers downstream of our connection are trustworthy? This will give people a false sense of security and will be abused. The best way to authenticate is still WPA2-Enterprise even for public networks if you want it to be secured, just give individualized tokens. Otherwise, leave the connection open and clients should be responsible for their own end-to-end encryption.

Re:I could be wrong but... (2)

ewanm89 (1052822) | more than 3 years ago | (#36974622)

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.

Re:I could be wrong but... (0)

Anonymous Coward | more than 3 years ago | (#36974940)

Kismet has supported finding "hidden" SSIDs by sniffing client traffic for many years. I'm sure any number of wireless sniffers support the same feature. If you think you're secure by not broadcasting the SSID from even the most trivial attack (below script kiddie level), you're mistaken.

Re:I could be wrong but... (1)

alienzed (732782) | more than 3 years ago | (#36975078)

Just as you guessed, you're wrong.

Re:I could be wrong but... (1)

dragon-file (2241656) | more than 3 years ago | (#36975342)

Yea, every time i guess that im wrong, I'm usually right.

So how do I know... (3, Interesting)

camperdave (969942) | more than 3 years ago | (#36974230)

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... (-1)

Anonymous Coward | more than 3 years ago | (#36974286)

Obviously through osmosis. Fucking hell, are you fucking cumstains so unimaginative that you can't think of any possible means of giving someone the certificate securely?

Re:So how do I know... (3, Informative)

phantomfive (622387) | more than 3 years ago | (#36974298)

Use a domain name as the SSID, and use the existing certificate framework that your browser currently uses. At least, that is the solution mentioned in the article.

Re:So how do I know... (3, Funny)

Anonymous Coward | more than 3 years ago | (#36974344)

But... that would have required reading the article.

Re:So how do I know... (2)

Svartalf (2997) | more than 3 years ago | (#36974472)

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:So how do I know... (1)

postbigbang (761081) | more than 3 years ago | (#36974552)

Epic. Didn't RTFA.

Re:So how do I know... (0)

Anonymous Coward | more than 3 years ago | (#36974590)

Yes, you sure did fail pretty epically there, since not one of your links supports the retarded accusation that "PKI's aren't good security". The first really just clarifies some common misconceptions about how PKI works, but certainly doesn't propose you don't use it. The second deals with a very minor issue related to TLS, a system that uses PKI, but is not in and of itself PKI any more than I am car simply because I use one. And the third appears to deal with MD5 (not about to open some shady powerpoint); assuming that your link and the file name are accurate, I don't really get why you posted it.

Re:So how do I know... (1)

Svartalf (2997) | more than 3 years ago | (#36974644)

If you're using Certs, you're using PKI- that's part of that framework.

Re:So how do I know... (0)

Anonymous Coward | more than 3 years ago | (#36974676)

Great, but the link you mention didn't say NOT to use PKI.

Re:So how do I know... (1)

ewanm89 (1052822) | more than 3 years ago | (#36974690)

probably because x.509 certs used to use MD5 for their signature hashes, however as they use SHA1 mostly now, and if they don't change your certificate/certificate authority.

Re:So how do I know... (1, Flamebait)

DoomHamster (1918204) | more than 3 years ago | (#36974358)

Just download and install the certificate with the cn of "Linksys". How hard can that be?

Re:So how do I know... (2)

DrgnDancer (137700) | more than 3 years ago | (#36974442)

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:So how do I know... (1)

camperdave (969942) | more than 3 years ago | (#36977450)

Since the access point is intercepting and transmitting all traffic, how do I know I'm communicating with the *REAL* Certificate Authorities vs one that's being spoofed?

Re:So how do I know... (1)

petermgreen (876956) | more than 3 years ago | (#36979076)

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:So how do I know... (0)

Anonymous Coward | more than 3 years ago | (#36982104)

> Since the access point is intercepting and transmitting all traffic, how do I know I'm communicating with the *REAL* Certificate Authorities vs one that's being spoofed?

because your browser and/or operating system comes with a list of certificates for the Certificate Authorities that "you" trust by default. A rogue access point giving you fake DNS results or routing your packets somewhere else still won't be able to give the correct cryptographic signatures to match the root signing certificates that you allow.

Re:So how do I know... (1)

suomynonAyletamitlU (1618513) | more than 3 years ago | (#36975524)

Someone will offer you a USB stick, and you let Windows Autorun do the rest. Perfectly secure!

VPN? (1)

Hatta (162192) | more than 3 years ago | (#36974256)

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:VPN? (2)

psyclone (187154) | more than 3 years ago | (#36974280)

But what if the Man in the Middle hosts the VPN and simply forwards your traffic to the VPN on the wifi router?

Re:VPN? (0)

Anonymous Coward | more than 3 years ago | (#36974328)

I don't think you really know what a VPN is. VPN is network/transport layer (the N stands for network). This is the data link layer. A VPN can be used to secure transport across an insecure data link, but it doesn't operate at the link level.

Re:VPN? (1)

NevarMore (248971) | more than 3 years ago | (#36974438)

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 be reasonably secure.

What the title really should read (1)

grimmjeeper (2301232) | more than 3 years ago | (#36974318)

"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 thing. There is (almost) no such thing as a completely secure wireless network.

Re:What the title really should read (1)

ArhcAngel (247594) | more than 3 years ago | (#36974534)

Except for one in a locked Faraday cage.

Re:What the title really should read (3, Interesting)

grimmjeeper (2301232) | more than 3 years ago | (#36974664)

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:What the title really should read (0)

Anonymous Coward | more than 3 years ago | (#36979528)

So...
To make the wireless system secure, you want to wire the grounds together? How is that wireless?

Re:What the title really should read (0)

Anonymous Coward | more than 3 years ago | (#36974646)

Properly encrypted networks are not vulnerable to sniffing - not unless you count seeing worthless ciphertext as "sniffing."

Re:What the title really should read (1)

grimmjeeper (2301232) | more than 3 years ago | (#36974772)

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 resources to cracking it.

Re:What the title really should read (1)

Anonymous Coward | more than 3 years ago | (#36974982)

Sure, it will slow down

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:What the title really should read (1)

grimmjeeper (2301232) | more than 3 years ago | (#36975102)

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:What the title really should read (1)

YojimboJango (978350) | more than 3 years ago | (#36974760)

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 behind this new wireless is that when your computer requests access to a public open network, that network can say, "Ok, send me all your data encrypted with the public key from trustyCo.com". From there you'd need access to the private key for trustyCo.com to read anything you send out. Presumably then, the only one able to read your data would be trustyCo, and it would be up to them to decrypt your traffic and send it out to the internets. The actual point isn't that it protects you by encrypting your traffic though, the point is in that the only one you can communicate with is TrustyCo, not every random script kiddie with firesheep installed sitting within 150 ft of you.

It's probably more complex than that, as I'm pretty sure it wouldn't take a team of IBM nerds years of development to do it if it were that simple, but the basic principal probably holds true.

Re:What the title really should read (1)

grimmjeeper (2301232) | more than 3 years ago | (#36974924)

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:What the title really should read (1)

jimbolauski (882977) | more than 3 years ago | (#36976504)

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.

Re:What the title really should read (1)

hitmark (640295) | more than 3 years ago | (#36983486)

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 (2)

Tomato42 (2416694) | more than 3 years ago | (#36974384)

> susceptible to a number of simple attacks, including passive sniffing and man-in-the-middle.

<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:Secure networks (0)

Anonymous Coward | more than 3 years ago | (#36974424)

Wait, your assuming that either the article writer, the person submitting the summary or CmdrTaco actually know this? lol you must be new here.

Re:Secure networks (0)

Anonymous Coward | more than 3 years ago | (#36975220)

Using the OSI Model, you just said Wireless LAN can never be secure [Layer 2 (Data Link)], we need wide deployment of DNSSEC and HTTPS [Layer 7 (Application)].

Given that Wireless LAN is infinitely less secure than Wired LAN (1 Watt wireless single antenna, vs 1 watt 8 wires next to each other causing radio interference), wouldn't it make sense to make layer 2 equally secure?

Re:Secure networks (1)

icebraining (1313345) | more than 3 years ago | (#36975384)

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 (1)

Baloroth (2370816) | more than 3 years ago | (#36974434)

FTFA:

"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, directs to anything run by IBM, in any way. And unless they are using some different system of certificate management, obtaining the public digital certificate is trivially easy. All this will do is make it look like untrustworthy APs are trustworthy. And that is very bad.

Is there any way at all in which such a system gives anything but the illusion of security?

Re:Wait (3, Informative)

DrgnDancer (137700) | more than 3 years ago | (#36974510)

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:Wait (0)

Anonymous Coward | more than 3 years ago | (#36984470)

Basically what they do is send you a cert when you connect to the hotspot, and if the name of the hotspot matches the name in the cert you're supposed to assume it's legit.
There is an unspoken assumption that your computer has to be able to tell if the certificate itself is valid, however. Which means you either have to pre-share the cert, or somehow verify it with a 3rd party which just brings us back to square one since you have to trust the hotspot to take you to the REAL cert authority.

And on the linked article, one of the comments already pointed out what I was going to say: You can already do something better yourself, it just takes a lot more work.

Re:Wait (1)

bgt421 (1006945) | more than 3 years ago | (#36974520)

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, obtaining a valid certificate is much less difficult than it ought to be.

Re:Wait (0)

Anonymous Coward | more than 3 years ago | (#36974532)

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?

You are forgetting the certificate authority in the chain. If you have a decent certificate authority (ha ha), you can be sure that only IBM is issued the ibm.com certificate. That it is signed by a reputable CA, and is issued for ibm.com, assures that it is indeed run by IBM.

I can probably get PublicIBMWireless.com (1)

a2wflc (705508) | more than 3 years ago | (#36974840)

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:Wait (0)

Anonymous Coward | more than 3 years ago | (#36974564)

You have absolutely no idea how certificates and chains of trust work, do you? Go read up on that, then come back and make a less stupid comment. How do you expect to get a digital certificate to match ibm.com from a trusted source? If you connect to an SSID that says ibm.com, it had better respond with a certificate from a trusted source that says it is indeed ibm.com.

Re:Wait (1)

sgt scrub (869860) | more than 3 years ago | (#36974674)

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:Wait (2)

plover (150551) | more than 3 years ago | (#36974848)

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.

Re:Wait (0)

Anonymous Coward | more than 3 years ago | (#36975538)

Is there any way at all in which such a system gives anything but the illusion of security?

Not to people who don't know how public-key cryptography works, like your fucktarded ass. Try learning about it next time BEFORE posting pointlessly clueless drivel.

Re:Wait (0)

Anonymous Coward | more than 3 years ago | (#36977328)

Uh, you're being quite dense, perhaps on purpose? If so, IHBT, IHL, etc. But maybe you're really so thick you think A) DNS is secure and B) SSL depends on that security.

It's relatively easy to hijack DNS and/or routing for a few people, so SSL is designed to prevent that attack. If you encrypt shit with IBM's public key, and then send it to a fake-IBM, how can they decrypt it without IBM's private key?? Of course that doesn't matter if you replace "obtain the digital certificate to match? Simply by connecting to a real ibm.com served AP" with "obtain a digital certificate claiming you are ibm.com but using your own public key, simply by contacting a fraudulent or negligent CA" -- which happens with alarming regularity. But if/when we fix the well-known issue of completely untrustworthy CAs for SSL, we'll have this one whipped too.

Self signed certs? (1)

sgt scrub (869860) | more than 3 years ago | (#36974594)

I wonder who will be the first to make a soho wireless router with self signed certs.

torture test (3, Insightful)

kent_eh (543303) | more than 3 years ago | (#36974600)

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"

Really!? (1)

shoehornjob (1632387) | more than 3 years ago | (#36974624)

Anyone want to take bets on how long it takes for a room full of black hats to take this thing down?

Re:Really!? (1)

courteaudotbiz (1191083) | more than 3 years ago | (#36974742)

5 minutes! I bet a grand on 5 minutes!

Re:Really!? (0)

shoehornjob (1632387) | more than 3 years ago | (#36974898)

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.

Re:Really!? (1)

blair1q (305137) | more than 3 years ago | (#36974880)

Take it down or take it over?

Down is easy.

Pwn is NP-hard.

Original proposal (1)

techy (23032) | more than 3 years ago | (#36974672)

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]

Why is IBM there? (1)

blair1q (305137) | more than 3 years ago | (#36974876)

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?

Re:Why is IBM there? (0)

Anonymous Coward | more than 3 years ago | (#36976536)

Actually, ISS was previously a dot-com-era startup that got bought up by IBM. They're still relatively independent in terms of their day-to-day work, and still have a (little) bit of that casual, freewheeling dot-com culture. There's kind of a low-intensity culture clash between them and the rest of IBM, from what I've seen.

Re:Why is IBM there? (0)

Anonymous Coward | more than 3 years ago | (#36986376)

Not for long... most talent has left already, rest is on the way out.

Re:Why is IBM there? (0)

Anonymous Coward | more than 3 years ago | (#36989728)

IBM is not hands-off with ISS.. IBM clobbered almost everything about ISS. This just looks like X-Force is now on the same patent treadmill that IBM puts all their engineers.

A thought (1)

munky99999 (781012) | more than 3 years ago | (#36975004)

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:A thought (1)

icebraining (1313345) | more than 3 years ago | (#36975462)

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:A thought (1)

munky99999 (781012) | more than 3 years ago | (#36976446)

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:A thought (1)

icebraining (1313345) | more than 3 years ago | (#36977514)

I don't think that exists for WPA-PSK, and using EAP requires per user credentials.

Re:A thought (1)

someSnarkyBastard (1521235) | more than 3 years ago | (#36975674)

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:A thought (1)

hawkinspeter (831501) | more than 3 years ago | (#36975732)

Wireless doesn't really have any "routing" between the client and the hotspot - it's just broadcast!

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.

Redundant? (0)

Anonymous Coward | more than 3 years ago | (#36975188)

Do we really need wireless security standards? The option of using an encrypted tunnel on top of the wireless connection has been around since forever, is far more flexible in terms of security and makes WEP, WPA etc effectively redundant.

wpa-eap (0)

Anonymous Coward | more than 3 years ago | (#36975982)

Isn't what does wpa-eap ?

SlyFi (0)

Anonymous Coward | more than 3 years ago | (#36976538)

http://tw.seattle.intel-research.net/index.php?title=SlyFi

End-to-end? (1)

nine-times (778537) | more than 3 years ago | (#36976698)

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?

Re:End-to-end? (0)

Anonymous Coward | more than 3 years ago | (#36993120)

I think you are. There is already a realistic end-to-end encryption system and you've been using it for years. It's called SSL. I think the idea of this is to stop eavesdropping on open wifi, useful when accessing content that doesn't give you a secure option. Sure with this someone could still listen-in between the router and the end-point, but that someone would have to have access to one of the intermediate routers to do that, this does at least make it a lot harder for a man on the street to listen-in to your 'net traffic.

This technology is more than 3 years old (1)

BuGless (31232) | more than 3 years ago | (#36976926)

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 which can be validated against. I don't know what IBM et al have been doing, but this is readily available tech (patching the radius server was/is not exactly rocket science) and it works since 2008, and it certainly is nothing exciting to get all fussy about at a black hat conference.

I see that they have a patent pending; this must be a joke (then again, the whole software patent system is a joke).

While you're at it, solve the whole problem! (1)

Lorens (597774) | more than 3 years ago | (#36978600)

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 or twenty years. Answer: hassle-free. You may want to choose your hotspot based on performance or price or simply because it's yours, but roaming far from home in an era of not-quite-ubiquitous Internet, you most probably just want one that works.

Redesign authentication using client certificates so that the user's ISP can authenticate the user directly for any hotspot. The hotspots would simply keep a list of approved CA certificates. You'd insert the name of the ISP's authentication servers into the ISP CA certificate into the client certificate.

You could add in a option for mandatory VPN direct to the ISP. It could be made mandatory by the user or by the hotspot. The hotspot provider would then not have to keep user logs and worry about responsibility and source ports and otherwise identifying abuse. The user would have his VPN, his own IP address, could roam almost seamlessly over hotspots belonging to different owners, and would not care about choosing the hotspot based upon the confidence that the hotspot operator will not sniff or use a sniffable upstream.

You could add in a fee (advertised through the SSID?) that would be put on the user's ISP bill and transferred to the hotspot operator. The ISP would need the address to send the money, but that can also be put in the authentication procedure. If the connection is mandatory VPN there can't even be disputes about the amount to bill, since the hotspot and the ISP should have the same amount.

Adoption? (1)

bouldin (828821) | more than 3 years ago | (#36985848)

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]

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>