Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Understanding Android Security

Understanding Android Security

Ratings: (0)|Views: 21|Likes:
Published by elvictorino

More info:

Published by: elvictorino on Mar 28, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





1540-7993/09/$25.00 © 2009 IEEE
UnderstandingAndroid Security
with existing online services.However, as the importance of thedata and services our cell phonessupport increases, so too do theopportunities for vulnerability. It’sessential that this next generationof platforms provides a compre-hensive and usable security infra-structure.Developed by the Open Hand-set Alliance (visibly led by Google),Android is a widely anticipatedopen source operating system for mobile devices that provides abase operating system, an applica-tion middleware layer, a Java soft-ware development kit (SDK), anda collection of system applications.Although the Android SDK hasbeen available since late 2007, the
rst publicly available Android-ready “G1” phone debuted in lateOctober 2008. Since then, An-droid’s growth has been phenom-enal: T-Mobile’s G1 manufacturer HTC estimates shipment volumesof more than 1 million phones bythe end of 2008, and industry in-siders expect public adoption toincrease steeply in 2009. Manyother cell phone providers have ei-ther promised or plan to support itin the near future.A large community of devel-opers has organized around An-droid, and many new productsand applications are now availablefor it. One of Android’s chief sell-ing points is that it lets developersseamlessly extend online servicesto phones. The most visible exam-ple of this feature is, unsurprising-ly, the tight integration of Google’sGmail, Calendar, and ContactsWeb applications with system util-ities. Android users simply supply ausername and password, and their phones automatically synchro-nize with Google services. Other vendors are rapidly adapting their existing instant messaging, socialnetworks, and gaming services toAndroid, and many enterprises arelooking for ways to integrate their own internal operations (such asinventory management, purchas-ing, receiving, and so forth) intoit as well.Traditional desktop and server operating systems have struggledto securely integrate such per-sonal and business applicationsand services on a single platform.Although doing so on a mobileplatform such as Android remainsnontrivial, many researchers hopeit provides a clean slate devoid of the complications that legacy soft-ware can cause. Android doesn’to
cially support applications de-veloped for other platforms: ap-plications execute on top of a Java
Pennsylvania State University 
he next generation of open operating systemswon’t be on desktops or mainframes but on thesmall mobile devices we carry every day. Theopenness of these new environments will lead tonew applications and markets and will enable greater integration
middleware layer running on anembedded Linux kernel, so de-velopers wishing to port their application to Android must useits custom user interface environ-ment. Additionally, Android re-stricts application interaction to itsspecial APIs by running each ap-plication as its own user identity.Although this controlled interac-tion has several bene
cial securityfeatures, our experiences devel-oping Android applications haverevealed that designing secureapplications isn’t always straight-forward. Android uses a simplepermission label assignment modelto restrict access to resources andother applications, but for reasonsof necessity and convenience, itsdesigners have added several po-tentially confusing re
nements asthe system has evolved.This article attempts to un-mask the complexity of Androidsecurity and note some possibledevelopment pitfalls that occur when de
ning an application’s se-curity. We conclude by attempt-ing to draw some lessons andidentify opportunities for futureenhancements that should aid inclarity and correctness.
 Android Applications 
The Android application frame-work forces a structure on devel-opers. It doesn’t have a
 function or single entry point for execution—instead, developersmust design applications in termsof components.
