Context-Based Access Control Systems for Mobile Devices

Context-Based Access Control Systemsfor Mobile Devices

Bilal Shebaro, Oyindamola Oluwatimi, and Elisa Bertino, Fellow, IEEE

Abstract—Mobile Android applications often have access to sensitive data and resources on the user device. Misuse of this data by

malicious applications may result in privacy breaches and sensitive data leakage. An example would be a malicious application

surreptitiously recording a confidential business conversation. The problem arises from the fact that Android users do not have control

over the application capabilities once the applications have been granted the requested privileges upon installation. In many cases,

however, whether an application may get a privilege depends on the specific user context and thus we need a context-based access

control mechanism by which privileges can be dynamically granted or revoked to applications based on the specific context of the user.

In this paper we propose such an access control mechanism. Our implementation of context differentiates between closely located sub-

areas within the same location. We have modified the Android operating system so that context-based access control restrictions can

be specified and enforced. We have performed several experiments to assess the efficiency of our access control mechanism and the

accuracy of context detection.

Index Terms—Context-based access control, smartphone devices, security and privacy, policies, mobile applications

Ç

1 INTRODUCTION

AS smartphones are becoming more powerful in termsof computational and communication capabilities,

application developers are taking advantage of these capa-bilities in order to provide new or enhanced services to theirapplications. For example, on March 2013 Samsungunveiled its Galaxy S4 device with 8 CPU cores and ninesensors that enrich the device with powerful resources [1].However, the majority of these resources can collect sensi-tive data and may expose users to security and privacy risksif applications use them inappropriately and without theuser’s knowledge [2]. The threat arises when a device appli-cation acts maliciously and uses device resources to spy onthe user or leak the user’s personal data without the user’sconsent [3], [4], [5]. Moreover, users carrying their smart-phones in public and private places may unknowinglyexpose their private information and threaten their personalsecurity as they are not aware of the existence of such mali-cious activities on their devices. To prevent such threats,users must be able to have a better control over their devicecapabilities by reducing certain application privileges whilebeing in sensitive contexts, e.g., confidential meetings. Toachieve this, smartphone systems must provide device own-ers with configurable policies that enable users to controltheir device usage of system resources and application priv-ileges according to context, mainly location and time. Sincesuch a feature is still missing in popular smartphone sys-tems, such as in Android systems, it is crucial to investigateapproaches for providing such control to device users.

The need for configurable device policies based on con-text extends from high profile employees to regular smart-phone users. For example, government employers, such asin national labs [6], restrict their employees from bringingany camera-enabled device to the workplace, includingsmartphones, even though employees might need to havetheir devices with them at all times as their devices maycontain data and services they might need at any time. Withcontext-based device policies, employees may be allowed touse smartphones as they can disable all applications fromusing the camera and any device resources and privilegesthat employers restrict while at work, while the user devicecan retain all its original privileges outside the work area.Context-based policies are also a necessity for politiciansand law enforcement agents who would need to disablecamera, microphone, and location services from their devi-ces during confidential meetings while retaining theseresources back in non-confidential locations. With context-based policies, users can specify when and where theirapplications can access their device data and resources,which reduces the hackers’ chances of stealing such data.

Previous work on security for mobile operating systems(OS) focuses on restricting applications from accessing sen-sitive data and resources, but mostly lacks efficient techni-ques for enforcing those restrictions according to fine-grained contexts that differentiate between closely locatedsubareas [7]. Moreover, most of this work has focused ondeveloping policy systems that do not restrict privileges perapplication and are only effective system-wide [8]. Also,existing policy systems do not cover all the possible ways inwhich applications can access user data and device resour-ces. Finally, existing location-based policy systems are notaccurate enough to differentiate between nearby locationswithout extra hardware or location devices [7], [9], [10]. Inmost cases, such systems assume the context as given with-out providing or evaluating context detection methods ofmobile devices [7], [11].

� The authors are with the Computer Science Department, Cyber Center andCERIAS, Purdue University, West Lafayette, IN 47907.E-mail: {bshebaro, ooluwati, bertino}@purdue.edu.

Manuscript received 4 Dec. 2013; accepted 3 Apr. 2014. Date of publication28 Apr. 2014; date of current version 13 Mar. 2015.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference the Digital Object Identifier below.Digital Object Identifier no. 10.1109/TDSC.2014.2320731

150 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 12, NO. 2, MARCH/APRIL 2015

1545-5971� 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

The design of context based policy systems for smart-phones is challenging as it should fulfill the followingrequirements:

1) Applications should not be able to fake the locationor time of the device, as they should not be able tobypass the policy restrictions applied on the devicein a specific context.

2) As users are assumed to be mobile, the policy restric-tions should be applied automatically on the deviceas the device’s location changes.

3) The accuracy of location needs to be higher than thelocation accuracy by GPS, as we need to apply differ-ent policies in different spots or nearby sub-areaslocated within the same GPS location.

4) The enforcement of context-based policies shouldnot require the application developers to modifysource code, or impose any additional requirementon their applications.

5) The applied policy should not cause significantdelays in the device functionality that could nega-tively impact the system performance.

In this paper, we propose a context-based access control(CBAC) mechanism for Android systems that allows smart-phone users to set configuration policies over theirapplications’ usage of device resources and services at dif-ferent contexts. Through the CBAC mechanism, users can,for example, set restricted privileges for device applicationswhen using the device at work, and device applicationsmay re-gain their original privileges when the device isused at home. This change in device privileges is automati-cally applied as soon as the user device matches a pre-defined context of a user-defined policy. The user can alsospecify a default set of policies to be applied when the useris located in a non-previously defined location.

Configured policy restrictions are defined according tothe accessible device resources, services, and permissionsthat are granted to applications at installation time. Suchpolicies define which services are offered by the deviceand limit the device and user information accessibility. Pol-icy restrictions are linked to context and are configured bythe device user. We define context according to locationand time. Location is determined basically through visibleWi-Fi access points (AP) and their respective signalstrength values that allows us to differentiate betweennearby sub-areas within the same work space, in additionto GPS and cellular triangulation coordinates wheneveravailable. We implement our CBAC policies on theAndroid operating system and include a tool that allowsusers to define physical places such as home or work usingthe captured Wi-Fi parameters. Users can even be moreprecise by differentiating between sub-areas within thesame location, such as living rooms and bedrooms at homeor meeting rooms and offices at work. Once the user con-figures the device policies that define device and applica-tion privileges according to context, the policies will beautomatically applied whenever the user is within a pre-defined physical location and time interval.

We deployed our CBAC policies on the latest AndroidGoogle Nexus 7 tablet and the Google Nexus 4 phone tocompare the effectiveness of enforcing these policies in

different contexts. Our investigation involved 250 applica-tions and several test cases in various locations on ourcampus grounds with several Wi-Fi access points installed.Our experimental results show the effect of CBAC policieson Android applications and the policies impact on thesystem performance.

Organization. This paper is organized as follows. Section 2introduces basic concepts and background information. Sec-tion 3 presents a model overview of our access controlframework. Section 4 introduces our policy constructs andtheir classification followed by implementation and techni-cal details in Section 5. Section 6 emphasizes our techniquein managing context information and how we keep policyrestrictions up-to-date with device location. Section 7reports results of experiments to assess the accuracy of con-text information and the impact of policy restrictions onapplications. We analyze the security of our approach inSection 8. Sections 9 and 10 discuss related work and outlinefuture work, respectively.

2 BACKGROUND

In this section, we cover related background information onAndroid operating system and its access control mecha-nism, and some basics on location services.

2.1 Android

2.1.1 Operating System and API

The Android operating systems are derived from Linuxbased kernels and have enhanced support for security andprivacy [12]. Android is designed with a multi-layered secu-rity infrastructure, which provides developers a securearchitecture to design their applications.

Android applications are sandboxed and run inside theDalvik Virtual Machine, which isolates each application’sprocesses and data. Each application is assigned a user ID(UID) with assigned privileges, and is given a dedicatedpart of the file system for its own data. The processes ofapplications with different UIDs run separately and are iso-lated from each other and from the system. While applica-tions have limited access to device resources, developerscan explicitly request access for their applications throughthe Android permission system.

2.1.2 Permission System

The Android permission system controls which applicationhas the privilege of accessing certain device resources anddata. Application developers that need access to protectedAndroid APIs need to specify the permissions they need inthe AndroidManifest.xml file which, if inaccurately assigned,can increase the risks of exposing the users’ data andincrease the impact of a bug or vulnerability.

