In Part 1 we covered how each of the 4 major smartphone OS vendors (iOS by Apple, Android by Google, Blackberry by RIM, and Symbian by Nokia) handle the security issues around distribution and installation of applications. In this post, I’ll dig a little deeper on the actual OS functions that need to be secured.
There are four main security features that are common to these 4 smartphone OSs:
- Process and File System Isolation: The idea is to protect apps from each other, by forcing them to run in their own context. Blackberry and Android use VMs for process isolation, while in iOS and Symbian native apps are isolated at the system level. In contrast to the desktop, smartphone apps can only read/write data in their own context. Android, with its Linux roots uses Posix file permissions to limit access. iOS uses restriction through sandbox policy files.
- App or Code Signing: Code signing involves an authority (often the app developer or OS vendor) digitially signing an app so that later it can be validated to not have been tampered with. All four major OSs use signing, but slightly differently. Android apps are self-signed, so developers sign their own apps and subsequent updates with the same key, ensuring continuity. Apple is much stricter on iOS, as apps that are not signed by Apple cannot run on iOS devices. Symbian enables signing of apps, but does not enforce how those apps are run on the platform; it is up to the platform vendor to institute a policy on the device (e.g. prompt before installing or running an unsigned app). Blackberry ties code signing to restricted API use; that is, only signed binaries can use certain APIs.
- ROM, Firmware and Factory Restore: All four OSs have a read-only portion of of memory holding the OS (i.e. the firmware), which can’t be modified by user apps. Updates are are distributed as firmware flashed onto the ROM. Android allows over-the-air updates, while others only allow updates through a desktop connection. Blackberry allows both. All devices can be easily restored to factory installed settings.
- Kill Switches: They allow remote app revocation and uninstallation and can be powerful tools. Android and iOS have kill switches that work in conjunction with their app marketplaces. Things are less clear for Blackberry and Symbian. While kill switches do provide a solid mechanism for controlling the spread of malicious software, there remains the concern that it might be abused by over-zealous vendors.
In the next post in this series we’ll cover the classification of smartphone software installation models.
Smartphone security series (4 articles):
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 1 of 4
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 2 of 4
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 3 of 4
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 4 of 4
(This series is based on an article in IEEE Security and Privacy Magazine, May 2011, by Dave Barrera and Paul Van Oorschot – http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5674007)
Good summary Mike, although you might want to point out that iOS 5, which should be released in a few weeks, will allow over-the-air updates.
More interesting though, is what are the implications (either good or bad) of each smartphone OS vendors’ approach to security. I’d like to hear your take on that.
@Eric Trepanier
Hi Trep,
Glad to know you are reading us! Parts 3 and 4 delve a little deeper into the implications, the articles have been written and will be out in a few days.
As for iOS 5 and over-the-air, I will tackle in a future post. Another reader suggested Windows mobile/phone, which I will also include.
Keep reading!