Fine-grained access control method for private data in android system

Abstract

In Android systems, sensitive information associated with system permission is exposed to the application completely once it gains the permission. To solve this problem, this article presents a fine-grained access control framework for sensitive information based on eXtensible Access Control Markup Language data flow model. In this framework, a user can define access policies for each application and resource and the application’s access request to sensitive information is evaluated by these policies. Therefore, all access requests must comply with the security policy irrespective of whether they have gained the permission associated with the information. This helps to protect sensitive data outside the Android permission mechanism. In order to facilitate users to manage policies, the proposed framework implements automatic policy generation and policy conflict detection functions. The framework is implemented in TaintDroid and experiments indicate that the improvement is effective in achieving fine-grained access control to sensitive information and does not adversely affect the system overhead costs.

Keywords

Permission mechanism security policy Android fine-grained access control policy conflict detection

Introduction

With the development of the Internet of things, the functions of sensor nodes are becoming more and more powerful.^1,2 Many smart sensor nodes are designed based on embedded systems, and Android, as an embedded operating system, is playing an increasingly important role in the Internet of things. Of course, its security is also receiving more and more attention.

In Android systems, several applications (apps) abuse permissions to access sensitive information and maliciously use user privacy data sometimes without their knowledge. According to the 360 company’s report (April 2016), the 360 security centre intercepted a total of 98,000 phone malicious app samples. Furthermore, a total of 1.462 million devices in China were infected by information stealing virus apps. Among them, 1.134 million devices were infected by SMS message stealing apps.³ According to the statistics of mobile device security vulnerabilities by China’s National Vulnerability Database (CNNVD) in 2016, buffer overflow vulnerabilities and permission permit vulnerabilities in access control were the two most common, amounting to 1207 and 853, respectively.⁴

For certain official apps trusted by users, issues of permissions abuse and privacy data leakage also exist. One hundred common apps (the names of these apps are shown in the Appendix 1) in Android markets have been tested in TaintDroid,⁵ and the report is shown in Tables 1 and 2. Table 1 counts the number of apps that apply for the respective permission, whereas Table 2 counts the number of apps that send sensitive information to known or dangerous servers.

Table 1.

Number of apps that apply for respective permissions.

Permission	Number of apps
Phone state	99
System setting	90
Location information	89
Hardware control	87
Read contact	63
Dial the phone	41
Send and read message	39
Read phone record	24
Send email	23
Read browser history	21
Modify calendar	11

Table 2.

Number of apps that send out private data.

Sensitive data	Number of apps
Sensitive data	To known servers	To dangerous servers
IMEI	92	23
ICCID	5	1
Location	37	1
Contact	3	0
Photo	2	0
Browser history	7	3

We arrive at two conclusions from the above statistics.

Apps may apply for additional permissions that are not required for its normal functioning.

Some apps send user’s private data to advertisements or other dangerous servers where their privacy may be used maliciously.

In order to strengthen the authority mechanism, Google proposed a runtime permission mechanism after the Android M version. While installing apps, users are not required to grant all secret permissions and can revoke one or more permissions from it at any time. At runtime, permissions required by the app are manually granted by the user through an alert dialog. This mechanism has solved the problem of permission abuse to a certain extent; however, it will never be eliminated. First, apps are ‘greedy’ and apply for extra permissions with ‘a seemingly legitimate’ reason. Non-professional users usually grant these permissions when this request is received. Second, some apps show ‘rogue’ characteristics and stop working when the user refuses to grant applied permissions. Third, apps are ‘curious’. Most of them expect additional privileges and snoop on extra private information of users even without maliciousness.

Android does not have additional protection for private information except for the permission mechanism. Once an app gains permission, whether it is obtaining private data or using information illegally, the users are helpless in this scenario.

Aiming at this limitation of Android, this article presents a fine-grained access control framework for Android based on an eXtensible Access Control Markup Language (XACML) data flow model.⁶ In this framework, a user can configure security policies for each private data item and each app. Even if an app is granted permission to a resource, whether it can access the resource or obtain real information depends on the users’ predefined security policies.

The rest of this article is organised as follows: ‘Related work’ section describes the related work on Android security research. ‘The fine-grained access control model for sensitive data’ section introduces the fine-grained access control method for private data in Android. ‘Implementation and experiments’ section carries out certain experiments to verify the effectiveness of the new mechanism. The ‘Conclusion’ section concludes the work of this article.