Example Application 
We developed a pair of applicationsto help describe how Android ap-
plications operate. Interested readerscan download the source code fromour Web site (http://siis.cse.psu.edu/android_sec_tutorial.html).Let’s consider a location-sen-sitive social networking applica-tion for mobile phones in whichusers can discover their friends’locations. We split the functional-ity into two applications: one for tracking friends and one for view-ing them. As Figure 1 shows, theFriendTracker application consistsof components speci
c to trackingfriend locations (for example, via aWeb service), storing geographiccoordinates, and sharing those co-ordinates with other applications.The user then uses the Friend-Viewer application to retrieve thestored geographic coordinates andview friends on a map.Both applications contain mul-tiple components for performingtheir respective tasks; the com-ponents themselves are classi-
ed by their 
component types
. AnAndroid developer chooses fromprede
ned component types de-pending on the component’s pur-pose (such as interfacing with auser or storing data).
Component Types 
Android de
nes four componenttypes:
components de
ne anapplication’s user interface.Typically, an application devel-oper de
nes one activity per “screen.” Activities start eachother, possibly passing and re-turning values. Only one activ-ity on the system has keyboardand processing focus at a time;all others are suspended.
components performbackground processing. Whenan activity needs to performsome operation that must con-tinue after the user interfacedisappears (such as download a
le or play music), it commonlystarts a service speci
cally de-signed for that action. The de-veloper can also use services asapplication-speci
c daemons,possibly starting on boot. Ser-vices often de
ne an interfacefor Remote Procedure Call(RPC) that other system com-ponents can use to send com-mands and retrieve data, as wellas register callbacks.
Content provider 
components storeand share data using a relationaldatabase interface. Each contentprovider has an associated “au-thority” describing the content itcontains. Other components usethe authority name as a handleto perform SQL queries (such as
, or 
) toread and write content. Althoughcontent providers typically storevalues in database records, dataretrieval is implementation- speci
c—for example,
les arealso shared through content pro-vider interfaces.
Broadcast receiver 
componentsact as mailboxes for messagesfrom other applications. Com-monly, application code broad-casts messages to an implicitdestination. Broadcast receiversthus subscribe to such destina-tions to receive the messagessent to it. Application code canalso address a broadcast receiv-er explicitly by including thenamespace assigned to its con-taining application.Figure 1 shows the Friend-Tracker and FriendViewer appli-cations containing the di
erentcomponent types. The developer speci
es components using a man-ifest
le (also used to de
ne policyas described later). There are norestrictions on the number of com-ponents an application de
nes for each type, but as a convention, onecomponent has the same name asthe application. Frequently, this isan activity, as in the FriendViewer application. This activity usuallyindicates the primary activity thatthe system application launcher uses to start the user interface;however, the speci
c activity cho-sen on launch is marked by metainformation in the manifest. Inthe FriendTracker application,for example, the FriendTracker-Control activity is marked as themain user interface entry point.In this case, we reserved the name“FriendTracker” for the servicecomponent performing the coreapplication logic.The FriendTracker applicationcontains each of the four com-ponent types. The FriendTracker service polls an external serviceto discover friends’ locations. Inour example code, we generatelocations randomly, but extend-ing the component to interfacewith a Web service is straightfor-ward. The FriendProvider con-
FriendTracker applicationBootReceiver Broadcast receiver  ActivityFriendTracker FriendProvider Content provider ServiceFriendTracker-ControlFriendViewer applicationFriendReceiver Broadcast receiver  ActivityFriendTracker  ActivityFriendViewer 
Figure 1. Example Android application. The FriendTracker and FriendViewer applicationsconsist of multiple components of different types, each of which provides a different set of  functionalities. Activities provide a user interface, services execute background processing,content providers are data storage facilities, and broadcast receivers act as mailboxes for messages from other applications.
tent provider maintains the mostrecent geographic coordinates for friends, the FriendTrackerCon-trol activity de
nes a user inter-face for starting and stopping thetracking functionality, and theBootReceiver broadcast receiver obtains a noti
cation from thesystem once it boots (the applica-tion uses this to automatically startthe FriendTracker service).The FriendViewer applicationis primarily concerned with show-ing information about friends’ lo-cations. The FriendViewer activitylists all friends and their geograph-ic coordinates, and the FriendMapactivity displays them on a map.The FriendReceiver broadcast re-ceiver waits for messages that in-dicate the physical phone is near a particular friend and displays amessage to the user upon such anevent. Although we could haveplaced these components withinthe FriendTracker application,we created a separate applicationto demonstrate cross-applicationcommunication. Additionally, byseparating the tracking and user interface logic, we can create al-ternative user interfaces with dif-ferent displays and features—thatis, many applications can reuse thelogic performed in FriendTracker.
Component Interaction 
The primary mechanism for component interaction is an
, which is simply a messageobject containing a destinationcomponent address and data.The Android API de
nes meth-ods that accept intents and usesthat information to start activities(
),start services (
), and broadcast messag-es (
).The invocation of these methodstells the Android framework tobegin executing code in the targetapplication. This process of in-tercomponent communication isknown as an
. Simply put, anintent object de
nes the “intent”to perform an “action.”One of Android’s most pow-erful features is the
exibility al-lowed by its intent-addressingmechanism. Although develop-ers can uniquely address a targetcomponent using its application’snamespace, they can also specifyan implicit name. In the latter case, the system determines thebest component for an action byconsidering the set of installed ap-plications and user choices. Theimplicit name is called an
because it speci
es the typeof requested action—for exam-ple, if the
action stringis speci
ed in an intent with data
elds pointing to an image
le,the system will direct the intent tothe preferred image viewer. De-velopers also use action strings tobroadcast a message to a group of broadcast receivers. On the receiv-ing end, developers use an
to subscribe to speci
c actionstrings. Android includes addi-tional destination resolution rules,but action strings with optionaldata types are the most common.Figure 2 shows the interac-tion between components in theFriendTracker and FriendViewer applications and with componentsin applications de
ned as part of the base Android distribution. Ineach case, one component initi-ates communication with another.For simplicity, we call this inter-component communication (ICC).In many ways, ICC is analogousto inter-process communication(IPC) in Unix-based systems. Tothe developer, ICC functions iden-tically regardless of whether thetarget is in the same or a di
erentapplication, with the exception of the security rules de
ned later inthis article.The available ICC actions de-pend on the target component.Each component type supportsinteraction speci
c to its type— for example, when FriendViewer starts FriendMap, the FriendMapactivity appears on the screen.Service components support start,stop, and bind actions, so theFriendTrackerControl activity,for instance, can start and stop theFriendTracker service that runsin the background. The bind ac-tion establishes a connection be-tween components, allowing theinitiator to execute RPCs de
nedby the service. In our example,FriendTracker binds to the loca-tion manager in the system server.Once bound, FriendTracker in-vokes methods to register a call-back that provides updates on
System server Locationmanager SystemserviceContacts application (system) ViewContactFriendTracker applicationBootReceiver Start/stopFriendTracker Read/writeFriendTracker-ControlFriendViewer applicationFriendReceiver FriendViewer FriendMapStartBroad-castintentReadStartBindBroadcast intentReadFriendProvider 
Figure 2. Component interaction. Android’s application-level interactions let the FriendTracker and FriendViewer applications communicate with each other and system-provided applications.Interactions occur primarily at the component level.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->