01-01-2013, 09:42 AM
HOW SMART IS YOUR ANDROID SMARTPHONE
HOW SMART.docx (Size: 1.14 MB / Downloads: 33)
ABSTRACT
Smart phones are ubiquitous today. These phones generally have access to
sensitive personal information and, consequently, they are a prime target for attackers. Avirus or worm that spreads over the network to cell phone users could be particularlydamaging.
Due to a rising demand for secure mobile phones, manufacturers have increasedtheir emphasis on mobile security. In this project, we address some security issuesrelevant to the current Android smartphone framework. Specifically, we demonstrate anexploit that targets the Android telephony service. In addition, as a defense against theloss of personal information, we provide a means to encrypt data stored on the externalmedia card. While smartphones remain vulnerable to a variety of security threats, thisencryption provides an additional level of security.
Introduction
Mobile phones are no longer devices restricted to making voice callsthey can run mostof the processes that one expects from a desktop computer. Mobile phones are equipped withapplications such as e-mail clients, chat clients, short messaging service (SMS), and multimediamessaging service (MMS). Most smartphones are equipped with cameras so that one can havepersonal pictures and videos on the phone. Communication between two mobile devices is nolonger limited to the services of a GSM provider. One can have two mobile phones communicatewith the help of Bluetooth, external media cards, or the Internet. Thanks to the efforts of the
World Wide Web Consortium (W3C) and Open Mobile Alliance (OMA), being away from one’slaptop does not mean being disconnected from the rest of the Internet world.
The first mobile phone virus, Cabir, was created in 2004 and targeted for Symbian OSbasedphones. This virus replicated itself on Bluetooth wireless networks [1]. Since then, therehave been many similar versions of the virus and a few new ones. However, the number ofmobile phone viruses is significantly fewer than computer viruses.
One major difference between PC and mobile phone viruses has been that it is moredifficult for mobile virus infections to spread as fast as computer viruses can. This is due to thevariety of mobile platforms; lack of documentation and lack of support tools has led to lessexploitation of vulnerabilities [1].
However, the trend has been to synchronize computers with smartphones. Hence, thethreat to all critical and private data has become twofold. Even worse is that smartphones comewith a built-in billing system; a virus can cause immediate financial loss. Most of the threatsinterrupt user productivity, drain the battery, increase messaging charges, and have the potentialto damage users’ reputations.
With the rich variety of data centric applications available, it is important that thesmartphone be made smart to preserve user privacy. Various platforms have evolved in theprocess to achieve this goal. Some of the current mobile platforms such as Symbian, Android,and so on, have taken steps to ensure that their architecture is build around security.
Objective of the Project
The objective of this project is to identify security holes and any missing security featuresin Android’s architecture. Using this as a starting point, the goal is to develop a prototypeapplication that serves as a justification for our findings.
Order of the Project
Section 2 begins with a discussion of the Android security architecture and some of itslimitations. Section 3 briefly covers the security architecture of iPhone and Symbian, comparingthem with Android’s architecture. Section 4 lists some mobile phone risks, and Section 5 brieflycovers some of the best practices that users of smartphones should follow for their personalsecurity.
Section 6 discusses in detail the telephony exploitation that we have successfullydeployed on Android phones. This malicious behavior tries to breach the user’s privacy byretrieving all his or her contacts and sending an SMS message on each incoming voice call. Italso prevents the user from dialing any numbers, hence exploiting the most basic feature of aphone.
Section 7 covers the implementation details and limitations of the security enhancementwe have developed for dealing with external data. In the current Android framework, eachapplication has private access of the data stored on the internal phone memory. However, this isnot applicable to data stored on an external media card. In our solution, we encrypt the databeing written to external media and store the encryption key on the phone memory, which isprivate to the application that uses this solution.
Section 8 concludes our work and reiterates our goals and achievements while studyingthe security architecture of smartphone operating systems, and provides the scope for furtherstudy.
Android Framework
Introduction
Android is the mobile phone platform led by Google’s Open Handset Allowance (OHA).Android has a unique security model in which the user is in complete control of the device. It isan open source platform based on Linux. All applications are written in Java and compiled into acustom byte-code (DEX) [6]. Each application executes in its own process with its own instanceof the Dalvik virtual machine interpreter [2].
Application behaviour
Every application in Android runs as a separate process with a unique UID, unlike adesktop computer where all the applications run with the same UID. The UID of an applicationin Android protects its data. Programs cannot typically read or write each other’s data, andsharing between applications must be done explicitly [3]. Due to this feature, a compromise suchas a buffer overflow attack [3,17] is restricted to the application and its data. However, it isimportant to note that an application can launch another program that will run with the launchingapplication’s UID.For a developer to run an application on the Android phone, his or her application needs
to be signed. Developers can generate self-signed certificates and use this for code signing. Codesigning is done to enable developers to update their own applications without creatingcomplicated interfaces and permissions.
Application components
Applications are comprised of components. Components interact using Intent messages[6]. Recipient components assert their desire to receive Intent messages by defining Intent filters
[6]. There are four types of components used to construct applications:
1. Activity components interact with the user via the touchscreen and keypad. Only oneactivity is active at a time, and processing is suspended for all other activities [5].
2. Service components provide for background processing when an application’s
activity leaves focus and another GUI application comes in the foreground [6].
3. Broadcast receiver components provide a general mechanism for asynchronous eventnotifications [6]. The receivers receive Intent messages that are implicitly addressed
with action strings; for instance, dialing a number is associated with the action
OUTGOING_CALL_ACTION.
Content provider components are the preferred method for sharing data between
applications [5]. These APIs implement an SQL-like interface; however, the backend
implementation is up to the application developer.
Application level security framework
Applications need approval to do things their user might object to, such as sending SMSmessages, using the contacts database, or using the camera. To keep track of what the applicationis permitted to do, Android maintains manifest permissions that are enforced by the middlewarereference monitor. The permission label is a unique text string that can be defined by the OS aswell as by a third-party developer. These permissions indicate what resources and interfaces areavailable to the application at run-time. An example of a permission is READ_CONTACTS,which permits the application to read the user’s address book. In addition to reading and writingdata, permissions allow applications to access system services such as dialing a number withoutprompting the user or taking complete control of the screen and obscuring the status bar.A developer should specify all permissions that his or her application requires in theAndroidManifest.xml file; however, it is not necessary that all permissions be granted. When theapplication is getting installed, the user has the choice to decide whether or not to trust thesoftware based on the application’s promised features. and the permissions required. Thesepermissions are different from file permissions. Once an application is installed, its permissionscannot be changed. The fewer permissions an application needs, the more comfortable the usershould feel installing the application.Permissions have a protection level. The four protection levels are outlined in Table 1.
Files and preferences
Android uses UNIX-style file permissions [2]. Each application has its own area on thefile system that it owns [2,16]. This is similar to programs having a home directory to go alongwith their User IDs. This feature is limited only to the internal phone memory and not theexternal memory. The standard way for applications to expose their private data to otherapplications is through content providers [16].
Android limitation
The current security policy of Android works on a static level only during installation toidentify whether the application is permitted all the requested permissions from the user. Oncethe permission is granted, there is no way to govern to whom these rights are given or how theyare later exercised [3]. Permissions are asserted as vague suggestions as to what kinds ofprotections the application desires. One must place good faith in the user and the OS to makegood choices about permissions granted to the application which, in many cases, may not be theabsolute best .choice.Due to the above architecture, Android system libraries have limited ability to control
installed third-party applications that can be granted permissions to use their interfaces. Thisimplies that there is no control to restrict an installed application based on its signatures. Further,it is not possible to define the desirable configurations of an installed third-party application suchas the minimum version and the set of permissions it is allowed or disallowed.This implies that Android applications built with the right set of permissions protect thesystem from malicious applications but provides severely limited infrastructure for applicationsto protect themselves.
iPhone and Symbian Mobile Frameworks
iPhone and Symbian are the two popular competitors of Android smartphones. Each ofthese platforms has its own security model. A comparison of these architectures is essential tounderstanding the current trends in mobile security.
iPhone security architecture
iPhone’s security features include encryption of data in transit and authorization by
strong passwords to corporate services. On iPhone 3GS, there is a new enhancement of hardwareencryption of data stored on the device [12]. Users of the device can be restricted from accessingcertain features by setting up device restrictions through configuration policies.iPhone also comes with the feature of remote wipe, which is helpful in case of the devicebeing lost or stolen. The user of iPhone can login to his or her web account and issue the remotecommand to securely wipe the the phone’s data, making it unrecoverable. It also supportserasing of data from the device after a certain number of failed authorization attempts. Toprovide secure access to corporate data, iPhone also integrates with VPN technologies [12].
Symbian’s security framework
Symbian was one of the first smartphone operating systems, with its first phone based onSymbian v6.0, released in 2001. Nokia acquired Symbian Software Limited in 2008 and, inFebruary 2010, Symbian source code became available as open source [14].
To free the users from the task of deciding about security of an application, Symbian OSreleased Symbian v9.x, which introduced the concept of platform security. This includescapabilities and Symbian signing. In early 2005, Symbian 9.1 was released and can runapplications that pass the constraints set by both the Android and iPhone platforms. This meansthat, just as in Android, an application needs to enlist permissions or capabilities that its APIswill use. This is exactly the UNIX-style permissions per process-based model; however, unlikeAndroid, this application is not available for market use without the signing process.There are two types of certificates used by the Symbian community: A developercertificate is used by the developer to sign his or her application and run on a specific phoneThis developer certificate contains the requested capabilities of the application but is confined torun only on certain phones as specified by the International Mobile Equipment Identity (IMEI)which are mentioned in the certificate request process. It is not possible to request more than 20IMEI numbers in a developer certificate. This means that a malicious application does not spreadextensively as soon as it is developed.The second certificate is the Symbian Signed Certificate, obtained through the Symbiansigning process. Just like iPhone, a Symbian application needs to be signed by a certifyingauthority before deploying the application in the market. There is a cost associated with eachsigning. One needs a publisher ID from Verisign, which costs $200 per year, and the Symbiansigning process has an additional cost of around $300 [9] per signature.Once the application is ready to be deployed, it needs to be submitted to the Symbiansigned site [15]. There, the application is tested against criteria specified by Symbian. After thetesting is successfully completed, the application is certified and returned to the developer, whocan then distribute the application. This process is shown in Figure 3.