User Defined Context Privacy Policy Management

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 2, Issue 12, December 2012)

558

User Defined Context Privacy Policy Management

Dr. A.B. Bagwan1, Prof. R. A. Deshmukh2, Dr. P.K.Deshmukh3, P.A.Wankhade4

1,2,3,4

RSCOE Department of Computer Engineering, University of Pune

Abstract—Android being an open source operating system android supports development of third party applications. Third party applications developed for android, which uses smart phone features are gaining popularity rapidly. Many security mechanisms are provided by android, such as application permission, signing application, component encapsulation to control these applications. Limited focus is given for the handling application behavior in different context. Context can be time, locations, permissions, data and resource access. Currently there are no ways for users to define different context to control applications. To achieve this, we propose user defined context privacy policy management (PPM) for android. In this work, we enhance android security mechanism to support context. The enhanced security mechanism will check user defined context configuration to grant access to application, it also detect any conflict between the contexts and resolved based on the priority given to the context. PPM provide interface to manage user defined context, where user can create context to control applications behaviour.

Keywords— Android, Context-aware, Mobile Computing, Policy Management, Security.

I. INTRODUCTION

Over the past decade, mobile phones have evolved from simple devices used for phone calls and SMS messages to sophisticated devices that can run third-party software. Phone owners are no longer limited to the simple address book and other basic capabilities provided by the operating system and phone manufacturer. They are free to customize their phones by installing third-party applications of their choosing. Mobile phone manufacturers support third-party application developers by providing development platforms and software stores (e.g., Android Market, Apple App Store) where developers can distribute their applications. Mobile-phone operating systems currently provide only coarse-grained controls for regulating whether an application can access private information, but provide little insight into how private information is actually used. For example, if a user allows an application to access location information, user has no way of knowing if the application will send location to a location-based service, to advertisers, to the application developer, or to any other entity. As a result, users must blindly trust that applications will properly handle their private data.

Android provide various security mechanisms such as UIDs, permission label, application signing and sandbox have been adopted into Android to enhance its security. However, the permission model of Android is coarse-grained and incomplete. For example, an Android application requests a list of permissions at installation; the user can only choose to either allow all these permissions or none. In addition, the user cannot revoke or change the permissions of an application once he grants the permissions, unless the application is re-installed. It cannot provide data protection and resource usage constraints in a fine-grained manner. Furthermore, there is no mechanism for the user to enforce permission constraints on resources usage in Android.

[image:1.612.328.566.512.588.2]

Some approaches have attempted to enhance the security of Android (or similar smart phone platforms) through malware detection, application certification and access control. However, to the best of our knowledge, no existing studies have combined context information to provide fine-grained security/privacy measures on smart phone platforms, especially on Android. To address these challenges, we propose user defined privacy policy management (PPM) for android platform to support context information and to control application behaviour.

Figure 1 Application with time constrain

(2)

International Journal of Emerging Technology and Advanced Engineering

559 Similarly, user can define various constraint related to location, private data and resources like Camera & Bluetooth accessibility. It is obvious that when user defines different constraints on single permission, some of these constraints may conflict with each other. So to detect and resolve such conflict, algorithms given in section III can be used.

[image:2.612.65.303.257.413.2]

II. PPMARCHITECTURE OVERVIEW

Figure 2 PPM architecture

Android layered architecture has application layer, framework, middleware and linux kernel layers. In the above architecture diagram Fig.2, we enhance the Android component Activity Manager Service to handle the context information, which is in the middle ware layer. We introduce the PPM Service Provider, which will provide the context information to the Activity Manager Service. The circled numbers in the Fig.2 indicate the processing flow sequence.

Step 1: User will use PPM Administrator application to create or define constraint on permission, resource and data which is stored in database.

Step 2: PPM Service Provider store the data into database and provide the updated information to administrator setting application.

Step 3: When Messenger application tries to access the permission e.g. Internet or Read Contact the Activity Manager Service will start processing the request.

Step 4: Activity Manager Service checks constraints defined by user from database. If there are any conflicts between constraints, it will resolve to grant or deny the access.

Step 5 & 6: If steps 4 grant the permission then Activity Manager Service checks for android permission access and grant or deny access for internet permission usage.

PPM components consists of following components, which are explain in details as mentioned below.

A. PPM Administrator Setting

This component will provide user interface for user to configure the context information. Context supported are Time, Location and Permissions, user can create its own context add the constraints for various permission. It can also enable and disable particular resource permission, for example read contacts or read SMS, access camera etc.

B. PPM Service Provider

