Majid Hatamian
email: majid.hatamian.h@ieee.org

Agnieszka Kitkowska
email: agnieszka.kitkowska@kau.se

Jana Korunovska
email: jana.korunovska@wu.ac.at

Sabrina Kirrane
email: sabrina.kirrane@wu.ac.at

A K Lieberknecht

C Stern

H Chen

"It's shocking!": Analysing the Impact and Reactions to the A3: Android Apps Behaviour Analyser

Keywords: smartphone ecosystems, android, privacy, permission, privacy concern, privacy behaviour

The lack of privacy awareness in smartphone ecosystems prevents users from being able to compare apps in terms of privacy and from making informed privacy decisions. In this paper we analysed smartphone users' privacy perceptions and concerns based on a novel privacy enhancing tool called Android Apps Behaviour Analyser (A3). The A3 tool enables user to behaviourally analyse the privacy aspects of their installed apps and notifies about potential privacy invasive activities. To examine the capabilities of A3 we designed a user study. We captured and contrasted privacy concern and perception of 52 participants, before and after using our tool. The results showed that A3 enables users to easily detect their smartphone app's privacy violation activities. Further, we found that there is a significant difference between users' privacy concern and expectation before and after using A3 and the majority of them were surprised to learn how often their installed apps access personal resources. Overall, we observed that the A3 tool was capable to influence the participants' attitude towards protecting their privacy.

Introduction

In the last decade, the privacy of data users/owners has become a growing concern due to the massive increase in personal information utilised in smartphone apps [START_REF] Gilbert | Automating privacy testing of smartphone applications[END_REF], social networks [START_REF] Raad | Privacy in online social networks[END_REF], outsourced search applications [START_REF] Razeghi | Privacy-Preserving outsourced media search using secure sparse ternary codes[END_REF][START_REF] Razeghi | Privacy preserving identification using sparse approximation with ambiguization[END_REF], etc. Smartphone apps are designed with consideration for the demands and constraints of the smartphones and to take advantage of any specialised capabilities that they have. The smartphone apps market is rapidly growing. In 2017, the total number of iOS and Android apps available on their marketplace were 2.2 and 3.5 millions, respectively [START_REF]Number of apps available in leading app stores[END_REF]. Furthermore, the number of mobile app downloads has grown to 197 billion worldwide in 2017, which is almost 50 billion more than 2016 [START_REF]Number of mobile app downloads worldwide in 2016[END_REF]. Such enormous number of apps available and the high number of downloads resulted in increased dependency on apps. In 2017, eMarketer released a study showing the average amount of time people spent using apps is two hours, 25 minutes per day [START_REF]eMarketer unveils new estimates for mobile app usage[END_REF]. The Techcrunch's report showed that on average, smartphone owners used nine apps per day and 30 apps per month. Accordingly, it was argued that smartphone users rely heavily on apps [START_REF]Report: Smartphone owners are using 9 apps per day, 30 per month[END_REF]. For instance, Marketing Land [START_REF]More time on Internet through smartphones than PCs[END_REF] reported that the smartphone users spent 86% of their internet usage time using apps. As a result, the landscape of smartphone use today is very much app-focused. All of these factors make smartphones an attractive target for privacy invasion.

Each app can request a certain number of permissions which allows it to gain access to the device resources such as contacts, location, storage, camera, etc. In older Android versions (prior to version 6.0), users had to grant permissions requested by each app at the install time and they were not able to restrict those permissions later. However, with the release of Android 6.0, the users were given control, and they are able to restrict the requested permissions even at runtime. Although this feature enables users to better preserve their privacy, prior studies have shown that few users are aware of it, hence permissions are often ignored even though they might appear irrelevant to the real functionality of the app [START_REF] Lin | Expectation and purpose: understanding users' mental models of mobile app privacy through crowdsourcing[END_REF]. This is due to the fact that many users do not understand the technical and sometimes ambiguous definitions of permissions [START_REF] Felt | Android permissions: User attention, comprehension, and behavior[END_REF]. Additionally, most of them value the use of the apps more than their personal information, despite the fact that the apps collect large amounts of personal information, for various purposes ranging from functionality to empower their ads mechanisms [START_REF] Felt | I've got 99 problems, but vibration ain't one: A survey of smartphone users' concerns[END_REF][START_REF] Solove | Nothing to Hide: The False Tradeoff between Privacy and Security[END_REF].

The invasive nature of smartphone apps, harvesting personal data has been demonstrated in many studies. The Wall Street Journal reported a study in which 101 popular smartphone apps were examined for personal information gathering activities. Their results showed that more than half of the apps exhibited at least one risky behaviour, such as location tracking, transmission of a smartphone's unique device ID number, or the gathering of other personal information [START_REF]Your apps are watching you[END_REF]. A report by Appthority showed that 95% of the top 200 free apps and 80% of the top paid apps for Apple and Android phones did the same [15]. Chia et al. [START_REF] Chia | Is this app safe?: a large scale study on application permissions and risk signals[END_REF] studied risk signaling concerning the privacy intrusiveness of Android apps in two repositories. Their results showed that the number of dangerous permissions an app requested was positively correlated with its popularity. Therefore, the fact that an app is popular does not imply that it respects users' privacy.

This paper presents the results of interviews and surveys of 52 participants who used our privacy enhancing tool called Android Apps Behaviour Analyser (A3) that is solely designed and implemented for Android devices. In this study, we examine, compare and contrast smartphone users' concern and expectation, by leveraging a user study as a reference point for understanding smartphonespecific concerns and perceptions. This study is aimed to (1) propose a privacy enhancing tool for smartphone users to support them for informed privacy decision-making, (2) test our hypothesis that smartphone users are willing to take action and change their privacy attitude once they realise how their personal resources are treated by their installed apps, and (3) provide data over the understanding of users' privacy concern and expectation in using smartphone apps.

The rest of the paper is organised as follows: Section 2 reviews the existing works in the literature related to the privacy concern and expectation analysis of smartphone users. Section 3 describes the main concepts associated to the Android Apps Behaviour Analyser (A3) as a novel privacy enhancing tool for Android users. Section 4 presents the research steps and design decisions taken in the implemented user study to analyse the impact of A3 on the users' privacy concern and expectation and the obtained results are then presented in Section 5. Finally, we conclude the paper and point the future directions of research in Section 6

Related Work

Kelley et al. [START_REF] Kelley | When are users comfortable sharing locations with advertisers?[END_REF] tried to identify possible causes and incentives for users to willingly share their location with advertisers. The results showed that users were highly concerned about their personal data. Almost 80% (19 out of 24) of the people questioned expressed the highest level of concern towards an unsolicited transfer of personal data gathered about them by a company on a corporate level (e.g. to other companies, institutions, governments, etc.). The authors concluded that the users are least concerned when they share information about being at certain pre-selected locations. The study suggested that this could be attributed, in part to the fact, that users may like being informed regarding certain promotion activities or other similar events related to the places specified (e.g. coupons for favourite restaurants). Differently, Erika et al. [START_REF] Chin | Measuring user confidence in smartphone security and privacy[END_REF] studied overall privacy and security expectations of the users in choosing apps. They first surveyed 60 smartphone users to measure their willingness to perform certain tasks using their smartphones to test the hypothesis that people currently avoid using their phones due to privacy and security concerns. Second, they investigated why and how the users trust a certain app. The results showed that users are more concerned and conservative about privacy on their smartphones than their laptops. The authors also identified the threats which scare smartphone users of using smartphones (e.g. malicious apps, data loss, etc.). Based on these results, they suggested some recommendations to ameliorate privacy and security confidence of users to increase trust in choosing apps. A different user-centric study was published by Felt et al. [START_REF] Felt | I've got 99 problems, but vibration ain't one: a survey of smartphone users' concerns[END_REF]. They presented a risk ranking of sensitive smartphone resources by user concerns. A successive open-end enquiry among a group of 42 participants gathered personal descriptions and ratings of a subset of evaluated risks which disclosed that the lowest-ranked risks are seen as disturbances, the highest-ranked risks however represent serious issues. They found that warnings in Android and iOS do not satisfy users' concerns. They concluded that future permission systems should consider user concerns when deciding which permissions are protected with warnings.

Lin et al. [START_REF] Lin | Expectation and purpose: understanding users' mental models of mobile app privacy through crowdsourcing[END_REF] investigated privacy expectations of smartphone users. The main goal of the authors was to figure out when an app violates users' expectations. Having considering this and by arguing that if a user's mental model aligns with what the app actually does, the authors claimed there would be fewer privacy issues since the user is adequately informed of the actual app's behaviour. This brought them to the point of allowing users to see the most common misexpectations about an app by revising users' mental model. For this reason, they suggested the use of both crowdsourcing users' mental models and profiling mobile apps using log analysis tools. Amini et al. [START_REF] Amini | Analyzing mobile app privacy using computation and crowdsourcing[END_REF] employed crowdsourcing as part of a procedure to analyse mobile apps privacy expectation.

Participants were asked to rate their expectation and comfort feeling according to the access of sensitive information related to the identified tasks. Thus, by considering the context of apps as well as privacy invasive behaviour, an assessment of the desirability of this information leakage can be depicted. Continuing this work, Amini et al. [START_REF] Amini | Mobile application evaluation using automation and crowdsourcing[END_REF] envision the tool AppScanner, consisting of different sub-modules, to be able to evaluate mobile apps privacy on a large scale. Enhancing the work presented before, crowdsourcing still presents a main component for gathering user's expectation related to the privacy behaviour of apps. The analysis of the past research lead to the following research questions: RQ-1: What are people's privacy expectations of mobile apps? RQ-2: Do people have correct mental models of mobile apps resource access behaviour? RQ-3: Are privacy concerns and trust correlated with people's expectations?

In [START_REF] Wijesekera | Android permissions remystified: A field study on contextual integrity[END_REF], the authors studied the compliance of accessing permissions by installed apps with regard to the users' expectation. To this end, they modified the Android OS to log whenever an installed app accessed a permission-protected resource and then gave modified smartphones to 36 participants who used them as their primary phones for one week. Afterwards, they showed various instances over the past week where apps had accessed certain types of data and asked whether those instances were expected, and whether they would have wanted to deny access. The results showed that 80% of the participants would have preferred to prevent at least one permission request, and overall, they stated a desire to block over a third of all requests. This is an important work that revealed the discrepancy between users' expectation and actual app behaviour. One of the most relevant outcomes from their work is identification of the need of transparency with regard to which app accesses which resources and at what frequency. A study from 2017 by Crager et al. [START_REF] Crager | Information leakage through mobile motion sensors: User awareness and concerns[END_REF] considered a different type of threat for users' privacy that comes from smartphones' sensors and other wearables. One specific threat that they presented was from an advertising software developer kit (SDK), that used the smartphone's microphone to listen the near-ultrasonic sounds placed in the TV, radio and Web ads, which could be eventually used to infer the user's preferences. The results showed that users were only aware of the location tracking, and had not been considering the other three, namely Device-Fingerprinting, Keystroke-Monitoring and Acoustic Eavesdropping. As expected, users learning about the threats were immediately concerned about their privacy. The authors concluded that more efforts should be put into educating trivial (not experienced) users about the possible threats, but acknowledged the fact that the users would generally avoid using an app or a device if its security system affects usability.

Having included related work from 2011 to 2017, we conclude that although people are concerned, they are not in fact, fully aware how their data is being treated and how this affects their privacy. The part we shall be more concerned about is that the users, even after being alerted, tend not to change their behaviour (attitude) and instead try to rationalise using privacy-violating apps and willingly ignoring or accepting the possible risks. This behaviour, was coined in the literature as privacy paradox meaning that people's attitude toward privacy does not align with their actual behaviour [START_REF] Brown | Studying the Internet experience[END_REF][START_REF] Norberg | The privacy paradox : Personal information disclosure intentions versus behaviors[END_REF]. This phenomenon is frequently assigned to psychological biases and heuristics that accompanies decision-making process. In the digital context the privacy paradox could be diminished by the reduction of information asymmetry. Currently, the end-users are not provided with a sufficient and understandable information about the data collection processes, unlike the service providers who have all the information about their data collection practice. Due to the lack of information, users are trapped in the bounded rationality, where the rational maximisation of benefits is restricted due to the limits of cognitive abilities [START_REF] Acquisti | The economics of privacy[END_REF].

Unlike the mentioned studies, we aim to increase the smartphone users awareness of privacy. By proposing a transparency tool called Android Apps Behaviour Analyser (A3) we analyse the behaviour of installed apps on the user's smartphone to identify privacy deviated activities. Out tool does not rely on the existing reviewed techniques for log analysis that require modification the OS (or root access). Additionally, we perform a user study to examine the users' privacy concern and expectation after revealing how much and to which level their personal information is accessed with/without their awareness. Hence, our remaining research questions are: RQ-4: Is A3 tool capable of increasing mobile privacy awareness and altering privacy concerns? RQ-5: What are people's reactions for the A3 tool and to the information it provides?

3 Technical Implementation: The A3 Tool This section elaborates on the technical implementation followed in this paper to develop the A3 tool including its respective components. Fig. 1 shows a high level Fig. 1. A high level overview of the A3 tool. architecture of A3. As it can be seen, A3 has several components. In principle, the log reader component is responsible to read device's logs, and accordingly, produce the raw data. These data are then sent to the data mining component which aims to analyse the apps' privacy behaviour. The results obtained from the data mining component are then sent to the user for further evaluation and decision.

Log Reader Component

Throughout the implementation phase, we consistently target three main goals. Firstly, A3 must work without any need for root access to the OS. Secondly, there must not be any modification to the core of the OS. Lastly, it should be capable of being installed on the recent versions of Android. We implemented the log reader based on AppOps which is a privacy manager tool and introduced in Android 4.3. However, Google decided to make it hidden in later versions of Android and it is currently inaccessible, unless the device is rooted [START_REF]Google removes vital privacy feature from Android, claiming its release was accidental[END_REF]. To the best of our knowledge, root access is only necessary to access the AppOps management system, e.g. to tell the system to deny access to one of the operations that is controlled by AppOps. We found that to view the AppOps logs, there is no need to root the device, and they are accessible to any app with debugging privileges [START_REF] Hatamian | Beacon alarming: Informed decision-making supporter and privacy risk analyser in Smartphone applications[END_REF][START_REF] Hatamian | FAIR: Fuzzy alarming index rule for privacy analysis in smartphone apps[END_REF]. Generally, in order to collect the logs, a timer is sent to the PermissionUsageLogger service periodically. When it is received, the logger queries the AppOps service that is already running on the phone for a list of apps that have used any of the operations we are interested in tracking. We then check through that list and for any app that has used an operation more recently than we have checked, we store the time at which that operation was used in our own internal log. These timestamps can then be counted to get a usage count.

Data Mining Component

This component is supposed to behaviourally analyse the installed apps by getting help from the results obtained from the log reader component. This is done according to a rule-based approach which is supposed to increase the functionality and flexibility of our data mining component. Consequently, we have defined a set of privacy deviated behaviour detection rules that are aimed to analyse the privacy behaviour of the users' installed apps. We initially defined a set of sensitive permissions (introduced by Android4 ) and we mainly analyse the accesses to these resources. For example, consider the device's screen is off and it is in the horizontal orientation (and the user does not talk on the phone, meaning that the AUDIO permission is not being used). In such situation, we assume that the user does not use the phone (e.g. the phone lies on the desk) and if one of the sensitive resources is accessed by a given installed app, we record this and report to the user about the detail of the access (date, time and reason together with a short explanation). Therefore, the users can transparently manage their resource accesses (due to space limitations, we refrained from explaining all the defined rules).

Graphical User Interface

The A3 tool informs users of the potential misuses of their personal data. For this reason, we emphasise how the privacy indicators are shown to the user. Therefore, the Graphical User Interface (GUI) plays a crucial role in A3. The GUI offers the following functionality:

App selection In order to follow the principle of data minimisation [START_REF][END_REF], the users are given this option to choose the apps that they are interested to analyse their privacy behaviour, meaning that the users can freely choose which app(s) should be scanned (Fig. 2(a)).

Scan intervals

We have given users the ability to decide about the desired scan intervals, meaning that they can determine the watchdog intervals at which the sensitive resources are scanned for any potential privacy invasive activity (Fig.

2(b)).

Permission restriction As Google has initiated a new permission manager system in Android 6.0 and later versions, we have embedded a direct access to this permission manager system to revoke/grant permissions for any app (Fig. 2(c)).

Behaviour analysis

The users are able to check which personal resources (permissions) have been accessed by their installed apps. They can also observe the time and frequency of accesses. Accordingly, a synopsis of apps and resources accessed including the corresponding timestamps are communicated to the user. This also entailed to translate the technical terms of permissions defined by Android (e.g. PHONE_STATE, COARSE_LOCATION, etc.) to understandable definitions for the ordinary users (Fig. 2(d)).

The Design of the User Study

The user study comprises four main phases, including, recruitment, enter survey, a one week apps' behaviour analysis, and exit survey. In order to link enter and exit surveys, we supplied participants with an anonymous personal code.

We asked participants about their privacy concerns, attitudes and expectations of the personal information that their smartphone would collect and transfer before and after using A3. The results gathered from this user study provide us with a sound foundation to compare the users expectations with actual results obtained from A3. This helps and supports users to judge to which extent their expectations match what the apps are doing in the reality. In the following, each phase is described in detail.

Recruitment

In total, 52 participants were recruited through placing an online recruitment advertisement on social networks (e.g. Facebook) within a three month time period (Nov 2017 to Jan 2018). In order to participate in the user study, the participants were asked to read and sign a consent form in which they stated that they are over 18 years old and they own Android smartphones. To reduce potential biases, we requested for participants without advanced knowledge in computer science and IT related areas.

Enter Survey

In this phase, the participants were given certain questions about their: (1) privacy concern and (2) expectation of the smartphone apps behaviour. We tried to reuse the questions from [START_REF] Lin | Expectation and purpose: understanding users' mental models of mobile app privacy through crowdsourcing[END_REF][START_REF] Chin | Measuring user confidence in smartphone security and privacy[END_REF][START_REF] Rao | Expecting the unexpected: Understanding mismatched privacy expectations online[END_REF] and adapted them to our application domain. The majority of the survey used Likert [START_REF] Likert | A technique for the measurement of attitudes[END_REF] like item scales to measure the privacy concern and expectation of the participants in the area of smartphones. The scores ranged from one extreme attitude (not at all concerned) to another (extremely concerned). In the first set of questions, we collected data on participant demographics, privacy concern and expectation. In the demographics section, we asked participants to provide information on their demographic background, such as their age and gender. We then investigated participants' privacy concern when using a smartphone app in different scenarios such as when the information they shared was considered sensitive in general, or when an app accessed information that did not seem as relevant. Lastly, we collected data on participants' expectation of what information they believed had been accessed by different kinds of apps.

Apps Privacy Behaviour: A One Week Analysis

After the successful completion of the enter survey, the participants gave us the permission to install A3 on their smartphones and they agreed to keep it running for one week. In order to make sure whether this one week time period is representative enough, we purchased ten Android smartphones and we installed the A3 tool on them. We then let A3 to run in the background for two weeks while it was scanning each individual phone (during this period, we never interacted with the devices, ensuring that they have sufficient battery level). We found that after almost one week, it is possible to observe a significant number of permission (resource) accesses by installed apps which would give us an indicator/understanding about the apps' behaviour. That is why we decided to choose the one week time slot. During the one-week interval, participants launched A3 on their smartphones and performed their usual daily activities with their phones while the tool was scanning all the resource accesses by their installed apps. It is worth to mention that we did not collect any personal information and all the scan results remained on the users' phones (the analysis results were not transmitted to external parties, servers, etc.).

Exit Survey

At the end of the week, the participants returned to our lab. They were presented with the results of the analysis of their installed apps' behaviour and completed the exit survey. We asked the participants to go through the results of the scans to see how their personal resources have been treated by their installed apps during the one week period. The questions in the exit survey examined how participants' expectation changed as a result of using A3, e.g. whether they changed their privacy attitude, do they have the intention/willingness to change their behaviour, what do they think about A3, whether its results are informative, annoying, expected, etc. Finally, each participant was compensated by a €15 Amazon voucher.

Results

General Exploration over the Data

Among 52 study participants, the majority (48.1%) were between 25-34 years old. The sample was almost equally distributed among two genders, females (42.3%) and males (57.7%). Most of the respondents held higher education, either bachelor's (57.7%) or master's degree and higher (26.6%). The detailed demographics are presented in Table 1.

Only three (5.7%) participants admitted that they read privacy policy before installing the new smartphone app, while 17 (32.7%) said they never read it, 23 (44.2%) said they read it rarely, and nine (17.3%) sometimes. The majority of respondents expressed their lack of knowledge about privacy in general (N = 31, 59.6%). Most of them were certain (N = 23, 32.7%) or not sure (N = 16, 30.8%) whether they have a basic knowledge about technical terms of privacy and security.

The participants admitted that they prefer social media and convenience to privacy and security. 16 (30.8%) said it is very true and 16 (30.8%) said rather true. Additionally, 33 (63.5%) participants confessed that they actively use social media.

Regardless, most participants stated that they feel motivated, and spend considerable time trying to protect their online privacy (N = 32, 61.5%). 29 (55.8%) respondents did not feel confident that somebody could track or monitor their online activities, and 15 (28.8%) were not sure how they feel about it.

User Expectation

In the enter survey we asked participants about their expectations of apps behaviour (RQ-1). First, we wanted to know how likely they think the app which they did not create an account for, will have access to sensitive information (i.e. location, contacts, etc.). The majority of participants said that it is not likely (N = 22, 42.3%) or only slightly likely (N = 12, 23.1%). The small percentage of respondents thought it is moderately (N = 10, 19.2%), or very and extremely likely (N = 8, 15.3%). Additionally, we asked to what extent the respondents agree with the following statement Smartphone apps are only accessing resources and permissions which are related to their functionality (e.g. navigation apps need to have access to your location etc.). In total 20 participants strongly or somewhat agreed with the statement (38.4%), and 13 (25%) were neutral about it.

We wanted to examine whether participants would like to know more about the data collection and processing of smartphone apps. First, we asked if they would like to know what personal information is accessed by apps installed on their smartphones. The majority of participants strongly agreed (N = 36, 69.2%) or somewhat agreed (N = 10, 19.2%) with such statement. Additionally, we asked whether they would like to know how their personal information is used by apps installed on their phones. Once again, the participants even strongly agreed (N = 39, 75%) or somewhat agreed (N = 9, 17.3%) that they wish to know it.

App Resource Access Behaviour

We were interested to identify whether participants have the correct mental model for the frequency of access to the phone resources of certain app types (RQ-2). Therefore, in the enter survey we asked participants whether they have a social network, messaging and navigation app installed (most common sensible app categories to ordinary users), and if so, how many times such app is accessing their phone's location, storage, contacts, accounts, phone number, audio, calendar, camera and SMS/MMS. To see whether the assumptions were close to reality, in the exit survey we asked respondents to provide the access information from the A3 tool, collected over the week.

In general, respondents underestimated the frequency of resource access by different apps. Among the respondents who had social network app on their phones (N = 34), 48.1% underestimated the location access, 59.6% storage, 30.8% contacts while 38.8% overestimated camera access. Similarly, the owners of messaging apps (N = 46) underestimated the numbers of access to location (N = 20, 30.8%), storage (N = 43, 88.5%), contacts (N = 34, 65.4%), accounts (N = 33, 63.5%), audio (N = 28, 53.8%), camera (N = 21, 40.4%). Lastly, the respondents highly underestimated the navigation apps resource access, such as location (N = 41, 78.7%) and storage (N = 44, 84.6%). We found that the real frequencies of apps accessing various resources vary, and where really high, some of them reaching over 40000 times per day.

Privacy Concern Aspects in Smartphone Apps

General Privacy Concerns and Trust We developed a Likert scale [START_REF] Likert | A technique for the measurement of attitudes[END_REF] to investigate privacy concerns and online trust. We checked the reliability, and Cronbach α was .848 for the five trust items, and .754 for the five privacy concerns items. The Cronbach alpha is a reliability test that should be applied to check whether the scale is consistent, and whether it measures the desired attitude. It is based on the calculation of the average value of the reliability coefficients of all available items when divided into two half-tests [START_REF] Gliem | Calculating, interpreting, and reporting Cronbach's alpha reliability coefficient for likert-type scales[END_REF].

We applied Spearman test for correlations to investigate whether there are relationships between privacy concerns, trust and expectations (RQ-3). The Spearman correlation was used because the data did not meet the assumptions of parametric tests. Spearman correlation is used on the ranked data, and it measures the strength of the relationship between two variables [START_REF] Field | Discovering statistics using SPSS[END_REF]. We found significant correlations between trust and the role of an app reputation when deciding upon personal information disclosure (r s = .35, p < .05). There was a positive correlation between trust and a belief that an app accesses only resources related to its functionality (r s = .49, p < .001). Additionally, we found a negative correlation between trust and refusal of providing personal data to smartphone apps (r s = -.41, p < .05), apps' access to sensitive information (r s = -.30, p < .05) and the restrictions of applications' permissions (r s = -.40, p < .05).

Further, we found a significant correlation between privacy concerns and willingness to uninstall the app, if it violates users' privacy (r s = .38, p < .05). Lastly, there was a correlation between concerns and fear about the safety of information (r s = .30, p < .05).

We used Spearman test for correlations to examine whether people with higher levels of privacy concerns rank higher the importance of clear information about app's access to different types of personal information (when deciding on app's download or usage). We identified positive correlations between privacy concerns and importance of information about access to the phone's location, storage, contacts, accounts, audio, and camera (Table 2).

Privacy Issues in Smartphone Apps One of the research goals was to investigate whether the A3 tool is capable of increasing smartphone users' privacy awareness (RQ-4). To examine this we used repetitive measures, pre-and post questionnaires asking participants about their privacy concerns in the context of smart-phone apps. We applied Wilcoxon test to measure whether the participants' level of privacy concern changed after using A3. We used Wilcoxon test because we it is suitable for ordinal, ranked data. This test enables a direct comparison in related design studies, between participant's scores in two conditions [START_REF] Greene | Learning to use statistical tests in psychology[END_REF].

The test indicated that in the exit survey, participants scored significantly higher on concerns about personal data being leaked or transferred to third parties (Z = -5.106, p < .001). Similarly their concerns were significantly higher about data falsification (Z = -4.088, p < .001), online bullying and flaming (Z = -3.7006, p < .001), receiving spam emails (Z = -5.056, p < .001), and receiving behavioural adds (Z = -4.080, p < .001). Further, after a week of using A3 participants were more worried about government surveillance (Z = -4.375, p < .001) and about apps accessing irrelevant information (Z = 5.442, p < .001). However, there was no significant difference in before and after scores regarding the level of concern about their credit card being used by others.

Reaction to the Transparency Tool

Overall, we were interested in how the participants react to the A3 tool, and to the information it has provided (RQ-5). After using the A3 tool for a week, the majority of respondents were surprised to learn how often apps access their personal resources (N = 46, 88.5%). The respondents found information provided by A3 shocking (N = 40, 76.9%) but informative (N = 36, 69.3%). The participants realised that some apps access permissions that are not related to their functionality (N = 49, 94.3%), and they were shocked about it (N = 46, 88.4%). In regards of privacy intentions and concerns, participants expressed the willingness to restrict apps permissions in the future (N = 46, 88.5%), as well as uninstalling some of the apps that they find privacy invasive (N = 40, 86.9%). The majority (N = 46, 88.5%) found themselves more worried about privacy than before using A3, and they intend to report privacy invasive behaviours (N = 32, 61.6%), e.g. in the form of user comment on the Google Play Store to increase the privacy awareness of other users. Similarly, they expressed a willingness to read privacy policies before installing the app (N = 36, 69.3%). Lastly, the respondents admitted they would like to have tool like A3 earlier (N = 47, 90.4%) and if possible wish to use it to monitor their smartphone apps behaviour (N = 43, 82.7%). The Spearman correlation tests identified significant positive correlations between the information sensitivity and privacy concerns. There was a weak correlation between concerns and sensitivity of location and accounts. Additionally, sensitive information about the storage, audio and calendar was correlated with concerns. Further, we found that there is a significant negative correlation between trust and sensitivity level of contacts, calendar and SMS/MMS information. The results of correlation analysis are presented in Table 3.

Discussion

Our findings confirm that A3 is able to affect the way by which people are concerned about their privacy. Although the majority of the participants (65.4%) said it is not likely or slightly likely that an app which they did not create an account for, will have an access to sensitive resources, the participants realised it is incorrect. They reported a higher number of apps that were not being used by them during the one week analysis, but still they were accessing users' personal resources in a very aggressive manner (without any user interaction, e.g. account creation, etc.). Further, 38.4% of the participants believed that smartphone apps only access resources relevant to their functionality (e.g. a weather forecasting app requires access to location). However, we discovered that some apps (e.g. health & fitness, navigation, etc.) that do not need to excessively request or access privacy sensitive information, are doing so without users' knowledge.

Overall, the information provided by A3 raised the participants' privacy awareness after a trial period. This indicates that the reduction of information asymmetry by providing users with information about the apps resource access, may help to overcome or at least reduce the privacy paradox. However, this requires further investigation in different experimental settings enabling examination of causal relationship between the attitude and behaviour prior and after using the A3 tool. Additionally, our results demonstrated that users have an inaccurate mental model of apps' resource access behaviour, and they mostly underestimated the frequency of permission accesses by their installed apps. However, the participants expressed willingness to change their attitude and behavior after using the tool. This willingness to change suggests that the tool such as A3 could adjust users mental models, raising privacy awareness and enabling informed privacy decision-making.

Limitations

The scope of this paper comprises Android OS. Regardless of the choice of the research area, currently the A3 tool cannot be applied to other smartphone platforms (e.g. iOS). Another limitation is the low number of participants (52 people) due to the complexity of the study. This happened due to several reasons. Firstly, A3 is solely executable on Android devices, correspondingly, we missed lots of participants who showed interest but they were not technically qualified to participate in the study (e.g. iOS users). Secondly, since A3 is not publicly available on the Google Play Store, several interested people expressed that they do not feel comfortable to install an app from unknown sources on their phones. Further, we tried our best to keep the study safe from any biases (e.g. to not focus on privacy experts). Unfortunately, in such studies, it is challenging to have a diverse type of participants which would further enhance the validity of our analysis.

Conclusion

In this paper, we studied the smartphone users' privacy awareness by conducting a user study based on an implemented privacy enhancing tool (A3 ). We examined the applicability of such tool with the real users and investigated the users' reaction to A3. Thus, we performed a user study comprising of 52 participants and we analysed their privacy concern and expectation before and after using the A3 tool. The results clearly showed that users' privacy concern and expectation changed after using A3. We identified that users' privacy awareness increased due to the implication of A3. Moreover, we observed that users mostly have poor knowledge of how their installed apps treat their personal sensitive resources. Additionally, we found that there is a gap between what smartphone users perceive about privacy and what is happening in the reality by their installed apps. Study participants were shocked once they understood how their apps are accessing their resources without their knowledge, especially when accessing resources that are not necessary for the appropriate functionality of an app. As a result, we believe that the smartphone users need such privacy enhancing tool to better protect their privacy and to make informed privacy decisions. Although the results showed the changed perceptions of privacy issues that might be due to the use of A3, for the future work we plan to implement an explanatory study investigating the role of A3 tool in the causal relationship of privacy attitude-behaviour change. This will enable us to contrast the control group with the experimental group for a more confident comparative analysis.

Fig. 2 .

 2 Fig. 2. A3 user interface (a) app selection (b) scan intervals (c) permission restriction, and (d) behaviour analysis.

Table 1 :

 1 Participants demographics.

	Demographic Group	N %
	Age	18-24	16 30.8
		25-34	25 48.1
		35-44	7 13.5
		45 or older	4 7.7
	Gender	Female	22 42.3
		Male	30 57.7
	Education	High school	4 7.7
		Some college	4 7.7
		Bachelors degree	30 57.7
		Masters degree or higher 14 26.9
	IT experience Not at all	21 40.4
		Trivial	20 38.5
		Moderate	9 17.3
		A lot	2 3.8

Table 2 :

 2 Spearman correlations: privacy concerns and importance of clear information about the apps access to different types of personal information.

	Information type Correlation Sig. (2-tailed)
	Location	.494	.000
	Storage	.335	.015
	Contacts	.362	.008
	Accounts	.522	.000
	Audio	.386	.005
	Camera	.508	.000

Table 3 :

 3 Spearman correlations: privacy concerns and trust with information sensitivity.

		Sensitive information Correlation Sig.(2-tailed)
	Privacy Concerns Location	.286	.040
		Storage	.417	.002
		Accounts	.277	.047
		Audio	.326	.018
		Calendar	.327	.018
	Trust	Contacts	-.277	.047
		Calendar	-.346	.012
		SMS/MMS	-.276	.047
	5.6 Additional Findings
	Privacy Sensitivity Degree of Different Smartphone Resources We
	asked respondents about the sensitivity of different types of information, on a
	scale from Not at all sensitive to Extremely sensitive. The participants perceived
	as extremely sensitive storage information (photos & videos)(N = 20, 38.5%),
	audio (N = 15, 28.5%), camera (N = 17, 32.7%). They perceived as a not at
	all sensitive calendar information (N = 16, 30.8%) and SMS/MMS (N = 13,

25%). The other information types were scored as moderately (accounts on your phone, phone number) or slightly (location, contacts) sensitive.

https://developer.android.com/guide/topics/permissions/requesting.html

and Y. Obreshkov that partially contributed in the data collection task. This research work has received funding from the H2020 Marie Sk lodowska-Curie EU project "Pri-vacy&Us" under the grant agreement No 675730.


Gunjan Batra
email: gunjan.batra@rutgers.edu

Vijayalakshmi Atluri
email: atluri@rutgers.edu

Jaideep Vaidya
email: jsvaidya@rutgers.edu

Shamik Sural
email: shamik@cse.iitkgp.ernet.in

Enabling the Deployment of ABAC Policies in RBAC Systems

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Role-Based Access Control (RBAC) has been a well accepted standard for access control for more than three decades. Most businesses today use RBAC to assign access to the network and systems based on job title or defined role. However, a primary limitation of RBAC is its significant dependence on user identity for mapping it to a set of roles. As an alternative, the Attribute Based Access Control (ABAC) model has been developed. In ABAC, subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions [START_REF] Fisher | Weeks Attribute Based Access Control In NIST SPECIAL[END_REF]. As such, ABAC can comprehensively handle various factors affecting access control decisions like location, time, server load, etc., and also facilitates inter-domain accesses. Furthermore, use of user and object attributes for defining access control makes ABAC more portable across organizational domains. Indeed the flexibility, portability and identity-less access control features make ABAC very attractive to be employed in many application domains, including cloud computing, web services, collaborative and coalition based systems, as it is feasible to make access control decisions without any prior knowledge of the subject. As a result, many organizations are now moving to ABAC, which is a non-identity based model and is highly dynamic and flexible. Indeed, Gartner predicts that by 2020, 70% of enterprises would use ABAC as the dominant mechanism to protect critical assets, up from less than 5% today [START_REF] Fisher | Weeks Attribute Based Access Control In NIST SPECIAL[END_REF].

ABAC is also advantageous from a security management perspective. Since ABAC allows for the creation of access policies based on the existing attributes of the users and objects, rather than the manual assignment of roles, ownership or security labels, it minimizes the need for manual intervention in configuring and deploying access control. More specifically, if an employee changes roles or leaves the company, an administrator must manually change access rights accordingly perhaps within several systems. As organizations expand and contract, partner with external entities, and modernize systems, this method of managing user access becomes increasingly difficult and inefficient [START_REF] Fisher | Weeks Attribute Based Access Control In NIST SPECIAL[END_REF]. On the other hand, such organizational changes effectively do not incur any manual cost under an ABAC system as no changes need to be made to the access control configuration. As such, the administrative cost of ABAC is significantly lower as compared to that of RBAC (or even that of discretionary access control (DAC)).

Despite many organizations wanting to adopt ABAC as their method of access control, there do not yet exist many commercial ABAC implementations. Some vendors such as Axiomatics, do offer ABAC implementations as dynamic authorization solutions, however, ABAC implementations have not yet been incorporated into any of the popular operating systems, or applications such as DBMS, etc. As such, organizations wanting to adopt ABAC, need to implement it on their own, which can often be error-prone and unreliable. Since RBAC is widely deployed in almost all commercially available OS and application systems, our basic idea in this paper is to propose an approach that can help realize an ABAC policy using a RBAC system. Essentially, we translate the ABAC policies into an equivalent RBAC configuration so that a user gains access to a resource in RBAC if and only if that user has the specified access under ABAC.

There are a number of benefits for taking this path to enforcing access control. First, our approach is an alternative where ABAC can simply be realized with a readily available RBAC implementation. Second, it is well known that when an access request is submitted by a user, the enforcement in ABAC is much more expensive in terms of time and processing power than that in RBAC. We experimentally show that this is indeed true. As a result, with our approach, one can enjoy the benefits of ABAC (such as flexibility, etc.) as well as the benefits of RBAC (efficient authorization enforcement). Due to this, one may still want to go on our proposed path, even if an ABAC implementation were to be available in future. Third, as ABAC paradigm is more suited for cloud environments due to its fine-grained property. Therefore, our proposed approach is a solution for the organizations that have an RBAC system in place and would like to be a part of cloud or another data sharing environment.

However, while RBAC administration and maintenance are considered less costly when compared to DAC, as mentioned earlier, it is more expensive when compared to ABAC. Recognizing this fact that the maintenance cost in RBAC is significantly higher than that of ABAC, we propose methods to handle such changes effectively by considering the different change scenarios such as addition/deletion of users and objects, changes to ABAC policies including addition/deletion of subject/object attributes, addition/deletion of ABAC rules.

The rest of this paper is organized as follows. In Section 2, we provide a brief overview of ABAC and RBAC. In Section 3, we discuss the problem of converting an ABAC policy to RBAC. The idea is to cover all the authorizations of ABAC model and build an equivalent RBAC model. We also examine how the number of policy rules in ABAC relates to the number of roles in RBAC. In Section 4 we experimentally compare the cost of enforcement in an ABAC system to the cost of enforcement in RBAC once the ABAC policies are implemented in the RBAC system. In Section 5, we discuss the management cost by considering the administrative operations in this system and ways to make it more efficient. In Section 6, we discuss related work. Finally, in Section 7, we conclude the paper and discuss future research directions.

Preliminaries

In this section, we briefly present the attribute based access control (ABAC) model [START_REF] Hu | Guide to Attribute Based Access Control (ABAC) Definition and Considerations[END_REF][START_REF] Talukdar | Sural Efficient Bottom-Up Mining of Attribute Based Access Control Policies[END_REF] and the Role Based Access Control model [START_REF] Sandhu | Youman Role-Based Access Control Models[END_REF], upon which all of the following work is based. In ABAC, the authorization to perform an operation (e.g.,read/write/modify) is granted based on the attributes of the requesting user, requested object, and the environment in which a request is made. In RBAC, the authorization to perform an operation is based on role of a user requesting permission to access and object.

RBAC

The basic components of RBAC are as follows: Users (U): Represents a set of authorized users/subjects. Each member of this set is denoted as u i , for 1 ≤ i ≤ |U |. Objects (O): Represents a set of resources to be protected. Each member of this set is denoted as o i , for 1 ≤ i ≤ |O|. ROLES (R): Represents a set of roles. Each member of this set is denoted as r i , for 1 ≤ i ≤ |R|. OPS: Represents a set of operations. Each member of this set is denoted as op i , for 1 ≤ i ≤ |OPS|. PRMS: Represents the set of Permissions PRMS ⊆ {(o-op) | o ∈ O ∧ op ∈ OPS}. UA: User Role assignment relation, UA ⊆ U × R is a many-to-many mapping of user to role assignments. We use a m × n binary matrix to represent UA. PA: Permission Role assignment relation, PA ⊆ PRMS × R is a many-to-many mapping of permission to role assignments.

ABAC

The basic components of ABAC are as follows: Users (U): Represents a set of authorized users/subjects. Each member of this set is denoted as u i , for 1 ≤ i ≤ |U |. Objects (O): Represents a set of resources to be protected. Each member of this set is denoted as o i , for 1 ≤ i ≤ |O|. Environment (E): Represents a set of environment conditions, independent of users and objects. Each member of this set is denoted as e i , for 1 ≤ i ≤ |E|. U A : Represents a set of user attribute names. Members of these sets are represented as ua i , for 1 For the sake of simplicity, in this paper, we ignore environmental attributes. U C : Represents a set of all possible user attribute conditions denoted as uc j , for 1 ≤ j ≤ |U C |. Members of this set are represented as equalities of the form n = c, where n is a user attribute name and c is either a constant or any. For instance if user attribute Position has possible values {Manager, Associate, Customer } and user attribute Region has possible values as {EastCoast, WestCoast}, then U C will be a set comprising of {Position=Manager, Position=Associate, Po-sition=Customer, Position=any, Region=EastCoast, Region=WestCoast, Spe-cialty=any}. Note here, that the condition n = any does not have to be explicitly chosen. It is set only if at least one other condition for n is present. We use the notation U C .u i to express the user attribute condition set of a user u i . O C : Represents a set of all possible object attribute conditions denoted as oc k , for 1 ≤ k ≤ |O C |. Members of this set are represented as equalities of the form n = c, where n is an object attribute name and c is either a constant or any. For instance if object attribute Region has possible values {EastCoast, WestCoast} and object attribute RecordOf has possible values {Manager, Associate, Customer, Staff }, then O C will be a set comprising of {Region=EastCoast, Region=WestCoast, Region=any, RecordOf=Manager, RecordOf=Customer, RecordOf = Associate, RecordOf = Staff, RecordOf=any}. For an attribute name n, if the value of c is any, then the attribute n is not relevant for making the corresponding access decision. Therefore, as above, the condition n = any does not have to be explicitly chosen. It is set only if at least one other condition for n is present. We use the notation O C .o i to express the object attribute condition set of an object o i . ABAC Policy base Π A : This represents a set of access rules in the ABAC system. Each member of this set is denoted as π i , for 1 ≤ i ≤ |Π|, where π is a quadruple of the form uc, oc, ec, op . If a user makes a request to access an object, the policy base is searched for any rule through which the user can gain access. If such a rule exists, then access is granted, otherwise it is denied.

≤ i ≤ |U A |,
In U C and O C we have represented the attribute conditions as equalities, however, our approach is flexible to include the complex attribute condition Table 1: UAR

User (u) Region =EastCoast (uc1) Position= Manager (uc2) Region= WestCoast (uc3) Position= Associate (uc4) u1 0 1 1 0 u2 0 0 1 1 u3 1 1 0 0 u4 1 0 0 1 Table 2: OAR Object (o) Region =WestCoast (oc1) Region =EastCoast (oc2) Recordof =Customer (oc3) o1 1 0 1 o2 0 1 1 Table 3: Policy (Π A ) Attributes P ermission uc3, uc4, oc1, oc3 op1 uc2, uc3, oc1, oc3 op1 uc1, uc2, oc2, oc3 op1 uc1, uc4, oc2, oc3 op1 uc2, uc3, oc1, oc3 op2 uc1, uc2, oc2, oc3 op2
constructs (inequalities, negation, subset, etc.) by converting them to their corresponding list of attributes conditions. In the following, we define the mapping between users and user attribute conditions as well as objects and object attribute conditions. UAR: User attribute relation UAR ⊆ U × U C is a many-to-many mapping of users and user attribute conditions. We use a m × n binary matrix to represent UAR, where UAR[i,j ]=1, if user u i satisfies an attribute condition uc j . As shown in the example in table 1, user u 1 is an Manager whose region is WestCoast. OAR: Object attribute relation, OAR ⊆ O × O C is a many-to-many mapping of objects and the set of all attributes conditions, where we again use a m × n binary matrix to represent OAR. OAR[i,j ]=1 if an object o i satisfies an object attribute condition oc j . Table 2 shows an example where object o 1 is the recordof Customer in WestCoast region.

ABAC to RBAC Translation

This section presents our methodology to translate the ABAC policy configuration to an equivalent one in RBAC. Towards this end, we first formally define the optimal ABAC to RBAC translation problem and then present our approach.

Problem Formulation

Intuitively, our goal is to discover RBAC roles from ABAC policy base in such a way that the set of RBAC roles is minimum and at the same time the authorizations are the same as those under ABAC. In the following, we formalize the definition of the ABAC to RBAC translation problem.

A: An authorization a having the form of u, o, op denotes that the user u is allowed to perform an operation op on the object o, where u ∈ U, o ∈ O, and op ∈ OPS. We use u.a, o.a and op.a to denote the user, object and operation associated with a. We denote the set of all authorizations as A. For each operation op i ∈ OPS, we define A opi ⊆ A such that for every a ∈ A opi , op.a = op i . For example, if OPS = {read,write}, we have A read and A write such that A read ∪ A write = A.

Given an ABAC policy base Π A , we say A covers π if for every user u and object o combination where u is allowed to perform operation op on o, there exists an authorization a = u, o, op ∈ A. (In the following subsection, we provide an algorithm on how to derive such A from Π.) Similarly, given an RBAC policy Π R , we say A covers Π R if for every user u and object o combination where u is allowed to perform operation op on o in Π R , there exists an authorization a = u, o, op ∈ A. Now we are ready to formally define the optimal ABAC to RBAC translation problem. Problem Statement. Given an ABAC policy Π A , Users U, Objects O, User Attribute relation (UAR), and Object Attribute relation (OAR), the ABAC to RBAC translation problem is to identify a RBAC policy Π R that includes a set of Roles R, PA and UA such that the set of authorizations A derived from Π A and Π R are equal and the number of roles |R| is minimum.

Approach

In this section, we discuss how we develop a system that will translate ABAC policies in a manner that they can be implemented by an RBAC. The UAR, OAR and ABAC policy base Π A is fed to an ABAC-RBAC Translator which generates Π R , which includes R and the corresponding UA and PA that form the RBAC policy. The detailed process for translation is described below and has been shown in Figure 1. Table 5:

UPA o1-op1 o1-op2 o2-op1 o2-op2 u1 1 1 0 0 u2 1 0 0 0 u3 0 0 1 1 u4 0 0 1 0 in table 4.
Step 2. Derive User Permission Assignment (UPA) from A: The UPA is defined as an M × N matrix, where M = |U| comprising of a row for each user, and N = |O-op| , comprising of a column for each object and operation combination in A. Using (A), we derive (UPA) as follows: We consider all the Users in (A) and associate the objects with permissions to form PRMS(o-op) in RBAC.

There is a row in UPA for each user and a column for each PRMS(o-op). For each row, if the (o-op) is true for that user, the corresponding cell is filled with 1, otherwise with 0. The procedure is automated in the second part of algorithm 1. Given A in table 4, the derived UPA is shown in table 5.

Step 3. Derive User Assignment Relation (UA) and Permission Assignment Relation (PA) by performing Role Mining: For the automation of this step, we have used DEMiner algorithm proposed by Uzun et al. [START_REF] Uzun | Migrating from DAC to RBAC[END_REF]. The primary reason to choose this is because it generates a compact set of roles which are disjoint in their permissions. As a result, it makes administration of access requests much easier, which is in sync with the idea of this work. When a user requests for a specific permission, there will be a single role with that specific permission, thus making the access control decision faster and efficient. This is the reason why we choose this algorithm as the benchmark. It reduces the administrative cost, as the roles generated are non overlapping and the access request decision is evaluated faster than any other role mining algorithm that produces overlapping roles.

Table 6: UA

r1 r2 r3 r4 u1 1 1 0 0 u2 1 0 0 0 u3 0 0 1 1 u4 0 0 1 0 Table 7: PA o1-op1 o1-op2 o2-op1 o2-op2 r1 1 0 0 0 r2 0 1 0 0 r3 0 0 1 0 r4 0 0 0 1
We performed slight modification to the DeMiner algorithm by sorting the users in the UPA in decreasing order of the number of PRMS before applying the algorithm on our dataset. This helped improve the efficiency and effectiveness of the algorithm in terms of time and the number of roles created. Because 'k ' is the minimum number of rules, each rule covers atleast one unique authorization. So, if we map each of the policy rules π i in ABAC to a role r j in RBAC (where both π i and r j cover same set of authorizations in A), we will get exactly 'k ' roles. We have shown the same in Example 1 described below. Therefore, for every rule we can create one corresponding role which will cover same set of authorizations. So, we can infer that in all possible cases, the count of roles to express a set of authorizations A will never be more than the count of rules. In the worst case, |Π A | and |R| will be equal.

So far, we know that, for 'n' to be the minimum roles required to express A, 'k ' has to be equal to 'n' or greater than 'n'. Else we cannot say that 'n' is the minimum number of roles (i.e. k ≥ n). To check if 'k ' could be less than or equal to 'n', we conjecture that, we can map the authorizations expressed by a single role in RBAC to a single rule in ABAC. We use a simple counter example to disprove the above conjecture. We can see in Example 2 below, that for 2 RBAC roles, we need atleast 6 ABAC rules to express the same authorizations. We need 5 ABAC rules : π 1 , π 2 , π 3 , π 4 and π 5 to describe authorizations of r 1 and one ABAC rule π 6 to describe authorizations of r 2 . Note that it is impossible to describe role r 1 by a single ABAC rule as r 1 covers the set users which satisfy no common attribute condition(s).

In case we have common attributes between users or objects in the role, for example in role r 2 , user u 1 and u 4 have a common attribute uc 4 , then one ABAC rule could cover the same authorizations of r 2 , i.e. π 6 (this will give access to both u 1 and u 4 to o 3 to perform op 1 as both u 1 and u 4 satisfy user attribute condition uc 4 ). Hence, we need at least 6 ABAC Rules to express the authorizations covered by 2 roles. Thus, Example 2 is a testimony to that fact that it is possible to have an RBAC role where no single ABAC rule can express the authorizations of that particular single role.

To conclude, the number of Policy Rules in ABAC is always greater than or equal to the number of Roles in RBAC, i.e., |Π A | ≥ |R|.

Example 1 : An ABAC rule π 1 : uc 1 ,oc 1 ,read gives users u 1 and u 2 (both having attribute uc 1 ), read access on object o 1 (having attribute oc 1 ); i.e. two authorizations A 1 and A 2 , where A 1 = u 1 , o 1 , read and A 2 = u 2 , o 1 , read . The corresponding role r 1 will be assigned to users(u 1 ,u 2 ) and will be granted permission (o 1 ,read ). Example 2 : An RBAC system which has two roles r 1 and r 2 giving authorizations A (Table 8) to four users(u 1 , u 2 , u 3 , u 4 ). The UA relation is given in Table 9 and PA relation is in Table 10. The users and objects satisfy the attribute conditions as shown in the User Attribute Relation UAR (Table 11) and Object Attribute Relation OAR (Table 12). In total, atleast 6 ABAC policy rules are required to cover the authorizations of both the roles. They are as follows: Table 9: Since we are interested in seeing how the access request evaluation cost changes with respect to different parameters, we run fours sets of experiments where one parameter is varied while keeping the rest constant. Specifically, we examine the following four different scenarios: 1) increasing the rule size, 2) increasing the number of attributes in ABAC rules, 3) increasing the number of users and objects, and 4) increasing the count of positive authorizations. Here positive authorizations imply access requests that should be granted, while negative authorizations imply access requests that should be rejected. To compare the efficiency of ABAC and RBAC, we have evaluated the time taken to evaluate access requests for 100 user-object pairs. For the first three cases, we take 50 random positive authorizations and 50 random negative authorizations. For the last case, we have increased the count of positive authorizations and reduced the count of negative authorizations by keeping total access requests at 100. Further these access request evaluations were run three times and the time was averaged over all of these runs.

π 1 : uc 1 , Any π 4 : uc 3 , oc 1 π 2 : uc 2 , oc 1 π 5 : uc 3 , oc 2 π 3 : uc 2 , oc 2 π 6 : uc 4 , oc 3
UA r1 r2 u1 1 1 u2 1 0 u3 1 0 u4 0 1 Table 10: PA o1-op1 o2-op1 o3-op1 r1 1 1 0 r2 0 0 1 Table 11: UAR U ser uc1 uc2 uc3 uc4 u1 1 0 0 1 u2 0 1 0 0 u3 0 0 1 0 u4 0 0 0 1
The key parameters are the number of users (U), objects (O), user attributes (U C ), object attributes (O C ), number of rules given (Π A ) to the ABAC system. In Tables 13, 14 and 15, the first column |U| is count of users, the second column |O| is count of objects, third column |U C | is count of user attribute conditions, fourth column |O C | is count of object attribute conditions, fifth column |Π A | is count of ABAC policy rules, |R| is the number of RBAC roles discovered after role mining, AvgRT ABAC is the average run time for ABAC and AvgRT RBAC is the average run time for RBAC. In Table 16, there are two additional columns for count of Positive Authorizations and Negative Authorizations.

For all the experiments, we observe that the count of roles |R| discovered after role mining is much less than the count of ABAC policy rules |Π A | for the same set of authorizations. We can also observe that the run time for access request evaluation for ABAC is significantly greater than the run time for access request evaluation for RBAC. Next we see the individual effects of varying the parameters while keeping all others constant. Varying number of ABAC rules: Table 13 and Figure 2 show the results obtained for access request evaluation time of ABAC and RBAC, while increasing the count of ABAC Rules, but keeping all other parameters constant. We have varied the ABAC rule count between 500, 1000, and 2000. We observe that the Fig. 2: Increasing Rule Size Fig. 3: Increasing Attribute Size count of RBAC roles discovered was 200 in all the three cases. The average access request evaluation time for RBAC remains roughly the same, whereas the access request evaluation time for ABAC increses linearly. This is due to the fact that the size of UA and PA remain the same for the three cases, whereas the count of ABAC rules to be checked for granted access doubles each time.

Varying number of User and Object Attributes: Table 14 and Figure 3 show the results obtained for access request evaluation time of ABAC and RBAC, while increasing the count of Users and Objects Attributes for ABAC policy rules, while keeping all other parameters constant. We have increased both user and object attribute counts for ABAC rules using values 500, 1000 and 2000 for both. We observe that the count of RBAC roles discovered was 200 in all three cases. The average access request evaluation time for RBAC remains roughly the same, whereas the access request evaluation time for ABAC increases linearly. This is because of the fact that the size of UA and PA relation remains the same for the three cases, whereas the count of attributes to be checked for granting access in each rule increases.

Varying number of Users and Objects: Table 15 and Figure 4 show the results obtained for access request evaluation time of ABAC and RBAC, while increasing the count of Users and Objects, but keeping all other parameters constant. Again, we observe that the average access request evaluation time in ABAC is almost 75 times that of RBAC. Varying number of Positive Authorizations: Table 16 and Figure 5 show the results obtained for access request evaluation time of ABAC and RBAC, while varying the count of positive authorizations, but keeping all other parameters constant. Out of the 100 random user-object access requests we predetermine the number of accesses that would evaluate to be positive (granted). These positive access requests were varied betwen the values 0, 20, 40, 60, 80, and 100, with the remaining requests used being negative requests. We observe that the average access request evaluation time in RBAC is roughly the same as earlier, however the average access request evaluation time in ABAC has reduced linearly. An ABAC system checks each policy rule, one by one, to see if it can grant the access. When an access request is granted, no further policy rules need to be checked; whereas, when an access request is denied the ABAC system keeps on checking all the policy rules it has.

The overall results indicate the fact that evaluation of access requests in RBAC is significantly faster across the board in all cases than those of ABAC. In this section, we discuss the configuration and the maintenance cost while dealing with various changes to the ABAC policy and the cost of translating them into an equivalent RBAC policy. The list of operations that can be performed on the original ABAC policy system is as follows: We know that in ABAC, the initial configuration cost is the sum of number of attributes of users, objects and the policy rules, i.e.,

|U C | + |O C | + |Π A |.
Whereas, when we implement ABAC in an RBAC system, the initial configuration cost will be the sum of the number of user role assignments and role permission assignments, i.e., |UA| + |PA|. The maintenance cost of the above mentioned operations will be negligible in case of an ABAC system as every access request is evaluated at the time of enforcement. However, if we wish to deploy the ABAC policies using an RBAC system with our approach, the maintenance cost for some operations vary from making changes to the RBAC system directly to performing the entire ABAC-RBAC translation again. In the following, we have identified the maintenance cost associated with each change operation. While figure 6 provides the overview of how these changes are handled, the exact approach for each change is discussed in detail. To discuss the way these change operations are handled, we have divided them into two types based on the type of effort required. Specifically, some changes require the ABAC-RBAC translation to be done all over. On the other hand, due to the additional information that we maintain, they do not require such translation to be done again, but lend itself to make the relevant changes to the RBAC policy directly. In the following subsections, we elaborate on these cases, and discuss what additional information need to maintained. It turns out that, very few cases require performing the ABAC-RBAC translation all over again. Fig. 6: Management of Administrative Operations on the system 5.1 Changes requiring direct modification to the RBAC policy Addition of Users: When a new user is added to the system, the UPA changes which would require performing role mining all over again. However, if we keep the user attributes required for that role, we can avoid this expensive step, as we can simply derive which role to assign to the user. Therefore, we create a Role User Attribute Assignment Relation RUA, which is a many-to-many mapping of roles to user attribute conditions, i.e., RUA ⊆ R × U C . We use a m × n binary matrix to represent RUA, where RUA[i,j ]=1, if user attribute condition uc j is present in all the users assigned to a role r j .

For example, we created a RUA in Table 17 using Tables 1 and6. Notice that role r 1 in RUA, has uc 3 = 1 as uc 3 is present in both the users assigned to r 1 (u 1 and u 2 ). Basically, attribute conditions assigned to a role are the set of maximum possible common attribute conditions of users in a given role. When a new user is added we can now simply select the roles to be assigned to this user by checking if user has the user attributes necessary for the role. A new row will be added to UA to reflect this.

Role uc1 uc2 uc3 uc4 r1 0 0 1 0 r2 0 1 1 0 r3 1 0 0 0 r4 1 0 0 1 Table 18: ROA Role oc1 oc2 oc3 op1 op2 r1 1 0 1 1 0 r2 1 0 1 0 1 r3 0 1 1 1 0 r4 0 1 1 0 1
Addition of Objects: Similar to the case of adding a new user, in this case we maintain a Role Object Attribute Assignment Relation ROA which is a manyto-many mapping of roles to object attribute conditions (O c ) and operations (OPS), i.e., ROA ⊆ R × (O C OPS). We again use a m × n binary matrix to represent ROA, where ROA[i,j ]=1, if object attribute condition oc j (or op) is present in all the objects (or operations) assigned to a role r j . Table 18 shows ROA created using Tables 2 and7. The attribute conditions assigned to a role are the set of maximum possible common set of object attribute conditions and permissions in a given role. When a new object is added, we select the roles that contain the permissions to perform an operation on the object by checking if the object has the object attributes necessary for the role. PA relation will be updated with this PRMS(o-op) by adding a corresponding column to it. Deletion of Users/Objects: When a user is removed, the row corresponding to that user is deleted from UA. Similarly, on deletion of an object, all the permissions associated with the object will be deleted from PA. Addition of User/Object Attributes: Addition of new attributes to a user requires updates to UA. Essentially, we need to delete the earlier record of this user from UA and find the new roles to be assigned from RUA based on this new set of attributes. Similarly, when new attributes to an object are added, the row pertaining to the object needs to be deleted from PA, and a new row need to be added based on this new set of attributes after checking eligibility using ROA.

Addition of Rules: Upon adding an ABAC rule, since the UPA changes accordingly, we need to redo the ABAC-RBAC translation step to generate the new UA and PA. However, there is an alternative to avoid this expensive step. Instead, one can add a new role corresponding to this new ABAC rule by examining the users and objects satisfying this new rule and reflect that in UA and PA. While this is somewhat a manual process, this avoids redoing the translation every time a new ABAC rule is added. However, in this case, the translation step can be performed after a batch of ABAC rules are added. Note, however, that this action might create redundant roles in the system.

Changes requiring redoing of ABAC-RBAC translation

Deletion of Rules: On deleting an ABAC rule, the UPA changes, and as a result the step of ABAC-RBAC translation has to be redone, which generates new UA and PA. Addition/Deletion of attributes to ABAC Rules: Since addition or deletion of attributes to a ABAC rule essentially creates a new rule, it results in a new UPA. Therefore, it requires redoing of the ABAC-RBAC translation step.

Related Work

There have been attempts in past to integrate ABAC and RBAC. Authors have proposed methods to unify both the models to get benefits of both. Kuhn et al. [START_REF] Kuhn | Adding attributes to role-based access control[END_REF] discussed incorporating attributes into roles to combine the best of ABAC and RBAC and provide an effective access control. Also, Al-Kahtani et al. [START_REF] Al-Kahtani | A model for attribute-based user-role assignment[END_REF] proposed a model to dynamically assign users to roles using attribute based rules. Further, Jin et al. [START_REF] Jin | RABAC: role-centric attribute-based access control[END_REF] proposed RABAC: Role-centric Attribute based Access Control where they extend RBAC with user and object attributes and also add a Permission Filtering Policy (PFP) to their model. All these focus on extending RBAC rather than using the basic RBAC that is available in most commercial implementations today.

Huang et al. [START_REF] Huang | A framework integrating attribute-based policies into role-based access control[END_REF] have proposed a model to integrate ABAC and RBAC at two levels: aboveground and underground. The aboveground level is RBAC model with environment constraints added to it and the underground level uses attribute-based policies for user-role assignment and role-permission assignment. Their work is different from that of ours as they focus on a top-down model to integrate ABAC and RBAC.

To the best of our knowledge, there have been no attempts to address this problem of deployment of an ABAC policy in a RBAC system. The NIST report on ABAC [START_REF] Hu | Guide to Attribute Based Access Control (ABAC) Definition and Considerations[END_REF] mentions that "while it is possible to achieve ABAC objectives using ACLs or RBAC, demonstrating access control (AC) requirements compliance is difficult and costly due to the level of abstraction required between the AC requirements and the ACL or RBAC model. Another problem with ACL or RBAC models is that if the AC requirement is changed, it may be difficult to identify all the places where the ACL or RBAC implementation needs to be updated." Our approach attempts to draw the benefits from ABAC as well as RBAC by automatically translating a ABAC policy into RBAC.

Conclusions and Future Work

In this paper we demonstrate how ABAC can be deployed using an RBAC system. Our evaluation shows that the access request evaluation cost of RBAC is always less than the cost of the ABAC system implementing the same policy. However, since RBAC's maintenance cost is higher than that of ABAC, we also discuss several mitigation strategies to minimize the cost of various administrative operations that cause changes to ABAC. In future, we plan to implement this deployment approach while enforcing segregation of duty constraints [START_REF] Jha | Enforcing Separation of Duty in Attribute Based Access Control Systems[END_REF]. In this work, we assumed there were no environmental conditions in ABAC. In future, we would like to include the environmental conditions as well and see how they translate into a context aware RBAC model.

Fig. 1 :

 1 Fig. 1: Approach for Deployment of ABAC in RBAC Steps for ABAC to RBAC translation: Step 1. Construct the set of Authorizations A from the User Attribute Relation (UAR), Object Attribute Relation (OAR) and the ABAC policy base (Π A ): For each user(u i )-object(o j ) combination from UAR and OAR, we check if their corresponding attribute conditions(U C .u i and O C .o i ) form a superset of any of the given ABAC rules in Π A . For every such superset occurence, we include the set comprising of user(u i ), object(o j ) and the operation(op k .π k ) in A.The procedure is automated in the first part of algorithm 1. As an example, given UAR in table 1 , OAR in table 2 and Π in table 3, the derived A is shown

Fig. 4 :

 4 Fig. 4: Increasing User Object Size Fig. 5: Increasing Positive Authorizations

  Each ua i is associated with a set of possible values it can acquire. For instance, if a user attribute Position is associated with the values {Manager, Associate, Customer }, then for every u ∈ U, value of the attribute Position can be either Manager, Associate or Customer. O A : Represents a set of object attribute names. Members of these sets are represented as oa i , for 1 ≤ j ≤ |O A |. Each oa i is associated with a set of possible values it can acquire. For instance, if an object folder with records of customers has object attribute Region associated with a set of values {EastCoast, WestCoast}, then for every o ∈ O, Region can be either EastCoast or WestCoast.

  1. As an example, given UAR in table 1 , OAR in table 2 and Π in table 3, the derived A is shown Algorithm 1 Generating A and UPA INITIALIZE UPA of size M × N such that M =1,. . . , |U |; N =1,. . . , |ui -oi| in A for all a l in A do UPA(ui.a l , oj.a l -op k .a l ) ← 1 end for

	Require: UAR, OAR, ΠA
	INITIALIZE A= ∅
	for all (ui-oj) combinations in UAR and OAR do
	for all π k in ΠA do
	if π k ⊆ UC.ui	OC.oj then
	A ← A	(ui,oj,op k .π k )
	end if
	end for
	end for

Table 4 :

 4 A

	User	Object	Permission
	u	o	opi
	u1	o1	op1
	u2	o1	op1
	u3	o2	op1
	u4	o2	op1
	u1	o1	op2
	u3	o2	op2

  Considering our example once again, given UPA in table 5, the derived UA and PA are shown in tables 6 and 7, respectively. Theorem 1. Let A be the set of authorizations covered by Π A and R. If |Π A | is the minimum number of ABAC rules required to cover A and |R| is the minimum number of roles required to cover A, then |Π A | ≥ |R|.Proof. Let 'k ' be the minimum number of ABAC Rules |Π A |, where Π A = {π 1 , π 2 , π 3 . . . π k } that cover a set of authorizations A and let 'n' be the minimum number of RBAC roles R that cover the same set of authorizations A is R= {r 1 , r 2 , r 3 , . . . r n }.

Table 8 :

 8 A

	User Object Permission
	u1	o1	op1
	u1	o2	op1
	u1	o3	op1
	u2	o1	op1
	u2	o2	op1
	u3	o1	op1
	u3	o2	op1
	u4	o3	op1

Table 12 :

 12 OARIn order to compare the time taken for access request (AR) evaluation, the same ABAC and RBAC policy, we need to first create two equivalent policies and compare the time taken to evaluate the same set of access requests. This is done as follows. First, a synthetic ABAC policy base (Π A ) is created. For creating synthetic ABAC Policies we used the data generator used by Talukdar et al.[START_REF] Talukdar | Sural Efficient Bottom-Up Mining of Attribute Based Access Control Policies[END_REF]. Next, using the ABAC policy base and the User Attribute relation (UAR) and Object Attribute Relation (OAR), the (UPA) relation is created, on which Role Mining is done on the (UPA) relation to create the User Assignment (UA) and Role Assignment (PA) relation. Any Role Mining algorithm could be used, as long as it completely covers the given UPA. In this particular case, we use the DEMiner algorithm proposed by Uzun et al.[START_REF] Uzun | Migrating from DAC to RBAC[END_REF].For each set of experiments, we have compared the access request evaluation time for both ABAC and RBAC. The experiments are performed on a Intel Core i7 2.60 GHz machine with 8.00 GB memory running 64-bit Windows 10.

	Object oc1 oc2 oc3
	o1	1 0 0
	o2	0 1 0
	o3	0 0 1

Table 13 :

 13 Increasing Rule Size

	|U| |O| |UC| |OC| |ΠA| |R| AvgRTABAC AvgRTRBAC
	(in ms)	(in ms)
	200 200 500 500 500 200 19.385	0.032
	200 200 500 500 1000 200 35.227	0.032
	200 200 500 500 2000 200 69.108	0.032

Table 14 :

 14 Increasing Attribute Size

	|U| |O| |UC| |OC| |ΠA| |R| AvgRTABAC AvgRTRBAC
	(in ms)	(in ms)
	200 200 500 500 500 200 19.385	0.032
	200 200 1000 1000 500 200 35.381	0.032
	200 200 2000 2000 500 200 73.894	0.033

Table 15 :

 15 Increasing User/Object Size

	|U| |O| |UC| |OC| |ΠA| |R| AvgRTABAC AvgRTRBAC
		(in ms)	(in ms)
	300 300 150 150 50 41	0.656	0.008
	400 400 150 150 50 41	0.705	0.008
	500 500 150 150 50 41	0.658	0.009

Table 16 :

 16 Increasing Positive Authorisations|U| |O| |UC| |OC| |ΠA| |R| Positive Negative AvgRTABAC AvgRTRBAC

		Accesses Accesses (in ms)	(in ms)
	200 200 2000 2000 500 200	0	100	128.640	0.032
	200 200 2000 2000 500 200	20	80	106.464	0.031
	200 200 2000 2000 500 200	40	60	86.615	0.032
	200 200 2000 2000 500 200	60	40	65.242	0.032
	200 200 2000 2000 500 200	80	20	46.610	0.031
	200 200 2000 2000 500 200 100	0	25.495	0.032

Table 17 :

 17 RUA

Acknowledgments

Research reported in this publication was supported by the National Institutes of Health under award R01GM118574, by the National Science Foundation under awards CNS-1564034 and CNS-1624503 and by the National Academies of Sciences, Engineering, and Medicine under the PAK-US Science and Technology Cooperation Program. The content is solely the responsibility of the authors and does not necessarily represent the official views of the agencies funding the research. We would also like to thank Dr. Emre Uzun for his comments.