Related work

Research on Android security can be classified into two directions. The first is improving system security by modifying the Android system. The second is concentrating on security detection of Android systems and apps such as Dypermin,⁷ Android malware detection,^8,9 and permission system security flaws detection.^10,11 The work in this article corresponds to the former category and merely introduces studies corresponding to the latter category.

M Ongtang¹² proposed Saint that modified the framework layer and realised the assignment of permissions. Saint controls the permission usage in the app runtime. M Nauman proposed an Android policy execution framework called Apex. Similar to Saint, in order to protect private data, Apex allowed users to grant permissions selectively when an app was installed in the system.¹³ These ideas were proposed earlier than Google’s runtime permission mechanism in Android Marshmallow. To overcome the rigidities of the Android permission mechanisms, Inverardi et al.¹⁴ proposes a user-centric approach that authorises the end users to specify the desired privilege level based on each feature. In Aron and Hanacek,¹⁵ a dynamic permission mechanism for Android was proposed. This mechanism prevents possible leakage of secret data by dealing with assignments or enforces permissions to the app according to the files that the app works with. D Wang et al.¹⁶ proposed an OS-level middleware which is a secure, usable and transparent middleware that enables the permission manager to confront permission leaks. Moreover, it makes Android permission mechanism flexible and fine-grained. In Beresford et al.,¹⁷ Beresford proposed MockDroid which is an improvement on the Android system that allows users to simulate the app’s access to resources and achieves dynamic removal of access to specific resources at runtime. The Android security extension model (YAASE) proposed by G Russello et al.¹⁸ is specifically for accessing leak-sensitive data over the network. YAASE provided a fine-grained security mechanism without adding extra performance overhead. S Bugiel et al.¹⁹ proposed FlaskDroid that provides mandatory access control (MAC) on both the middleware and kernel layers in Android. The author also proposed an efficient policy language that is specific to the middleware semantics of Android. Another security architecture that provides MAC is proposed by R Chang et al.,²⁰ which is designed based on the ARM TrustZone security extension mechanism and provides permission-based MAC on Android middleware, Linux kernel and hardware layers. Samlley proposed the Security Enhanced Android (SEAndroid)²¹ that also implemented the MAC model in Android. The basis of SEAndroid is the discretionary access control, and the added MAC is used to enhance the flexibility of the system. Apart from the above works on improving the permission mechanism of Android, there are various classic works to solve a specific security problem in Android, such as privilege escalation attacks,^21–24 man-in-the-middle attacks^23,25 and inter-process communication call vulnerabilities.^26–28 To help inexperienced users manage permissions securely, some researchers proposed numerous permission management methods such as RecDroid²⁹ and the use of categories.³⁰ They can also be classified as an improvement of Android permission mechanisms.

Most of the above research is aimed at the permission mechanisms of Android. In fact, we believe that users have a better understanding of information than permission, and that most users know what information is private and should not be accessed by others. Therefore, it is easier for users to understand protecting information than granting permission. Motivated by this concept, this article proposes a fine-grained access control method. When different security policies are applied, an app that is granted permission to a resource may obtain different access results. This provides secondary protection for sensitive information after Android permissions, and provides meaningful security management for users.

The fine-grained access control model for sensitive data

The design of the model is based on the XACML data flow model, and its components are similar to the definition of XACML. The architecture is shown in Figure 1.

Figure 1.

Architecture of the fine-grained access control model.

Definition of related terms

Components and terms in the model are defined formally as follows:

Subject: subject refers to the app in the Android system.

Object: object refers to all user data and system sensitive data. For example, contacts, SMS, call records, files and so on are user data. IMEI code, ICCID code, GPS information and other equipments are system sensitive data.

Op: the operation of the subject on the object. Two operations, read and write, are defined in the proposed access control model, that is, op ∈ {read, write}.

Decision: the access control decision, decision ∈ {real, empty, bogus}. Real indicates that real data will return to the requester, empty for empty data, and bogus for faked data. Some apps may not work properly if the system does not grant it permission to an object. It may lead to privacy leakage if permission is granted and real data are returned. The security policy allows the system to return empty or bogus data to the app such that it can work normally.

