What to do about mobile devices that lie

Much of security is built on trust, but it turns out you can’t always believe a mobile device’s claims. They can be programmed to lie about their capabilities, as in the case of several Android devices, as well as jailbroken iPhones and iPads. Thus, they can appear to conform to IT security policies managed via Microsoft’s Exchange ActiveSync (EAS) protocol even when they don’t. Two recent events show that trust may be misplaced in the mobile world.

Last week, Apple quietly dropped its jailbreak detection capability from iOS 4’s APIs, so iPhones and iPads can’t report whether they’ve been jailbroken. (Apple did not comment.) Jailbreaking, although legal, can compromise a device, allowing malware and worse into the corporate network. Indeed, the few reported cases of iPhone viruses have occurred on jailbroken units.

Also last week, InfoWorld.com discovered that Samsung’s Galaxy Tab Android tablet can connect to Exchange servers that require on-device encryption to gain access — even though, as Samsung acknowledged, the Android OS and, in turn, Galaxy Tab don’t support on-device encryption. Samsung stopped responding to our requests when we pointed out its device was doing what the company said it shouldn’t do.

The same thing happened last month when we discovered that Motorola Droid devices were accessing Exchange servers when they shouldn’t have been able to, due to similar EAS policy restrictions. Motorola promised to investigate the issue but then stopped responding to us.

By contrast, our tests show that Google’s own Nexus is truthful about its policy support, and Google publishes a list of the EAS policies supported (PDF) so you can know what behavior to expect from Android devcies and thus identify those that may be lying. Note that because Android is open source, device makers could modify their mail or other clients to include encryption in their workspaces — or use third-party clients that do, such as NitroDesk Touchdown, IBM Lotus Notes Traveler, Good for Enterprise, and MobileIron MyPhone@Work.

So I have to suspect that Samsung and Motorola’s devices aren’t accurately reporting to Exchange the policies they in fact support. Perhaps some rogue developer or contractor thought he or she was being smart by getting around the EAS policy requirements. No matter: It feels as if maybe some in the Android community are abusing the trust that EAS requires to be effective — and such behavior could cause businesses to distrust all Android devices on their networks and ban the whole lot.

If I were Google, I would use its trademark on the Android name and logo to force Android device makers to be honest or else lose the ability to use the Android name in their marketing. (Because Android is open source, Google can’t prevent people from using the OS, but it can control the use of the trademark.)

The uncomfortable truth is that there’s no easy way to make sure a device is being honest about its capabilities. Any software feature can be hacked, which is likely why Apple pulled the jailbreak detection from iOS 4 — after all, a jailbroken iPhone is a hacked iPhone, and that hack could easily include a false status indication that it had not been compromised. It’s better not to pretend you know the truth when you can’t say for sure.

Devices need not be hacked to lie. In 2009, Apple’s iPhone OS 3.0 OS incorrectly reported Exchange ActiveSync policy compliance due to a software bug, for example. When iPhone OS 3.1 shipped, the bug was quietly fixed, so truthful iPhones suddenly stopped connecting to Exchange servers, taking users and IT by unhappy surprise.

There is a way to detect devices that are lying about their capabilities. Google is using it in the forthcoming Chrome OS laptops: an encrypted hardware module that can’t be hacked. The technology, called Trusted Platform Module (TPM), has been around for years and is used in some laptops — particularly those in the defense industry. In order to work, device management software needs to have access to the device’s read-only status through the operating system, to compare the safeguarded actual state against the device’s software-reported state.

Conceivably, all the mobile device makers could agree to implement TPM in some common way, providing an API-level tool that could not be hacked to lie. That’s unlikely — and it hasn’t happened in the world of laptops, which are much more widely deployed and tend to hold gobs of potentially sensitive information.

Another approach is to have a secure client run on a device with its own encrypted “real state” information that a management tool can then compare against the device’s reported state. That’s how mobile device management tools such as MobileIron’s detects jailbroken iPhones even without Apple’s jailbreak-detection API. Network access controllers (NACs) have used a similar approach for years.

As for the problem of lying Androids that weren’t jailbroken but somehow shipped from reputable manufacturers, the use of a client app that coordinates with a server tool can also work to detect the liars. In fact, that’s how several mobile management tools catch such lies.

In the case of Android, there’s an even simpler way to block lying devices: compare the known capabilities of a device to the ActiveSync policies at the server end, rather than worry about what the device is reporting. Again, mobile management tools use that technique — though Exchange by itself does not. The flaw in this approach is that it requires the mobile management vendors to keep their profiles updated for all supported devices, and for IT to keep its systems updated accordingly; as anyone who handles security patches and antivirus definitions knows, this is not so easy to do.

As you can see, the lie-detection techniques aren’t simple or consistent; as more devices connect to corporate resources, there’s a greater chance some of them are lying about compliance. IT can reduce the risk by spending money on mobile device management tools. IT can simply disallow risky classes of devices (such as all Androids) from access to corporate resources despite the furor that will cause. IT can turn a blind eye to the devices and focus instead on in-the-network detection of malware and internal access controls based on user authorization, or it can try a mix of these approaches. There’s no easy answer — just like in any security endeavor.

This article, “What to do about mobile devices that lie,” was originally published at InfoWorld.com. Read more of Galen Gruman’s Mobile Edge blog and follow the latest developments in mobile technology at InfoWorld.com.