The line between the personal computer and mobile smartphone has already begun to blur. The hardware race is in full swing as chip manufacturers put out the latest and greatest every quarter and the operating systems on top of that hardware have evolved into an entire ecosystem. An ecosystem complete with exciting new features, applications, developers, and let us not forget the enthusiasts. However, with each new smartphone activation there is a new target born. An unfortunate side-effect of the explosive growth seen in smartphones is the issue of security.
As the demand for mobile platforms to offer the same conveniences as modern personal computers increases the risks do as well. Vulnerabilities such as malware, direct attacks, data interception, exploitation, and social engineering all have transitioned into mobile space as fluidly as the operating systems themselves. This paper will inform the reader of these threats, identify the pros and cons of some operating systems, and draw a conclusion towards the future of security in mobile devices.
In June 2004 the first malware application was identified for the popular Symbian operating system. According to the Alexander Gostev, a member of the Kaspersky new virus identification team, “The trickle of new malicious programs for Symbian that began in 2004 has become a constant stream which threatens to become a torrent.” This marked the first time his team had dealt with a virus designed for the ARM family of processors since the focus previously was only on x86 based architectures. Gostev goes on to talk about the origin of the virus, several methods by which to spread and concludes by reference to his law of computer virus evolution. It can be summarized in three points:
The platform must be popular.
There must be well-documented development tools for the application.
The presence of vulnerabilities or coding errors.
While these points may seem obvious, there is no doubt that a relationships exists between these points and the amount of attacks on an operating system. But since the focus of this paper is on mobile space, let’s take a look at the current market share of smartphone operating systems.
Figure 1: Worldwide Smartphone Sales in Quarter 2 of 2011 
Researchers believe growth of the smartphone market will continue to rise at the expense of feature phones. Roberta Cozza, a researcher at Gartner believes “Consumers in mature markets are choosing entry-level and midrange Android smartphones over feature phones, partly due to carriers’ and manufacturers’ promotions.”  It would be a fair assumption that some of these new first time smartphone buyers are not the tech savvy sort and their upgrade from a relatively safe feature phone to a smartphone will leave them vulnerable to exploitation. The operating system documentation and Software Development Kits (SDKs) available to anybody is beyond what one might imagine. This research paper explores the official documentation of Android, iOS, Symbian, and Windows Phone barely scratched the surface of what is available. A multitude of wikis, forums, chat rooms, and tutorials exists outside official documentation, and some even about how to exploit the device itself.
The combination of popularity, accessibility of resources, and a wide range of users each with unique vulnerabilities it is no wonder the smartphone security is becoming a hot issue. In fact, in IBM’s annual X-Force Trend and Risk Report for mid-2011 it states: “The bad guys are moving on to new attack surfaces, and one of those new battlefields is smartphones” IBM predicts that exploits targeting mobile devices “will more than double from 2010.”
Types of Attacks
Briefly mentioned before, the basic types of attacks that can happen include: Malware, Direct Attacks, Data Interception, Exploitation, and Social Engineering. Many of these attacks have origins in or are direct copies of previously developed exploits and hacks.
Malware is also known as viruses, worms, trojans, and spyware. One of the most well-known types of exploits, malware has steadily increased in the absence of any real dire need for a third-party security suite for mobile devices.
The trend of smartphone targeted attacks is rapidly increasing due to the combined portability of along with the computing and networking power of PCs. Malware can be installed on a device in several different ways and the three most common routes are attacks from the Internet, infection from compromised PC during the data synchronization, and peer smartphone attack or infection. Alexander Gostev and his team found that the virus was transmitted through a Bluetooth flaw.
Without going into too much detail; malware typically is after two things. First it needs a way to propagate itself to more devices. It will look for ways to spread such as sending SMS messages to the victim’s entire contact list. Secondly, it will want to gather data, this can be accomplished many ways, logging keystrokes, installing illegitimate software, spoofing certificates or entire websites, all the way to hijacking an entire system until the process itself is killed.
Direct Attacks are targeted attacks on a device based on a known security issue, many times these stem from a weakness in a common application or a fault within the OS itself. Last year Android users were urged to update their Adobe Flash Player application as it had a serious flaw that would allow a malicious script crash the entire system. Direct attacks differ from malware because a harmful program is not installed on the device; rather a weakness is exploited and can cause the system to behave erratically possibly setting it up for a chained exploit.
An increasingly common method of obtaining information is via data interception. Data interception usually happens when a device is connected to a compromised network. There are many programs and tools available to accomplish this task.
One in particular for the Android OS is called WireShark. From their application description: Wireshark is the world's foremost network protocol analyzer. It lets you capture and interactively browse the traffic running on a computer network. It is the de facto (and often de jure) standard across many industries and educational institutions. WireShark merely analyzes the packets, however, combined with some type of password cracker would allow an intruder to obtain your unique logon information.
Another exploit involving data interception is setting up a wireless network with the same name as a genuine network that is in close proximity. That way the attacker only needs to store all the packets of data from a terminal with administrative access to the network. Cain and Abel, Abel specifically allows the installation and execution of a cache dump of all logons. Cain and Abel is another versatile tool that is perfectly legitimate to have on a system, but has the potential to crack through network encryption given enough time to run.
Exploitation and Social Engineering
While it may be a very low tech approach to obtaining sensitive information, social engineering and exploitation should not be underestimated. Receiving a text message from an unknown source or solicitation (phishing) are likely attempts at social engineering. Recently, the Android Marketplace fell victim to some social engineering where malware was named to be similar popular applications. The fake applications pulled all the device information and also had the potential to download more code after “rooting” the device. Rooting means the operating system allows certain applications full root access to the device and may cause more problems.
Comparison of Operating Systems
The popular mobile operating systems today are Android, iOS, Symbian, Blackberry OS, and Windows Phone. This paper will cover Android and iOS in detail with a few comments on other mobile operating systems in general.
The newest contender in the smartphone arena and as Figure 1 described the biggest as well. Android is a modern mobile platform that was designed to be truly open, the source code for Android is all open source as well as any Android developed application on the phone. It is not uncommon to see people with different “ROMs” of Android. These ROMs are typically based off of the open source code along with third-party modifications. In the context of an Android device, ROM (Read-only Memory) is the internal flash memory where the core operating system resides. It can also refer to a specific version firmware that can be applied to a device through a process usually referred to as flashing. An improperly flashed ROM can often “brick” the device, rendering it unusable.
Android claims to reduce the chance for most of the common attacks to happen especially social engineering attacks using a unique permissions system. Android runs on many devices, now ranging from smartphones, tablets, and set-top boxes all with their own hardware configuration. However, Android does take advantage of some hardware-specific security capabilities such as ARM v6 eXecute-Never which marks certain areas of memory as non-executable. Android’s operating system itself is built over the top of the Linux kernel. As such system level applications Display, Bluetooth, Camera, Network controllers, etc. are accessed directly by the operating system. Refer to Figure 2 to get a better picture of how the Android OS is organized and to understand how the Android sandbox works. Android has two main security measures, the Android Security Program and the Android Platform Security Architecture.
Android Security Program
The Android Security Program outlines the model and describes the standards for the hardware, firmware, and applications developed for the operating system. The key components include:
Design Review: Each major feature is reviewed by engineering and security teams, with appropriate security controls integrated into the architecture of the system.
Penetration Testing and Code Review: Vigorous security reviews performed by the Android Security Team, Google’s Information Security Engineering team, and independent consultants.
Open Source and Community Review: Security reviews are also available to any interested party. The open nature of the Linux kernel and the Android OS guarantee significant external security reviews.
Incident Response: The response and follow up of released devices, firmware, and hardware. The Android team monitors the security concerns from the community and release updates, patches, and minimizes and vulnerabilities discovered. Updates are received OTA (over the air) or can be downloaded and patched manually.
In short, the Android Security Program mission statement is to “Enable a vigorous ecosystem of applications and devices built on and around the Android platform and supported by cloud services.”
Android Platform Security Architecture
On the other side of the coin, the actual code that drives Android has key security features implemented. This code is constantly maintained and updated to compensate for any new risk introduced to the system. Its key components include:
Linux Kernel Security: The Linux kernel is a stable and secure kernel that has been in widespread use and the specific version running under Android, Linux 2.6 has been around since late 2003. Some features include, a user-based permissions model, process isolation, an extensible mechanism for secure Inter-Process Communication (IPC) and the ability to remove potentially unsecure parts of the kernel.
Application Sandbox: One of the most important security measures is the application sandbox the chart below (Figure 2) shows the layout of the software stack. The purpose of the layout is to demonstrate how integral the sandbox protects the operating system from being compromised by just one application. Each library, framework, runtimes and application runs in its own sandbox, it has full control of everything in its sandbox but nothing more unless granted permissions by the user. This means that any erratic behavior by one application will not cause any instability outside of its own sandbox. The only exception is if an application has been granted super user (root) permissions, which is not the default setting for the stock operating system and is not recommended for the typical Android user.
Figure 2: The Android Software Stack 
System Partition and Safe Mode: The kernel and OS level resources are on a separate partition that is read only while the operating system is in use. Safe mode allows only operating system level applications to run.
Filesystem Permissions: A user-based permissions means that each user cannot read from or write to another user’s files. In the case of Android, a user is an application. This goes along with the idea that each application can only run in its own sandbox and has only the permissions granted to it by the user.
Filesystem Encryption: All user data can be encrypted with the dm-crypt implementation of AES128 with CBC and ESSIV:SHA256. User passwords are encrypted with SHA1 that protects against brute force attacks. Stricter password guessing methods can be chosen by the user and enforced directly by the operating system.
Android security measures reaches farther than this but this is a solid overview for the basics of its security.
Apple has developed a similar set of security precautions for their iOS operating system. Like Android, iOS has developed its own security architecture. Unlike Android, iOS is closed source, Apple decides which parties are responsible for the testing and review of code and security risks. The actual procedure that Apple uses in code review and testing is not something publically shared.
Before looking at the response of an incident, it is important to note that iOS has strictly defined terms to which the user must adhere. The iStore, similar to the Android market, has stricter regulation on which applications can be created and sold. There are specific interface design characteristics, functionality, content allowed, and technologies allowed and if any one of these rules is not followed to the discretion of the review board an application is likely to be rejected until it is fixed accordingly. The upside of this strict regulation is that the chance of Malware being released on an official channel is very slim, the downside is that applications which may not pose a security risk may still be denied.
When an incident is discovered the response team releases a public notification and will release the appropriate patch to the end-user. This patch will install the next time the device connects to a PC to synchronize.
The implemented security architecture of iOS has some similarities to Android, those will be explained later in this section, but it is worth mentioning that iOS is built upon a “Core OS” kernel. This kernel, while it may share some similarities with UNIX based systems is developed specifically for iOS.
Figure 3: Overview of iOS security architecture. 
Security Server Daemon: The security server that implements protocols to keychain items and other security APIs. iOS security services do not provide an authentication interface, there is no need for a user interface since everything is automated or handled by the APIs themselves.
iOS Security APIs: Based in the Core Services layer, the four main security APIs are.
Keychain: The keychain will store passwords, keys, certificates, and other secrets. It is also in charge of encrypting and decrypting this data (not to be confused with encryption of data, the keychain encrypts the actual passwords and encryption keys). Calls upon Core OS libraries in that case.
CFNetwork: High-level API that is technically outside the security APIs that is used by applications to create and maintain a secure data stream and add authentication to a message.
Certificate, Key, and Trust Services: Handle certificates, add certificates to the keychain, create encryption keys, encrypt and decrypt data, sign and verify signatures, and manage trust policies. Also requires Core OS libraries.
Randomization Services: Creates pseudorandom numbers for encryption that are virtually discernible from any recognizable sequence. Uses a randomization service located in the Core OS layer. Two layers of abstraction from the actual randomization seed.
Authentication, Identification, and Authorization: Contains the sandboxing, similar to what Android does but iOS only has one sandbox for all applications, libraries, and runtimes outside of the kernel layer. Permissions are granted from here once an application has been authorized. The means by which might be automatic or could ask the user to input a specific PIN. 
There are many more concepts to be discussed about the specific security precautions in the code, but as a general overview one can see that iOS and Android have their differences but also share many of the same security precautions.
Android OS vs. iOS
Dr. Charlie Miller, a security researcher who has exposed vulnerabilities in just about every mobile OS, expressed his feeling on Android and iOS security. He believes that Android has the stronger Application sandboxing but with the weak control on the market, more and more applications are able to install Malware which bypasses this security feature by rooting the target’s phone and granting the malware administrative privileges. He also mentions that Apple, while weak in its application sandboxing, has superior memory encryption, due to the fact that the number randomizer offers better protection against a spoofed certificate. Dr. Miller gives the nod to iOS as the best in security, but he believes the worst is yet to come. The “bad guys” as he puts it, have not yet shown a lot of interest in the mobile device world.
The growth of smartphones and mobile devices in general has impacted society in a big way. The smartphone is now its own industry and with that comes a greater importance to have tight security precautions without hindering the end-user. The hackers, malware, and spyware writers are making the transition to mobile. Android, iOS, Windows Phone, and many other big software developers must step up their security game. Users of those systems must also stay vigilant and practice good habits when downloading software to their device. Looking over the official documentation one can see that the security practices are there, in fact they are adequate for the time being. However, mobile devices are quickly changing the way we handle our digital activities and our processes and code design has to adapt accordingly. Otherwise, the “bad guys” will seize the chance and attack the unsuspecting end-users.
Gostev, Alexander. (2006 September) Retrieved October 2011, from Securelist – Mobile Malware Evolution: An Overview Part 1 http://www.securelist.com/en/analysis?pubid=200119916
Wikipedia. Retrieved October 2011, from Wikipedia http://en.wikipedia.org/wiki/File:Smartphone_share_current.png
Gartner (n.d.). Retrieved October 2011, from Gartner – Gartner Says Sales of Mobile Devices in Second Quarter of 2011 Grew 16.5 Percent Year-on-Year; Smartphones grew 74 Percent http://www.gartner.com/it/page.jsp?id=1764714
Google. (n.d.). Android Open Source Project. Retrieved Sept 2011, from Android Open Source – Android Security Overview http://source.android.com/tech/security/index.html
Apple. (n.d.). Mac OS X Developer Library. Retrieved Sept 2011, from Apple Developer – Security Overview http://developer.apple.com/library/mac/#documentation/Security/Conceptual/Security_Overview/Introduction/Introduction.html
Nokia. (n.d.). Symbian C++ Books. Retrieved October 2011, from Nokia Developer – Fundamentals of Symbian C++/Platform Security http://www.developer.nokia.com/Community/Wiki/Fundamentals_of_Symbian_C%2B%2B/Platform_Security
Microsoft. (n.d.). MSDN. Retrieved October 2011, from MSDN – Security for Windows Phone http://msdn.microsoft.com/en-us/library/ff402533.aspx
IBM. (n.d.). IBM Security Solutions. Retrieved September 2011, from IBM – IBM X-Force 2011 Mid-Year Trend and Risk Report http://public.dhe.ibm.com/common/ssi/ecm/en/wge03015usen/WGE03015USEN.PDF
PCWorld. Bradley, Tony. Retrieved September 2011, from PCWorld – Adobe Flash Zero Day Puts Android Smartphones at Risk. http://www.pcworld.com/businesscenter/article/205411/adobe_flash_zero_day_puts_android_smartphones_at_risk.html
(n.d.). WireShark User’s Manual. Retrieved October 2011, from WireShark Wiki – WireShark User’s Manual http://www.wireshark.org/docs/wsug_html_chunked/
 Montoro, Massimiliano. Retrieved October 2011from oXit – About Cain http://www.oxid.it/cain.html
(n.d.). Retrieved October 2011 from CyanogenMod Wiki – What is CyanogenMod? http://wiki.cyanogenmod.com/index.php?title=What_is_CyanogenMod
Google. Retrieved October 2011 from Android Open Source http://source.android.com/tech/security/images/image00.png
Apple (n.d.). Retrieved October 2011 from Apple Developer – Guidelines for Appstore Submissions http://developer.apple.com/appstore/resources/approval/guidelines.html
Apple. Retrieved October 2011 from Apple Developer http://developer.apple.com/library/mac/documentation/Security/Conceptual/Security_Overview/art/iphone_security_architecture.jpg
Accuvant. Farnum, Michael. Retrieved October 2011 from Accuvant – Dr. Charlie Miller Compares the Security of iOS and Android http://www.accuvant.com/blog/2011/10/20/dr-charlie-miller-compares-security-ios-and-android