Back to municipal Wi-Fi security again (I'll get onto other topics as soon as I get all of this out, I swear). There are two important things left to cover though: transmission security and device security. If you're new to this topic of muni Wi-Fi security, please have a look at some of my previous posts first, in order to catch up (Part I, Part II, and Part III).

I'll start with transmission security, which generally gets a lot of discussion. Transmission security really covers everything that you send or receive over the wireless network after you're "connected". Now...

I spoke in my previous entry about how, when using Symbian's C++ descriptors for variables, traditional buffer overflows can be turned into denial of service (DoS) conditions. Well, I thought it might be important to point out that traditional overflows can still exist in Symbian-developed software to this day. Although not recommended, Symbian does allow the inclusion of 'libc\string.h', among other headers; this allows programmers to utilize all of the unsafe “C” functions we have become accustomed to (such as strcpy, strcat, sprintf, etc.).

The subject of buffer overflows, the danger they pose, and how best to mitigate them is well documented on the Internet; so, for brevity’s sake I won't cover it here yet again. However, what I will say is that some of the research I've done at Symantec has shown that these overflows...

In a previous blog I wrote about security in municipal Wi-Fi networks and talked about what I called network identification. I wanted to talk a little more about that now. I think this is actually one of the hardest problems to deal with.

Just to recap, the problem is that when you attempt to connect to a wireless network, you do so based on the network name (the SSID). That name, however, is a very poor identifier. The administrator of the access point can name it whatever they like. So, if I want to setup an access point and name it "GoogleWi-Fi", I can. And now when anyone in range attempts to connect to a wireless network they will see one called "GoogleWi-Fi". So, how do you know who you're connecting to?

People have suggested a number of approaches. I've heard some suggestions around educating users...

I thought I'd write a blog entry around this, as it seems that it is a question that comes up a lot when speaking to press, operators, enterprises, and users alike. The common question is usually along the lines of: "Why not build security into the network to protect mobile devices?" In this case the “network” could be cellular, WiFi, WiMax, or a hybrid of technologies; “mobile devices” can be cell phones, SmartPhones, PDAs or laptops, among others.

Well, there are two reasons why a network can’t mitigate all the risks involving mobile devices. First, mobile devices today are not always connected via a network that is controlled by just one entity. For example, it is feasible (although in my experience, rare) within GPRS (2.5G) or UMTS (3G) to ensure that a roaming user's traffic never touches the home operator’s Gateway GPRS Support Node (GGSN) when the user is, say, accessing the Internet using a mobile device (this is dependent on the policies...