Apple iOS and Google Android have some big differences when it comes to mobile security, creating distinct potential vulnerabilities for enterprises embracing devices running these operating systems, according to analysis by Symantec.
In some ways, the analysis concludes, mobile security for both platforms is superior to that of traditional PCs, because both were designed from the outset with security in mind. At the same time, their security features often don't add up, yet, to the protection enterprises might need.
BACKGROUND: Smartphones and tablets create huge corporate security challenge
The report, "A Window into Mobile Device Security," was prepared by Carey Nachenberg, Symantec fellow and chief architect of Symantec's Security Technology and Response (STAR) division. An 18-year veteran of the vendor, Nachenberg oversees the technical strategy for all of the company's core security technologies and content.
"We set out to analyze the core security architecture of iOS and Android," he says. "To analyze how secure they are, their potential vulnerabilities, and [determine] what is the state of security for these devices."
Both platforms have what Nachenberg calls "traditional access control" via passwords, and both allow administrators to set password policies. Apple iOS has an edge here, because it offers more options for protecting data, such as automatically wiping a device of data after a specified number of password attempts.
One of the biggest differences between the two operating systems is their approach to what Nachenberg calls "application provenance" -- identifying, certifying and vetting an app before it's published in the appropriate online catalog.
Apple's approach currently is far more stringent than Google's, he says. Every iOS developer has to register, every submitted app is reviewed by Apple, "but how is not disclosed," Nachenberg says. Then it's published in the iTunes App Store, which acts as the certificate authority to "sign" the app, and is the only source for iOS applications (unless the iPhone or iPad has been "jailbroken," a process that lets the user then load iOS apps from any source). Apple provides an option for corporate users: a signing certificate that lets them internally distribute iOS apps to their users, without publishing them publicly in the App Store.
For Android, the approach is completely different. "In effect, Google lets you create your own [signing] certificate and public/private key pairs" says Nachenberg. "There is no vetting of apps posted on the Android Marketplace. And apps can be sideloaded from any other website."
"Apple gets the edge in this category," he says.
On-device data encryption is also different between the two platforms. Apple offers built-in hardware encryption for all on-device data. The key to unscramble the data is stored on the device, but currently it is not protected by the user's passcode. That means, Nachenberg says, that if an attacker gains physical control of the device and jailbreaks it, then "iOS is very happy to decrypt all that data for the attacker."
This makes the device "reasonably secure against the casual attacker overall," Nachenberg says.
Apple does make use of a not-well-understood secondary level of encryption, Nachenberg says. It applies to the email inbox, its contents and attachments. And unlike the hardware encryption it is only available if the user logs into the device. This is a "much more secure" encryption, he says.
By contrast, Android 2.2 and 2.3, which are currently the most commonly deployed versions, have "no encryption at all." In some recent tablets, running Android 3.0, an encryption option is available, but the user has to deliberately turn it on and it takes about an hour to run the first time, Nachenberg says.
Apple, Google tackle access control
Both platforms make use of isolation and permission-based access control. Application "sandboxing" makes use of both, for example: in effect, wrapping a policy-based security bubble around an application or some other feature.
Nachenberg says these bubbles have three parts: blocking certain actions in all cases, allowing others in all cases, and letting the user explicitly approve or disapprove of some actions. The two platforms draw the line between these in different ways.
In iOS, apps are always forbidden to read/write other apps or the OS. One app "can't even tell if other apps are running," says Nachenberg. Apps are limited in accessing the OS kernel and information on the SIM card. At the same time, all apps can perform a very wide range of actions without notifying the user at all: They can access the Internet, a range of device identifiers, the phone number, calendar events, media files, recent browser history, the microphone and video camera. All without any user prompts.
Some iOS actions do involve the user: apps wanting to send SMS or email messages or GPS location or to make a call trigger a prompt to the user who must explicitly approve the action by pressing an onscreen button.
In both iOS and Android, data associated with each application always remains private to that application.
Android has important differences. For example, an app can read the entire contents of a plug-in SD card, Nachenberg says, including any sensitive corporate data that might be on it.
By default, Android apps unlike iOS ones are blocked from accessing a battery of system services unless explicitly granted permission by the user. When the app installs, the user is given a list of permissions, for example, "will you let this app send silent SMS messages without your permission." But there's a catch, says Nachenberg. "It's all or nothing," he says. "You can't select what the app will do and not do."
So Android gives the user more control over deciding if actions are harmful or not, compared to iOS. This has to be done on a case-by-case basis.
Finally, when deployed in an enterprise, IT has to be aware of how corporate data might be able to flow from protected corporate servers and networks through the mobile device via synching to personally-owned PCs at home, with weak or non-existent security, or to relatively unprotected cloud services used by the employee. "These use cases are happening right now," Nachenberg says.
One recommendation he offers: Protect information, not devices. "What types of information can your user gain access to?" he asks. "If you limit this, it won't get onto the device in the first place."
John Cox covers wireless networking and mobile computing for Network World.
Twitter: http://twitter.com/johnwcoxnww
Email: john_cox@nww.com
Blog RSS feed: http://www.networkworld.com/community/blog/2989/feed
Read more about anti-malware in Network World's Anti-malware section.