Lately, there has been a whole bunch of cities announcing plans for the creation of municipal (“muni”) Wi-Fi networks. From San Francisco and Silicon Valley to New York, Philadelphia, Toronto, and even Paris, this seems to be the hot new thing to do for cities that want to be "modern". Everyone talks about how great it will be to have network access anywhere and all the cool things you can do with that convenience. You read about all the companies who want to be part of these rollouts, and you even hear lots of noise about how it will affect ISP and telco businesses. The one thing you don't hear much about though, is the first thing that worries me: security. While the details of each rollout seem to vary (and those details are often hard to come by), there is a common set of security concerns that exists. I usually split it into four buckets: network identification, authentication, transmission security, and device security.
Network identification is the process of determining which wireless network you should join. When you decide to connect to a network, you and your computer will have a list of visible wireless networks to choose from. Here’s the catch: how do you know which one is the right one? Just because the network is called "SF Muni" doesn't mean it's the real network operated by the city of San Francisco. The person operating the access point is free to name it whatever they want. Of course, there are people who will abuse this weakness, often to implement what is called an “evil twin attack”. The general idea of this attack is that fake access points are created so that you will join up to them, thinking that they are real access points, but then the attackers operating the fake access points will use your connection details to do bad things.
Authentication is the process by which you prove to the network operator that you should have access to their network. In most cases, this means proving who you are by providing something like a username and password. Once the provider verifies that you have an account, access is allowed. There are many possible authentication schemes, each with their own strengths and weaknesses.
Transmission security refers to the work being done to secure what you're sending over the “network”; in this case, that's “over the air”. This is well trod ground in the Wi-Fi space. If you've read any news article about Wi-Fi security, then you've probably heard about people snooping wireless traffic and encrypted networks. So, the big question is, in a muni scenario, how is the wireless traffic secured to prevent snooping? If you're sitting a cafe and decide to send a credit card number to a remote site, or are sending an email containing some personal information, do you really want anyone within wireless range to be able to see that? Of course not.
Finally, I like to consider device protection, but this is often overlooked. One thing to remember is that in a wireless network other people can see you (over the network). Your computer is visible on the wireless network and there are bad people that will try to take advantage of that. Many people rely on their home or company firewall to keep them safe. When you're out on the muni network you don't have those protections, so you need to think about how to protect your computer by yourself.
Now, none of these concepts are hard to tackle per se, as we deal with them all the time in the business world. What makes them more difficult to deal with is the context of a municipal network. When your network is open to everyone, your users are "average people", and things need to be free or cheap. You don't have the crutch of an IT group next door to rely on, and things become much more complicated. For example, in a business we might use a closed, encrypted network with strong authentication for security; consider what it would take to implement that in a muni network. Is it really a "closed" network when 200,000 people know its name (SSID)? In addition, for most systems the setting up of encryption keys and provisioning strong authentication is pretty complicated, often requiring specialized IT staff. Will we have IT staff to help configure all those machines?
This entry is already pretty long, so I'll leave these ideas for you to ponder for a while. I’ll post some of the ideas we have about how to solve these problems in a future blog.