Opinion: Hackers watch for mobile opportunities

What a world. We have to fight off viruses, zombies, bots, phishing, and on and on. Can you believe how many just plain evil people there are in the world? And what is their point? Simple thievery? To prove they are smarter than the rest of us? And think of all the money that’s spent on defending, as best we can, against these miscreants or in cleaning up the mess when they get the better of us? Indeed, what a waste.

While viruses have appeared on mobile devices, they are, thankfully, few and far between. Part of the reason for this has been a lack of standardization of software environments on handsets, and part is due to the minimal functionality that is typical on these products. It’s hard for the socially challenged to overwrite boot sectors, corrupt data, or otherwise run amok on most cell phones today.

Apple’s decision to limit local software execution on the iPhone is undoubtedly due, at least in part, to a fundamental fear of hackers. While the Macintosh hasn’t been much of a target for the hacker community, the iPhone could be a lot more tempting. There will be far more iPhones than Macs in the world in just a few years. Plus, Apple partner AT&T doesn’t need the support headaches that come with having a large number of users jamming its 800 numbers with reports of bizarre symptoms on their iPhones. Regardless, being a Web services guy, I absolutely applaud Apple for moving the Web services art forward a notch or two with a very capable platform that might indeed replace PCs for many of us over the next decade or so. We don’t need to run a lot of local code to have a meaningful IT experience while on the go.

Of course, the iPhone will be hacked over time, requiring updates and fixes, just as is the case with the PC. There are already reports of hackers working diligently to unlock the phone so that non-AT&T SIM cards can be used, and to avoid cellular activation so that the device would be used only Wi-Fi networks — with VoFi services, of course. Any programmable device runs this kind of risk, and defending against unauthorized code will remain a challenge for some time to come.

Which brings me to a really obscure but very important, shall we say, “opportunity” for hackers. Last year, I wrote about one of the most exciting technology developments in wireless, software-defined radio (SDR). Basically, SDR simplifies radio hardware design by replacing specialized circuitry with software. Among the many benefits of SDR are over-the-air bug fixes, the ability to add new features on demand, and dynamic reprogrammability — turning, for example, a GSM phone into a CDMA phone or even Wi-Fi or Bluetooth or UWB or whatever on the fly.

With so much software at play here, the question has to be asked: Could an SDR get hacked? Suppose someone figures out how to build a virus that quickly spreads to SDR-based handsets, disabling them or using them as jammers or worse? What if those handsets are being used for public-safety applications? This is not to say that hacking is the only vector for wireless disruptions. After all, anyone can use a jammer to disable communications in a local area, and any moron with a reasonable shortwave transmitter can pretend to be an air traffic controller. That fact that we still use an unencrypted, unauthenticated communications protocol for such a critical service boggles my mind.

The FCC is rightfully concerned about SDR hacking and has issued new regulations for SDRs that mostly attempt to deal with open source software in SDR applications. There is significant concern that open source software creates specific vulnerabilities that hackers could exploit.

I don’t think this is very likely for two reasons. First, open source isn’t the same as open architectures. Each product vendor would of necessity keep certain elements of their implementation secret, locking out all but the most determined hackers. But secondly, and more importantly, the real issue is how to protect individual phones from ever loading harmful software. We already have pretty good techniques for this from the PC world, and there are many effective approaches to solving this particular security concern. It could even be argued that the technical scrutiny that comes with open source actually enhances security and integrity; the real issue is controlling what software, open source or not, gets onto the mobile device.

As I noted in my last column, the big issue with SDR isn’t hackers or security: It is the need to lower the power demands of SDR implementations so that they have a prayer of running on batteries. The road to SDR-based handsets isn’t at all paved yet, but open source is a relatively minor concern.