Internet Security Systems - AlertCon(TM)

A new solution to wireless security issues

Posted by Tom Cross and Takehiro Takahashi on October 27, 2010 at 12:43 PM EDT.

Eric Butler’s Firesheep plugin for Firefox has kicked off a firestorm of discussion. It’s a pretty nicely designed demonstration of the security risks that you face when you connect to open wireless networks. The plugin displays all of the potential victims who are using the wireless network you are connected to and gives you one click access to their accounts on services like Facebook and Twitter. The release of this tool has resulted in renewed warnings about open wifi as well as calls for greater use of HTTPS by websites.

X-Force Research has been working on a more fundamental solution to these problems and this blog post is the first time we’ve ever discussed our approach on the Internet. Wifi network security is a hobson’s choice. You can either set up an open access point with no security at all that anyone can access, or you can set up an encrypted access point, but people have to have a password or other credential setup with you beforehand in order to access your access point. There is currently no secure way to set up an open access point that has encryption and authentication of the network provider. We think it’s possible, and we call it Secure Open Wireless Access.

If you think about how HTTPS works, you’re establishing an encrypted connection to a website, but you don’t have to have a password set up with that website in order to establish that encrypted connection. The security of an HTTPS session comes from the fact that the website you are connecting to presents a digital certificate, signed by a trusted third party certificate authority, demonstrating that the website you are connecting to legitimately controls the domain name you are trying to reach.

You can do the exact same thing with wireless networks. In our proposal, wireless networks would establish encrypted connections with their clients by presenting a digital certificate demonstrating that the operator of the access point is the legitimate user of the SSID associated with that access point. You could even use domain names as SSIDs and use off the shelf SSL certificates.

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.  

The result would be that when you open up your wireless client you could establish secure, encrypted connections to networks operated by people (or companies) that you trust, knowing that those networks are really operated by the people (or companies) that they claim they are operated by without needing to have a password.

We’ve been thinking about this for a long time, we’ve looked at it from a lot of different angles, and we’re pretty sure it would work, and that it would not interfere with any legitimate thing people are doing with wifi today. Unfortunately the process associated with moving from an idea like this to an actual implementation in real networks can be frustratingly slow. We have a patent pending and we have a paper with a complete technical discussion that we have been trying to publish. The wheels of the peer review machine turn slowly, but hopefully we will publish our paper within a few months and you will read about it here.
 
However, publishing a paper is not enough to get this idea into your laptop. If you are reading this post and you are a certificate authority, wireless access point manufacturer, wireless client software developer, or wireless network operator, and you’d like to understand this idea in more detail, please get in touch with us. We would like to see this idea become a reality.  If you can help, let’s talk.

Comments or opinions expressed on this Weblog are the opinions of the authors alone. They are not necessarily reviewed in advance by anyone but the individual authors, and neither IBM Internet Security Systems nor any other party necessarily agrees with them. The views expressed by outside contributors and links to outside websites do not represent the views of IBM Internet Security Systems, its management or employees. All content on this Weblog has been made available on an “as-is” basis, and IBM Internet Security Systems shall not be liable for any direct or indirect damages arising out of use of this Weblog.