Security: Android vs. iOS

I started working on getting my masters recently.  Here is a paper I wrote for my network security class.  I figured I’d be lazy and re-use it as a post.  I apologize for any weird formatting.  Hope you enjoy…

Security: Google Android vs. Apple iOS


In this paper I will compare and contrast the security models of the Google Android and Apple iOS operating systems. Specifically I will examine how applications are developed and accepted, how permissions are granted, and what kind of threats are imminent to these operating systems. Then I will explore various defenses that are available to consumers now or that may be available in the future.

I. Android Security Model

The Android platform is built on the Linux kernel, and on top of the Linux kernel is a virtual machine called the Dalvik Virtual Machine. This virtual machine is what allows each Android application to run in a “sandbox,” meaning all applications are run in silos that can’t access other applications. Any application that needs to access system services, uses the built-in Android APIs to do so. Upon installation, each app is assigned a User ID that allows for standard Linux file access rights.

On top of all this, Android uses a permissions-based security model as another layer of security. When a user goes to download a certain app found in the Android Market, he will be prompted by the system to allow the app certain permissions. Android is supposed to follow a least-privilege security model.

However, even though a least-privilege model is used, the access permissions are left up to the developer, which can lead to unnecessary permissions being granted. Third-party developers are free to upload most apps to the Market without any review. Because Android permissions documentation is fairly limited, developers often give too many privileges to an app. Other reasons why apps might be over-privileged include the developer requesting permissions that merely sound liek they are necessary, even though they aren’t; some apps also request permissions that they don’t need because the systems uses the API to call dependent programs that already have the necessary permissions. In other occasions, developers request permissions that may have been necessary on older versions of Android, but are no longer needed.

Researchers have used a tool called Stowaway to find unnecessary privileges in a sample of applications downloaded from the Android Market. They found that about one third of apps were assigned unnecessary privileges. Although many of these privileges were deemed unnecessary, researchers know they won’t cause any harm or information leakage either.

Although Android does require user permission to install an app, it is an all-or-nothing scenario. There is no granularity in the permissions granted to the app. Thsi constant notification of whether to allow access to apps may condition the user to blindly accept the permissions without knowing what he has agreed to, thereby rendering permissions queries somewhat useless.

II. iOS Security Model

Apple iOS has basically taken the opposite route with its security model in comparison to Google Android. Instead of asking for user’s permission upon install of an app, iOS grants full access to all smartphone services by default.  iOS also has a Security Server that implements several security policies built in. The Security Server manages access to key chains and root certificate trust management.

Another way iOS manages security is by the app submittal process. A developer must submit his app for review by Apple developers. About 95% of all apps submitted to the app store that are approved, are given this status within a couple of weeks.  Apple rejects about 20% of apps upon their first submittal, mostly based on software bugs found by the reviewers.

Apple also has application guidelines and contracts developers must follow in order to have their apps published. For instance, Apple gives all the developers the same software suite to create their apps. Some other guidelines include:

• “Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used. Apps that require users to share personal information … in order to function will be rejected.”

• “Developers who create apps that surreptitiously attempt to discover user password or other private data will be removed from the iOS Developer Program.”“App Store Review Guidelines.”

III. iOS vs. Android

It’s hard to compare the iOS and Android operating systems because they use seemingly opposite security models. Android gives the end user more control by using permissions notifications, and iOS boasts of (what they claim to be), rigorous reviews of apps that have been submitted by developers. One can cite evidence against these claims, however.

Recently a researcher was removed from the App Developer program for proving that it’s possible to get a trojan through the approval process and then notifying Apple of this exploit.  It can also be noted that Apple’s approval process is somewhat unclear. One can question how many checks could be put into place during the average two week review. It seems that reviewers could check the identity of the developer and find easily located software bugs, but can they really catch every piece of malware that might be hidden? Do they lose incentive to really search since these apps are submitted by people in the Developer Program? Especially because all apps downloaded from the app store have full access to the device, this could prove to be a major security flaw.

