The Android Platform Security Model

From AcaWiki
Jump to: navigation, search

Citation: René Mayrhofer, Jeffrey Vander Stoep, Chad Brubaker, Nick Kralevich (2019/04/11) The Android Platform Security Model.
Internet Archive Scholar (search for fulltext): The Android Platform Security Model
Wikidata (metadata): Q63248169
Download: https://arxiv.org/abs/1904.05572
Tagged:

Summary

Authors describe Android mobile operating system security model, in particular three-party consent (user, developer, platform), its threat model, and how the Android Open Source Project has implemented the security model over time.

Ecosystem context:

  • Android is an end user focused operating system
  • The Android ecosystem is immense (including diverse hardware OEMs and app stores)
  • Apps can be written in any language

Security principles:

  • Actors control access to the data they create
  • Consent is informed and meaningful
  • Safe by design/default
  • Defense in depth

Threat model:

  • Adversaries can get physical access to Android devices (powered off or screen locked access by unauthorized user, screen unlocked by different authorized user, proximity)
  • Network communication is untrusted
  • Untrusted code is executed on the device
  • Untrusted content is processed by the device

Android platform security model:

  • Three party consent
  • Open ecosystem access
  • Security is a compatibility requirement
  • Factory reset restores the device to a safe state
  • Applications are security principals

AOSP's implementation of the above uses isolation of both application and system components extensively, in comparison to traditional desktop operating systems. For example, each application is run under its own user id, which has extensive implications for both process and persistent data isolation.

As of Android 9.0 authentication is split into 3 tiers:

  • primary, restricted to knowledge factors (eg password, PIN, pattern) obtains access to all fuctions
  • secondary, strong biometrics with low spoof and imposter acceptance rates, access to most functions but not access to encrypted partitions, and requires fallback to primary every 72 hours
  • tertiary, such as weak biometrics, trusted location, and bluetooth pairing, access per secondary minus Keymaster auth-bound keys (eg requiremed for payment) and falls back to primary after 4 hours idle

Theoretical and Practical Relevance

Notably missing from threat model is screen unlocked access by unauthorized user

Retrieved from "https://acawiki.org/index.php?title=The_Android_Platform_Security_Model&oldid=11483"