This component will provide the updated configured context information to ActivityServiceManager component. This component will also provide the list of context to PPM Administrator setting component.

C. DbAdapter

SQLite database is local to android device. Here it can be used to store the PPM policy configuration. This database is access by PPM administrator setting application and android core library component Activity Service Manager. This component is a part of PPM Service Provider which provides methods to store and access context information to database. In Table 1, we have defined different context.

User might want to set context when he is doing shopping and do not want Bluetooth service to be available. User might want to set the context when he is travelling, and want his location access service available for applications.

User defined impersonate context, when phone is given to a friend and do not want his SMS, file to be accessible.

TABLE 1DATADEFINITION

Ctx _Id

User Defined ctx_name

Constraint s Type

Status Permission Value

1 Shopping Permission active Bluetooth Access

false

2 Travelling Location active Location Access

true

3 At Home Permission active Wi_Fi true 4 Impersona

te

Multi-select

active Read SMS, Read Contacts, Files

false

5 Office Time active Camera access

10 am to 5 pm 6 College Time active Bluetooth 9 to 11

[image:2.612.316.581.542.718.2]

(3)

International Journal of Emerging Technology and Advanced Engineering

560

D. Activity Manager Service

The Activity Manager Service is a singleton object which runs in the system server process. This is a part of android core library framework. It is responsible for managing the lifecycle of Android application processes and components such as Services, as well as the interactions between Android components in different processes. ActivityManagerService initiates the creation of component, that is start application service. This also checks if the application has access to the permission which are defined in AndroidManifest.xml. As shown in the Fig.2 above, we modified Activity Manager Service checkpermission method, which is the only public entry point for permission checking, this method can enforce android permission, PPM policies and constraints, which will grant or deny permission access to application. Check permission method in Activity Manager Service will access PPM database to get the latest policies and constraint configurations. Also it will resolve any conflict between these constraints (using algorithm CDR given below in section III).

III. POLICY IMPLEMENTATION

In this section, we will explain the policy implementation in details

A. Mathematical Model

Let A be a set of applications, R be a set of resources, X be a set of actions, and O be a set of obligations, respectively, our P-RBAC model[4] is defined using a condition language LC, which includes the following sets.

1. Resources Permissions RP = {(x,r)|xЄX,rЄR} X-actions, O-obligation.

2. Privacy-sensitive Resources Permission

PRP ={(rp,c,o)|rp ЄRP, o ЄO, c is an expression in LC}

3. Application Assignment AA ⊆ AxPRP is a set of many-to-many mappings from applications to permission.

Permission conflict detection and resolution is important in order to guarantee the consistency of permissions assignments. In this section, we present two algorithms CDR and CFDT. CDR algorithm is used to detect and resolve conflict. CFDT algorithm is used to resolve the conflict between to condition which are of different type. Examples of conflict scenario are given below.

Example 1: Two different time constraints C1 & C2 for same permission P2.

C1: P2: (App, (has, android.permission.INTERNET), (time > 9 ^ time < 11))

Example 2: Two different constraint C3 & C4 for two different permissions P2 & P3 respectively, which is also conflicting with each other. Here we have time and location constraints for two different permissions i.e. Internet and Read contact.

C4:P3: (App, (has, android.permission.READ_CONTACT), (location=Office))

B. Algorithm Conflict Detection and Resolution (CDR)

The algorithms given below can detect and resolve conflicting constraints for single type like Time as in example 1 as well as for different types as in example 2. This ability makes these algorithms robust enough to handle all different type of conditions.

CDR(c1, c2)

Declaration: c1 and c2 are two different conditions added on permission.

1.cList ← list of conditions

2.typeList ← list of all types of constraints used in application

3.op ← operator variable

4.result ← variable to hold the resultant value; 5. if(c1.type == c2.type)

6. op = typeList.getOperator(c1.type) 7. result = evaluate(c1,c2, op)

8.if(result.flag==true && result.name=c1) then 9. return c1

10. else

11. return c2 12. else

13. result = CFDT (cList) 14. if(result.flag == ―true‖) then 15. return result.name 16. end if

(4)

International Journal of Emerging Technology and Advanced Engineering

561 In algorithm CDR evaluate function; compare two conditions of same type with each other with appropriate operator. In algorithm CFDT evaluate function compares, value of condition with the current value of given condition type. For example, if the c[1] is time constraints, then in CFDT, it check if the current time is in between the given time constraints. If the c[2] is location constraints, then in CFDT it check if the current location is same as the c[2] value. Preference will be given to time, location and permission respectively.

C. Algorithm Conflict for Different Type (CFDT)

