1. Personalizing context-aware access control on mobile platforms
Prajit Kumar Das Anupam Joshi
Tim Finin
Personalizing context-aware access control on mobile platforms 

2. User data under threat

3. …can lead to security breach
Excessive permission requests…
…can lead to security breach
Why should we care?
Apps collect user data
s, Messages, Documents, Sensor data – Highly Personal Data
Can’t App permissions handle privacy and security of data?
App permissions – “Take it or leave it”
Is user okay with sharing location in public place not private place, no way to control that
Use Privacy and Security module to implement context-dependent Rules
Mal-intent app downloaded by 50 million users
sanctioned by United States Federal Trade Commission December 2013
Source and Images courtesy: Google Play Store

4. One-time permissions – Inadequate
Pre-Marshmallow
Marshmallow

5. Solution: Context dependent permissions
9 AM – 5PM, weekday,
work location,
client(work app container)
-> allow storage access
11 AM
birthday party,
Before DND hours of 10PM
a/v app
-> allow camera access
9 PM
driving,
after 5PM,
navigation app
-> allow location access
7 PM 
Context-sensitive
A day in Bob’s BYOD work life

6. Key take-away points
A mobile-middleware that uses human-in-the-loop collaborative editing of access control policies.
Displays run time app activity to assist user in editing their preferences
Show feasibility of using “Violation Metric” as a way to determine completion of policy capture process
Show that a curated initial default policy reduces the amount of user interaction required
MithrilAC attribute-based access control app
Created an end-to-end context-dependent access control framework that monitors mobile application activities on a user's mobile device, in various contextual situations and captures their access control preferences in that context.
\item Created a back-end mobile application analytics system capable of determining mobile application behavior class and risk and generating an initial default policy based on crowd-sourced data.
\item Created a mobile-middleware system capable of observing mobile application behavior and detecting policy violations in context, which is then used to refine an initial default policy.
\item Enriched the Mobipedia~\cite{Pappachan} KB with mobile application behavioral facts.
\item Enhanced presence context detection using nearby messages and beacons.
App behavior classification - system call analysis (MobiSec’17)
Crowdsourced policy clustering for initial generic policy creation
There are 3 most important goals for access control today:
Malware well-researched problem
Google’s PHA taxonomy despite it’s vague definitions are a problem to consider: Backdoors, Spywares, SMS fraud, Hostile downloaders, Privilege escalators, Ransomware, Rooting,
AC policy capture has two aspects to it one that has been heavily researched in this group:
Determining appropriate set of permissions user will prefer to allow Bin Liu and Jialiu Lin’s work
Context hierarchy at which permissions will be allowed
Mithril system: MithrilAC (Access control app)
Framework for capturing ABAC access control policies
User context-sensitive policy capture
Semantic Web technologies
Policy enforcement using custom ROMs / Root privileges
Discussed Heimdall
System calls are less than adequate
Perhaps multi-functionality apps complicated matters

7. Related Work

8. Usable privacy and security
Convergence of personal and enterprise application usage in BYOD scenario leads to new threat models (Kodeswaran et. al.’13)
People are privacy pragmatists (Kumaraguru’12)
User permission decision simplified through profiles (Liu et. al.’14)
Contextual policies on Mobile: CRêPE (Conti’11)
Focus on user context capture for which policy variations exist
– no user control
People are privacy pragmatists
Users are not so sure of their privacy needs
Analyzing the settings on 4.8 million smartphone users concluded a small number of privacy profiles might be able to significantly simplify user decisions
A new challenge in the BYOD space is that the enterprise has no control over applications that are installed on the user device, and cannot prevent those applications from inappropriately accessing (and perhaps sending out) enterprise data. 
The Platys project focused on developing a high-level, semantic notion of location called place. A place, unlike a geospatial position, derives its meaning from a user’s actions and interactions in addition to the physical location where they occur.
Ghosh, Jagtap contextual privacy preservation in mobile devices through semantic reasoning
(Liu’14) Goal was to find permissions that user will allow – A natural extension is contextual situations under which certain permissions will be allowed

9. Context generation
Dey’99: created the popular definition of primary user context as:
Identity (we use presence ) Location , Activity , and time 
Wibisono et.al.’13 defined context in a peer-to-peer environment by reasoning about situations in presence of uncertain context information
Jagtap et.al.’11 created the Platys ontology to model high-level notion of “context” using collaborative information sharing
Mithril uses Platys ontology and extends presence context using nearby messaging and beacons 
– no user control
People are privacy pragmatists
Users are not so sure of their privacy needs
Analyzing the settings on 4.8 million smartphone users concluded a small number of privacy profiles might be able to significantly simplify user decisions
A new challenge in the BYOD space is that the enterprise has no control over applications that are installed on the user device, and cannot prevent those applications from inappropriately accessing (and perhaps sending out) enterprise data. 
The Platys project focused on developing a high-level, semantic notion of location called place. A place, unlike a geospatial position, derives its meaning from a user’s actions and interactions in addition to the physical location where they occur.
Ghosh, Jagtap contextual privacy preservation in mobile devices through semantic reasoning
(Liu’14) Goal was to find permissions that user will allow – A natural extension is contextual situations under which certain permissions will be allowed

10. Approach: Mithril Mobile Middleware
We also called it MithrilAC!

11. Access control model Traditional access control models
Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC) – Sandhu et.al.’96
Do not define context-awareness
Attribute-based Access Control (ABAC) – Draft NIST security standard (Hu et.al.’13)
Attributes in form of tuple (R, C, Q)
R: Represents the requester's context
C: Represents the user's context
Q: Represents the query received
DAC allows access through owner’s discretion; example: An owner of an object has the discretionary right to decide object access
MAC allows access based on policy for an initiator on a target object; example: Security clearance of users and classification of data (as confidential, secret or top secret) are used as security labels to define the level of trust.
RBAC allows access based on role; example: An HR specialist should not have permissions to create network accounts; this should be a role reserved for network administrators
ABAC allows access to users through the use of policies which evaluate user attributes, resource attributes and environment conditions

12. Policy representation
Semantic Web Rule Language (SWRL, Horrocks’04)
Antecedent  Consequent
Antecedents represent context attributes
Requester(?app) ^ hasCategory(?app, “Social_Media”) ^
User(?u) ^ hasLocation(?u, “School”) ^
Request(?app, “$Camera”)  denyAccess(“Camera”)
Policy consequent: Both deny/allow
Things that are allowed by policy but blocked by OS – critical to system
Things that are blocked by policy but allowed by OS – critical to user policy
Antecedent(s) => Consequent
We use a Closed World Assumption.
Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requestor is a manager, THEN allow read/write access to sensitive data.[1]
Unlike Role-Based Access Control (RBAC), which employs pre-defined roles that carry a specific set of privileges associated with them and to which subjects are assigned, the key difference with ABAC is the concept of policies that express a complex Boolean rule set that can evaluate many different attributes.[2] Attribute values can be set-valued or atomic-valued. Set-valued attributes contain more than one atomic value. Examples are role and project. Atomic-valued attributes contain only one atomic value. Examples are clearance and sensitivity. Attributes can be compared to static values or to one another, thus enabling relation-based access control.
Although the concept itself existed for many years, ABAC is considered[3] "next generation" authorization model because it provides dynamic, context-aware and risk-intelligent access control to resources allowing access control policies that include specific attributes from many different information systems to be defined to resolve an authorization and achieve an efficient regulatory compliance, allowing enterprises flexibility in their implementations based on their existing infrastructures. Dynamic authorization using ABAC streamlines the management process by removing the need to deploy expensive and complex identity governance solutions. Hundreds of roles can be replaced by just a few policies.[4]

13. Relevant Terminologies
Observer: Observe system; captures rules
Enforcer: Enforce captured rules
Violation: App  and resource usage contradicts known policy in contextual situation(s)
At location  or during event  or in presence of  or At time 
True Violation – TV: User votes  - Policy is good
False Violation – FV: User votes  - Policy needs revision
MithrilAC has two modes of operation: Policy capturing mode and policy enforcing mode
Violation: An app launch contradicts current known policy in one of the following contextual situation(s) contradicts current known policy
True Violation: User agrees with current policy
False Violation: User disagrees with policy; launch was legitimate

14. User feedback algorithm: Violation detection
Step 1: Detect app launch
Step 2: Detect resource usage
Step 3: Detect context: Using Platys ontology and mobile APIs
Step 4: Look up existing policies and detect violations
Get all apps on mobile device
for each app do:
Observe app launches
Capture resource requested by app
Collect snapshot of context
Look up policy rules that deny resource access to app in current context
Store potential violations for user feedback
for each recorded violations do:
if User denotes as false violation do:
Ask user to modify rule.
if User wants to add a condition to the rule then
Let user choose one of the conditions to add.
else if User wants to delete a condition from the rule then
Let user choose one of the conditions to delete.
else
if User wants to generalize a condition then
Provide user with a more generic condition as defined by the Platys ontology.
Provide user with a more specific condition as defined by the Platys ontology.
User denoted as a true violation.

15. Mithril knows user’s policies, recording true violations!
User feedback algorithm: Policy modification
Step 5: User votes on policy
Step 6: True violations: good!
Good policy 
VM = TV / (FV + TV)
Transitional marker
Mithril knows user’s policies, recording true violations!

16. Mithril needs to capture policy changes!
User feedback algorithm: Policy modification
Step 7: False violations: trigger policy modification steps
Mithril needs to capture policy changes!
Bad policy 
VM = TV / (FV + TV)
Transitional marker

17. User feedback algorithm: Policy modification
Step 7: False violations
Condition generalization
Condition specialization
Delete conditions (Policy deletion)
Add conditions (Policy creation)
VM = TV / (FV + TV)
Transitional marker
Step 7a: User adds condition to rule – Ensure no context conflicts
Step 7b: User deletes condition from rule – Delete rule if empty
Step 7c: User generalizes a rule – May subsume other rules higher level and deny rules have precedence
Step 7d: User specializes a rule

18. He sometimes has lunch with his students.
Why capture policy modifications?
Generic Rule: When at work Professors do not open location sharing apps 
This is Prof. Smith.
He sometimes has lunch with his students.
When out to lunch, Prof. Smith used a location sharing app to coordinate with students.
A default deny rule would allow us to capture rules from scratch but causes user fatigue.
Sadeh et.al’09 has shown asking too many questions leads to user confusion and fatigue

19. Context definition: Platys Ontology
When out to lunch, Prof. Smith used a location sharing app to coordinate with students.
Ontology helps us represent knowledge about the world.
It also makes our system flexible because if you want to use a different ontology to define context for another type of user you don’t have to change the system.
Platys ontology helps define context of a user assuming a professional setting.
We use an ontology to provide users with contextual options for choosing the conditions of a rule
User feedback app uses feedback algorithm for rule refinement. Choices are to generalize or specialize rules.
�         To share common understanding of the structure of information among people or software agents
�         To enable reuse of domain knowledge
�         To make domain assumptions explicit
�         To separate domain knowledge from the operational knowledge
�         To analyze domain knowledge

20. Context definition: Location hierarchy

21. Context definition: Activity hierarchy

22. Presence context: Physical Web
Response: JSON
{“text”: “In front of Dr. Joshi’s office”,
“Location”: “ITE_325_I”}
Organizational context knowledge-base
Where am I?
Carlton is a privacy aware QA system that uses the NearbyMessagesAPI to discover contextual situations like “I am in meeting room A”
Nearby Messages API
Beacons store organizational context:
sitsIn object property defines where people are located in the organization
Semantic knowledge and privacy in the physical web, PrivOn’16

23. User study: Creating context instances
Launch app
Enter Work/Home
Start using phone
Provide feedback
Android Fence API: Location, activity and proximity fences – Energy efficient

24. User study: Challenges and solutions
Application operations API
Inaccessible to user land app and hidden since Android 4.3
Middleware requires “privileged status”, even rooted phones won’t work
Solution: Created custom Android ROM; added Middleware with OEM privileges

25. Policy Enforcement Built Android (LineageOS) – MithrilAC as a priv-app
I am not discussing too much details about the engineering challenges rather focusing on the scientific contribution

26. Evaluation: Mithril Mobile Middleware

27. When can we say we have achieved convergence?
Research Question
Given an initial policy P and user’s implicit desired goal policy P’, can the violation metric be used to determine the completion of the capture process? Use Violation Metric or Policy Precision (range [0,1]) 𝑉𝑀= 𝑇𝑉 𝐹𝑉+𝑇𝑉
Given initial default Policy P, for a generic user Group G, how do we know if our system has reached the goal Policy P’ for a User A who belongs to group G? Or
When can we say we have achieved convergence?
VM = TV / (TV+FV)
Violation Metric akin to “positive predictive value” or “precision” - Compute the “Precision” of the system with respect to violations
In pattern recognition and information retrieval binary classification, precision (also called positive predictive value) is the fraction of retrieved instances that are relevant, while recall (also known as sensitivity) is the fraction of relevant instances that are retrieved. Both precision and recall are therefore based on an understanding and measure of relevance.

28. User study: Stats
Number of participants: 24 (graduate students from the department)
Max number of policies Round 1: 3200
Max number of policies Round 2: 800
Average number of apps per user: 48
Total stats for two round of user study
Average True violations Round 1 per user:
Key observation: Round 2 has more true violations and less false violations
#Users
#Violations
#TV
#FV
Round 1 14
778
228
550
Round 2 10
347
300 47

29. User study round 1 Strategy used: Default deny policy
Key lesson: Default deny causes issues with legitimate app activity

30. User study round 2 Strategy used: Crowdsourced policy
usr1 usr11
usr10 usr12
usr15 usr13
usr17 usr14
usr2 usr16
usr21 usr18
usr22 usr19
usr23 usr20
usr3 usr4
usr7 usr5
usr6
usr8
usr9
Strategy used: Crowdsourced policy
Key lesson: Crowdsourced policy creates less violations thus less user interaction required but still results in fairly high values of Policy precision or Violation metric

31. Reduction in required user interaction

32. End of study survey 5 point Likert scale survey
User feedback questions tries to understand the following:
Are mobile apps intrusive?
Do app risk ratings help? Given appropriate granular information do users feel confident in deciding their access control preferences?
Did the Mithril framework helped user's and the final captured policy indeed represented their privacy and security preferences?
Did the feedback process feel like it was worth the effort given the benefits?
Likert-type scale used for feedback questionnaire
5 point Likert scale survey
Average rating received out of 5 – 4.3

33. User feedback
User A: “…There is a difficulty understanding the time of old notification. Permissions requested in prior day can no longer be configured since the exact time unclear. What does allowed ignore and running mean? All in all its a good starting effort and the setting requires more explanation and further ease to configure.” User B: “... not sure why wikipedia needs my contacts, call log and calendar details. I was happy that mithiril allows context modeling. …, I would not mind if waze asks for contact information and call log access when I am driving. ... Having context is helpful. I also like that number of feedbacks asked by mithiril reduced overtime. … would prefer to add context … customize button … in same window, …”

34. Conclusions
Mithril, a mobile-middleware that uses human-in-the-loop collaborative editing of access control policies
Displays run time app activity to assist user in editing their preferences
Using policy precision or “Violation Metric” to determine completion of user policy capture process is feasible
A curated initial default policy reduces the amount of user interaction required
Default deny policy creates too many policy violations and causes user fatigue

35. Future research goals
Combine static, dynamic and network features to create app behavior knowledge.
Currently using these techniques separately (Das’17, UMBC PhD Dissertation)
Incorporate user feedback from survey
Use computed risk to completely block “too unsafe” apps
Perform user study for things that were allowed in policy and blocked in OS

36. Questions 