Date post: | 18-Dec-2014 |
Category: |
Technology |
Upload: | giuseppe-la-torre |
View: | 553 times |
Download: | 0 times |
SecureDroid: An Android Security Framework Extension for Context-‐‑
Aware policy Enforcement
V.Arena, V. Catania, G. La Torre, S. Monteleone
Department of Electrical, Electronics and Computer
Engineering University of Catania - Italy
PRISM 2013, International Conference on Privacy and Security in Mobile Systems
June 24-‐‑27, 2013 Atlantic City, NJ, USA
F. Ricciato
Innovation and Industry Relations
Telecom Italia S.p.A. - Italy
What do we do with our smartphone?
Call + Text = ~ 17%
Mobile Applications v Plenty of applications in online markets
v Loss of money, loss of personal information v Users’ security depends on applications’ security
Applications’ Security in Mobile OSs
v Apple – App Store v Microsoft – Windows Phone Store v Google – Google Play
v Applications are signed and must specify permissions v User consent v Isolation
v Once an application has been installed it gets access to required permissions until it will be uninstalled
Google’s guideline about application’s security
Android has no mechanism for granting permissions dynamically (at run-time)
because it complicates the user experience to the detriment of security
PARTIALLY TRUE …
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.
Android Security Framework
Android’s security framework checks for permissions when one of the following situations occurs. v An application wants to access to a particular
functionality protected by a permission (e.g. GPS information),
v An application tries to start an activity of another application,
v Both when an application sends and receives broadcasts,
v An application tries to access and operate on a content provider and
v When binding to or starting a service.
SecureDroid v Extends Android Security Framework
v Standard security control still remains v Compatible with applications from market
Provides the possibility to: v Check custom policies at runtime v Specify policies after an application has been
installed v Use context information as policy’s constraints v Allow multiple parties to set policies v Handle policy enforcement: PolicyDenyException
User’s Context v User Context: mobile devices follow the users v Context from sensors, device status, …
v Applications’ behavior may depend on user/device’s context
Some examples v Deny notification from app X while my position is in the
range (Lat, Lon, R) v Deny Internet access to App Y if my device is roaming v Allow only my girlfriend to call me when I’m running
Policy Model v Based on XACML
v Subject information from certificate v Package, author, distributor, …
v Resource information from the application v Android permissions e.g android.permission.INTERNET v Content provider URI
v Context information from sensors v Battery level v User’s Position v Roaming v Accelerometer, gyroscope, …
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>
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
Request ���<Request> " <Subject>" <Attribute AttributeId=”id”>" <AttributeValue>com.example.exampleApp</AttributeValue>" </Attribute>" <Attribute AttributeId=”author-signature”>" <AttributeValue>Bzx62xM45Lc34</AttributeValue>" </Attribute>" </Subject>" <Resources> " <Attribute AttributeId=”android-permission"> " <AttributeValue>android.permission.INTERNET</AttributeValue> " </Attribute>" <Attribute AttributeId=”uri"> " <AttributeValue>http://blockedsite.org/some_content.html</AttributeValue> " </Attribute>" </Resources>" <Environment>" <Attribute AttributeId=”connection-type"> " <AttributeValue>mobile-roaming</AttributeValue>" </Attribute> " </Environment>"</Request>"
Run-‐‑Time policy enforcement
Who can set policies? v Manufacturer v Operator (e.g. Branded smartphones) v Third-parties (e.g. Museum, Company, …) v User
SecurityManagerService class: v Defines READ_POLICY and WRITE_POLICY permissions v Provides readPolicy and writePolicy methods
Policy Management UI
My Context
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
Scenarios
v User’s context-aware policies
v Companies: Bring Your Own Device
v Museum: Deny camera
Conclusions and Future Works
Our contribute: SecureDroid v Acts at system level: platform extension v Enforces context-aware policies at runtime v Allows multiple parties to set policies Future Work v Analysis of user-experience in dealing with Policy
Management UI v Improve context selection
v Help users in choosing policies v Similar applications >> Similar policy in similar context
Thanks for your aXention!
Giuseppe La Torre PhD Student
University of Catania (ITALY) [email protected]
Q