A Perspective on the Evolution of Mobile Platform Security Architectures Kari Kostiainen Nokia Research Center, Helsinki TIW, June 2011 Joint work with N. Asokan, Jan-Erik Ekberg and Elena Reshetova 1
Introduction Recent interest on smartphone security Smartphones Open software platforms Third party software Internet connectivity Packet data, WiFi Personal data Location, contacts, communication log Risk of monetary loss Premium calls Feature phones Yes (Java Me) Yes Yes Yes PCs Yes Yes Yes? Is smartphone platform security different? 2
Outline Background and requirements for smartphone security Basics on hardware security enablers Comparison of modern mobile (software) platform security architectures Discussion: open issues, applications and summary 3
Background 4
Security requirements for mobile phones Mobile network operators 1. Subsidy locks immutable ID 2. Copy protection device authentication, app. separation 3. Regulators 1. RF type approval secure storage 2. Theft deterrence immutable ID 3. End users 1. Reliability app. separation 2. Theft deterrence immutable ID 3. Privacy app. separation 4. Different from PC world: Closed Open 5
Early adoption of security mechanisms Operators Regulators End users ~2002 ~2001 ~2005 ~2008 Hardware-based mechanisms Software-based mechanisms 6
Hardware security enablers 7
Hardware support for platform security Public key hash E.g., serial number Trust root Base identity Crypto Library Boot sequence (ROM) TCB for platform software Start of boot code Basic elements in immutable storage 8
Secure bootstrapping Code certificate Boot code hash Trust root Base identity Validate and execute Crypto Library Secure boot Boot sequence (ROM) TCB for platform software Ensure only authorized boot image can be loaded Launch platform boot code 9
Identity binding Identity certificate Base identity Code certificate Boot code hash Assigned identity E.g., IMEI, link-layer addresses, Trust root Base identity Secure boot Crypto Library Boot sequence (ROM) TCB for platform software Validate and accept assigned ID Securely assign different identities to the device Launch platform boot code 10
Trusted execution Identity certificate Base identity Assigned identity Code certificate Boot code hash Code certificate Validate and execute TrEE code hash Isolated execution Trust root Base identity TrEE Crypto Library Device key Basis for secure external storage Secure boot Boot sequence (ROM) TrEE code TCB for platform software 11 Launch platform boot code TrEE API Authorized code execution, isolated from the OS
Secure state Identity certificate Base identity Assigned identity Code certificate Boot code hash Code certificate TrEE code hash Securing TrEE sessions, authenticated boot Trust root Secure boot Base identity Crypto Library Boot sequence (ROM) TCB for platform software Launch platform boot code Configuration register(s) Device key TrEE code TrEE API TrEE Non-vol. memory or counter Rollback protection for persistent secure storage 12 Integrity-protected state within the TrEE
Device authentication Identity certificate Code certificate Base identity Assigned identity Boot code hash Code certificate TrEE code hash External trust root Device certificate Identity Public device key Trust root Secure boot Base identity Crypto Library Boot sequence (ROM) TCB for platform software Configuration register(s) Device key TrEE code Device authentication, secure provisioning, attestation TrEE Non-vol. memory or counter 13 Launch platform boot code TrEE API Prove device identity or properties to external verifier
Summary of hardware mechanisms Secure boot: Ensure only authorized boot image can be loaded Authenticated boot: Measure and remember loaded image Identity binding: Securely assign identities to the device Secure storage: Protect confidentiality and integrity of data Isolated execution: Run authorized code isolated from OS Device authentication: Prove device identity to external verifier Remote attestation: Prove device configuration to verifier 14
Hardware security architectures (mobile) TI M-Shield and ARM TrustZone Augments central processing unit Secure processor mode Isolated execution with on-chip RAM Very limited (<10kB) Secure storage Typically with write-once E-fuses Usually no counters or non-volatile memory Cost issue 15
Hardware security architectures (TCG) Trusted Platform Module (TPM) Standalone processor on PCs Isolated execution for pre-defined algorithms Arbitrary isolated execution with DRTM Platform Configuration Registers (PCRs) Monotonic counters Mobile Trusted Module (MTM) Mobile variant of TPM Defines interface Can be implemented using e.g. TrustZone or M-Shield 16
Uses of hardware security Recap from features Secure/authenticated boot Identity binding/device authentication Secure storage Remote attestation Uses of hardware security (device manufacturer) Device initialization DRM Subsidy lock How can developers make use of hardware security? 17
Software platform security 18
Open mobile platforms Java ME ~2001 For feature phones 3 billion devices! Not supported by the latest smartphones Symbian ~2004 First smartphone OS App development in C++ (Qt) Android ~2007 Linux-based OS App development in Java MeeGo ~2010 Linux-based OS App development in C (Qt) MSSF We exclude iphone, Windows Phone, Blackberry, webos 19
Mobile platform security model Three phases 1. Distribution 2. Installation 3. Run-time enforcement Common techniques Code signing Permission-based access control architecture 20
Distribution Software package Developer produces a software package Code Manifest May submit to a signer for a trusted signature Distributed to device via on-line stores (typically) Developer Software package Signed software package 21
Installation Installer consults local policy and trusted signature Identify application Grant requested privileges Installer may prompt user Software package Installer Signed software package Policy 22
Run-time enforcement Monitor checks if subject has privileges for requested access Monitor resource Resource may perform additional checks principal User may be prompted to authorize access 23
Platform security design choices (TOP 10) 1. Is hardware security used to secure OS bootstrapping? 2. How are applications identified at install and runtime? 3. How is a new version of an existing application verified? 4. How finely is access control defined? 5. What is the basis for granting permissions? 6. What is shown to the user? 7. When are permissions assigned to a principal? 8. How is the integrity of installed applications protected? 9. How does a resource declare the policy for accessing it, and how is it enforced? 10.How can applications protect the confidentiality and integrity of their data? 24
1. OS bootstrapping Is hardware security used to secure OS bootstrapping? Symbian Java ME Android MSSF Secure boot Not applicable No? Authenticated boot: Normal mode vs Developer mode 25
2. Application identification How are applications identified at install and runtime? Symbian Java ME Android MSSF Install and run-time: Protected range SID and VID (managed) UID (unmanaged) Install: Signing key Midlet attributes Install: Signing key Runtime: Unix UID Package name (locally unique) Install: Software source (signing key) Package name Runtime: Software source Package name Application ID 26
3. Application update How is a new version of an existing application verified? Symbian Java ME Android MSSF Protected SID, VID: trusted signature Signed midlets: same-origin policy Same origin policy Same or higher origin policy Rest: no controls Unsigned midlets: user prompt 27
4. Permission granularity How finely is access control defined? Symbian Java ME Android MSSF Fixed set of capabilities (21) Fine-grained permissions (many) Fine-grained permissions (112) Fine-grained resource-tokens Linux access control Linux access control Android and MSSF: Each application is installed under a separate Linux UID 28
5. Permission assignment (basis) What is the basis for granting permissions? Symbian Java ME Android MSSF 4 categories Trusted signature (also user prompts) Trusted signatures for protection domains 4 permission modes 4 protection levels Trusted signatures Local policy file User System, Restricted, Manufacturer Blanket, Session, One-shot, No Normal (automatic) Dangerous (user-granted) Signature (developer-controlled) SystemOrSignature (Google-controlled) 29
6. Permission assignment (user prompting) Symbian Java ME Android MSSF Capability description 21 capabilities Function group description 15 groups Permission group description 11 groups E.g.,Read user data, Use network, Access positioning, E.g., NetAccess PhoneCall Location, E.g., LOCATION, NETWORK, ACCOUNTS, What is shown to the user? 30
7. Permission assignment (timing) When are permissions assigned to a principal? Symbian Java ME Android MSSF Install-time assignment Run-time prompts Install-time assignment Install-time assignment Run-time privilege shedding possible Symbian and MSSF: Permissions of app loading a DLL is a subset of permissions of DLL 31
8. Application integrity How is the integrity of installed applications protected? Symbian Java ME Android MSSF Dedicated directory Java sandboxing Java sandboxing IMA, Smack Linux access control Offline protection with EVM and TrEE Integrity Measurement Architecture (IMA) Store hash of file (in extended attribute security.ima) and verify on launch Extended Validation Module (EVM) Store MAC of all extended attributes (in security.evm) and verify on access 32
9. Access control policy How does a resource declare the policy for accessing it? How is it enforced? Symbian Java ME Android MSSF Declare in code Enforced by IPC framework or code [System resources] Enforced by VM Declare in manifest Enforced by VM Declare in manifest Enforced by Smack or via libcreds 33
10. Application data protection How can applications protect the confidentiality and integrity of their data? Symbian Java ME Android MSSF Runtime: private directory Off-line: private secure storage Runtime: private record stores Runtime: dedicated UID file system Runtime: fine-grained data caging Off-line: private secure storage 34
Discussion 35
Recurring themes (hardware enablers) Hardware-support for platform security Cambridge CAP etc. (~1970s) Extended to Trusted Execution Environments Hardware-assisted secure storage Secure and authenticated boot TCPA and TCG (late 1990s) Academic research projects (mid 1990s) Extended (private secure storage for applications) Adapted (normal vs. developer mode in MSSF) 36
Recurring themes (software platforms) Permission-based platform security architectures VAX /VMS privileges for user (~1970s) Adapted for applications Code signing (mid 1990s) Borrowed for application installation 37
Open issues Permission granularity Coarse-grained permissions vs. principle of least privilege Fine-grained permissions vs. user/developer confusion Permission assignment Is it sensible to let end users make policy assignment decisions? Centralized vetting for appropriateness Can central authority decide what is offensive? Can there be crowd-sourced or clique-sourced alternatives? [Chia et al] Colluding applications How to detect/prevent applications from pooling their privileges? [Capkun et al] 38
On-board Credentials 39 2011 Nokia Research Center
On-board Credentials architecture Credential issuer Credential issuer OS Application Credentials Manager TrEE Credential program Credential program Available for experimentation! Interpreter Kostiainen, Asokan, Ekberg and Rantala. On-board Credentials with Open Provisioning. ASIACCS 2009. 40
Summary Mobile phone security Requirements, regulations, user expectations Early adaptation of hardware security mechanisms Platform security architecture Many features borrow or adapted Permission based access control and code signing Open issues Permission granularity and assignment Kostiainen, Reshetova, Ekberg and Asokan. Old, New, Borrowed, Blue: A Perspective on Evolution of Mobile Platform Security Architectures. CODASPY 2011. 41