This is the final post in a three-part series on smartphones and information security. The series has covered overall security of the BlackBerry, Apple and Android mobile operating systems.
Continuing from our earlier posts on the advantages and challenges of the Blackberry and Apple iOS, we are concluding with Google’s Android operating system (OS).
Android is a Linux-based open-source platform whose unified progress is sponsored by Google. Android Inc. developed Android OS circa 2004 and was purchased by Google in 2005. The OS caught on like wild fire and is used by literally dozens of companies who are creating tablets, phones and myriad other form factors around it. Despite competition from Apple and Blackberry, 2010 was a huge year for Google. With more than 250,000 apps available on the Android Market, the platform saw an 861 percent increase in app sales.
Additionally, customer intelligence firm Market Force Information recently released findings from a survey on smartphones, which indicated Android’s current appeal over its competition. According to a Feb. 22, 2011 Market Force press release, “When asked which smartphone they would purchase, 34% of survey respondents said Android, while only 21% said iPhone, and 12% said Blackberry.”
Android OS Security Concepts
A major aspect of the Android security model resdies in the interface of the platform’s OS application layers and is implemented by running each application in its own efficient Dalvik virtual machine.
From the end user's perspective the effect is quite similar to sandboxing in Apple’s iOS. Each application’s default view of the device is that it has the entire device to itself, i.e., unless it is explicitly permitted to see other apps, its default view is that it is the only application on the device.
How this works is that when a developer is coding and packaging an application, they must declare what device resources, e.g. GPS, Bluetooth, W-Fi, etc. the application needs to use. This is necessary to build the application but that information is then also used when the end-user installs the app! This user notification takes the form of an install-time dialog that indicates the list of resources needed on the device to run that application. So, depending on what resources are listed, the user can either accept, or refuse, installation. For example, if you can’t figure out why the first person shooter game “I Spy On U” wants access to the GPS information on the phone, then you could simply terminate the installation.
Android vs iPhone – Swiss Army Knife vs Sabatier Fine Cutlery
The Android environment is much less centrally controlled than Apple’s iOS. For example, users can skip the Android Market altogether, and download an application directly from a developer’s web site. Of course, you do so at your own risk. The developer might have bad intentions or, if the developer’s download server has been compromised, and his downloads tampered with, you may be getting “more than you bargained for”. Many Android fans suggest that the healthy skepticism that the Android openness encourages is the only sane default attitude and that Apple users dangerously naïve to believe that “because it came from iTunes App Store it must be safe and well-behaved.”
Incidentally to take complete and utter control of your Android device from the carrier you will need to “root” the phone. “Rooting” is the equivalent of jailbreaking an Apple iOS device, which, as described in the iOS edition of this blog, pretty much lets the end user do anything the hardware is capable of.
Android Virtual Phones
Improving upon the user and developer experience with Android, virtualization software company VMware has created a new offering that changes the platform interface, called Mobile Virtualization Platform (MVP).
MVP is similar to the Dalvik VMs of Android; however, whereas the virtual machine presented by Dalvik is an idealized JVM-like set of resources, the VMware VM is more like a thin layer of virtualized hardware implemented as a so-called hypervisor. This allows a carrier or end-user to install multiple virtual phones! E.g., on a phone model sold by multiple carriers or by one carrier with multiple versions – like an HP phone that runs either WebOS or Win 7 Mobile – if there was a version of the MVP hypervisor for HP mobile phone hardware, one could run both a Win 7 Mobile and a WebOS phone instance on the same hardware at the same time and “flip” between them. The Win 7 and WebOS phones don’t even “know” the other personality is resident on the same hardware. This example is hypothetical but intriguing.
These “guest virtual phones”, running atop the MVP hypervisor, look and act like full-fledged phones! Besides being interesting technology, VMware’s mainstream concept is that a device owner can have one phone with multiple “personalities” – like a work phone and a personal phone but on a single handset. With this ability, a corporate IT department could manage the “work phone,” while the owner could have complete control over the personal side. The MVP platform is mature to the point of being released for some of the most popular phone hardware and it only remains for the phone manufacturers and carriers to embrace it.
What has your experience been?
Have you experienced any issues with your Android device? Have you felt the need to “root” the device? If so, what drove you there; curiosity, annoying carrier apps which you couldn’t delete? How many apps have you installed? Did you get them straight from the developer’s site or the Android Market? Have you ever refused application installation because of the resource the app was asking to use? We’d like you to share your thoughts and questions with us.
Check out the other posts in this series, and stay tuned for more posts on information security with the leading smartphone operating systems:
----------------------------
John Brady is an Information Security Architect Engineer at Westfield Insurance. Sharing Knowledge. Building Trust.
IMAGE SOURCE: http://www.flickr.com/photos/osde-info/4623612094/