Priority: the priority of a policy. Two priorities are defined in this article: ‘low’ for user-defined policy and ‘high’ for system-generated policy.

Context: the runtime context of a policy and it is different from the concept of context in Android. Here, only time context is defined and it is expressed as ‘t0–t1’, which defines a period from t0 to t1.

Policy: the policy is defined as a six tuple <subject, object, op, time, decision, priority>. It defines the access rules of the subject to the object. For example, the policy p = <GoogleMap, MMS, read, 8–22, real, high> indicates that when GoogleMap reads messages between 8:00 and 22:00, system would return real data, and this policy has ‘high’ priority.

Request: a request can be expressed as a triple <s, o, op>, where s is the subject, o is the object and op is the action of the request.

PDP: policy decision point, evaluating request according to policy and making decision.

PEP: policy enforcement point, executing request according decision made by PDP.

Data flow of the model

The proposed fine-grained access control framework is shown in Figure 1. A user can view, add and delete policies at any time. When a policy is added, the conflict between it and policies in the policy database will be detected and resolved by the policy conflict detecting and resolving module. A complete access request process is detailed as follows:

Subject s sends request to PEP when it wants to access object o.

PEP sends req = <s, o, op> to PDP, where s is the app and o is the resource requested by s, and op is the operation type.

PDP sends parameters <s, o, op> to the policy database interface module.

The policy database interface queries policy database and returns a policy set (pSet) to PDP:pSet = {p₁, p₂,…p_i,…, p_n}, where p_i = <subject_i, object_i, op_i, time_i, decision_i, priority_i>, and satisfy: subject_i = s, object_i = o, op_i = op.

PDP obtains current system time: valtime;

PDP evaluates the request with pSet and valtime, and returns decision to PEP.

PEP executes this request according to the decision returned by PDP.

PEP triggers the auto policy generating module.

Auto policy generating module generates new policies dynamically based on the last executed policy and sends them to the policy conflict detecting and resolving module.

Policy conflict detecting and resolving module adds the new policy to policy database after conflict resolution.

Analysis of policy generation and conflicting resolution

As mentioned above, there are two interesting functional modules in the proposed access control model. The first is the auto policy generating module and the second is the policy conflict detecting and resolving module. These two key aspects will be discussed in the next sections.

Policy auto generation

Some resources or data in Android are highly correlated. When one of them is authorised, the correlative resources should also be authorised in the same manner. Table 3 lists a few strong correlative resources. For example, when an app is granted permission to read SMS, extra policy may be generated according to this policy, which will allow reading MMS in the same condition. The priority of the automatically generated policy is ‘low’, which is lower than the user-defined policy. For example, policy p₁ is the current executed policy and p₂ is the policy that is automatically generated.

p₁ = <BaiduMap, SMS, 8–20, read, real, high>

p₂ = <BaiduMap, MMS, 8–20, read, real, low>

Table 3.

Resource set with correlation.

Telephony	Contact Book, Call Log
Location	ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, ACCESS_MOCK_LOCATION
Phone	CALL_PRIVILEGED, READ_PHONE_STATE, CALL_PHONE
Message	SMS, MMS
Internet	ACCESS_NETWORK_STATE, INTERNET
…	…

In the proposed access control framework, once an authorisation is completed by PEP, the matched policy is send to auto policy generating module to generate extra polices according to the access control decision and related object set.

Policy conflict detecting and policy evaluating

When a request is evaluated by PDP (step (6) in ‘Data flow of the model’ section), multiple polices may be matched, and policy conflicts or redundancy may emerge. Policy conflicting refers to when two or more policies match the same request and make different decisions. If these policies make the same decision, they are redundant. For example, there are three policies as follows:

p₂ = <GoogleMap, MMS, read, 8–22, real, high>

p₃ = <GoogleMap, MMS, read, 8–10, real, high>

p₄ = <GoogleMap, MMS, read, 8–22, bogus, high>

Evidently, p₃ is a redundant policy, and policy p₂ and p₄ are conflicting policies. When adding a new policy to the policy database, redundant and conflicting policies must be detected and resolved. Figure 2 presents the redundancy and conflicting policies detection and resolution algorithm. However, the algorithm only resolves some conflicts; most of them may still exist, such as p₅ and p₆ as shown in the following; it is not resolved by the algorithm:

p₅ = <UNIONPAY, MMS, read, 9–19, real, high>