Each application declares the permissions listed in itsAndroidManifest.xml file at the time of installation, and usershave to either grant all the requested permissions to proceedwith the installation, or cancel the installation. The Androidpermission system does not allow users to grant or denyonly some of the requested permissions, which limits theuser’s control of application’s accessibility.

SHEBARO ET AL.: CONTEXT-BASED ACCESS CONTROL SYSTEMS FOR MOBILE DEVICES 151

2.1.3 Android Application Components

Every Android application is composed of four essentialcomponents: Activities, Services, Content Providers, andBroadcast Receivers. An Activity defines an application’suser interface. The Service component is designed to be usedfor background processing. The Content Provider componentacts as a global instance for a particular application, so thatall applications on the device can use it. It stores and man-ages a shared set of data belonging to the owner applicationusing a relational database interface. Finally the BroadcastReceiver component acts as mailboxes that allows applica-tions to register for system or application events. All regis-tered receivers for an event will be notified by Androidonce this event happens.

2.1.4 Intents

Intents are asynchronous messages that allow the threecore application components Activities, Services, and Broad-cast Receivers to communicate and request functionalityfrom each other. Communication between componentsoccurs within the application own processes or acrossexternal applications. Intents are used for many purposessuch as data transfer, service requests, and applicationaction requests.

2.2 Location Positioning Methods

In our paper, we rely on Wi-Fi-based positioning techniquesto retrieve the location of the device. In addition to thesetechniques, we also collect location data retrieved from theGlobal Positioning System (GPS) and cellular networks forsituations where there is no Wi-Fi coverage in the areas ofinterest. Moreover, we use public GPS location data indefining policy contexts for areas that have not been previ-ously visited, as described in Section 6. In this section, weintroduce a brief description on methods used in smart-phones for locating the devices.

2.2.1 GPS Trilateration

GPS is a positioning tool available in most smartphoneswhich uses data signals from satellites to compute the posi-tion of the device. Data received from satellites contains thetime stamp of sending, the orbital information, and the posi-tion of satellites. With at least three different satellite sig-nals, the GPS uses the trilateration method to calculate thedevice’s location by measuring the satellite signals time dif-ference or their received signal strengths. The location infor-mation provided from the GPS includes the latitude,longitude, altitude, and time. The accuracy of this method isestimated to be in the range of 50 to 100meters.

2.2.2 Cellular Triangulation

Cellular triangulation (cell ID) is another positioningapproach based on cellular technology. It refers to trackinga mobile phone’s current location using radio towers.Through contacting every nearby antenna tower, cellulartriangulation can make a measurement of how far away thecellular mobile device is based on the signal it is transmit-ting. This is done by measuring signal strength and theround-trip signal time. Once this distance is calculated, finer

approximations can be done by interpolating transmittingsignals between adjacent radio towers. The accuracy of thismethod varies according to the density of cell towers exist-ing in an area. For instance, the accuracy in large cities canreach up to 10 meters due to the high density of cellulartowers that a device could be in contact with [13].

2.2.3 Wi-Fi Positioning Method

Many smartphone devices nowadays rely on Wi-Fi-basedpositioning techniques due to its efficiency in computingthe location of a device especially in places when GPS andcellular signals are weak or unavailable [14]. These techni-ques are based on comparing the device’s received Wi-Fiaccess points with database fingerprints containing Wi-Fiaccess points with known geographic locations [15].

In our work, smartphone users will define their owndatabase of Wi-Fi APs which only includes the user’s areasof interest. In addition to the Wi-Fi APs, we also store theReceived Signal Strength Indication (RSSI) of each AP toenhance the positing accuracy of the device, which in ourcase, needed to differentiate between nearby sub-areas. Wedescribe in details how we capture and store these Wi-Fiparameters in Section 6, in addition to how we use them fordetecting the device location.

3 MODEL OVERVIEW

In this section, we present an overview of our access controlframework through describing its components and the roleof its entities.

Our framework consists of an access control mechanismthat deals with access, collection, storage, processing, andusage of context information and device policies. To handleall the aforementioned functions, our framework designconsists of four main components as shown in Fig. 1.

The Context Provider (CP) collects the physical locationparameters (GPS, Cell IDs, Wi-Fi parameters) through thedevice sensors and stores them in its own database, linkingeach physical location to a user-defined logical location. Italso verifies and updates those parameters whenever thedevice is re-located.

The Access Controller (AC) controls the authorizations ofapplications and prevents unauthorized usage of deviceresources or services. Even though the Android OS has itsown permission control system that checks if an applicationhas privileges to request resources or services, the AC com-plements this system with more control methods and spe-cific fine-grained control permissions that better reflect theapplication capabilities and narrow down its accessibility to

Fig. 1. Access control framework.


resources. The AC enhances the security of the device sys-tem since the existing Android system has some permis-sions that, once granted to applications, may giveapplications more accessibility than they need, which mali-cious code can take advantage of. For example, the permis-sion READ_PHONE_STATE gives privileged applications aset of information such as the phone number, the IMEI/MEID identifier, subscriber identification, phone state(busy/available), SIM serial number, etc.

The Policy Manager (PM) represents the interface used tocreate policies, mainly assigning application restrictions tocontexts. It mainly gives control to the user to configurewhich resources and services are accessible by applicationsat the given context provided by the CP. As an example, theuser through the PM can create a policy to enable locationservices only when the user is at work during weekdaysbetween 8 am and 5 pm.

The Policy Executor (PE) enforces device restrictions bycomparing the device’s context with the configured policies.Once an application requests access to a resource or service,the PE checks the user-configured restrictions set at the PMto either grant to deny access to the application request. ThePE acts as a policy enforcement by sending the authoriza-tion information to the AC to handle application requests,and is also responsible to resolve policy conflicts and applythe most strict restrictions.

Through the PM, users can create CBAC policies throughconfiguring application restrictions and linking them to con-texts. When an application requests a resource or service,the AC verifies at run-time whether the application requestis authorized and forwards the request to the PE. If therequest is authorized, the PE then checks if there is any pol-icy that corresponds to the application request. If such a pol-icy exists, the PE requests from the CP to retrieve the contextat the time of the application request. The PE then comparesthe retrieved context with the context defined in the policy.In case of a match, the PE enforces the corresponding policyrestrictions by reporting back to the AC to apply thoserestrictions on the application request.

We carefully design the access control framework so thatthe user-configured policies are securely enforced with min-imal processing steps and execution time to avoid any sig-nificant delays in responding back to the requestingapplication. As our design should securely handle policyexecution, we maintain the context data provided by the CPto make sure it is accurate, precise and up-to-date.

4 POLICY CORE MODEL

In this section we describe the core policy constructs thatcompose our CBAC policies. We start by defining the policyconstructs and then categorize our policies according to thetype of restrictions and modifications that we need to applyto the Android OS.

4.1 Policy Constructs

We define our CBAC policies as a set of restrictions appliedto the smartphone applications when the device is locatedwithin a specified context. Policy restrictions represent theconstraints applied on the applications’ privileges in access-ing device resources, system methods, functions, user data,

and services. Policy contexts represent to where and whenthe policy must be enforced.

In what follows, we assume three sets: (1) SUB the set ofsubjects representing the device applications, (2) OBJ the setof protected objects (objects, for short) representing the per-missions, services, and functionalities available for the sys-tem or applications, and (3) ACTION the set of restrictionactions that can be applied through the CBAC policies.

The set of subjects SUB is composed of the PackageNamesof all applications installed on the device. In addition, a spe-cial character � is added to the set to represent all installedapplications. This character is useful for policies that needto be enforced on all applications, rather than creating thesame policy for every application. Moreover, we assumethat each object from set OBJ has an associated type fromthe set {Permission, Data, Intent, System_Peripheral}. Let obe an object from the set OBJ; notation type(o) denotes thetype of o. The set of actions ACTION defined for our CBACmodel includes the following actions:

revoke_Permission: denys permission(s) from beinggranted to application(s).

shadow_Data: conceals the actual user data stored on thedevice.

disable_Intent: intercepts and drops the specified intentmessage.

save_State: disables toggling the state (ON/OFF) of thespecified system peripheral.

Definition 1 (Restriction). Let s 2 SUB, o 2 OBJ , anda 2 ACTION . A policy restriction is defined as the tuple½s; o; a� such that:

a ¼revoke Permission if type(o) = Permission:shadow Data if type(o) = Data:disable Intent if type(o) = Intent:save State if type(o) = System Peripheral:

8>><

>>:

Access control policies are linked to a context that speci-fies where and when these policies should be enforced. Inour model, the policy context is composed of a device loca-tion and a time interval. The device location corresponds towhere a policy should be enforced. For defining a devicelocation, we use the reference geometric model thedescribes how locations on Earth are represented. We adoptthe spatial model compliant with Open GeoSpatial Consor-tium (OGC) [16] that uses the notion of GIS features. Fea-tures have a defined geometry (points, lines, or polygons) ina reference space, with points to represent a feature with asingle location in the coordinate space, lines to represent afeature that has a linear interpolation of an orderedsequence of points, or polygons to represent a feature thathas an ordered sequence of closed lines defining the exteriorand interior boundaries of an area. Features also have types(road, town, region) and can be given an instance for eachtype (Champs-Elysees, Paris, lle-de-France).

Specific to ourCBACpolicies, we define the device locationas the physical location that represents a geographicallybounded feature (such as a residential and/or commercialbuilding), with boundaries specifying the interior area inwhich the device is located. The physical location data andboundaries are obtained from the mobile device sensors,mainly captured fromGPS, cellular network, andWi-Fi device


sensors as detailed in Section 6. In addition to the device phys-ical location, users can assign logical location names to the fea-ture or sub-area (such as living room or work office) in whichthe device is located. Using these logical location names, userscan reuse them inmultiple policieswithout the need to re-cap-ture the device physical location for every policy.

On the other hand, a policy time interval represents thespecific time period within which a policy should beenforced. We represent the specific date and time in the for-mat of YYYY-MM-DD-hh:mm:ss. Additionally, we intro-duce the R flag to define recurring events. The value of R isdrawn from the set {O, D, W, M, Y} defining the event fre-quency: O ! once, D ! daily, W ! weekly, M ! monthly,and Y ! yearly. An event is recurred based on the value ofR and the date/time set in the policy time interval. Forexample, to set an event that occurs every Monday from 5to 10 pm, R is set to W and the time interval should be set toa sample event date-time, such as starting on 2013-04-01-17 : 00 : 00 and ending on 2013-04-01-22 : 00 : 00.

Definition 2 (Context). Let LOC be a logical location name rep-resenting a particular feature or sub-area. Let fST;ET;Rgrespectively be the starting time, ending time, and frequency towhen a particular policy should be enforced. A policy contextis defined as the tuple [LOC, {ST, ET, R}].

Definition 3 (Policy). Let r be a restriction as defined in Defini-tion 1 and c be a context as defined in Definition 2. A policyis defined as a tuple ½r; c�.Below is an example of a policy that disables the Skype

application from having the Camera permission monthlybetween 4.00 and 5.00 pm on the first of every month start-ing August 1, 2013 at our department meeting roomRoom110:

POLICY ¼ [[com.skype.raider,android.permission.CAMERA, revoke_Permission],[Room110,{2013-08-01-16:00:00, 2013-08-01-17:00:00, M}]]

4.2 Policy Categories and Examples

We here classify location dependent run-time policiesaccording to the type of restrictions and modifications thatwe need to apply on the Android OS. Table 1 displaysexamples of policy restrictions for each policy category.

Resource restriction policies. This category corresponds tothe Android resource permissions, mainly restricting deviceapplications from using certain resources such as Camera,GPS, etc. As Android applications are granted all their set ofrequested permissions upon installation, this category dealswith policies that can manage these permissions and controlthe applications’ access to system resources post-installa-tion. Permission restrictions are either applied system-wideor per application, as it is also possible to revoke some or all

of the previously granted permissions per application. Thesepermissions are managed by intercepting an application’srequest to use a permission at run-time, and then determineif the permission should be granted or denied depending onthe current context. We discuss technical details on how toachieve permission restrictions in Section 5.

In situations when a resource, such as a camera, can beaccessed by the application using more than one possiblemethod, we automatically create the appropriate policiesthat can restrict all these methods, as users have no knowl-edge of what method the application is using. For instance,the camera resource can be either requested directlythrough the Camera API (requires permission) or indirectlyby calling a camera intent message (no permission needed).For this reason, we complement the camera-related policywith two intent-related policies, one for capturing imagesand another for capturing videos.

Data access policies. This category relates to user datastored on the device such as Contacts, Calendar, Accounts,etc. As device users might wish to disable their applicationsfrom accessing such data at specific contexts, we designdata-specific CBAC policies that allow users to set restric-tions on data access per application or system-wide. Thesedata access policies are enforced through obfuscating thedata request and returning empty lists of the request data.We discuss more details in Section 5.

Similar to the resource restriction policies, we createadditional policies to cover all possible methods of access-ing Contacts, mainly intent-related policies.

System peripheral state policies. This category relates to pol-icies that restrict applications from modifying the state ofthe device peripherals, such as toggling the Bluetooth state.While some developers may embed functionality for chang-ing the state of device peripherals within their applications,users can disable such functionality in specific contexts thatwill restrict the configured applications from overriding theuser’s choice of the state of these peripherals. Restrictionson system peripherals are implemented mainly throughmodifying the peripheral API method to intercept anyapplication’s request to enable/disable a particular systemperipheral. Section 5 contains more details on how toachieve these restrictions.

Multitasking and intercommunication policies. This categorycorresponds to policies that restrict data communicationand messages between different device applications inwhich many system restrictions can be applied. Forinstance, users may choose to disable multitasking andenable only one application to run at a time. Moreover,users may choose to automatically close all running applica-tions whenever the device location is changed. These sys-tem restrictions are achieved by intercepting system andapplication Intentmessages as we discuss in Section 5.

TABLE 1Policy Categories and Examples


User security policies. This category of policies relate tomodifications of the security level of the device whichallows users to specify security restrictions based on con-text. With these policies, users can specify the context inwhich to ask for a passcode for using the device. Users canalso choose to block certain applications from loading andrunning at a specific context, while enabling them at differ-ent contexts. Finally, as some applications may have func-tionality for installing/uninstalling other applications andscripts, users can use these policies to disable this function-ality to avoid installing malicious code in the device. Usingthese types of policies, a user may choose to disableuntrusted applications from running while at home. Asthese applications may use device sensors to track its users,device owners can temporarily block these applicationswhen located in private places, and enable them in otherpublic locations.

5 IMPLEMENTATION

In this section, we introduce the technical details of ourimplementation which includes our modifications to theAndroid OS and the components of the Policy Manager cus-tom application that acts as an intermediary between the OSand the user’s desired policy configurations.

5.1 Policy Manager Components

The Policy Manager custom application consists of the fourmain Android application components: Activities, Broad-cast Receivers, a Content Provider, and a Service.

Activities. The user interacts with the Policy Manager viaactivities, and through these activities, a user is able todefine physical locations and subsequently configure a setof policies for these locations. The main constituents of theseactivities include Application Events, Permission Access,Resource Access, System Preferences, and Time Restriction.

BroadcastReceiver. We extended the Android’s Broadcas-tReceiver class and created two custom classes, the StartLo-cationServiceReceiver and the BootReceiver classes. TheStartLocationServiceReceiver is responsible for triggeringour customized LocationService for retrieving device loca-tion information. The BootReceiver’s main task is to sched-ule when the StartLocationServiceReceiver should requestthe location service. Once the BootReceiver receives theBOOT_COMPLETED Intent from the system, it uses theAndroid’s AlarmManager service to let the receiver sched-ule a pending Intent to be sent periodically to our StartLo-cationServiceReceiver in order to update the device location.

Service. The LocationService service is derived from theIntentService class that facilitates offloading work from themain application’s thread, allowing tasks to be performedin the background on a separate thread if desired. Location-Service determines if the device has moved to or still is in apreviously registered area. Offloading the aggregation oflocation-based data in a separate thread reduces the perfor-mance impact of the execution of the LocationService on thePolicy Manager. We use the AlarmManager to periodicallyactivate the LocationService to ensure the device’s location isalways up-to-date. By default, the LocationService is acti-vated once per minute, but we give the user the choice toconfigure how often the service is executed. The duration of

the service depends on the number of snapshots of locationparameters to be taken, which is currently configured tofour per area.

