1.
SecureDroid: An Android Security Framework Extension for Context-­‐‑Aware policy Enforcement V.Arena, V. Catania,G. La Torre, S. MonteleoneDepartment of Electrical,Electronics and ComputerEngineeringUniversity of Catania - ItalyPRISM 2013, International Conference on Privacy and Security in Mobile Systems June 24-­‐‑27, 2013 Atlantic City, NJ, USA F. RicciatoInnovation and IndustryRelationsTelecom Italia S.p.A. - Italy

2.
What do we do with our smartphone? Call + Text = ~ 17%

3.
Mobile Applications v Plenty of applications in online marketsv Loss of money, loss of personal informationv Users’ security depends on applications’ security

4.
Applications’ Security in Mobile OSs v Apple – App Storev Microsoft – Windows Phone Storev Google – Google Playv Applications are signed and must specify permissionsv User consentv Isolationv Once an application has been installed it gets accessto required permissions until it will be uninstalled

5.
Google’s guideline about application’s security Android has no mechanism for grantingpermissions dynamically (at run-time)because it complicates the userexperience to the detriment of securityPARTIALLY TRUE …

6.
Android Security Framework v Permissions are granted only during installation v Accept all or cannot install v Users don’t pay aXention to them v Downloads’ count and users’ comments are more effective.

7.
Android Security Framework Android’s security framework checks for permissionswhen one of the following situations occurs.v An application wants to access to a particularfunctionality protected by a permission (e.g. GPSinformation),v An application tries to start an activity of anotherapplication,v Both when an application sends and receivesbroadcasts,v An application tries to access and operate on acontent provider andv When binding to or starting a service.

8.
SecureDroid v Extends Android Security Frameworkv Standard security control still remainsv Compatible with applications from marketProvides the possibility to:v Check custom policies at runtimev Specify policies after an application has beeninstalledv Use context information as policy’s constraintsv Allow multiple parties to set policiesv Handle policy enforcement: PolicyDenyException

9.
User’s Context v User Context: mobile devices follow the usersv Context from sensors, device status, …v Applications’ behavior may depend on user/device’scontextSome examplesv Deny notification from app X while my position is in therange (Lat, Lon, R)v Deny Internet access to App Y if my device is roamingv Allow only my girlfriend to call me when I’m running

10.
Policy Model v Based on XACMLv Subject information from certificatev Package, author, distributor, …v Resource information from the applicationv Android permissions e.g android.permission.INTERNETv Content provider URIv Context information from sensorsv Battery levelv User’s Positionv Roamingv Accelerometer, gyroscope, …

11.
Policy <policy−set combine=”deny−overrides” description=“User’s policyset”> "<policy combine=”deny−overrides”> "<target> "<subject> "<subject−match attr=”id” match=”com.example.exampleApp”/> "</subject>"</target> "<rule effect=”prompt-session”>"<condition> "<resource−match attr=”android-permission” "match=”android.permission.INTERNET”/>""<resource−match attr=”uri” match=”http://blockedsite.org∗”/>""<environment−match attr =”connection−type” "match=”mobile−roaming”/> "</condition> "</rule> "<rule effect=”permit”> "</policy> "</policy−set>

12.
SecureDroid’s Architecture Get capability 1. PEP sends to CH subject’s information about the App (e.g. Certificate) and the required capability (e.g. INTERNET) 2. CH asks the PAP which context information are required for the subject (e.g. Roaming) 3. CH asks to PIP the current value for context (Roaming) 4. CH creates a request and asks to PDP to evaluate the policy for given subject, resources and context App PEP PAP Security Manager Service Context Handler Policy PDP PIP Sensors, Device status 1 2 3 4 5 Read/ Write policies

13.
Request Request SubjectAttribute AttributeId=”id”AttributeValuecom.example.exampleApp/AttributeValue/AttributeAttribute AttributeId=”author-signature”AttributeValueBzx62xM45Lc34/AttributeValue/Attribute/SubjectResources Attribute AttributeId=”android-permission AttributeValueandroid.permission.INTERNET/AttributeValue /AttributeAttribute AttributeId=”uri AttributeValuehttp://blockedsite.org/some_content.html/AttributeValue/Attribute/ResourcesEnvironmentAttribute AttributeId=”connection-type AttributeValuemobile-roaming/AttributeValue/Attribute /Environment/Request

14.
Run-­‐‑Time policy enforcement

15.
Who can set policies? v Manufacturerv Operator (e.g. Branded smartphones)v Third-parties (e.g. Museum, Company, …)v UserSecurityManagerService class:v Defines READ_POLICY and WRITE_POLICY permissionsv Provides readPolicy and writePolicy methods

16.
Policy Management UI My Context

17.
Overall evaluation Android Check SecureDroid Check Application requires a capability at runtime 1. Is a system app/service? 2. Is the permission declared in the manifest? Policies evaluation order Manufacturer Operator Third-­‐‑parties User Allow Deny SecureDroid won’t be invoked

18.
Scenarios v User’s context-aware policiesv Companies: Bring Your Own Devicev Museum: Deny camera

19.
Conclusions and Future Works Our contribute: SecureDroidv Acts at system level: platform extensionv Enforces context-aware policies at runtimev Allows multiple parties to set policiesFuture Workv Analysis of user-experience in dealing with PolicyManagement UIv Improve context selectionv Help users in choosing policiesv Similar applications Similar policy in similar context

20.
Thanks for your aXention! Giuseppe La Torre PhD Student University of Catania (ITALY) giuseppe.latorre@dieei.unict.it Q