CAPEF: Context-Aware Policy Enforcement Framework for Android Applications

,


Introduction
Context awarenes service is a key driver for the modern mobile operating systems which are commonly prompting users by showing authorization dialog boxes asking for allowing or denying access to some functionalities. These services opened a big interest in defining, managing, and enforcing context-aware policies especially for those scenarios that put users under the risk of leaking or misusing their credential information. Yet, thousands of malicious applications are developed on the Android store and affecting millions of Android users worldwide. To safeguarded Android users, Google is frequently announcing the cracking down of such malicious applications. For instance, Google has removed over 700,000 malicious applications from the Play Store in 2017 only [1]. Based on Goggle statistics, this is 70% more than what Google removed in 2016. Very recently in 2022, Google has removed 16 bad apps that missuses mobile data and draining batteries. Surprisingly, these apps have been downloaded by more than 20 million users around the world [2].
Android system protects sensitive APIs by granting them permissions to amplify application privileges on the device, including access to stored data and services, such as network, memory, and so on. All permissions required to access the protected APIs in each application's manifest file (AndroidManifest.xml) [3] are necessarily set by the Android app developers. System permissions are divided into two categories, normal and dangerous. Normal permissions do not pose a direct threat to the privacy of the user, although dangerous permissions may allow the application to access the user's confidential data. Existing application authorization system in Android allows you to control only the permissions that are classified as dangerous, whereas our developed policy approach, offers the ability to control all monitored permissions as any application may cause a risk or conflict within a specific context without user awareness. Also, our model will mitigate malware collusion in which two or more malicious apps combine to accomplish their goals. For example, a user can choose to allow a camera app to access the camera, but not to the contact information without his consent or awareness. Another example, where normal applications can be granted permissions to collecting user's contacts, photos, videos, locations, or banking information then sending it over the internet to a remote server and taking into consideration pre-defined context aware access control policies. Therefore, a flexible policy-based access control system is needed to monitor APIs functions in Android applications, especially those requiring access to the user's sensitive and crucial information. The current permission system of Android still has some limitations, where users must grant most permissions requested by an application to install it, without being able to automatically manage most of these permissions based on the user's context afterwards. This drawback has motivated the researchers to propose context-aware policies and/or define policy languages to enforce the current Android permission system either by modifying the Android platform such as in [4]- [8] or by instrumenting the Android Applications [9]- [18] and more recently in [19]- [21] (more details and comparisons can be seen in the background and literature review section). While, existing works have demonstrated significant effectiveness in protecting users against threats, these approaches are still impeded by several drawbacks.

Challenges
Defining and monitoring context-aware inter-app policies of sensitive APIs on Android applications presents several challenges. Especially, when we are trying to defend applications collaborating to create malicious contexts: i Context-aware inter-app policies are difficult to predict as they frequently get changed and need to be updated accordingly for accuracy and correctness.
ii Beside the difficulty of representing the security policies in a logical language which can contain user contexts and semantics, a key challenge is how to design and develop effective and efficient algorithms to monitor private information leakage on semantics levels.
iii There is a need for a policy language that can provide certain agreements that empower users with the ability to prioritize specific mobile resource and specify the amount and kind of information that can be shared within particular contexts. For instance, a user should be able to share a personal data with a specific service provider based on his location or at a specific time of the day to ensure his privacy. In this case, the user must agree on a trade-off between data privacy and the needed service. As a result, a policy should be defined to ensure privacy, while certain context-based information can be shared.
iv Android Sandboxing is introduced in the recent Android version 13.0. Sandboxing protects apps data and permission from getting access from other apps. This new feature will have an impact on our inter-apps policy model, but our main goal still effective which is to allow the user to define his policies to work automatically depending on the context update, to the running apps etc. Therefore our, framework can fully protect the Android OS versions lower than 13.0 in which the installed apps can communicate between each others.
v Due to the resourced constrained mobile devices, we have to decide, in early stages the instrumentation and monitoring location, whether to be on device, external PC or App market.