Content provider. The policies configured by the user arestored within the Policy Manager data directory. This data isprivate to our custom application and cannot be accessedby other applications or the system itself, as a result ofLinux’s kernel user ID access control mechanisms. PolicyCPis our custom content provider that acts as a secure interme-diary between the policy database and all objects outside ofthe Policy Manager’s running process. We chose to use theSQLite database to store user-configured policies due to thesupport and ease of programming provided by the AndroidAPI’s associated with storing and managing databases onAndroid devices.

We provide some built-in policies that are pre-configuredand can easily be modified to achieve the required userneeds. Moreover, we can also refer to existing usability tech-niques [17], [18], [19], [20] that can be used to offer regularusers with preset and adapted policy configurations.

5.2 Permission Management

In the Android system, all resources that require explicitaccess rights in the form of permissions are protected by theActivityManagerService class via permission verification.When an application attempts to use any of these resources,the ActivityManagerService’s method called checkComponent-Permission is invoked to verify if the calling application hasthe appropriate permission(s) to access the resource.

We apply our modifications to this particular method bysimply intercepting the permission call before the systemperforms its standard permission verification process.Given the permission and the application name, the systemsubsequently calls our custom content provider’s revokeRe-sourceAccess to determine the next course of action. Depend-ing on the user’s policy configuration, the next course ofaction could either be returning the constant PackageMan-ager.DENIED in the checkComponentPermission if the userhas configured to block that permission from the requestingapplication, or letting the normal verification process takeits course. We also give the ability to revoke any or all per-missions system-wide via the PolicyManager’s interface.

5.3 Restrictions on User Data

Our implementation of data obfuscation complementsmany of the techniques previously used in [21] and [22], butinstead under the domain of CBAC policy restrictions. Weobfuscate user data from applications attempting to accessit if the policy restriction applies to those applications. Wemodify the Android APIs that access the user data saved onthe device.

Relational database systems are the common data man-agement systems used to create, store, and manage userdata. Accessing these data usually require calling the Con-tentResolver’s query() method, and thus we modify it for ourpurposes. Instead of returning the expected Cursor objectneeded to point to the required data, a NullCursor object issubstituted. A NullCursor object represents an empty dataset, such as an empty list of pictures as if pictures were notpresent or never stored on the device.


5.4 Managing System Peripheral State

We also give users the option to configure a policy to restrictaccess to peripherals (e.g., Bluetooth) when entering a par-ticular location. Specifically, users can set up their devicesto prevent applications from modifying a peripheral’s cur-rent state (enabled/disabled). While it is possible to modifya peripheral’s current state by using permission manage-ment, we modify the specific methods that enable/disablesthese peripherals in order to prevent applications fromcrashing that do not have code for handling exceptionsresulting from revocation of permissions. As an example,for Bluetooth we modified the BluetoothAdapter class and forWi-Fi we modified the WifiManager class so to assure thatthese modifications do not result in application crashes andto prevent applications from modifying peripherals currentstate. Whenever an application tries to modify the state of asystem peripheral, our content provider PolicyCP checks thevalidity of the request and would refuse the request if therequest tries to override a user-configured restriction.

5.5 Intent Management

Intent messages are one of the common forms for inter- andintra-communication between application components, sentvia three methods: startActivity(), sendBroadcast(), and start-Service(). Preventing an application from sending intents issimply a matter of intercepting the intents when the afore-mentioned methods are called by applications. Intent inter-ception provides the user the ability to prevent anapplication component from starting another activity,broadcasting any possible sensitive information, or execut-ing a possibly suspicious background service. For example,without the need of declaring the Android permission”RECORD_AUDIO”, an application can indirectly accessthe device’s microphone recorder application by requestingthe Activity class to send a record audio intent. Therefore,we modified the Activity class which hosts startActivity()and startActivityForResult(), and the ContextWrapper classwhich contains sendBroadcast() and startService(). We modi-fied these methods to intercept the Intents and control theactions performed based on those Intent objects.

We classify these Intents based on the contents anddescription of the intent objects. The user is given, via thePolicy Manager interface, the ability to prevent a specific setof Intents from being sent. Table 2 lists few examples ofthese Intent-related restrictions.

Launching applications is achieved by intercepting thoseintents and preventing applications from being startedeither by users or by other applications. The first method iswhen users launch applications through the defaultAndroid Launcher application, which is the home screen of

the device. The second method for starting another applica-tion is calling its activity within an already opened applica-tion. We extract the action and category from the Intentobject, and verify if it is “android.intent.action.MAIN” and“android.intent.category.LAUNCHER”, respectively. Ifthose specific contents are present and if the simultaneousrunning of applications is restricted, we discard the intentpreventing the framework to handle it.

Finally, through the Intent management, users can con-trol when to request a pin code when unlocking the device.In our implementation, we modify the KeyguardViewMedia-tor class in order to intercept the locking operation of thedevice, and thus controlling when a PIN is required.

To summarize, users will have all the options to specifyapplications restrictions associated with context datathrough the policy managers. In the policy manager, thepermission management is used to configure applicationrestrictions related to device resources (e.g., Camera).Restrictions on user data are used to shadow user data (usu-ally saved in relational databases) and to return fake data tothe application (e.g., Contacts). Managing system peripheralstate is used to control applications actions in toggling thestate of certain resources (e.g., enabling/disabling Blue-tooth). Finally, intent management is used to control thecommunication between applications and filter user andapplication actions on the system. Intent management isalso used to configure restrictions on applications accessingresources, as in some cases, these applications are devel-oped to access system resources indirectly through using anintent message rather than requesting a permission.

6 CONTEXT MANAGEMENT

The main source of location-related information for ouraccess control system is the Wi-Fi APs and their correspond-ing signal strengths. Location information acquired fromGPS and cellular towers is also aggregated to our contextdefinition but may not be sufficient for indoor localizationespecially that they may become weak or unavailable insidebuildings or areas within building structures [23], [24].However, location information retrieved from Wi-Fi param-eters could be more precise to differentiate between closelylocated sub-areas within the same GPS location [25], [26].

A spatial region is represented by combining GPS coordi-nates, cellular triangulation location data, and Wi-Fi APsand signal strengths. In Android, the GPS coordinates andcellular triangulation are obtained in a similar fashion byinvoking the Android LocationManager service. Once theLocationManager is invoked, we request location updates bycalling the requestLocationUpdates method that returns aLocation object which contains latitude, longitude, time-stamp, and other information.

Wi-Fi is handled differently than the previous two loca-tion methods. We obtain the Wi-Fi parameters by invokingthe WifiManager service to retrieve the Wi-Fi access pointsscans. We register our BroadcastReceiver mWifi_receiver withan IntentFiler action to receive the broadcasted Wi-Fiscanned intent, and then request for and subsequently pro-cess the actual scanned access points data.

In our CBAC policy system, we provide users with a util-ity to either capture the physical location of the device or to

TABLE 2Examples of Policy Restrictions That Can Be Controlled via

Intercepting Intents


manually enter the device location coordinates. In the fol-lowing sections, we show our design and implementationof the location capturing phase and detection phase andhow the device’s context is matched with a pre-defined pol-icy context.

6.1 Location Capturing Phase

Fig. 2 describes how location data is captured for each con-text defined by the user. Through the location scan interface,the user is able to capture several snapshots of location datain different sub-areas. For each sub-area, location data isaccumulated from each snapshot; the GPS coordinates andthe cellular triangulation, when applicable, import the lati-tude and longitude from the captured snapshots and onlyselect those with the highest position accuracy. With respectto Wi-Fi, we noticed that the Wi-Fi access points signalstrengths fluctuate even if the device is stationary ormotionless. Therefore, our application scans the signalstrengths of each access point for several seconds gatheringthe RSSI values at each particular sub-area. Finally, theaccumulated data, which mainly consists of Wi-Fi accesspoints with signal strength ranges in addition to GPS andcellular triangulation data as supporting location informa-tion, will represent the device’s physical location.

Any location that is not defined by the user or does nothave location information saved on the device will be con-sidered “Unregistered”. Therefore, we designate a defaultpolicy restrictions for the user to configure whenever thedevice is located in an unregistered location. In addition,we allow users to register locations that have not been pre-viously visited. This is achieved through either manuallyentering the publicly known longitude and latitude of thedesired location, or by acquiring the fine-grained Wi-Fiparameters from other devices who have saved thoseparameters. This becomes very practical when the user isswitching between two devices and needs to import previ-ously saved policy contexts to the new device.