p₆ = <UNIONPAY, MMS, read, 17–22, empty, high>

Figure 2.

Policy conflicting and redundancy detection.

When UNIONPAY requests MMS at 6 p.m., p₅ and p₆ are matched and a conflict occurs. The resolution of these conflicts has to be performed dynamically during runtime.

There are several dynamical resolution algorithms for security policy conflicts, such as deny-overrides, permit-overrides, first-applicable, only-one-applicable and so on.³¹ Here, we use the approximation algorithm of only-one-applicable. In that case, the result of this algorithm ensures that only one policy is applicable. If no policy applies, then the result is ‘bogus’, but if more than one policy is applicable, then the result is ‘empty’. When exactly one policy is applicable, the result of the algorithm is the result of evaluating the single applicable policy.

Comparison to other models

Most of the existing models focus on permission mechanism and improve the flexibility of permission management to protect private information. Our model modified Android framework layer to add an additional protection module in addition to permissions of Android. Even if the app gets the permission, whether it can access the real private data depends on the user-defined security policy. Table 4 analyses and compares several models in the literature. The uniqueness of this article is also illustrated.

Table 4.

Comparison of different models.

	Basic principle and function	Real-time controlof privacy	Bogus data return	Dynamic policygeneration
Kirin	Extracting the privilege information before installing an app, and then decide whether to instal the application or not.	No	No	No
Mock-droid	It realises the function of dynamically revoking access to specific resources at runtime	Yes	Yes	No
Saint	Modified the framework layer, and realised the assignment of permissions, restricting application access resources by filtering request.	Yes	No	Yes
Apex	When installing APP, users can selectively grant permissions, and in the runtime, the previous restrictions can be modified.	Yes	No	No
YAASE	Added a layer of access control framework, designed policy configuration programme to control the sensitive resources through the network access system.	Yes	No	Yes
Our model	Presented a fine-grained access control framework for sensitive information, user can define access policies for each app and resource. Protecting private information beyond the permission mechanism	Yes	Yes	Yes

Kirin takes a crude approach to protect privacy, refusing to instal apps that violate security policies. MockDroid, Saint and Apex all add runtime granting to increase flexibility of permission mechanism. YAASE added an access control layer to prevent sensitive information from leaking through the network. Our work is similar to YAASE, but with more fine-grained access control to private data. In our proposed framework, a user can configure security policies for each private data item and each app. When an app requests private data, our framework returns real, bogus or empty data to it based on user-defined policies. In this way, the abuse of permissions is prevented and users’ private data are protected.

Implementation and experiments

To verify the effectiveness of our work, the framework is implemented in TaintDroid. The reason TaintDroid has been chosen is because the flows of all sensitive data can be monitored. Figure 3 shows the modification in TaintDroid. It is mainly modified in the app and framework layers. We add the PolicyConfig app to the app layer. As shown in Figure 4, the user can configure policies through the PolicyConfig. In the framework layer, the relevant managers and system API are modified, and the function of policy decision for private data is added.

Figure 3.

Modified module in TaintDroid.

Figure 4.

Application of PolicyConfig.

On the improved TaintDroid, experiments are carried out to test the compatibility with apps, system availability, memory overhead and overall system performance.

Compatibility testing

A total 100 apps for 10 categories (shown in Appendix 1) in the Android market are selected as samples, and each app runs 5 min in the improved TaintDroid system. Testing covers the maximum possible functions, and we observe the running results of each app. As shown in Table 5, it can be concluded that the improved TaintDroid system is still compatible with most apps. In the 100 apps, 360 mobile assistant and Baidu map failed to be launched. Moreover, NetEase News and QQ Mailboxes were unresponsive. The remaining 96 apps can run normally on the improved TaintDroid system.

Table 5.

Result of compatibility test.

Category	Number of test apps	Incompatible	Start failure	No response
News	10	1		NetEase News
Life	10	0
Shopping	10	0
System	10	1	360 mobile assistant
Social	10	0
Business	10	1		QQ Mailboxes
Traffic	10	1	Baidu Map
Video	10	0
Sport	10	0
Comics	10	0
Total	100	4

Effectiveness in access control

Ten apps were selected from the above 100 sample apps to be tested. These 10 apps apply for the permissions to read contact, get location and get IMEI code, respectively. Table 6 presents the predefined security policies. Each app runs for 5 min, and we have the test results by comparing the notification of TaintDroidNotify and the experimental data as shown in Table 7. It shows that all the requested private data were sent out of the device in TaintDroid system, but 0 true data item in the improved TaintDroid system. For one app, the privacy leakages in the TaintDroid and the improved TaintDroid are shown in Figure 5. In TaintDroid, the true IMEI code (‘000000000000000’ for simulator) is sent out, but it is a randomly generated one (‘361805934860532’) in the improved TaintDroid. It shows that the test results match the defined security policies.

Table 6.

Security polices for test apps.

Sensitive information	Security policies
Location	<Toutiao, ACCESS_COARSE_LOCATION, read, 0–24, empty, high><TcentNews, ACCESS_FINE_LOCATION, read, 0–24, bogus, high><Ganji, ACCESS_FINE_LOCATION, read, 0–24, empty, high><Keep, ACCESS_ FINE _LOCATION, read, 0–24, bogus, high><Zhihu, ACCESS_COARSE_LOCATION, read, 0–24, empty, high>
IMEI	<Toutiao, READ_PHONE_STATE, read, 0–24, bogus, high><TcentNews, READ_PHONE_STATE, read, 0–24, empty, high><Ganji, READ_PHONE_STATE, read, 0–24, bogus, high><Keep, READ_PHONE_STATE, read, 0–24, empty, high><Zhihu, READ_PHONE_STATE, read, 0–24, bogus, high>
Contact	<Toutiao, READ_CONTACTS, read, 0–24, bogus, high><TcentNews, READ_CONTACTS, read, 0–24, bogus, high><Ganji, READ_CONTACTS, read, 0–24, empty, high><Keep, READ_CONTACTS, read, 0–24, bogus, high><Zhihu, READ_CONTACTS, read, 0–24, empty, high>
Browser history	<Toutiao, READ_HISTORY_BOOKMARKS, read, 0–24, bogus, high><TcentNews, READ_HISTORY_BOOKMARKS, read, 0–24, bogus, high><Ganji, READ_HISTORY_BOOKMARKS, read, 0–24, empty, high><Keep, READ_HISTORY_BOOKMARKS, read, 0–24, bogus, high><Zhihu, READ_HISTORY_BOOKMARKS, read, 0–24, empty, high>

Table 7.

App effectiveness test.

	TaintDroid(true/total)	ImprovedTaintDroid(true/total)
Location information	5/5	0/5
IMEI information	9/9	0/9
Contact information	3/3	0/3
Browser history	3/3	0/3

Figure 5.

IMEI code sent out by app: (a) true IMEI sent out in TaintDroid and (b) bogus IMEI sent out in improved TaintDroid.

Memory consumption test

The purpose of this experiment is to test the additional memory cost. In this experiment, 40 security policies are defined for four categories of sensitive data and 11 apps (shown in Table 8). Four apps are selected as samples to run in both the TaintDroid and improved TaintDroid. Table 9 lists the average memory cost of four samples. As for memory consumption test, the main purpose is to show that the additional memory cost of improved TaintDroid is just small. Memory consumption is unrelated to the number of policy or the size of private data. In addition, the policy conflict detecting and resolving module and app working are executed asynchronously. There are no influences on memory consumption.

Table 8.

Policies in memory cost testing experiments.

Sensitiveinformation	Number ofsecuritypolicies	Apps
Location	10	Toutiao, Ink weather, etao,Mobile Jingdong, UC Browser,WeChat, dingtalk, KEEP,sohu video, Baidu Travel, Tencentcartoons
IMEI	10
Contact	10
Browserhistory	10

Table 9.

Memory cost.

Privacy data type	TaintDroid(MB)	Improved TaintDroid (MB)	Growth amount
IMEI	24.32	24.36	0.16%
Contact	24.47	24.73	1.06%
Location	24.33	24.36	0.12%
Browser history	24.05	24.12	0.29%

System overall performance test

We use Caffeine Mark 3.0 to evaluate the performance of the improved TaintDroid. Ten tests are conducted to measure and average the test scores of the two systems. The test environment is shown in Table 10, and the test results are shown in Figure 6. The results show that the overall performance of the improved TaintDroid is slightly reduced; however, the difference between the two systems is considerably small.

Table 10.

Test environment.

	TaintDroid	Improved TaintDroid
CPU	ARM (armeabi-v7a)	ARM (armeabi-v7a)
RAM	2G	2G
CaffeineMark Version	3.0	3.0
Other	TaintDroidNotifyRun	TaintDroidNotifyRun

Figure 6.

Test results of system performance of the two systems.

Conclusion

In this article, we analyse the limitations of the permission mechanism of Android and present a sensitive data protection method that enables the user to define access policies for sensitive information. Whether an app that has been granted permission to a private resource can obtain data related to this permission depends on the predefined access polices. In the new proposed access control method, the decision forms of the traditional access control model have been changed from two states (permit and deny) to three states (real, bogus and empty). This transformation ensures the availability of an app and achieves the purpose of privacy protection. In addition, to improve practicality, policy generation and conflict detection are discussed. Experiments demonstrate that the improvement has little effect on the system performance; however, it provides secondary protection to private information beyond the permission mechanism of Android systems.

Footnotes

Appendix

Appendix 1.

One hundred sample apps used in this article.

Appcategories	Apps name
News	Toutiao, Tencent news, Phoenix News, NetEase News, 36 Kr, Home of IT, Tiexue, Jike, Zaker news, Particle News
Life	58 City, Ganji Web, Chinese calendar, Ink weather, Meittuan Takeout, Baidu Takeout, eleme, taopiaopiao, MyWheather, Dianping
Shopping	Mobile Jingdong, etao, Mobile Taobao, Tmall, Suning, Chuchujie, Meilishuo, VipShop, dangdang, Ebay
System	Mobile Baidu, UC Browser, LBE Privacy Guard, Baidu browsers, Baidu Mobile phone guard, sougou Typewriting, Zupool, Baidu Typewriting, QQ Typewriting, Xunfei Typewriting
Social	WeChat, weibo, QQ, Baidu tieba, Zhihu, QQ Synchro assistant, easyMarkets, WhatsApp, inke, quhepai
Business	youdao note, yinxiang note, WPS, Hammer note, 163 Mail, QQ Mail, camcard, dida, linkedin, dingtalk
Traffic	Qunar Travel, Ctrip, Baidu Map, Tecent Map, amap, Alitrip, Didichuxing, Shenzhou special car, Baidu Travel
Video	Youku, Iqiyi, kuaishou, sohu video, NetEase cloud music, Kmplayer, Himalaya FM, Meitu Xiu Xiu, Tecent tu, Beauty shot
Sport	KEEP, the joy run, Music power, Daily yoga, Doctor of spring rain, good doctor, Medicine assistant, lamabang, sythealth, More beautiful
Comics	Kuaikan manhua, Tencent cartoons, cartoon island, buka, icartoons, migu, manman catroons, u17 cartoons,comicool cartoons, manhuaren

Handling Editor: Suat Ozdemir

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported in part by the National Science Basic Research Plan in Shaanxi Province of China (Programme No. 2018JM6034) and the National Natural Science Foundation (NNSF) of China (Grant No. 61572385).

ORCID iD

Gang Liu

References

Wang

A privacy-preserving and accountable authentication protocol for IoT end-devices with weaker identity. Future Gener Comp Sy 2018; 82: 342–348.

Yin

Sun

et al . Location privacy protection based on differential privacy strategy for big data in industrial Internet of Things. IEEE T Ind Inform 2018; 14(8): 3628–3636.

360 Fenghuo Lab. Mobile phone malicious program personal information situation analysis report. Beijing, China: Qihu 360 Company Fiber Optics Laboratory, 2016.

China Information Security Evaluation Center. Information security vulnerability bulletin. China Inform Secur 2014(12): 126–129.

Enck

Gilbert

Chun

et al . TaintDroid: an information flow tracking system for real-time privacy monitoring on smartphones. ACM T Comput Syst 2010; 32(2): 129–129.

Schilders

Daoudagh

Lonetti

et al . Automated testing of extensible access control markup language-based access control systems. IET Software 2013; 7(4): 203–212.

Lyvas

Lambrinoudakis

Geneiatakis

Dypermin: dynamic permission mining framework for android platform. Comput Secur 2018; 77: 472–487.

Sun

Yan

et al . Significant permission identification for machine-learning-based android malware detection. IEEE T Ind Inform 2018; 14: 3216–3225.

Navarro

AKW

Grégio

et al . Leveraging ontologies and machine-learning techniques for malware analysis into Android permissions ecosystems. Comput Secur 2018; 78: 429–453.

10.

Bagheri

Kang

Malek

et al . A formal approach for detection of security flaws in the android permission system. Form Asp Comput 2018; 30: 525–544.

11.

Geneiatakis

Fovino

Kounelis

et al . A permission verification approach for android mobile applications. Comput Secur 2015; 49(C): 192–205.

12.

Ongtang

Mclaughlin

Enck

et al . Semantically rich application-centric security in Android. In: Computer security applications conference, Honolulu, HI, 7–11 December 2009. New York: IEEE.

13.

Nauman

Khan

Zhang

Apex: extending android permission model and enforcement with user-defined runtime constraints. In: 5th international symposium on ACM symposium on information, computer and communications security, Beijing, China, 13–16 April 2010. New York: ACM.

14.

Inverardi

Salle

Autili

et al . User-centric Android flexible permissions. In: International conference on software engineering, Buenos Aires, 20–28 May 2017, pp.365–367. New York: IEEE.

15.

Aron

Hanacek

A concept of dynamic permission mechanism on android. AIP Conf Proc 2016; 1705: 020022.

16.

Wang

Yao

et al . A secure, usable, and transparent middleware for permission managers on Android. IEEE T Depend Secure 2017; 14: 350–362.

17.

Beresford

Rice

Skehin

et al . MockDroid: trading privacy for application functionality on smartphones. In: 12th workshop on mobile computing systems & applications, Phoenix, AZ, 1–2 March 2011. New York: ACM.

18.

Russello

Crispo

Fernandes

et al . YAASE: yet another android security extension. In: IEEE third international conference on privacy, security, risk and trust, Boston, MA, 9–11 October 2011. New York: IEEE.

19.

Bugiel

Heuser

Sadeghi

. Flexible and fine-grained mandatory access control on Android for diverse security and privacy policies. In: Proceedings of the 22nd USENIX conference on Security, Washington, DC, 14–16 August 2013. Berkeley, CA: USENIX Association.

20.

Chang

Jiang

Chen

et al . Towards a multilayered permission-based access control for extending Android security. Concurr Comput: Pract Exp 2018; 30: e4180.

21.

Malley

Craig

Security enhanced (SE) Android: bringing flexible MAC to Android. Auckland, New Zealand: NDSS, 2013.

22.

Alshehri

Hewins

McCulley

et al . Risks behind device information permissions in Android OS. Commun Netw 2017; 9: 219–234.

23.

Heuser

Negro

Pendyala

et al . DroidAuditor: forensic analysis of application-layer privilege escalation attacks on android (Short paper). In: Grossklags

Preneel

(eds) Financial cryptography and data security. Berlin: Springer, 2017, pp.260–268.

24.

Marforio

Francillon

Capkun

Application collusion attack on the permission-based security model and its implications for modern smartphone systems, vol. 19. Zurich: Department of Computer Science, ETH Zurich, 2010, pp.1–18.

25.

Conti

Dragoni

Lesyk

A survey of man in the middle attacks. IEEE Commun Surv Tut 2016; 18(3): 2027–2051.

26.

Wei

Wolf

A survey on HTTPS implementation by Android apps: issues and countermeasures. Appl Comput Inf 2016; 13(2): 101–117.

27.

Dietz

Shekhar

Pisetsky

et al . Quire: lightweight provenance for smart phone operating systems. In: Proceedings of the 20th USENIX conference on security, San Francisco, CA 8–12 August 2011, p.23. Berkeley, CA: USENIX Association.

28.

Yagemann

Intentio ex machina: Android intent access control via an extensible application hook. In: International conference on ubiquitous intelligence & computing and international conference on autonomic & trusted computing, Fukuoka, Japan, 4–7 September 2012. New York: IEEE.

29.

Rashidia

Funga

Vub

Android fine-grained permission control system with real-time expert recommendations. Pervasive Mob Comput 2016; 32: 62–77.

30.

Morales

Rueda

SJ.

Meaningful permission management in Android. IEEE Lat Am T 2015; 13: 1160–1166.

31.

Rissanen

. eXtensible access control markup language (XACML) version 3.0. OASIS Standard, 2013, http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html