systems and algorithms for smartphones improved security
play

Systems and Algorithms for Smartphones Improved Security and - PowerPoint PPT Presentation

Systems and Algorithms for Smartphones Improved Security and Usability University of Perugia Perugia, Italy, March 28, 2011 Mauro Conti Vrije Universiteit Amsterdam Amsterdam, The Netherlands mconti@cs.vu.nl


  1. Systems and Algorithms for Smartphones Improved Security and Usability —— University of Perugia Perugia, Italy, March 28, 2011 Mauro Conti Vrije Universiteit Amsterdam Amsterdam, The Netherlands mconti@cs.vu.nl http://www.cs.vu.nl/˜mconti Systems and Algorithms for Smartphones Improved Security and Usability 1 / 64

  2. Outline Introduction 1 CRePEdroid: Context-Related Policy Enforcement for Android 2 Transparent Smartphone User Authentication 3 Other Ongoing Research Projects 4 5 Ready For Take Off? Systems and Algorithms for Smartphones Improved Security and Usability 2 / 64

  3. Outline Introduction 1 CRePEdroid: Context-Related Policy Enforcement for Android 2 Transparent Smartphone User Authentication 3 Other Ongoing Research Projects 4 5 Ready For Take Off? Systems and Algorithms for Smartphones Improved Security and Usability 3 / 64

  4. Smartphones Usage Systems and Algorithms for Smartphones Improved Security and Usability 4 / 64

  5. Smartphones Usage Systems and Algorithms for Smartphones Improved Security and Usability 5 / 64

  6. Why Android? The Android platform: Support the application developer with low-level features Fine-grained security permissions bundling with applications Open source Very popular Systems and Algorithms for Smartphones Improved Security and Usability 6 / 64

  7. Android Architecture Systems and Algorithms for Smartphones Improved Security and Usability 7 / 64

  8. Android in a slide Application Framework Components: Activity, Service, Content Provider, Broadcast Receiver Security: (1) Application isolation (kernel), (2) ICC Ref. Monitor provides MAC Permissions: (1) all-or-nothing, (2) once granted, no revocation or constraints Permission Levels: normal, dangerous, signature, signature or system Systems and Algorithms for Smartphones Improved Security and Usability 8 / 64

  9. Moving Forward Research. What are we looking for? Original Idea... (it seems) we all have many better if (at a point) it soves a concrete/important problem why the state of the art does not solve the problem? Thourough Analisys and Investigation! An example? Well... probably you need Google to search for it! Systems and Algorithms for Smartphones Improved Security and Usability 9 / 64

  10. Outline Introduction 1 CRePEdroid: Context-Related Policy Enforcement for Android 2 Transparent Smartphone User Authentication 3 Other Ongoing Research Projects 4 5 Ready For Take Off? Systems and Algorithms for Smartphones Improved Security and Usability 10 / 64

  11. Authorization Policy Constraints on phone functions over the phone (e.g. Bluetooth, Camera, WiFi) Constraints on access by external systems or by the user Systems and Algorithms for Smartphones Improved Security and Usability 11 / 64

  12. Context-Related Policy Context defined by the status of different system variables (time, location, presence of the user, interaction from the user, etc.) high level contexts are also possible (e.g. is the user running? is the user alone in the room?) Policy specifying access constraints over system functions (e.g. camera, bluetooth, etc.) depending on the context Typically defined at run-time Systems and Algorithms for Smartphones Improved Security and Usability 12 / 64

  13. Examples Policy examples Bluetooth communication enabled only at home or in the office Friend profile, employee profile Camera disabling in museums, Silent mode in meeting rooms Flight mode Systems and Algorithms for Smartphones Improved Security and Usability 13 / 64

  14. Related Work Security enforcement at install time Kirin 1 , it does not support context-related run-time policies Security enforcement at run time Concept of Dynamic in Access Control 2 Saint, Secure Application Interaction 3 , allows run-time application (non user) policies enforcing—e.g application A can define: (1) which apps can access A’s interfaces, (2) how, (3) select at run time if using interface of B or C Apex 4 extends Android permissions with run time constraints—not system wide, no policy set at run time, no 3rd party policies, weak overhead evaluation Taintdroid 5 traces information handled by applications 1 [W. Enck et al. CCS ’09] 2 [V. Rao and T. Jaeger, SACMAT ’09] 3 [M. Ongtang et al., ACSAC ’09] 4 [M. Nauman et al., AsiaCCS ’10] 5 [W. Enck et al., OSDI ’10] Systems and Algorithms for Smartphones Improved Security and Usability 14 / 64

  15. CRePEdroid — Context-Related Policy Enforcement 6 Context-Related policies—with a system scope Specified by Users Trusted Third Party (i.e. Developer, Government, Employer, Device manufacturer, Network Operator, etc.) Dynamically enforced and dynamically specified 6 Mauro Conti, Vu Thien Nga Nguyen, and Bruno Crispo. CRePE: Context-Related Policy Enforcement for Android. (ISC 2010 - Springer LNCS), to appear, Boca Raton, FL, USA, October 25 - 28, 2010. - (acceptance rate 22/134 - 16.41 %) Systems and Algorithms for Smartphones Improved Security and Usability 15 / 64

  16. CRePE — Definitions Context : defined by condition(s) on attributes. A context is active if the condition is verified Policy : How the phone acts in the context. Set of rules Rule : < resource , Allowed | Denied > (e.g. R = < CAMERA , denied > ) Resource Phone functionalities (e.g. Bluetooth, Camera, WiFi, etc.) Applications, components Systems and Algorithms for Smartphones Improved Security and Usability 16 / 64

  17. CRePE — Policy Conflicts Resolution Rules might specify conflicting behaviour Labels and MAC to regulate policy/rule priority Labels relations: L 1 > L 2 > L 3 L 1 = Government L 2 = Trusted Party L 3 = User Conservative approach: Denied > Allowed Deny as default Systems and Algorithms for Smartphones Improved Security and Usability 17 / 64

  18. CRePE — Architecture Policy Provider Policy Manager CRePE Permission Check Action Performer Context Detector User Interactor Trusted Party Interactor Systems and Algorithms for Smartphones Improved Security and Usability 18 / 64

  19. Policy Provider Database to store contexts and policies Embedded inside the Android middleware Systems and Algorithms for Smartphones Improved Security and Usability 19 / 64

  20. Policy Manager Manage active contexts Set of active rules Conflict resolution Update information in Policy Provider Systems and Algorithms for Smartphones Improved Security and Usability 20 / 64

  21. Context Detector Time: system timer Location: GPS: Accurate but slow, consume much energy Easy to extend to other context sensors (i.e. movement, connectivity, etc.) Systems and Algorithms for Smartphones Improved Security and Usability 21 / 64

  22. CRePE Permission Check Hooks before Android Permission Checks CRePE Check based on the set of active rules Systems and Algorithms for Smartphones Improved Security and Usability 22 / 64

  23. Action Performer When the set of active rules is updated: Stop running applications prohibited by the set of active rules Start applications Airplane Mode Systems and Algorithms for Smartphones Improved Security and Usability 23 / 64

  24. User Interactor Support operating on contexts and policies Android application Authentication by password Systems and Algorithms for Smartphones Improved Security and Usability 24 / 64

  25. Trusted Party Interactor Support remote policy and context administration SMS messages Authentication Trust the network carrier PKI Systems and Algorithms for Smartphones Improved Security and Usability 25 / 64

  26. Security Evaluation Reduce the number of allowed accesses Not reduce security Systems and Algorithms for Smartphones Improved Security and Usability 26 / 64

  27. Overhead Evaluation CRePE Permission Check Context Detector Trusted Party Interactor Systems and Algorithms for Smartphones Improved Security and Usability 27 / 64

  28. Overhead — Permission Check Depend on the number of active rules Time overhead is small Systems and Algorithms for Smartphones Improved Security and Usability 28 / 64

  29. Overhead — Context Detector Investigated: Time overhead when activating or deactivating contexts Depending on the current configuration Experimental configuration 2 active contexts, 10 rules each, no conflict new context with 10 rules, 5 conflicts Result Operation Execution Time (millisecond) 72 . 487 ± 19 . 743 Context activation 42 . 942 ± 4 . 536 Context deactivation Time overhead is small Systems and Algorithms for Smartphones Improved Security and Usability 29 / 64

  30. Overhead — Interaction 140 CRePE core User interface Sms interface 120 Time overhead (milliseconds) 100 80 60 40 20 0 User Sms Interaction type Systems and Algorithms for Smartphones Improved Security and Usability 30 / 64

  31. Overhead — Trusted Party Interactor Operate on contexts and policies Time overhead: depend on the operation and the current configuration Experimental configurations Scenario 1: similar to the previous experimental configuration, activate the context Scenario 2: deactivate the context Scenario 3: add a new context (not enable, not set up context detector) Scenario 4: add a new rule to an inactive policy (not update the set of active rule) Scenario 5: enable a context defined by time and location (need to set up context detector) Systems and Algorithms for Smartphones Improved Security and Usability 31 / 64

Recommend


More recommend