Our implementation does not store all the GPS or tri-angulated cellular coordinates acquired, rather a subsetof those coordinates that bound into a convex hull andtheir associated precision. The points in the interior ofthe convex hull are discarded. We also only store theRSSI range for each distinct Wi-Fi access point scanned.This range is the minimum and maximum RSSI valuesaggregated from all the sub-areas for each access point.A sub-area is therefore represented as a range of Wi-Fi

signal strength values at the least, and if with high posi-tion accuracy, also a representation of a convex hull ofGPS or triangulated cellular coordinates.

6.2 Location Detection Phase

Fig. 3 describes how device context is detected and matchedwith pre-defined context. Periodically, the location back-ground service is re-instantiated to accumulate location-context data to determine the device’s current whereabouts.Like when registering and scanning a sub-area in the loca-tion capturing phase, we scan the device’s location-relateddata. The list of user-registered areas that have a subset ofthe scanned neighboring access points are extracted fromthe database first. Matching distinct access points is compu-tationally less expensive than determining if coordinateposition falls within the boundaries of a convex hull. Then,using the current signal strengths of the access points, wereduce the list to only a set of “best-match” list of physicallocations whose access points fall within the current cap-tured signal strength values. If the current scanned GPS orcell network coordinates fall within the convex hull of theassociated sub-area, then it is highly likely that the sub-areahas been located.

In the unlikely situation when the “best-match” list ofphysical locations contain more than one location, the useris given the list to confirm his/her location. Even thoughthis event is unlikely to happen, it may still occur becauseWi-Fi access point’s signal strengths are volatile; their signalstrengths fluctuate at a given location. As a consequence, anaccess point’s signal may be, at some point, too weak for theAndroid’s device sensor regardless of whether the device isin motion or stationary. In the location capturing phase, weaggregate the retrieved data that records a range of RSSIvalues from different sub-areas within the same location,for example, instead of just a single snapshot. In the detec-tion phase, however, we take a snapshot of the locationdata, which may have only a subset of the previously aggre-gated data. We compare the previously stored values withthe snapshot data. Specifically, with respect to Wi-Fi, wedetermine if the captured RSSI value of a particular accesspoint is within the stored range. We perform this operationfor each access point captured in the snapshot and countthe number of tests passed, which is the basis in determin-ing the physical location of the device.

Fig. 2. Location capturing phase.

Fig. 3. Location detection phase.


7 EXPERIMENTAL RESULTS

In this section, we report experimental results about theCBAC mechanism and evaluate its impact on the devicesystem and applications. Our modifications to the Androidsource code were tested on the Android Nexus 4 cellulardevice and Android Nexus 7 tablet running the Android4:2:2 OS (API level v. 17). We ran the top 250 applicationsfrom the Google Play market for testing and evaluating ourmodifications. Each experiment has been carried out withthe help of the Android Debug Bridge (ADB) utility byusing the command “adb logcat”. We inserted logging com-mands in various parts of the operating systems wheremodifications were made to observe, for example, applica-tion access events.

Experiment 1: Location detection accuracy. The goal of thisexperiment is to evaluate the accuracy of the location detec-tion algorithm used in our CBAC mechanism. We measurethe number of success and failure detections per sub-area.Fig. 4 displays the schematics of one building where we per-formed some of our experiments. The large, grid-patternrectangles point out main locations or areas, identified bynumbers. Areas outside the rectangles are considered“unregistered.” The black circles indicate the specific sub-areas examined during the location capturing phase. Allother colors indicate other sub-areas examined during thedetection phase.

Fig. 4 shows three tested rooms located on the same floor.However, our experimentation included several buildingsand areas. In each room, we chose at least four spots to par-ticipate in the location capturing phase to accumulate loca-tion-related data, in order to construct a robust set oflocation parameters per room to be stored in the database.In each location, we analyzed three sub-areas, indicated by‘A’, ‘B’, or ‘C’ and measure the detection rate in each ofthese subareas. For that particular floor which contains over15Wi-Fi access points, we captured the top five Wi-Fi accesspoints per snapshot with the highest signal strength for eachtested sub-area.

Fig. 5 displays the detection accuracy rate in the threesub-areas of rooms 1, 2 and 3. At each of the sub-areas ofeach room, we performed 50 location tests and counted thenumber of successful detections. Our experimental resultsshow that the successful detection rates were up to 91 per-cent, and in the worst case scenario we had up to 29 percentof incorrect detections. This experimental result was

complemented by testing several “unregistered” areasaround the registered rooms. We detected 16 percent offalse positives, that is, unregistered areas that appeared tobe user-defined. Within the registered areas, the values ofthe signal strengths of matching Wi-Fi access points fellwithin the range of signal strengths first acquired duringthe location capturing phase. However, in the unregisteredareas, especially the further away the device was when thesnapshots at the location capturing phase were taken, thevalues fell outside the stored range because of buildingstructures hindering the Wi-Fi signal strengths.

Experiment 2: Impact of permission restrictions. The purposeof this experiment is to observe the impact of permission-related policy restrictions on applications. Specifically, weare interested in whether or not an application crashes as aresult of being denied a permission that was initiallygranted at installation time. Therefore, we performed astress test on each application and observed the impact onthe application upon revoking its permissions whenrequesting a service or resource. We performed our experi-ment on 245 Android applications and used the ADB log-ging utility to view the permission being revoked when thecheckComponentPermission()method is called.

Fig. 6 shows the percentage of application crashes uponperforming the stress test on each permission. We countedan application as crashing even if it crashed during the exe-cution of one minor functionality. The main cause of thesecrashes is due to the developers’ mishandling the denial ofpreviously granted permissions. Since application crashesare due to developers’ mishandling the denial of previouslygranted permissions to their applications, application

Fig. 4. Tested areas in one of our campus buildings.

Fig. 5. Detection accuracy rate of closely located areas.

Fig. 6. Impact of permission revoking on applications.


crashes can be prevented if error-handling is added when-ever an application attempts to access a resources or requesta service. In fact, throughout testing several application ver-sions, we realized that the number of application crasheshas been decreasing over time. This is because developersare now aware that not having the permission error-mis-handling script is causing several application crashes. Ascript is thus being added in their application updates espe-cially with the evolvement of many permission restrictiontechniques.

Experiment 3: Performance overhead. The purpose of thisexperiment is to evaluate the timing overhead introducedby our modifications to the Android OS. We calculate theamount of time it takes for our modified methods to fullyexecute once called by applications. We also compare theexecution times of these methods before our modificationsto estimate the overhead introduced by our modifications.Specifically, we measure the overhead time caused byintercepting application permissions, user data accesses(e.g., Contacts), Intent messages, and access to systemperipherals (e.g., Bluetooth).

Table 3 reports in milliseconds the time imposed on thesemethods. As the results show, the overall delay introducedby enforcing our CBAC policies is not perceivable by theend-user.

Experiment 4: System memory overhead. The purpose ofthis experiment is to measure the amount of memoryoverhead placed on the system after our modifications.Mainly, we aim to observe the changes in memory usagecaused by our application restrictions and by the Loca-tionService method that continuously run in the back-ground for context updates.

Fig. 7 shows that the memory usage when enforcing ourCBAC policies closely matches the memory usage whenthese policies are not enforced. Even though our experi-ments test the different restriction categories separately asshown in the figure, we believe that the observed memoryoverheard is due to the LocationService that is instantiatedperiodically to keep the device’s context up-to-date.

Experiment 5: Battery consumption. The purpose of thisexperiment is to observe the Android device’s battery con-sumption change when CBAC policies are enforced com-pared to when they are not. For this purpose, we monitoredthe device’s battery percentage when running both theunmodified OS and our customized system, separately. Inboth cases, we forced the device’s screen to never turn offwith Wi-Fi and GPS enabled, a representation of a somehowworst case scenario as when the user is continuously usingthe device for that duration. Since the period for which theLocationService method that is responsible for checking thedevice’s location can be customized by the user, we testedthe battery consumption for different time periods for thepurpose of getting a fair evaluation.

We started our experiment by setting the device tocheck for any device location updates every 30 seconds.Fig. 8 shows that the battery percentage displayed on thedevice when enforcing our CBAC policies drops � 5% lessper hour compared to when the policies are not enforced.We achieved similar results when context was updatedevery 45 seconds. However, when we set the timer tocheck for device context every 60 seconds or above, thebattery usage percentage of when the CBAC policies areenforced closely matches the battery consumption whenthe policies are not enforced.

8 SECURITY ANALYSIS

In this section, we present a security analysis of our imple-mentation of the CBAC system to analyze possible threatsfrom a malicious user or applications that can bypass ourpolicy restrictions. The aim of our security analysis is toidentify possible threats by malicious users or applicationsthat can bypass CBAC policies and to mitigate these threats.

Colluding applications. In Android, each device applica-tion is assigned a unique UserID that the system uses torefer to an application. However, if two applications are

Fig. 7. Total memory overhead comparison with and without our CBACpolicy restrictions.

Fig. 8. Comparison of device battery consumption when checking forcontext updates every 30 seconds.

TABLE 3Time Overhead (in Milliseconds) for Some of the Core Android

Methods That Were Modified


created and signed by the same developer, the system willgive both applications the same UID, which gives theseapplications the ability to share the same processes ifneeded [27]. The stock Android OS applies its security poli-cies not based on the application label or its package name,but rather on the process UID. In our modifications of theOS, we obtain the name of the package (application) whichis performing an action by calling the PackageManager’sgetPackagesForUid(int uid). This way, our restrictions are notbased on UID but are transformed in order to refer to thepackage name. As an example of such threat, consider twoapplications, Application A and Application B, that sharethe same UID. Suppose that the user blocks access to GPScapabilities from application A. However, although success-fully blocked, application A may still be able to acquireinformation about the user’s or device’s location becauseApplication B was not denied access to GPS. In our system,we prevent such threat by blocking all package names asso-ciated with a UID using the getPackageForUid()method.

Circumventing application multitasking restriction. A mali-cious developer may attempt to bypass the restriction thatdisallows multiple applications from running simulta-neously by creating a custom launcher-like app. Android ismodular, and thus the default home screen can be replaced.Our system is not vulnerable to such an attack because wecheck all possible intents as our system is not limited tointents related to the stock Launcher. Thus any intent with“android.intent.action.MAIN” and “android.intent.cate-gory.LAUNCHER” will be intercepted and processed todisable multitasking of any launcher the user decides to use.

Protection of policies. As users can configure policy restric-tions based on time and location, these restrictions are eitherapplied system-wide or per application. If these policyrestrictions can be altered by applications, then any mali-cious application can perform specific attacks based on pol-icy configurations. To protect policies, we thus do not allowwrite privileges to be granted on policies so to prevent poli-cies from being modified.

Malicious applications that are aware of our CBAC poli-cies may try to drop a policy or modify the device’s detectedcontext so that the wrong policy is applied. However, in ourimplementation we retrieve context information directlyfrom the system protected APIs that cannot be altered byapplications. Moreover, context information is managed byour Content Provider that gathers such information regard-less of which applications are running on the device or serv-ices requested by applications. This independency from theContent Provider gives robustness in gathering context datathat is forwarded to the Policy Manager as discussed inSection 3.

Sensitive information disclosure. Some applications maymaliciously leak private user information once they detectthat a previously granted privileged application is revoked.As an example, a malicious application that was grantedaccess to Camera and GPS at installation time may uploadthe device GPS location to the application server once itdetects that the CAMERA permission is revoked, leakingthe user-private location. For this reason, our implementa-tion provides the user, at the time of policy configurations,with a list of privileges that are still granted to the config-ured applications, acting as a warning for the user to be

aware of the sensitive information still accessible by the con-figured applications in a particular context.

Continuous running application processes.When an applica-tion requests access to a resource, the Android OS checks ifthe application has the appropriate permission(s) just at thetime of the request. If the user-configured policy grantssuch permission to the requesting application in a givencontext, some processes associated with certain resourcesmay continuously run even if the device is later located in adifferent context for which the user has denied access tosuch resource. The reason is that permission granting is notchecked continuously while the process is running, rather isonly checked when the request is issued. Malicious applica-tions may take advantage of this, for example by continu-ously recording audio in one context while transitioning toanother context.

Audio recording using the Microphone resource is oneexample of a continuously running process that will not ter-minate until the recording is stopped. Take for example auser who attends private meetings in a same meeting roomthat he configured a policy to disable the Microphoneresource. A malicious application can begin recording out-side of the meeting room area without alerting the user, andcontinue recording when the user enters the restricted meet-ing room. The Android OS does not continuously verifywhether an application has audio recording permissionduring recording. It verifies each time a request is made,and thus when approved the application can continue usingthe peripheral for that specific session. Our implementationprevents this type of attack. Once a registered area is associ-ated with a restriction on video or record audio access, thelocation service forces the applications with the associatedpermissions in their AndroidManifest.xml to close.

9 RELATED WORK

The area of location-based policies on mobile phones isrelated to work done in the areas of access control policiesand techniques for reliable location information. Also, sinceour work applies policy restrictions on Android applica-tions, our work is also related to work on Android restric-tion techniques.

Several approaches have been proposed for context-based access control. Generalized Role Based Access Con-trol (GRBAC) is an approach that incorporates the conceptof environment information (such as time) into access con-trol [28]. GRBAC is very expressive and thus suitable forcontext aware authorization [29], [30]. However GRBACmay not be feasible in practice due to the large amounts ofenvironment roles that make the system very hard to main-tain. Zhang and Parashar proposed dynamic RBAC(DRBAC) that dynamically adjusts for roles and permis-sions based on context information [31]. GEO-RBAC isanother approach that incorporates spatial awareness intorole-based access control [32], [33], [34]. However, thesemodels are conceptual and just focus on high level abstrac-tion that does not specify on how to deploy theseapproaches on real implementations. For the purpose ofapplying those models to real implementations, Sandhuet al. proposed the notion of PEI (policy, enforcement,implementation) models that define a usable structure for


creating an implementation of enforcement mechanisms[35]. Kirkpatrick and Bertino defined such enforcementmechanism and emphasized the importance of authenticat-ing the user’s claim to a particular context through incorpo-rating the NFC technology into an access controlmechanism for information systems [10]. Gupta et al. pro-posed a context profiling framework based on the sur-rounding environment captured by the mobile devicesensors to estimate the familiarity of a place [11]. They usedsuch context to create context profilers that are used to con-figure access control policies on mobile devices.

Policy-specification languages also relate to our work asthey are intended to simplify the task of specifying andenforcing security policies on untrusted software. Examplesof expressive policy-specification languages are Ponder[36], XACML [37], PoET/PSLang [38], Naccio [39], Polymer[40] and Deeds [41]. However, none of these languages pro-vide user constructs to manage location information. On theother hand, OpenAmbient [42] and GEO-RBAC [43] areexamples of location-based policy-specification languagesable to manipulate location information but may fail indynamically changing roles or location that we require inour CBAC policies.

Our work also relates to techniques for providing reliablelocation information that can provide adequate securityguarantees once merged with security policies. GPS is themost commonly used technology for location purposes.However it is not very reliable when used indoor due to itslow signal power [14]. CellID, Bluetooth, or NFC technologieshave been extensively tested for proximity of device loca-tion [44]. However Madlmayr et al. [45] have shown thatthese technologies are not always reliable as they are vul-nerable to eavesdropping and collusion attacks. Therefore,our choice of using the Wi-Fi access points RSSI valuesseems to be the cheapest and most accurate as it does notrequire any extra hardware and is capable of differentiatingbetween closely located sub-areas. We benefit from techni-ques used for indoor localization and tracking purposes todefine the exact location parameters needed to form anaccurate indoor location [23], [24], [25], [26], [46].

Our work is also related to techniques implemented forthe Android OS to restrict device applications for protectingthe user privacy and device security. Past work has focusedon detecting applications that are over-privileged [47] andcategorized them based on their permission requirementsbefore installation, and their potential threats in case suchpermissions are granted and abused. Enck et al. [48] alsobuilt the Kirin tool that uses a formal model of policy mech-anisms to determine whether or not the privileges requestedby applications match the desired functionality. However,even though these mechanisms may solve the problem ofover-privileged applications, but they may not be able toaccurately differentiate between over-privileged and mali-cious or buggy applications, which represent our mainthreat. Roesner et al. [49] introduced user-driven access con-trol gadgets based on user intent, allowing Android users togrant resource privileges to their applications at the time ofuse. Our mechanism offers these controls with a largerscope of restrictions that give users a comprehensive controlover their device, with all restrictions tied to context. Otherresearchers have implemented detection mechanisms for

malicious applications [50], [51], [52], some of which areresponsible for user private information.

There are few approaches that have similar goals of our.The first [53] defines a language for specifying location-dependent runtime security policies. However ourapproach supports a wider range of policy restrictions andenforces them more efficiently on the Android system. Inaddition, our technique is able to acquire more accuratelocation information. Other closely related approches areAppFence [21], Apex [54], TISSA [55], and IdentiDroid [22]that have developed modifications to the Android OS inorder to limit data leakage and restrict application permis-sions. Our work complements these techniques by addingmore user controls and device restrictions (such as intentmanagement) and ties these configurations to context-basedpolicies that dynamically apply device restrictions. Ourwork also complements research efforts in protecting userand application data applied at the middleware and kernellayers of the Android OS, such as FlaskDroid [56], Moses[57], Saint [58], and TrustDroid [59].

10 CONCLUSION AND FUTURE WORK

In this work, we proposed a modified version of theAndroid OS supporting context-based access control poli-cies. These policies restrict applications from accessing spe-cific data and/or resources based on the user context. Therestrictions specified in a policy are automatically appliedas soon as the user device matches the pre-defined contextassociated with the policy. Our experimental results showthe effectiveness of these policies on the Android systemand applications, and the accuracy in locating the devicewithin a user-defined context.

Our approach requires users to configure their own set ofpolicies; the difficulty of setting up these configurationsrequire the same expertise needed to inspect applicationpermissions listed at installation time. However we plan toextend our approach to give network administrators oforganizations the same capabilities once a mobile deviceconnects to their network. In this way, network administra-tors are able to block malicious application accesses toresources and services that may affect the security of theirnetwork. We believe that such an approach is critical forassuring security of corporate networks when organizationsallow users to “bring their own devices”.

REFERENCES

[1] Wikipedia, (May 2013). Samsung galaxy s4 specifications.[Online]. Available: http://en.wikipedia.org/wiki/Samsung_Galaxy_S4

[2] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel,and A. N. Sheth, “Taintdroid: An information-flow tracking sys-tem for realtime privacy monitoring on smartphones,” in Proc. 9thUSENIX Conf. Oper. Syst. Des. Implementation, 2010, pp. 1–6.

[3] J. Leyden, (Apr. 2013). Your phone may not be spying on younow—but it soon will be. [Online]. Available: http://www.there-gister.co.uk/2013/04/24/kaspersky_mobile_malware_infosec/

[4] R. Templeman, Z. Rahman, D. J. Crandall, and A. Kapadia,“Placeraider: Virtual theft in physical spaces with smartphones,”in Proc. 20th Annual Netw. Distrib. Syst. Security Symp. (NDSS),Feb. 2013.

[5] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X.Wang, “Soundcomber: A stealthy and context-aware sound trojanfor smartphones,” in Proc. 18th Annu. Netw. Distrib. Syst. SecuritySymp., Feb. 2011, pp. 17–33.


[6] L. L. N. Laboratory, Controlled items that are prohibited on llnlproporty. (2013). [Online]. Available: https://www.llnl.gov/about/controlleditems.html

[7] M. Conti, V. T. N. Nguyen, and B. Crispo, “Crepe: Context-relatedpolicy enforcement for android,” in Proc. 13th Int. Conf. Inf. Secu-rity, 2011, pp. 331–345.

[8] A. Kushwaha and V. Kushwaha, “Location based services usingandroid mobile operating system,” Int. J. Adv. Eng. Technol., vol. 1,no. 1, pp. 14–20, 2011.

[9] S. Kumar, M. A. Qadeer, and A. Gupta, “Location based servicesusing android,” in Proc. 3rd IEEE Int. Conf. Internet MultimediaServ. Archit. Appl., pp. 335–339.

[10] M. S. Kirkpatrick and E. Bertino, “Enforcing spatial constraints formobile RBAC systems,” in Proc. 15th ACM Symp. Access ControlModels Technol., 2010, pp. 99–108.

[11] A. Gupta, M. Miettinen, N. Asokan, and M. Nagy, “Intuitive secu-rity policy configuration in mobile devices using contextprofiling,” in Proc. IEEE Int. Conf. Soc. Comput., 2012, pp. 471–480.

[12] W. Enck, M. Ongtang, and P. McDaniel, “Understanding androidsecurity,” IEEE Security Privacy, vol. 7, no. 1, pp. 50–57, Jan. 2009.

[13] E. Trevisani and A. Vitaletti, “Cell-id location technique, limitsand benefits: An experimental study,” in Proc. 6th IEEE WorkshopMobile Comput. Syst. Appl., 2004, pp. 51–60.

[14] J. LaMance, J. DeSalas, and J. Jarvinen, AGPS: A low-infrastructureapproach. (2002). [Online]. Available: http://www.gpsworld.com/innovation-assisted-gps-a-low-infrastructure-approach/.

[15] Sky hook. (2003). [Online]. Available: http://www.skyhookwire-less.com/.

[16] O. G. CONSORTIUM, “Open gis simple features specification forsql. revision 1.1,” 1999.

[17] M. Shehab, G. Cheek, H. Touati, A. Squicciarini, and P.-C. Cheng,“User centric policy management in online social networks,” inProc. IEEE Int. Symp. Policies Distrib. Syst. Netw., 2010, pp. 9–13.

[18] R. W. Reeder, L. Bauer, L. F. Cranor, M. K. Reiter, and K. Vaniea,“More than skin deep: Measuring effects of the underlying modelon access-control system usability,” in Proc. ACM SIGCHI Conf.Human Factors Comput. Syst., 2011, pp. 2065–2074. [Online]. Avail-able: http://doi.acm.org/10.1145/1978942.1979243.

[19] L. Cranor and S. Garfinkel, Security and Usability. Cambridge, MA,USA: O’Reilly Media, Inc., 2005.

[20] K. Fisler and S. Krishnamurthi, “A model of triangulating envi-ronments for policy authoring,” in Proc. 15th ACM Symp. AccessControl Models Technol., 2010, pp. 3–12 [Online]. Available: http://doi.acm.org/10.1145/1809842.1809847.

[21] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wetherall,“These aren’t the droids you’re looking for: Retrofitting androidto protect data from imperious applications,” in Proc. 18th ACMConf. Comput. commun. Security, 2011, pp. 639–652.

[22] B. Shebaro, O. Oluwatimi, D. Midi, and E. Bertino, “Identidroid:Android can finally wear its anonymous suit,” Trans. Data Privacy,vol. 7, no. 1, pp. 27–50, Apr. 2014.

[23] I. F. Progri, “Wireless-enabled GPS indoor geolocation system,” inProc. Position Location Navigat. Symp., 2010, pp. 526–538.

[24] C. Feng, W. Au, S. Valaee, and Z. Tan, “Received-signal-strength-based indoor positioning using compressive sensing,”IEEE Trans. Mobile Comput., vol. 11, no. 12, pp. 1983–1993,Dec. 2012.

[25] S. Ali-Loytty, T. Perala, V. Honkavirta, and R. Piche, “FingerprintKalman filter in indoor positioning applications,” in Proc. IEEEControl Appl., Intell. Control, 2009, pp. 1678–1683.

[26] A. S. Paul and E. Wan, “RSSI-based indoor localization and track-ing using sigma-point Kalman smoothers,” IEEE J. Select. TopicsSignal Process., vol. 3, no. 5, pp. 860–873, Oct. 2009.

[27] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A.-R. Sadeghi, and B.Shastry, “Towards taming privilege-escalation attacks onAndroid,” in Proc. 19th Annu. Netw. Distrib. Syst. Security Symp.,Feb. 2012.

[28] M. Moyer and M. Abamad, “Generalized role-based accesscontrol,” in Proc. 21st Int. Conf. Distrib. Comput. Syst., 2001,pp. 391–398.

[29] M. J. Covington, W. Long, S. Srinivasan, A. K. Dev, M. Ahamad,and G. D. Abowd, “Securing context-aware applications usingenvironment roles,” in Proc. 6th ACM Symp. Access Control ModelsTechnol., 2001, pp. 10–20.

[30] C. Wullems, M. Looi, and A. Clark, “Towards context-aware secu-rity: An authorization architecture for intranet environments,” inProc. Pervasive Comput. Commun. Workshops, 2004, pp. 132–137.

[31] G. Zhang and M. Parashar, “Dynamic context-aware access con-trol for grid applications,” in Proc. 4th Int. Workshop Grid Comput.,2003, pp. 101–108.

[32] M. L. Damiani, E. Bertino, B. Catania, and P. Perlasca, “Geo-RBAC: A spatially aware RBAC,” ACM Trans. Inform. Syst. Secu-rity, vol. 10, no. 1, 2007.

[33] D. Kulkarni, “Context-aware role-based access control in perva-sive computing systems,” in Proc. 13th ACM Symp. Access ControlModels Technol., 2008, pp. 113–122.

[34] R. J. Hulsebosch, A. H. Salden, M. S. Bargh, P. W. G. Ebben, and J.Reitsma, “Context sensitive access control,” in Proc. 10th ACMSymp. Access Control Models Technol., 2005, pp. 111–119.

[35] R. Sandhu, K. Ranganathan, and X. Zhang, “Secure informa-tion sharing enabled by trusted computing and PEI models,”in Proc. ACM Symp. Inform., Comput. Commun. Security, 2006,pp. 2–12.

[36] N. Damianou, N. Dulay, E. Lupu, and M. Sloman, “The ponderpolicy specification language,” in Proc. Int. Workshop Policies Dis-trib. Syst. Netw., 2001, pp. 18–38.

[37] U. Erlingsson, Oasis extensible access control markup language(XACML). (2013). [Online]. Available: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

[38] Erlingsson, F. Schneider, “IRM enforcement of java stackinspection,” in Proc. IEEE Symp. Secur. Privacy, 2000, pp. 246–255.

[39] D. Evans and A. Twyman, “Flexible policy-directed code safety,”in Proc. IEEE Symp. Secur. Privacy, 1999, pp. 32–45.

[40] L. Bauer, J. Ligatti, and D. Walker, “Composing expressive run-time security policies,” ACM Trans. Softw. Eng. Methodology,vol. 18, no. 3, pp. 9:1–9:43, Jun. 2009.

[41] G. Edjlali, A. Acharya, and V. Chaudhary, “History-based accesscontrol for mobile code,” in Proc. 5th ACM Conf. Comput. commun.Security, 1998, pp. 38–48.

[42] C. A. Ardagna, M. Cremonini, E. Damiani, S.D.C.di Vimercati,and P. Samarati, “Supporting location-based conditions in accesscontrol policies,” in Proc. ACM Symp. Inform., Comput. Commun.Security, 2006, pp. 212–222.

[43] E. Bertino, B. Catania, M. L. Damiani, and P. Perlasca, “Geo-RBAC: A spatially aware RBAC,” in Proc. 10th ACM Symp. AccessControl Models Technol., 2005, pp. 29–37.

[44] NFC forum tag type technical specification. [Online]. Available:http://www.nfc-forum.org/home/

[45] G. Madlmayr, J. Langer, C. Kantner, and J. Scharinger, “NFC devi-ces: Security and privacy,” in Proc. 3rd Int. Conf. Availability, Rel.Security, 2008, pp. 642–647.

[46] A. Kushki, K. Plataniotis, and A. Venetsanopoulos, “Intelligentdynamic radio tracking in indoor wireless local area networks,”IEEE Trans Mobile Comput., vol. 9, no. 3, pp. 405–419, Mar. 2010.

[47] T. Vidas, N. Christin, and L. Cranor, “Curbing Android permis-sion creep,” in Proc. Web 2.0 Secur. Privacy 2011 workshop, May2011.

[48] W. Enck, M. Ongtang, and P. McDaniel, “On lightweight mobilephone application certification,” in Proc. 16th ACM Conf. Comput.Commun. Security, 2009, pp. 235–245.

[49] F. Roesner, T. Kohno, A. Moshchuk, B. Parno, H. J. Wang, and C.Cowan, “User-driven access control: Rethinking permissiongranting in modern operating systems,” in Proc. IEEE Symp. Secu-rity Privacy, 2012, pp. 224–238.

[50] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A sur-vey of mobile malware in the wild,” in Proc. 1st ACM WorkshopSecurity Privacy Smartphones Mobile Dev., 2011, pp. 3–14.

[51] W. Enck, “Defending users against smartphone Apps: Techniquesand future directions,” in Proc. 7th Int. Conf. Inf. Syst. Security,2011, pp. 49–70.

[52] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri, “A study ofandroid application security,” in Proc. 20th USENIX Conf. Security,2011, pp. 21–21.

[53] J. Ligatti, B. Rickey, and N. Saigal, “Lopsil: A location-based pol-icy-specification language,” in Secur. Privacy Mobile Inform. Com-mun. Syst., Springer Berlin Heidelberg, vol. 17, 2009, pp. 265–277.

[54] M. Nauman, S. Khan, and X. Zhang, “Apex: Extending androidpermission model and enforcement with user-defined runtimeconstraints,” in Proc. 5th ACM Symp. Inform., Comput. Commun.Security, 2010, pp. 328–332.

[55] Y. Zhou, X. Zhang, X. Jiang, and V. W. Freeh, “Taming informa-tion-stealing smartphone applications (on android),” in Proc. 4thInt. Conf. Trust Trustworthy Comput., 2011, pp. 93–107.


[56] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible and fine-grainedmandatory access control on android for diverse security and pri-vacy policies,” in Proc. 22nd USENIX Security Symp., Aug. 2013,pp. 131–146.

[57] G. Russello, M. Conti, B. Crispo, and E. Fernandes, “Moses: Sup-porting operation modes on smartphones,” in Proc. 17th ACMSymp. Access Control Models Technol., 2012, pp. 3–12.

[58] M. Ongtang, S. Mclaughlin, W. Enck, and P. Mcdaniel,“Semantically rich application-centric Security in android,” inProc. Annu. Comput. Security Appl. Conf., 2009, pp. 340–349.

[59] S. Bugiel, L. Davi, A. Dmitrienko, S. Heuser, A.-R. Sadeghi, and B.Shastry, “Practical and lightweight domain isolation on android,”in Proc. 1st ACM Workshop Security Privacy Smartphones MobileDev., 2011, pp. 51–62.

Bilal Shebaro received the PhD degree from theComputer Science Department at the Universityof New Mexico in May 2012. During his graduatestudies, he was also a research assistant at theLos Alamos National Laboratories and aresearch scholar at the Universidad de Vigo inSpain. He is a post doctoral researcher at PurdueUniversity affiliated with Purdue Cyber Center(Discovery Park) and Purdue Center for Educa-tion and Research in Information Assurance andSecurity (CERIAS). His recent research interests

include mobile security, digital forensics, and sensor networks.

Oyindamola Oluwatimi received the bachelor’sof science degree from Norfolk State Uni-versity’s Computer Science (CS) undergraduateprogram in 2011 under the DNIMAS administra-tion. In the fall of that year, with both GEM andPurdue Doctoral fellowships, he began attendingPurdue University’s CS PhD academic program.His focus is in computer security, and hasrecently picked up an interest in mobile securityand privacy. He is currently a research assistantunder Dr. Elisa Bertino, collaborating in projects

involving enhancements of mobile operating systems with privacy-related features.

Elisa Bertino is a professor of computer scienceat Purdue University, and a director of the PurdueCyber Center (Discovery Park). She also servesas a research director of the Center for Informa-tion and Research in Information Assurance andSecurity (CERIAS). Prior to joining Purdue, shewas a professor and a department head at theDepartment of Computer Science and Communi-cation of the University of Milan. She has been avisiting researcher at the IBM Research Labora-tory (now Almaden) in San Jose, at the Micro-

electronics and Computer Technology Corporation, at RutgersUniversity, at Telcordia Technologies. Her recent research interestsinclude database security, digital identity management, policy systems,and security for web services. She received the IEEE Computer Society2002 Technical Achievement Award and the IEEE Computer Society2005 Kanai Award. She a member of the editorial board of IEEE Trans-actions on Dependable and Secure Computing, and IEEE Security andPrivacy. She has served as chair of the ACM Special Interest Group onSecurity, Audit and Control (ACM SIGSAC). She is a fellow of the ACMand the IEEE.

" For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


Context-Based Access Control Systems for Mobile Devices

Documents

Transcript of Context-Based Access Control Systems for Mobile Devices