CFDT(cl)

1. Declaration: cl ← List of conditions to be evaluated. 2. i=j=0;

3. typeList ← list of all types constraints used in application

4. result.flag = false 5. while(cl) do

6. while(typeList) do

7. if(c[i].type ==typeList[j]) then 8. result = evaluate(c[i].value,

typeList[j].currentValue, typeList[j].operator) 9. if(result.flag == true)

10. result.name = c.name 11. return result

12. else

13. result.name = null

14. end if

15. end if

16. j++

17. end while 18. i++

19. end while 20. return result

D. Steps to Modify Android core library

To enhance the android security mechanism, we need to modify android servicers.jar file by modifying the Activity Manager Service. We introduce the checkPPM method call in checkPermission method, before it checks for the android permission access. Following steps are performed to modify the Activity Manager Service.

 Get Services.jar from Mobile Device / Emulator using Pull Command

 Get Android 2.3.3 source code and setup eclipse project

 Modify Activity Manager Service class

 Build Project and add modified class file to services.jar

 Use Push command to upload the modified services.jar into Mobile Device / Emulator

 Restart the Mobile device / Emulator

 Develop PPM project, build project and generate PPM.apk file

 Install PPM application on mobile device using PPM.apk file

 Run PPM application to setup the context for policy enforcement

Try accessing application which u ses restricted permission.

IV. SYSTEM EVALUATION

In this section, we evaluate the performance overhead due to enhancing the security mechanism to support context information. We conducted performance overhead using android virtual device emulator. Main reason for the overhead is due to PPM context check added before the Android Permission Check. We capture the time before and after the PPM context check method is called to calculate the time taken to grant or deny the access. The performance overhead will be negligible and near about 200ms. The overhead increases with the number rules to be evaluated which are shown in Fig 3.

Also PPM does not reduce the security of Android, though it can improve its security significantly in several cases, as we have introduced addition check only.

[image:4.612.327.570.543.675.2]

Storage Overhead, for 1 context information it takes about 30 bytes. For 50 such context it will take 1500 bytes (approximately 1.5 KB), which is negligible.

Figure 3 Performance Impact with increase in number of rules

0 100 200 300 400 500 600 700 800

10 20 30 40 50

Ti

m

e

f

o

r

p

erm

is

si

o

n

c

h

e

ck

(5)

International Journal of Emerging Technology and Advanced Engineering

562 V. CONCLUSION

The existing security mechanism on the Android platform is facing great challenges because of the mobility and openness of mobile computing environment. This paper proposes a user defined context privacy policy enforcement to enhance data protection and resource usage constraints on Android.

We propose user defined context privacy policy management, which is able to take context and constraints on permission into consideration while granting the permission access to application. We extend the existing security mechanism to implement a policy enforcement framework on Android, which enables users to grant permission in a fine-grained manner to support revocation and modifications on an application’s permissions at runtime. We also evaluate our mechanism with some frequently used actions, which shows that the overhead introduced by the proposed solution is acceptable. We will further study to improve the performance overhead on different version of android platforms.

ACKNOWLEDGMENT

This work is an ongoing part of post-graduation at the Pune University for a master thesis in Computer Engineering at Pune. P.A.W. Author takes this opportunity to thank Dr. A.B.Bagwan, Dr. P.K.Deshmukh & Prof. R.A.Deshmukh of Computer Engineering Department for their encouragement, support and untiring cooperation.

REFERENCES

[1] Guillaume Benats, Arosha Bandara, Yijun Yu, Jean-Noel Colin, and Bashar Nuseibeh, ―PrimAndroid: Privacy Policy Modelling and Analysis for Android Applications‖,IEEE 2011 paper.

[2] M. Nauman, S. Khan, and X. Zhang , ―Apex : Extending Android Permission Model and Enforcement with User-defined Runtime Constraints‖, Apr. 2010 paper.

[3] David Barrera, H. Güne¸s Kayacık, P.C. van Oorschot, Anil Somayaji, ―A Methodology for Empirical Analysis of Permission-Based Security Models and its Application to Android‖, CCS’10, October 4–8, 2010, Chicago, Illinois, USA.

[4] Q. Ni, A. Trompette, E. Bertino, and J. Lobo, ―Privacy-aware role based access control", ACM press,June 2007

[5] Google. Android Home Page, 2009. Available at:http://www.android.com.

[6] Google. Android Reference: Manifest File -Permissions, 2009. Available

at:http://developer.android.com/guide/topics/manifest/manifest-intro.html\#perms.

[7] Google. Android Reference: Security and Permissions,2009.

Available at: