Smartphone security: an overview of security frameworks and controlled app marketplaces Part 1 of 4

With the proliferation of smartphones, third party application development is a determining factor in a platforms success. There are currently thousands of available apps, usually installed easily through some kind of on-device store. This raises obvious security concerns, as a user must be able to determine quickly whether to trust an application or not.

Concerns now arise mainly from the fact that the richer smartphone features result in much more data being stored on phones, while the phones are always on and syncing to cloud services. There is an obvious increase in the number of attack possibilities, as well as the ease with which they can be propagated.

Here is 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 these apps.

• Apple iOS: iOS applications are in Objective-C and communication with the hardware through published APIs. Similar to Mac OS X, iOS uses a sandbox mechanism – a policy file restricts access to device data and features. Developers wishing to publish apps submit them for approval to Apple. The details of the underlying process and criteria for acceptance are not own, although it is reasonable to assume that Apple employs a mix of manual and automated tests. If an app is considered suitable, it is digitally signed and distributed through iTunes. Their have been reports of somewhat cryptic and subjective rejections of application.

• Google Android: Android is an open-source Linux-based middleware (device independent API and UI) that runs on top of Linux. The applications are written in Java in Dalvik, the custom virtual machine. Each app runs as its own user, providing some process and file system isolation, as does the Dalvik machine. Of course, these can be circumvented by creating and writing libraries in C/C++ that run natively beyond the virtual machine boundaries. So, Android makes no claims that the VM provides security. Android does, however, let apps interact and use system resources based on a list of permission labels. Apps can be downloaded from the Google-controlled Android market, or directly from the developer, or even other third party marketplaces. Google has minimal involvement throughout this process, although it will remove apps from its marketplace that violate terms of use or have proven malicious activity. Key difference with iOS: no wait for external approval before making an app generally available.

• RIM Blackberry: This OS support third party apps written in Java and uses sandboxing to isolate apps at run-time through the Java Virtual Machine (jvm). Developers can distribute applications on their own, or publish them through Blackberry App World. Inclusion in App World requires approval from RIM. Blackberry goes a step further than Apple or Android in that administrators can push fine-grained policies to devices, restricting functionality available to users. For example, an admin could easily configure Blackberry Enterprise Server (BES) to only allow the download and installation of applications through App World.

• Nokia Symbian: Symbian is the grandaddy of them all, but has fallen on hard times recently as its share continues to decline. We should not forget though that this OS was built from the ground up with integrity, security and low resources in mind, unlike most of today`s smartphones. Malware targetting this platform in the past used social engineering rather than try to exploit software flaws, typical of a platform that used to be the king. While the OS requires all apps to be digitally signed, they don`t need to be signed by the Symbian foundation, which is required only for apps that modify system settings or access core OS files. Some carriers disable non-Symbian-signed certificates before the sale of the phone.

At first glance, in terms of security vis-a-vis the application installation it would seem that the application frameworks should be rated in this order, from most secure to least secure: Apple, Blackberry, Symbian, Android. It should come as no surprise that the first report of widely distributed malware on smartphones was on the Android platform. Also from the list, Blackberry should get a special nod over Apple for the additional flexibility of the BES policies.

In the next post, I`ll dig a little deeper on the actual OS functions that need to be secured.

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)

• http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5674007