On the flip side, Android has a very open model; after all, it is based on Linux. Although they do utilize user permissions, Android users often ignore the warnings, and there are many over-privileged apps available. Android is also now the most widely used smartphone operating system, which makes it a larger target. Android malware is up about 427% in the last six months. Also, Android apps have no central certification authority (CA). All certificates come from the developer of an app, which could potentially be a self-signed certificate that is not security. Apple handles app certificates by using a centralized CA through iTunes.

Both Android and iPhone smartphones can be remotely wiped and/or encrypted. iPhone actually has built-in capabilities to do this, but an app can be downloaded for Android to have similar capabilities.

IV. Known Malware and Threats

Several malware instances have attacked Android phones (as noted earlier, malware is up 427% on Android), and one of the more prominent ones is the AnserverBot Trojan. The AnserverBot Trojan attaches to legitimate applications and rebuilds them. This trojan has several layers, one being that it can check the signature of the rebuilt packages, and it’s believed that this will make it impossible to tamper with or analyze the newly infected app. The AnserverBot can also detect some anti-virus software and disable it. It has two different payloads, and the second payload can make a call to the server to make the device part of a BotNet network.

iPhone has also seen security flaws in recent times. The instance mentioned earlier, regarding the researcher getting kicked out of the Developer Program, involved a seemingly benign app that allowed unsigned code in memory. This flaw was exploited to download and run unauthorized code throughout the system.  Another recent example is an app that was created to supposedly allow users to change their screen color. However, this app actually allowed users to circumvent the fee-based tethering option and their phones as access points for free. This app has since been pulled from the app store, but users who already downloaded it can still use it.

V. Possible Lines of Defense

Smartphone defense is very important, both to individuals and to companies that allow their users to access private information about clients or employees. One theory put forth to defend against malware is the CPMC (Community-Based Proximity Malware Coping). Because centralized control is not really feasible in smartphone networks, this scheme uses proximity to establish when communication should be rejected with nodes in another community by the use of signatures. This is short-term, as a timer is started when the signature is initially communicated. Eventually, communication will be allowed again. These short-term components will be stored in the history and analyzed in a long-term fashion that will help the device make communication decisions in the future. This strategy can defend against proximity malware such as CommWarrior,

A suggestion for defending against Android malware, specifically, is to create a new privacy mode that can provide more granular options for security permissions to the user. One such system is the TISSA (Taming Information-Stealing Smartphone Apps). This tool uses a small amount of resources and has a very small footprint so as not to slow down the device.

A similar suggestion is to implement AppFence.  This tool offers two ways to avoid sharing private information. The first is what’s called data shadowing. If an app needs to send private information, AppFence will substitute benign data in its place. The second is exfiltration blocking, which basically sends nothing if private information is requested. However, with these tools, it is possible that the app will not function as it was originally intended to.

A very interesting line of defense, especially for business users, is to create a virtual machine on your phone. VMware is currently working on a project, called Horizon Mobile, which will allow a user to keep his personal data completely separate from business data without forcing the user to carry around two physical phones. The project will also allow IT admins to backup and restore the entire phone somewhere on the network, which could lead to “off-phone” attack forensics. IT admins will also be able to easily wipe business data from the VM without having to go near the personal information.

An interesting bonus for virtualization is that the hardware verifies the integrity of the bootROM. Then the integrity of the virtualization microkernel is checked, which can then check the operating system image. If any of these verifications turn out to be false, the system can deny access to certain resources. As of now, virtualization is being performed only on Android. Its open model makes it easily available for development and testing. When virtualization is generally available, I believe Android will be the superior choice among business, and more specifically IT departments.

VI. Future Work

It seems that the major security issue with Android is the lack of review performed during the app-submittal process. I would like to see a peer-review process put into place that would work much like signed drivers from Microsoft. Although you could download any app you want, you might get a warning if the app hasn’t been peer-reviewed. There could be some trusted developers who would act as peer reviewers by putting their stamps of approval on certain apps. Though this is not fool-proof, it would add an additional layer of security to apps found in the Android Market. Because this is a peer review, and users can still download any app they want, Android would still uphold its open spirit.

Another idea, especially in a business setting, would be to somehow restrict your users to an Adroid Market that is known to be secure. Android has the flexibility to use other markets than the one offered up by Google. If you could somehow create a market that would have known secure apps it would add another layer of protection. For personal use, this would also be an added layer of security. Even though the user would have access to all other Android markets, if this user was particularly cautious he could choose to only download apps from this secure market.

VII. Conclusions

Android and iOS confront security issues in two very different ways. The Android OS puts permissions and access controls in the hands of the end user, but does almost nothing to vet out apps available in the Android Market. iOS insists on at app-submission program and having at least two Apple developers review an app before approving the submission. However, there is no way for users to know what access the app needs and to prevent it from installing if a user deems it unsafe.

Although more viruses, trojans, and worms attack the Android, iOS is not without its security flaws. It is likely that the attacks will continue to rise, as well. Androids allow for more third-party security software, making it possible to contorl Android smartphones more granularly. With iOS, although very secure, you are stuck using Apple’s tools.

References Felt, Adrienne Porter, Chin, E., Hanna, S., Song, D., and Wagner, D. “Android Permissions Demystified.” Web. <;.

References Delac, G., Silic, M., and Krolo, J. “Emerging Security Threats for Mobile Platforms.” Web. <;.

References Napier, Rob. “IOS 5 Programming Pushing the Limits … – Rob Napier, Mugunth Kumar.”Google Books. Web. 04 Dec. 2011. <;.

References Noyes, Katherine. “Why Android App Security Is Better Than for the IPhone | PCWorld Business Center.” Reviews and News on Tech Products, Software and Downloads | PCWorld. Web. 04 Dec. 2011. <;.

References Li, Feng, Yang, Y., and Wu, J. “CPMC: An Efficient Proximity Malware Coping Scheme in Smartphone-based Mobile Networks.” Web.

References Wallach, Dan. “Smartphone Security: Trends and Predictions.” Web. <Delac, G., M. Silic, and J. Krolo. “Emerging Security Threats for Mobile Platforms.” Web. .>.

References Zhou, Y., Zhang, X., Jiang, X., and Freeh, V. “Tamin Information-Stealing Smartphone Applications (on Android).” Web. <;.

References Zhou, Yajin, and Jiang, X. “An Analysis of the AnserverBot Trojan.” Web. <;.

References Hornyack, Peter, Han, S., Jung, J., Schechter, S., and Wetherall, D. “The Aren’t the Droids You’re Looking For: Retrofitting Android to Protect Data from Imperious Applications.” Web. <;

References “Apple Answers the FCC’s Questions.” Apple. Web. 04 Dec. 2011. <;.

References “App Store Review Guidelines.” Web. <;.

References Slavov, Vlad. “Apple Kicks Researcher Out of IOS Developer Program for Exploiting Security Flaw, Microsoft Swoops In.” Web. <;.

References “Smartphone Security Smackdown: IPhone Vs. Android – Security – Mobile Security – Informationweek.” InformationWeek | Business Technology News, Reviews and Blogs. Web. 04 Dec. 2011. <;.

References Roberts, Laura. “15 Year-old Boy Creates ‘Trojan’ IPhone App Which Connects to Internet for Free – Telegraph.” – Telegraph Online, Daily Telegraph and Sunday Telegraph – Telegraph. Web. 04 Dec. 2011. <;.

References McGarvey, Robert. “IOS vs. Android Security: And the Winner Is? – ESecurity Planet.”ESecurity Planet: Internet Security for IT Professionals. Web. 04 Dec. 2011. <;.

References Shah, Rushang. “Android vs. IPhone for Business: 5 Questions to Answer – ZDNet.”Technology News, Analysis, Comments and Product Reviews for IT Professionals | ZDNet. Web. 04 Dec. 2011. <;.

References Cox, John. “Symantec Finds Big Differences in IOS, Android Security.” Network World. Web. 04 Dec. 2011. <;.

References Brodkin, Jon. “VMware to Virtualize Android Smartphones for Business Users.” Network World. Web. 04 Dec. 2011. <;.

References Brodkin, Jon. “VMware’s Virtualized Android Phones Coming to Verizon.” Ars Technica. Web. 04 Dec. 2011. <;.

About these ads

, , , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: