DeepDroid: Dynamically Enforcing Enterprise Policy on Android Devices

Xueqiang Wang∗†, Kun Sun‡, Yuewu Wang∗ and Jiwu Jing∗∗ Data Assurance and Communication Security Research Center,

Institute of Information Engineering, Chinese Academy of Sciences{wangxueqiang, ywwang, jing}@is.ac.cn

†University of Chinese Academy of Sciences‡Department of Computer Science, College of William and Mary

ksun@wm.edu

Abstract—It is becoming a global trend for companyemployees equipped with mobile devices to access compa-ny’s assets. Besides enterprise apps, lots of personal appsfrom various untrusted app stores may also be installedon those devices. To secure the business environment,policy enforcement on what, how, and when certain appscan access system resources is required by enterprise IT.However, Android, the largest mobile platform with amarket share of 81.9%, provides very restricted interfacesfor enterprise policy enforcement. In this paper, we presentDeepDroid, a dynamic enterprise security policy enforce-ment scheme on Android devices. Different from existingapproaches, DeepDroid is implemented by dynamic mem-ory instrumentation of a small number of critical systemprocesses without any firmware modification. DeepDroidcan be easily deployed on various smartphone platformswith a wide range of Android versions. Moreover, basedon the context information extracted from Binder intercep-tion, a fine-grained policy can be enforced. We develop aprototype of DeepDroid and test it on various smartphonesand Android versions. The experimental results showthat DeepDroid can effectively enforce enterprise resourceaccess policies with negligible performance overhead.

I. INTRODUCTION

Nowadays, an increasing number of employees areallowed to use mobile devices in workplace and con-nect to enterprise assets. Cisco surveyed that 51% ofend users rely on smartphones to perform their dailybusiness activities in 2013 [1]. This trend will continue

to influence the design and usage of mobile devices inthe enterprise environments. While users are blurring thelines between company and personal usage, enterprisesdemand a secure and robust mobile device managementto protect their business assets. For instance, in a buildingthat forbids any audio recording, all mobile devices’microphones should be disabled when the users checkin the building and be enabled when the users checkout.

The permission model on Android, the largest mobileplatform with a market share of 81% [2], only grantsan “all-or-nothing” installation option for mobile usersto either accept all the permissions an app asks for orsimply decline to install the app. After installation, theapp can keep accessing the approved system resourcesall the time. In Android 4.3, an experimental featurecalled “App Ops” [3] is added to permit mobile usersto configure one app’s runtime permissions. However,this feature has been removed from Android 4.4.2 dueto “the increasing burden for user configuration and theimpacts on advertisement market” [4]. SEAndroid hasevolved from Permissive mode in Android 4.2 and 4.3to Enforcing mode in Android 4.4 and later to provideflexible mandatory access control (MAC) mechanism inthe Linux kernel. However, until now, even the newestAndroid 5.0 has not fully integrated MAC mechanismin Android middleware [5]. Moreover, SEAndroid isnot available on legacy systems running old versions ofAndroid.

Since Android 2.2, Google provides Device Adminis-tration APIs [6] to help enforce enterprise security poli-cies; however, these APIs only provide a limited set offunctionalities that vary among different Android releas-es. The Mobile Device Management concept (MDM) [7]has also been introduced to enterprise administratorsfor a long time; however, OEMs usually develop their

Permission to freely reproduce all or part of this paper for non-commercial purposes is granted provided that copies bear this noticeand the full citation on the first page. Reproduction for commercialpurposes is strictly prohibited without the prior written consent of theInternet Society, the first-named author (for reproduction of an entirepaper only), and the author’s employer if the paper was preparedwithin the scope of employment.NDSS ’15, 8-11 February 2015, San Diego, CA, USACopyright 2015 Internet Society, ISBN 1-891562-38-Xhttp://dx.doi.org/10.14722/ndss.2015.23263

own proprietary MDM solutions [8], [9]. For instance,Samsung Knox provides a complete enterprise solution,including secure boot, kernel integrity checking, andSEAndroid [9]; however, it is only available on Samsungdevices [10].

In this paper, we propose an enterprise-level securitypolicy enforcement mechanism called DeepDroid thatcan be easily ported on various Android devices todynamically enforce a fine-grained system service and re-source access control policy by enterprise administrators.The basic idea is to apply dynamic memory instrumen-tation on the app runtime environment in Android. Allcurrent versions of Android share a common structurefeature that system services and resource access arecontrolled by a small number of system processes. Thus,we only need to instrument these system processes whosestructures are almost the same on all Android versions.DeepDroid dynamically hooks system server process inAndroid and uses it as a centralized controller to enforcethe enterprise-level permissions when an app requests toaccess a system service. It also tracks the zygote processto authorize native code’s access requests. Moreover,DeepDroid can intercept the Binder interactions betweenapps and a few system processes to retrieve details ofapps’ requests for a fine-grained access control.

DeepDroid needs root privilege to instrument andtrack system processes. It can be satisfied in a corporateenvironment where companies usually either rent orpurchase mobile devices from telecommunication com-panies and request vendors to customize the softwareimage before distributing the devices to employees. S-ince DeepDroid does not need to statically change theAndroid middleware and the Linux kernel, it carries littleburden on vendors for device customization.

Our enterprise-level policy enforcement solution hasseveral good properties. First, it is portable. Our solutioncan be deployed on almost all Android mobile deviceswith very small customization efforts. Instead of tailoringvarious Android systems from different OEMs, we usedynamic instrumentation and process tracing techniquesto hook the Android app runtime environment. The codebase of our system remains largely unchanged whendeployed on different Android versions. Our solutiononly requires minimal configuration changes in AndroidOS during the installation stage and does not need anychanges on any app. We have evaluated our system on avariety of Android devices from different OEMs runningAndroid 2.3 through Android 4.4.

Second, it is flexible to provide fine-grainedenterprise-level control over each app. The enterpriseadministrators can dynamically update the policy rulesfor each mobile device’s individual app. We cannot onlyenforce a general rule to constrain one specific service/re-source access for an app, but also achieve a context-aware access control by inspecting the communicationsbetween apps and service processes through AndroidBinder. In this paper, we focus on providing securitymechanisms instead of developing detailed policy rulesgiven an enterprise’s security requirements.

Finally, it has minimal impacts on user experience.DeepDroid is transparent to mobile users and supportslocation-aware automatic configuration. For instance, theenterprise policy enforcement mechanism only needs tobe enabled when a user enters the workplace; when theuser leaves the workplace, the policy enforcement mech-anism can be automatically disabled. Moreover, sinceour mechanism only needs to instrument a very smallnumber of critical Android processes and perform simplecheckings, it has negligible performance overhead.

In summary, we make the following contributions.

• We solve the portability problems of enforcingenterprise’s security policies on various Android de-vices. Our approach is based on dynamic code instru-mentation and process tracing, which enforce accesscontrol policies in Android middleware and Linuxkernel, respectively. Our system can be ported ondifferent Android mobile devices with small changes.• We can achieve a fine-grained control policy over

each Android app. By hooking and tracing criticalAndroid components, we can extract request details tobetter regulate one app’s operations. Thus, it enablesenterprise administrators to set fine-grained policyrules considering temporal and spatial constraints foreach app.• We minimize the impacts of our mechanism on

Android system. Only a few critical processes (e.g.,system server) need to be dynamically instrumentedin their memory spaces, and the performance overheadis minimal. Also, its impacts on Android systemis temporary and can be easily removed when thepolicies are no longer desired. It is compatible withthe existing permission mechanism.• We develop a DeepDroid prototype and evaluate

its effectiveness and efficiency on a number of main-stream Android devices with various Android versions.The evaluation results show that DeepDroid can work

2

process ensures that supplementary groups are properlyset to the app process by initiating setgroups. Next, theapp’s process will have the privilege to access resourcesavailable to those groups.

III. GOALS, CHALLENGES AND ASSUMPTIONS

DeepDroid targets at effectively enforcing enterprisesecurity policies on Android devices, and it is designedto meet the following goals:

Portability. Our scheme should be easily deployed tovarious Android versions and different Android mobiledevices. Current state-of-the-art solutions add proprietaryenterprise mobile management interfaces into Androidsource code, so the interfaces are typically customizedto specific Android versions and devices. When onecompany wants to adopt one mobile device that has notintegrated the management interfaces, the developmentcost will increase and the delivery time will be extended.Our goal is to support various kinds of Android devicesthrough making minimal configuration changes.

Fine granularity. Our scheme should support fine-grained service and resource access control on individualapps. It cannot only supervise the permission privilegesof an app, but also regulate the service provision proce-dure. Thus, our solution can support various enterprisepolicies. For instance, during working hours, SMS isonly allowed between employees. In this case, we needto limit the receiver of a SMS message rather thanprohibiting all SMS messages blindly. Location BasedService (LBS) apps may lead to location privacy leakage;however, blindly forbidding location related operationsmay generate except signals, which leak the informationthat the user may be at workplace. This problem canbe solved by regulating each location operation andreplacing some sensitive locations with fake information.

Trustworthy. All access control policy rules shouldbe completely enforced, so that malicious apps cannotviolate any rules. We trust the Android middleware andthe low-level Linux kernel. In Android, resource accessoperations through system services are controlled byAndroid permission mechanism; however, an app mayaccess resources using native system calls that totallybypass the permission checking. Thus, to assure allresource accesses are being supervised, our scheme mustenforce the policy rules in both Android middleware andLinux kernel layers.

Ease of use. Our mechanism could be promptly acti-vated and deactivated according to the enterprise policy

settings. For instance, it should be quickly activatedwhen the user enters the workplace and removed imme-diately when the user leaves the workplace. Moreover,its impacts on Android system performance should beminimal.

DeepDroid requires root privilege for installation.This requirement is common among enterprise mobilemanagement solutions, and typically the root privilegecan be obtained from OEMs. With OEM support, sinceDeepDroid does not change the framework and thekernel of Android system, its installation is simple andstraightforward. We assume the enterprise administratorscan be trusted. Some keying material is shared betweenthe smartphone and enterprise policy center to generatesecret keys for communication protection. We assumethe keying material is well protected and secure.

We assume the Android OS kernel can be trusted.Users have the freedom to install their favorite apps ontheir Android smartphones. Though some apps may bemalicious, we assume they cannot compromise the OSkernel or get the root privilege. A malicious or uncoop-erative device user may attempt to disable our policyenforcement mechanism, so we should guarantee thatDeepDroid is reliably active in the workplace. DeepDroidopens a management interface for policy enforcement,which may increase the attack surface for some newattacks misusing the interface.

IV. DEEPDROID SYSTEM ARCHITECTURE

DeepDroid consists of two parts: Enterprise PolicyCenter and DeepDroid On-device, as shown in Figure 2.

A. Enterprise Policy Center

Enterprise Policy Center consists of three modulesto authenticate the mobile devices, distribute enterprisepolicies, and monitor the mobile devices, respectively.The authentication module is responsible for authen-ticating the mobile devices. After being successfullyauthenticated, a device can share a temporary secretkey with enterprise policy center. A policy repositoryprovides policy rules according to enterprise’s securityrequirements and the user’s role. Since all communica-tions between the policy center and the mobile deviceare protected by the secret key, the policy rules canbe securely distributed to mobile devices. Moreover, thestatus of mobile devices should be continuously reportedto the policy center for logging and auditing purpose.Particularly, the policy center can use encrypted heartbeat

4

TABLE II: Binder Resource Accessing Interfaces

Resource Process Service Function CodeIMEI phone iphonesubinfo getDeviceInfo 1

Phone # phone iphonesubinfo getLine1Number 5location system server location getLastKnownLocation 17

contacts* system server activity getContentProvider 29camera mediaserver media.camera connect 3account system server account getAccounts 4

SMS/MMS phone isms sendText 5

it is difficult to define and enforce policy criterion onhigh volume media-related resources (such as camera andaudio) without an efficient support on image or voicerecognition. It is much easier for apps using AndroidAPIs to perform operations like locating or photograph-ing. However, an App may have multiple ways to bypassit using normal Android APIs. To solve this problem, wecan extend DeepDroid with a behavior detection modelsimilar to what has been proposed in FireDroid [14].

D. Native Code Context Enforcement

The process creation guard in Section V-B constrainsthe access privileges of native operations with a course-grained Granted or Denied decision; however, enterprisesmay request a more fine-grained control on native op-erations. For instance, instead of disconnecting an appcompletely from the Internet, the app may be allowedto access some specific trusted web servers. Therefore,besides configuring inet group, we develop a nativecode context enforcement module to regulate networkaccessing operations by confining the context of socketcalls, such as connect, recvfrom and sendto.

We trace system calls of the target process to con-strain its native behaviors. Since it is important toguarantee that the tracing code is executed before anyoperation of target process, we must detect the launchingof the target process and monitor the process throughits entire life cycle. To achieve this goal, we trace forkcalls of the processes (e.g., zygote, adbd) that are incharging of new app process creation and then mapnewly created processes to applications by matchingtheir uid. Once the target app is identified, system callsof its process tree are traced recursively by settingptrace options including TRACEFORK, TRACEVFORKand TRACECLONE. Since our module works as a traceron a target process, when the target process is attachedsuccessfully, the tracer can receive signals at both theentry and exit of system calls, and meanwhile the target

process is suspended after entering syscall-enter-stopand syscall-exit-stop. We maintain a flag for each targetprocess to distinguish its system call entries from systemcall exits. In a typical work flow, this module first usesptrace to extract CPU register information of a suspendedtarget. According to routines of ARM Procedure CallStandard [15], the parameters of system calls are storedin registers R0∼R3 and SP, and the result of a systemcall is always stored in register R0. Therefore, our tracescan easily parse the parameters and return value of thesystem calls. According to the policy rules, we can eithersimply decline a resource access request or send a fakereturn value.

Again, our work focuses on providing a mechanismto support native code context enforcement, instead ofdesigning detailed policy rules. For various applications,different parsers may be required to inspect their uniquecontext information. For instance, to restrict datagramcommunication with a certain remote server, we needto regulate system calls like sendto, sendmsg, recvmsgand recvfrom. At the entry of sendto, the destinationaddress is extracted from sockaddr structure. Then, thesystem calls can go through if the destination addressis valid or be stopped otherwise. Similarly, at the exitof recvfrom, we can recognize received buffer data andmask its content accordingly.

VI. DEEPDROID EVALUATION

Our goal of DeepDroid evaluation is threefold: (1) todemonstrate that security policies on resource accessingcan be effectively enforced; (2) to demonstrate thatDeepDroid can be easily deployed to various Androidplatforms, and (3) to measure its performance overhead.We also analyze security and reliability of DeepDroid.

A. Functional Evaluation

To test the effectiveness of DeepDroid, we choosethe prevalent resources of Android identified in [13]

9

TABLE III: Tested Resources

Resource Permission Group PEP1 Result2

IMEI READ PHONE STATE package√

Phone # READ PHONE STATE package√

location ACCESS FINE LOCATION package√

contacts READ CONTACTS package√

camera CAMERA camera package/PCG√

account GET ACCOUNTS package√

logs READ LOGS log PCG√

SMS/MMS message SEND SMS package√

network INTERNET inet package/PCG√

1 PEP is the policy enforcement point.2 The policy is enforced either in package service or by Process Creation Guard (PCG).

and run a number of popular apps that access theseresources. For each resource, 5 most widely used appsthat access this resource are chosen from Google Play. Inour experiment, we manually instrument each resourcerelated method call to check if the operations can besuccessfully regulated when we activate DeepDroid toprohibit accessing this resource. Table III shows the e-valuation results, which verify that all resource accessingoperations are controlled effectively.

B. Portability Evaluation

We run DeepDroid on a series of smart phoneswith Android OS from version 2.3 to 4.x. As Table IVsummarizes, DeepDroid can be successfully deployed onmainstream commercial Android devices with very smallsystem modification.

TABLE IV: DeepDroid Portability

Device Android ResultNexus S(Samsung) Android OS 2.3.6

√

Sony LT29i Android OS 4.1.2√

Android OS 4.2.2√

Galaxy Nexus(Samsung) Android OS 4.0√

Samsung Galaxy Note II Android OS 4.1√

Samsung Galaxy Note 3 Android OS 4.3√

Nexus 5(LG) Android OS 4.4√

Meizu MX II Flyme 3.21 √

HUAWEI Honor 3c Android OS 4.2√

1 Flyme 3.2 is a customized version of Android OS 4.2.1

C. Performance Evaluation

DeepDroid’s system overhead is mainly introducedby the operations on permission enforcement, bindermessage interception, and system call tracing. Since apermission checking is always accompanied by a bindertransaction, we combine the first two overhead factors.

1) Permission Enforcement Overhead: Permission en-forcement overhead is mainly introduced by PermissionConfigurator in the system server and behavior moni-toring from binder interception. Permission Configuratoroverrules system original permission checking procedurewith enterprise permission rules, and the Binder wrapperparses the binder messages to perform app’s behaviormonitoring.

Since most benchmarks focus on overhead of theentire process or the whole system, we need to design amechanism to benchmark the overhead of permission en-forcement operations. To minimize measurement errors,we choose sensitive operations that do not depend on acertain hardware module or volatile surroundings (e.g.,stability of network signal). As shown in Table V, weconstruct a test case from a subset of prevalent resourcesdescribed in [13].

TABLE V: Tested Permission Checking Transactions

Class Permission Trigger Pointphone state android.permission. TelephonyManager.

READ PHONE STATE getDeviceIdcontacts android.permission. ContentResolver.

READ CONTACTS query(Phone.CONTENT URI...)SMS android.permission. SmsManager.

messages SEND SMS sendTextMessage

We evaluate the performance by initiating resourceaccess operations that require a permission checkingprocedure in the following scenarios.

• Normal mode (S). The tested apps are granted re-quired permissions by original permission mechanismand the trigger points are executed successfully.

• Intercepted mode (S). The tested apps are grantedrequired permissions by Permission Configurator andthe trigger points are intercepted and monitored by thebinder.

• Normal mode (F). The tested apps are denied required

10

D. Security Analysis

Our system can ensure an enterprise security policyenforcement on Android device through dynamic mem-ory instrumentation of several critical system processes.

Malicious apps. DeepDroid may allow device usersto install their favorite apps on their Android smart-phones. Some apps may be malicious and target at com-promising our policy enforcement mechanism. However,since the user-level malicious processes are securelyisolated into separate containers, they cannot manipulatethe code or the control flow of DeepDroid unless theyhave the root privilege, which is strictly protected andmonitored by enterprise administrators. We assume theAndroid OS can be trusted. Therefore, without the rootprivilege, malicious apps cannot compromise our mech-anism.

Permission escalation attacks. An Android systemmay suffer from permission escalation attacks, such asconfused deputy attack and collusion attack [18], [19],[20]. In confused deputy attack, a malicious applicationexploits the vulnerable interfaces of another privileged(but confused) application to perform unauthorized op-erations. This kind of attack usually happens when aprivileged app unintentionally exposes interfaces of sen-sitive operation to an app without required permissions.In collusion attack, malicious apps collude and combinetheir permissions in order to perform actions beyond theirindividual privileges. DeepDroid can be used to regulatetwo apps’ communications that go through the binderand system calls; however, if two apps may communicatethrough some covert channels that are out of the controlof DeepDroid, we need to deploy other mechanisms tohelp remove the covert channels.

Uncooperative user. Some employees may be re-luctant to conform to enterprise’s security policies dueto various reasons, and they may simply deactivate oursystem. Therefore, it is critical to guarantee that Deep-Droid is correctly running on employees’ mobile devices,and we use heartbeat messages to prove it. Therefore,a mobile device that stops sending encrypted heartbeatmessages will trigger further investigation. Moreover, wecan use software based attestation approach [21], [22],[23] to make sure the integrity of DeepDroid. On themobile platforms with TrustZone hardware support [24],we can also use TrustZone to keep monitoring theintegrity of DeepDroid, similar to what has been donein Knox [9].

DeepDroid misuse. An attacker may impersonate the

enterprise administrators to send false policy rules to themobile devices; however, since the attacker cannot obtainthe keying material shared between the device and theenterprise server, it cannot perform this type of attacks.DeepDroid exposes one control interface of Androidsystem to third parties; however, since the code base ofDeepDroid is small and may be formally verified, theattacker can hardly misuse our mechanism to attack thesystem. Moreover, since all the communications betweenthe trusted enterprise server and the mobile device areprotected by a shared secret key, an external attackercannot steal the policy rules through eavesdropping.

VII. DISCUSSION

At Google I/O 2014 conference, Android L was un-veiled and the previously experimental Android Runtime(ART) [25] has replaced Dalvik as a default environment.ART compiles byte code into executable ELF only onceduring app installation. In spite of the runtime transfor-mation, foundations of DeepDroid, including permissionmechanism, system service architecture, and binder IPC,are barely changed. In other words, DeepDroid canbe easily ported to ART. Only the implementation ofruntime method interception in section V-A needs to bechanged accordingly. In ART, the .oat executable filecompiled from Java byte code is mapped into process bycalling dlopen function, and all Methods refer to theirnative code in oatexec segment of .oat. ART runtimemethod interception can be achieved by native codeinline-hooking. Hence, DeepDroid can also work onART-enabled devices with little modification.

DeepDroid requires root privilege for installation.This requirement is common among enterprise mobilemanagement solutions, and usually the root privilege canbe obtained from OEMs. With OEM support, DeepDroidinstallation is simple and straightforward. OEMs onlyneed to modify the “init.rc” file and import DeepDroid asa service. Then DeepDroid can run with a root privilegeand all other Android security features remain intact.Since DeepDroid does not change the framework andthe kernel of Android system, the above configurationincurs very little impact on OEMs. Some other worksuch as FireDroid [14] adopts a similar idea to obtainroot privilege from OEMs. Alternatively, with the supportof ARM TrustZone mechanism [24], DeepDroid mayuse the secure domain for the installation in the normaldomain.

There exists a number of system access control solu-tions for enterprise management, but our solution has

12

some advantages when comparing to those solutions,particularly, SELinux [26] and Knox [9]. SEAndroidenforces mandatory access control (MAC) in Androidkernel. Android’s support for SELinux has evolved frompermissive in 4.3 to full enforcement in 5.0 (L). SELinuxenhances system security by confining privileged pro-cesses and enforce policies on various domains. How-ever, it is unavailable or disabled by default on Androidversions older than 4.4. Thus, old devices cannot be wellprotected by SEAndroid. Moreover, it requires manufac-turers to have a better understanding of SELinux im-plementations. Until now, SEAndroid has not been fullysupported since Android 5.0 does not include middlewareMAC mechanism [5]. On the contrary, DeepDroid doesnot rely on any unique kernel features and thus workswell on almost all Android versions and platforms. Wemay enhance the security of DeepDroid with SEAndroidmechanism.

Samsung Knox has risen up to provide a completeenterprise solution. It focuses on providing capabili-ties including Trusted Boot, TrustZone-based IntegrityMeasurement Architecture (TIMA), SE for Android,and Knox container, to protect Android system fromadversaries and isolate different working scenarios [9].Through secure boot and kernel integrity checking, Knoxcan ensure a trusted OS in the normal world based onARM TrustZone hardware. As for policy enforcement,Knox integrates SEAndroid and provides managementAPIs to customize security policies. Despite that KnoxAPIs are integrated into Android 5.0 [27], its adoptionis limited to Samsung devices [10]. Moreover, Knoxrequires ARM TrustZone hardware support, which limitsits deployment to only certain Android platforms. OurDeepDroid system is a software-based solution that canbe deployed on almost all Android platforms. Mean-while, on TrustZone-enabled platforms, DeepDroid mayutilize TrustZone to obtain the root privilege of thenormal domain and protect the integrity of the rich OSin the normal domain.

VIII. RELATED WORK

Enterprise demands system resource access controlinterfaces in Android when employees are equippedwith Android smartphone in workspace. Android accesscontrol mechanisms can be generally categorized intofour classes by their technical approaches.

Modifying Android source code. Android sourcecode can be directly modified to support new access

control mechanisms when we can access the source codefor the enterprise-customized Android system. BecauseAndroid permission framework does not provide flexibleruntime configuration interface [28] and permission priv-ilege leaks happen to commercial images [20], severalsecurity extensions have been proposed to the permissionframework [29], [30], [31], [32], [33], [26], [34], [13],[35], [36]. Apex [29] enables users to grant a selected setof permissions and supports user-defined restrictions onapps. CRePE [30] can enforce fine-grained permissionpolicies by using context information of the mobiledevices. By introducing a privacy mode, TISSA [31] em-powers users to define what kinds of personal informa-tion are accessible to apps. To mitigate security problemsaroused by a certain third-party component, Compac [32]manages to distribute a narrowed set of permissions toone component. While the above approaches focus onprotection of system resources, Saint [33] provides aninfrastructure that protects apps’ interfaces and resources.

Another way to enhance access control is achievedby introducing Security Enhanced Linux (SELinux). Aflexible mandatory access control (MAC) can be support-ed on both Android’s middleware and kernel layers [26],[34]. Besides directly hardening access control system,privacy data can be further protected by being replacedwith some dummy data before providing it to apps [13].TaintDroid [35] monitors usage of sensitive data bydynamic taint tracking and analysis. Based on Taintdroid,TreeDroid [36] presents a novel scheme to monitorsecurity policies on data processing.

Since all these approaches require Android sourcecode modification, they have portability problem due tothe high cost incurred when customizing a specific An-droid branch from different OEMs. Our system performsdynamic memory instrumentation on the stable Androidstructures, so it can be deployed similarly on variousAndroid versions.

Rewriting apps. Compared with modifying Androidsystem code, app code can be rewritten to ensure aresource access policy. Due to good portability, enforcingsecurity on apps themselves becomes a competitive ap-proach. It is mainly implemented by integrating securitymeasures into Android app with app rewriting. [37]enables identifying and interposing of Security SensitiveAPIs by dalvik bytecode rewriting. [38] supports retrofitof app’s behaviors by static and dynamic method inter-ception. [39] is an on-the-phone instrumentation scheme,which enables flexible policies on apps by intercepting

13

high-level java calls. Security policies of [40] are en-forced by low-level libc.so rewriting.

Interactions between an app and Android system canbe recovered from system calls. [41] helps to perfor-m fine-grained permissions on resource accessing byintroducing a new module that supports parameterizedpermissions. Any access to sensitive resources from appsis forwarded to this module. To support behavior study-ing, [42] allows user to insert instrumentation code intoan app from a high-level of abstraction. App rewritingis an effective way that requires no modification toAndroid ROM. However, incomplete implementations ofbytecode rewriting may result in several potential attack-s [43]. It is difficult to assure that all apps are rewrittenwhich is critical to enterprise security management. Inaddition, due to signature difference of repackagingprocess, all history information of the original app cannotbe shared by the rewritten app.

Isolating business apps. Besides adding extra controlmeasures on Android system or apps, creating an isolatedsecure domain is another promising solution for runningbusiness related apps. It divides all user apps into twocategories: personal apps and business apps. Businessapps are running in a secure isolated environment,and thus attacks originated from personal domain canbe blocked out. Trustdroid [44] is an isolation frame-work based on modifying Android system source code.KNOX [45] provides a complete enterprise managementsolution including an integrity checking component in thesecure domain. All these solutions do not directly aimat enforcing enterprise security policies on employee’smobile device. It also has the portability problem due tothe changing of Android system or hardware supports.

Modifying Android runtime. Our system relies ondynamically modifying the Android runtime environ-ment. Patchdroid [46] uses a similar technique to applysecurity patches for the entire Android system, whileour work focuses on enforcing enterprise policies on allinstalled apps.

IX. CONCLUSIONS

In this paper, we present a mechanism named Deep-Droid to enforce enterprise security policy on Androiddevices. DeepDroid provides good properties includingportability, fine-grained control, and minimal perfor-mance overhead through dynamically injecting controlcode into Android framework, which has a stable set

of process structures in various versions. Thus, Deep-Droid may be deployed on various Android versionswith a similar installation procedure. Since DeepDroidcan regulate each app’s service access operations byintercepting Binder transactions and tracing system calls,it can achieve a fine-grained context-aware policy en-forcement. The evaluation results of a prototype showthat DeepDroid can work effectively on various Androidplatforms with negligible performance overhead.

X. ACKNOWLEDGMENT

The authors would like to thank the shepherd, Xi-aofeng Wang from Indiana University, and the anony-mous reviewers for their valuable comments and sug-gestions. This work is partially supported by National973 Program of China under award No. 2013CB338001and No. 2014CB340603. Dr. Kun Sun’s work is sup-ported by U.S. Office of Naval Research under awardnumber N00014-11-1-0471 and U.S. Army ResearchOffice under Grant W911NF-12-1-0448. This paper’scorresponding author is Yuewu Wang.

REFERENCES

[1] “Cisco global work your way study,” http://www.cisco.com/c/dam/en/us/solutions/collateral/borderless-networks/unified-access/ua survey infographic.pdf.

[2] “Android pushes past 80156.0http://www.idc.com/getdoc.jsp?containerId=prUS24442013.

[3] “App ops: Android 4.3’s hidden app permissionmanager, control permissions for individual apps!” http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s/hidden-app-permission-manager/-control-permissions-for/-individual-apps/.

[4] “App ops removed by google in android4.4.2 update,” http://www.phonearena.com/news/App-Ops-removed-by-Google-in-Android-4.4.2-updateid50340/.

[5] “Merge status,” http://seandroid.bitbucket.org/MergeStatus.html.

[6] “Device administration,” http://developer.android.com/guide/topics/admin/device-admin.html.

[7] “Mobile device management,” http://en.wikipedia.org/wiki/Mobile device management.

[8] Samsung, “Samsung For Enterprise,” http://www.samsung.com/us/business/samsung-for-enterprise/index.html.

[9] S. Electronics, “Samsung KNOX,” http://www.samsung.com/global/business/mobile/solution/security/samsung-knox.

[10] “Knox workspace supported devices,” https://www.samsungknox.cn/en/solutions/knox/technical/knox-supported-devices.

[11] “Openbinder,” http://www.angryredplanet.com/ hackbod/open-binder/docs/html/.

[12] “System permissions,” http://developer.android.com/guide/topics/security/permissions.html.

14

[13] 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 Proceedings ofthe 18th ACM Conference on Computer and CommunicationsSecurity, ser. CCS ’11, 2011.

[14] G. Russello, A. B. Jimenez, H. Naderi, and W. van der Mark,“FireDroid: Hardening Security in Almost-stock Android,” inProceedings of the 29th Annual Computer Security Applica-tions Conference, 2013.

[15] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E aapcs.pdf.

[16] “Caffeinemark 3.0,” http://www.benchmarkhq.ru/cm30/.[17] “Quadrant standard edition,” https://play.google.com/store/

apps/details?id=com.aurorasoftworks.quadrant.ui.standard.[18] A. D. T. F. A.-R. S. B. S. Sven Bugiel, Lucas Davi, “Towards

taming privilege-escalation attacks on android,” in NDSS, 2012.[19] A. P. Felt, H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin,

“Permission Re-Delegation: Attacks and Defenses,” in USENIXSecurity Symposium, 2011.

[20] Z. W. X. J. Michael Grace, Yajin Zhou, “Systematic detectionof capability leaks in stock android,” in NDSS, 2012.

[21] V. K. Y. K. Mark Shaneck, Karthikeyan Mahadevan, “Remotesoftware-based attestation for wireless sensors,” Security andPrivacy in Ad-hoc and Sensor Networks, vol. 3813, pp. 27–41,2005.

[22] v. D. L. K. P. Seshadri. A, Perrig A, “Swatt: software-basedattestation for embedded devices,” in IEEE Symposium onSecurity and Privacy, 2004.

[23] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach,“Quire: Lightweight Provenance for Smart Phone OperatingSystems,” in Proceedings of the 20th USENIX Conference onSecurity, 2011, pp. 23–23.

[24] T. Alves and D. Felton, “TrustZone: Integrated hardware andsoftware security,” ARM white paper, vol. 3, no. 4, 2004.

[25] http://source.android.com/devices/tech/dalvik/art.html.[26] S. Smalley and R. Craig, “Security Enhanced (SE) Android:

Bringing Flexible MAC to Android,” in NDSS, 2013.[27] “A closer look at knox contribution in android,” https://www.

samsungknox.cn/en/androidworkwithknox.[28] X. Wei, L. Gomez, I. Neamtiu, and M. Faloutsos, “Permis-

sion Evolution in the Android Ecosystem,” in Proceedings ofthe 28th Annual Computer Security Applications Conference,2012.

[29] M. Nauman, S. Khan, and X. Zhang, “Apex: Extending An-droid Permission Model and Enforcement with User-definedRuntime Constraints,” in Proceedings of the 5th ACM Sympo-sium on Information, Computer and Communications Security,2010.

[30] M. Conti, V. T. N. Nguyen, and B. Crispo, “CRePE: Context-related Policy Enforcement for Android,” in Proceedings of the13th International Conference on Information Security, 2011.

[31] X. J. Yajin Zhou, Xinwen Zhang and V. W. Freeh, “TamingInformation-Stealing Smartphone Applications (on Android),”in In: Trust and Trustworthy Computing, 2011.

[32] Y. Wang, S. Hariharan, C. Zhao, J. Liu, and W. Du, “Compac:Enforce Component-level Access Control in Android,” in Pro-ceedings of the 4th ACM Conference on Data and ApplicationSecurity and Privacy, 2014.

[33] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel,“Semantically rich application-centric security in android,”Computer Security Applications Conference, Annual, 2009.

[34] S. Bugiel, S. Heuser, and A.-R. Sadegh, “Flexible and Fine-Grained Mandatory Access Control on Android for DiverseSecurity and Privacy Policies,” in 22nd USENIX SecuritySymposium (USENIX Security ’13), 2013.

[35] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung,P. McDaniel, and A. Sheth, “TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring onSmartphones,” in OSDI, 2010, pp. 393–407.

[36] A. L. Mads Dam, Gurvan Le Guernic, “Treedroid: A tree au-tomaton based approach to enforcing data processing policies,”in CCS, 2012.

[37] B. Davis, B. S, A. Khodaverdian, and H. Chen, “I-arm-droid: A rewriting framework for in-app reference monitors forandroid applications,” in In Proceedings of the Mobile SecurityTechnologies 2012, MOST 12. IEEE, 2012.

[38] B. Davis and H. Chen, “RetroSkeleton: Retrofitting AndroidApps,” in Proceeding of the 11th Annual International Confer-ence on Mobile Systems, Applications, and Services, 2013.

[39] M. Backes, S. Gerling, C. Hammer, M. Maffei, and P. vonStyp-Rekowsky, “AppGuard: Enforcing User Requirements onAndroid Apps,” in Proceedings of the 19th International Con-ference on Tools and Algorithms for the Construction andAnalysis of Systems, 2013.

[40] R. Xu, H. Saı̈di, and R. Anderson, “Aurasium: Practical PolicyEnforcement for Android Applications,” in Proceedings of the21st USENIX Conference on Security Symposium, 2012.

[41] J. Jeon, K. K. Micinski, J. A. Vaughan, A. Fogel, N. Reddy,J. S. Foster, and T. Millstein, “Dr. Android and Mr. Hide: Fine-grained Permissions in Android Applications,” in Proceedingsof the Second ACM Workshop on Security and Privacy inSmartphones and Mobile Devices, 2012.

[42] S. Hao, D. Li, W. G. Halfond, and R. Govindan, “SIF: A S-elective Instrumentation Framework for Mobile Applications,”in Proceeding of the 11th Annual International Conference onMobile Systems, Applications, and Services, 2013.

[43] H. Hao, V. Singh, and W. Du, “On the Effectiveness of API-level Access Control Using Bytecode Rewriting in Android,”in Proceedings of the 8th ACM SIGSAC Symposium on Infor-mation, Computer and Communications Security, 2013.

[44] A. D. S. H. A.-R. S. B. S. Sven Bugiel, Lucas Davi, “Practicaland lightweight domain isolation on android,” in SPSM, 2011.

[45] Samsung Electronics, “White Paper: An Overview ofSamsung KNOX,” http://www.samsung.com/global/business/business-images/resource/white-paper/2013/06/SamsungKNOX whitepaper June-0.pdf.

[46] C. Mulliner, J. Oberheide, W. Robertson, and E. Kirda, “Patch-Droid: Scalable Third-party Security Patches for Android De-vices,” in Proceedings of the 29th Annual Computer SecurityApplications Conference, 2013.

15