Contributions
This article is contributing solutions for the above-mentioned challenges and limitations by introducing: i A formal context-aware policy specification framework for Android applications that effectively describe users defined consents.
ii A design and implementation of an instrumentation framework to mitigate privacy leakage across different Android applications.
iii Providing a centralized applications controller. This will allow users to manage all API calls performed by the applications installed on the device and to mitigate malware activities.
iv Effectively enforce different behaviors based on automated context-aware policies for each Android application individually without any modification to be entailed in the underlying platform.
v Experiments conducted on our CAPEF in terms of performance by analyzing the size of the enforced application after the instrumentation, also, the execution time of the policy decision, and the policy size which affects the complexity of the applied rules and conditions.

Background and Literature review
Android applications are distributed as APK files (Android Package). Each package consists of the application's manifest file, resources and application bytecode encoded for the Dalvik Virtual Machine (DVM) as a single classes.dex file.
The APK file has to be signed for verifying its authenticity. Android signed package (Dex files) runs separately in its own DVM. Also, Android system is an open source platform where applications are published in different markets without being monitored or analyzed to guarantee their behavior. For that reason, Android platform protection mechanisms such as Application Sandboxing, Permission Model and Application Signing are developed for privacy and security purposes. Accordingly, at the time of installing Android applications, each application will get a unique user identifier (UID) [22]. Also, no application will be able to access other application's files. Besides, every application run into separate VMs. Accordingly, no vulnerable application will affect other applications. For Android access control policies, context awareness have become an essential accessory in most mobile platforms and applications. This necessity has motivated many researchers to provide policy enforcement mechanisms to www.jenrs.com Journal of Engineering Research and Sciences, 2(1): [13][14][15][16][17][18][19][20][21][22][23]2023 define, manage and enforce different context aware policies. In this context, traditional access control models which generally refer to the process of determining what actions are allowed by a given subject upon objects and resources should be reinforced to fulfill the modern context-aware applications.
The most popular access control models are Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC) [23] . For instance, RBAC is a model that uses "roles" to determine access control, also permissions are associated with these roles, and users are made members of appropriate roles. In ABAC, requests are granted or denied based on subject and resource attributes, environment conditions, and a set of policies specified in terms of those attributes and conditions. When it comes to using ABAC models, one of the well-known standard system implementations is XACML [24]. The XACML standard defines a declarative access control policy language implemented in XML and provides a processing model on how to evaluate access requests.
Thus, to adopt an effective context-aware access control model on Android platform and its application, there are series of work studying and proposing security mechanisms for privacy and security requirements. In this context, many reviewed efforts in [4]- [8] have been developed to extend the Android security framework in order to improve the standard permission control provided by the operating system. For example, SecureDroid [4] addressed the issue of controlling security policies while applications are executing in the Android environment. During the installation of an application, Android allows the user to grant permission for an application to use certain features of the system. Therefore, SecureDroid introduced an extension of Android's security framework in order to improve the standard permission control provided by the operating system. To achieve this goal, they introduced a new control mechanism adding granularity and flexibility. Moreover, their policy framework is based on customizing the XACML standard to work on the Android system. Also, they have provided the ability to add or edit a policy through a dedicated system service. This will allow users to specify which permissions to grant and which others to deny for each of the defined contexts.
However, modified Android platform has a number of major drawbacks such as the need of building different versions of firmware and platform codes, where applications will be limited by the security policies supported by the modified Android platform. Therefore, many researchers in [9]- [18] and more recently in [19]- [21] have provided solutions that are based on instrumenting Android Applications in ordered to enforce some security policies. These solutions require no modification to the Android platform and can be easily deployed. For instance, Aurasium [9] is a concurrent approach that rewrites Android application to sandbox important native API methods and monitors the behavior of the application to detect any security violations. Also, Capper [17] is a prototype for context-aware policy enforcement to mitigate privacy leakage in Android applications. This mechanism will enforce privacy policy based on user preferences. By using this system, when a user tries to install any Android application the bytecode rewriting engine called BRIFT will rewrite the program of this application by selectively inserts instrumentation code along taint propagation slices for monitoring and preventing any information leakage. Another interesting research called Weave Droid [18] has provided a framework for weaving AspectJ aspects into an Android application. The framework takes two inputs at the beginning: APK and a set of aspects that will be weaved into the APK. The weaving process will be performed on the Android device. Also, very recently in [21] They have developed a lightweight monitoring system to detect malware activities with the log file and they evaluated the proposed model according to Policy-based permissions.
Accordingly, some of the reviewed frameworks have provided enforcement mechanisms to mitigate Malware activities by enforcing context-related policies, however they didn't afford a policy specification language that runs on Android system as an application or a service without modifying the Android platform. Thus, this article is introducing a more featured policy specification language that allow regular users and any company to easily interpret and enforce their complex context-aware inter-apps policies on their Android mobile applications.

Summary of the literature reviews
The table 1 shows the summary and differences between our research and the other works.

System Overview
This section gives an overview of our approach that automatically enforces user specific context-aware policies for android application and monitors all API calls that occur due to the interaction between enforced applications. Our developed system works in the application level of the Android framework, and its main components are illustrated in Fig. 1.
i From left, the first components represented the instrumentation of the targeted Android application (byte code or source code) by injecting monitoring code before each selected API method's call to intercept it at run time.
ii After the instrumentation, the applications will be forced to communicate with our controller that monitors the targeted context-aware inter-app calls.
iii Then, users will use CAPEF interface to create contextbased rules and conditions in the form of security and privacy policies. More precisely, the policy represents a rule or set of rules based on a set of conditions and save it in the policies Database.
To motivate and illustrate our approach, we present the following scenario for vulnerability pattern that consider context-awareness policies. In this scenario, a user is using a public WiFi network in a coffee shop and he is trying to consult his credential banking information through his banking application. As the public network is not secure   [25] Dynamic Analysis Android Platform ✗ ✗ Appink [26] Watermarking Application ✗ ✗ Apex [5] Policy Enforcement Application ✗ ✗ TISSA [6] Resources Access Control Android Platform ✗ ✗ AppFince [7] Dynamic Analysis & Resources Access Control Android Platform ✗ ✗ Aurasium [9] Rewriting Java Bytecode Application ✗ ✗ I-arm-droid [11] Rewriting Dalvik bytecode Application ✗ ✗ AFrame [14] Isolating Advertisements Application ✗ ✗ Capper [17] Rewriting Java Bytecode Application ✗ ✗ SecureDroid [4] Policy Enforcement Android Platform ✓ ✗ Weave Droid [18] Isolating Advertisements Application ✗ ✗ [21] Policy-based permissions Application ✗ ✗ CAPEF Policy Language Application

✓ ✓
and there are other people who use the same network, so there is a risk of sending requests to attackers and thefts of private data. Android system checks only if the user has been previously granted the permission of accessing WiFi network and doesn't provide any context-awareness policies to mitigate such dangers scenarios. CAPEF can provide more effective access control not only on the permissions declared in advance by the user but also at run time based on the context of the user, device, and resources. Thus, as a solution to the above-mentioned scenario, a user can use CAPEF to define a policy that prevent the use of banking applications while connecting to a public WiFi network.
When an enforced bank application attempt to get public WiFi access, our application controller will first check if the permission is declared in the application manifest file. Then, will check if the user has defined any policies related to this permission in the policies database. Subsequently, the controller access decision will be based on the predefined policies for that specific API. As a result, the controller will notify the user for not being allowed to connect to public WiFi for banking activities.

CAPEF
Context-Aware policies are not static and might be changing over time to fulfill users' needs. Therefore, these policies could be used to control the behavior of the applications during run-time, which in our case, means monitoring and controlling all sensitive activities across different applications according to user's context. To achieve this goal, we provided a native Java-based CAPEF that allow regular users and enterprises to interpret and enforce their complex context-Aware policies. Contexts will represent various parameters including time, location, identity, activity, application, device status, resources etc. Moreover, these policies can be exported in multiple formats such as XML and JSON as they are widespread use today for data interchange and structured stores.
To develop the CAPEF language that allows the user to define contextual policies and transform them into security controls, we must rely on a flexible design that varies with the complexity of the policies, rational, able to execute all the conditions and easy to add new contexts.

CAPEF Architecture
The main components of CAPEF are shown in Fig.2. which represents the following: i Security policies: which is an interface for the user to define context aware policies and save them at the policy store. This component will act as a policy administration point (PAP) which is the source of the policies.
ii Enforced Application: Which plays the role of policy enforcement point (PEP) that receives the access request and move it to the Monitoring application for making access decision based on the predefined context aware policies.

Formal Definition
Hereafter, we formally define our ABAC policy model, which is composed of three main entities: ii BgApps is the set of the applications running in background.
For the value assignment of each attribute, we use the following notation: entity.attribute= value , For example, for an application app, a permission per and a context c, we have the following assignments: app.visiblity = 'background', per.securityLevel = 'Dangerous', c.location = 'Montreal'. 4 The ABAC policy rule that decides whether or not an application app is allowed is allowed to get the permission per under a particular context c, is denoted as a predicate PR over the attributes of app, per and c as follows: Rule : Allow(app, per, c) ← PR(Attr(app), Attr(per), Attr(c)) Given all the attribute assignments of app, per, and c, if the predicate's evaluation is true, then the application app is allowed to get the permission per under the context c; otherwise, the permission is denied. Using the formal definition, we can have different types of policies for the app, for example: 1. A rule that dictates that " When a banking applications is being used, so the TakeScreenshot actions should be prevented from running" can be written as: ii Allow recordCall (app, per, c) ←( RecordCall ∈ app.APIs) ∧ (per.resource==call) ∧ ((c.fgApp != 'skype') ∨ (c.time < 9:00am ∨ c.time > 10:00am)) Or simply by combining the two rules as following:

CAPEF Policy Specification
CAPEF language is based on the definition of a policy that consists of a user ID, a policy name, a policy execution state, a control rule, and a list of applications to control. Each of these applications is characterized by a name, package name, execution status and a list of permissions. The permissions consist of a name and a execution state. The security rule consists of a list of objects that can be Parentheses, Conditions, Logical Operators, Conditional Operators, CPU, Time, Resource Used, Location and Battery. As shown in Fig.3, user-defined security policies and its rules can contain multiple conditions, different contexts, multiple logical operators, and parentheses to specify priority between conditions. Also, these policies can be executed simultaneously in different inter-app activities across different applications. In this case, policy decision becomes more complex. Therefore, to facilitate and accelerate the execution of any compound policy, our algorithm will receive the current contexts and the control rule as parameters then returns the policy decision of the controller. In addition, the security rule might have sub-nodes of other rules, and themselves are sub-rules of the main rule. Therefore, we have adopted a recursive technique to reduce the complexity of the composed security rules. In this case, the algorithm will call itself, and recursion stops condition must be checked, otherwise the program will be stuck in an infinite loop.
To show the usefulness of our solution, we have chosen two examples of dangerous scenarios and we will translate them into security policies. I Critical scenario 1: If the user uses his banking application to check his data and deposit a check in his account, while a TakeScreenshot application is installed on his smartphone.This application that takes screenshots automatic present a risk on banking data that is personal life data.
i Solution: You must prevent the TakeScreenshot application and any screenshot function from running when the user is using their banking application.
ii To apply and evaluate the defined context aware policies, an application controller has been developed to allow users to define policies depending on different types of contexts and conditions.

Centralized Application Controller
The developed controller provides a user interface to translate the dangerous scenarios into security policies using the CAPEF. Based on the defined policies, the controller will make the adequate access control decision to allow or block applications from using certain permissions. Moreover, provide centralized control of installed applications which capture mandatory decisions that are automatically dependent on the current context. Fig. 4, shows an example of how to define a security policy with our controller. The control scenario is to block the execution of the Camera resource in the Camera application if the user is in a meeting from 10:30 to 11

Managing Security Policies
The Application controller interface has been developed in a way that the user will be able to define any security policies in a few simple clicks. We chose our solution to be ergonomic, personalized, and user-centric design to have a convenient and easy-to-use service. It has also been taken into consideration that our user interface must reduce the search effort and limit data entry. In addition, all policies created by the user have been saved in a database. With the database, the user will be able to import, create, view, and modify security policies.

Export/Import Security Policies
Our developed solution allows the user to extract his defined policies and share them with other users of the controller or send them to nay server or cloud database. Therefore, our CAPEF flows same related policy language's architecture and structure. As discussed in the literature XACML is one of the good examples to extract our policies to its format. While Android system does not compile XACML language and all reviewed languages, our policies will be translated into java language to execute them, then will be extracted on different languages such as XML, JSON etc. Therefore, in order for our language to be compatible with other languages, we kept the same generic policy structure, objects and attributes applied by other languages as as shown in Table 2. Similar translation procedure will be applied when importing policies from other languages.
Among the values that can be assigned to attributes such as the names of applications, permissions, etc., we have defined symbols that allow us to simplify the rules, for example: i ANY: it means no, for example a rental context, we do not need permission in this condition.
ii ALL: it means that we want to control all the permissions or all the applications it depends on the attributes used.
iii APPS: it means that we want to force the shutdown of an application.
iv API: that means we're going to apply the control on an API permission.

Policy
Presents the policy object that contains the" Target and" Rule Sub-objects, as well as the attributes:" Combine "which presents the role of the policy, the" AUTHOR-KEY-CN attribute the author identifier of the policy and the attribute AUTHOR-KEY-FINGERPRINT" presents the fingerprint key of the author of the policy. Target This is the object that contains the definition of the target applications to control.

Rule
It is the object that defines the security rule, the attribute" effect "presents the decision of the control to give or withdraw the authorization.

Condition
Contains the permissions to remove and the contexts.

Resource-match
Contains different attributes:" attr "which can be an application to block or an API permission," subject-match "contains the application to control and" match "contains the permission to remove.  5. shows the extraction of the above security policy scenario to XML and Fig.6. shows the extraction of the same scenario to JSON security policy.

Experimental results
This section presented the evaluation of our CAPEF and the application controller in terms of performance by analyzing: (1) the size of the enforced application after the instrumentation, 2) the execution time of the policy decision (3) The policy size due to the complexity of the applied rules and conditions.

Enforced Application Size
To measure the effect of the instrumentation method on the original size of the applications, we have instrumented a set of 109 applications using our rewriting framework. Table 3 shows a sample of eighteen applications, the original size and the new size after the instrumented. Indeed, this percentage represents the size of the code added during the control of APIs calls for each application individually For all instrumented 109 applications, the average size added was 705 bytes, which is about 0.063% of the size of the original applications. Also, as shown in Fig.7, it is very clear that the size added is very small and will have a very small impact on the size of the original applications.

Execution time of the policy decision
To calculate and evaluate the execution time of our defined policies, we have calculated the decision execution time for several context aware policies with different rules and conditions based on some selected scenarios. The following is a set of scenarios that has been chosen among many others used during our tests. These scenarios will be ranked in ascending order according to their level of complexity.  The decision execution time has been calculated for each policy individually as following: i For the Policy 1 and Policy 2, the test results were fixed because the context does not vary when entering random test values. The execution time for the first policy is 116 ms and for the second policy is 234 ms.
ii For the policy 3, the context is related to three different running applications, but it remains fixed. The execution time for the whole policy is 307 ms.
iii For the policy 4, our context is the location, so the results were more or less close, but they vary according to the change in GPS values. In this case the execution time of the whole policy is 314 ms.
iv For the policy 5, two different contexts were used time and location. The average execution time for notifying each application also was calculated. For the Skype application the execution time is 549 ms, for the Messages application is 592 ms, for the Instagram application is 634 ms, for the Gmail application is 758 ms and for Facebook is 814. Also, the average execution time for the whole policy is 818 ms. Fig.8, shows the different policies execution times according to the complexity for each policy. All calculations and testes where repeated several times to ensure accuracy.
As a result, we have noticed that as more the policy becomes complex the execution time becomes bigger.

Policy Size
The policy size is also changing due to the complexity of the applied rules and conditions. We have calculated the policy www.jenrs.com Journal of Engineering Research and Sciences, 2(1): [13][14][15][16][17][18][19][20][21][22][23]2023 sizes on the list of 109 enforced applications. Also, we took the same fife scenarios and their security policies mentioned above in the previous section to make our simulation. Fig.  9 shoes the progression of policy sizes according to their complexities.

Conclusion and Future Work
This work addressed problems related to context aware policies for Android applications as its one of the main targets of attackers. We, therefore developed CAPEF, which is a policy specification framework that enforces context-aware inter-app security policies to effectively describe users defined consents. Thorough experiments we have performed a study on the efficiency of CAPEF with respect to the size and execution time of the enforced applications. The evaluation results demonstrated the feasibility of our framework and the effectiveness of our policy specification language in enforcing complex context-aware policies on different Android applications.
In the future, we are planning to improve our model using different ML techniques for varying IoT smart environments. Furthermore, we will implement a security framework that is capable of data security and access control by encrypting all sensitive data and making it available only for the authorized service providers according to the pre-defined context-aware policies.