Mobile Platform Security Architectures A perspective on their evolution

N. Asokan Kari Kostiainen

1 NA, KKo, JEE, Resarch Center 2011-2012 Introduction Recent interest in security

2 NA, KKo, JEE, Nokia Resarch Center 2011-2012 Jan 2011? Introduction Recent interest in smartphone security

3 Oct 2012 Introduction Securing smartphone application platforms: challenges

Smartphones “Feature phones” PCs Open platforms   Third party software Java ME connectivity   Packet data, WiFi Personal data   Location, contacts, communication log of monetary loss  ? Premium calls

Is smartphone platform security different?

4 Outline Outline

• A bit of background on requirements for securing mobile phones • Basics on hardware security enablers • Comparison of modern mobile (software) platform security architectures • Discussion: open issues and summary

5 Background

6 Background Platform security requirements for mobile phones Mobile network operators; Regulators; 1. Subsidy locks  immutable ID 1. RF type approval  secure storage 2.  device 2. Theft deterrence  immutable ID , app. separation 3. … 3. …

End users; 1. Reliability  app. separation 2. Theft deterrence  immutable ID 3. Privacy  app. separation Closed  Open 4. … Different Expectations compared to the PC world

7 Background Early adoption of hardware and software security GSM 02.09, 1993

3GPP TS 42.009, 2001

Different starting points: widespread use of hardware and software platform security

~2001 ~2002 ~2005 ~2008

8 Hardware security enablers

9 Hardware security Hardware support for platform security

E.g., Public key serial hash number Trust root Base identity

Crypto Library Start of boot code Boot sequence (ROM) Basic elements in TCB for platform software immutable storage

10 Hardware security Secure bootstrapping

Code certificate Boot code hash

Validate and Trust root Base identity execute

Crypto Library

Boot sequence Secure boot (ROM) Ensure only authorized boot TCB for platform software image can be loaded

Launch platform boot code

11 Hardware security Identity binding

Identity certificate Code certificate Base identity Boot code hash Assigned identity

E.g., IMEI, link-layer addresses, …

Trust root Base identity

Validate and accept Crypto Library assigned ID

Boot sequence (ROM) Secure boot Securely assign different TCB for platform software identities to the device

Launch platform boot code

12 Hardware security Trusted execution environment (TEE)

Identity certificate Code certificate Boot code hash Base identity Validate and execute Assigned identity Code certificate

TEE code hash Isolated Why?How? execution

Trust root Base identity TEE

Basis for secure Crypto Library Device key external storage

Boot sequence TEE code Secure boot (ROM)

TCB for platform software

Launch platform boot code TEE API

Authorized13 execution of arbitrary code, isolated from the OS; access to device key Hardware security Secure state

Identity certificate Code certificate Base identity Boot code hash

Assigned identity Code certificate TEE code hash Authenticated boot

Trust root Base identity Configuration TEE register(s)

Crypto Library Device key

Boot sequence TEE code Secure boot (ROM)

TCB for platform software

Launch platform boot code TEE API

14 Hardware security

Secure boot vs Authenticated boot

…

…

OS Kernel checker pass/fail OS Kernel measurer

Boot block checker pass/fail Boot block measurer

Boot seq. checker pass/fail Boot seq. measurer state

Trust root TCB TCB

Root of Trust for measurement

15 Hardware security Secure state

Identity certificate Code certificate Base identity Boot code hash

Assigned identity Code certificate Authenticated boot, Securing TEE code hash TEE sessions

Why?How? Trust root Base identity Configuration TEE register(s)

Crypto Library Device key Non-vol. memory TEE code or Boot sequence counter Secure boot (ROM)

TCB for platform software Rollback protection for persistent secure storage Launch platform boot code TEE API 16 Integrity-protected state within the TEE Hardware security Device authentication External trust root Identity certificate Code certificate Boot code hash Base identity Device certificate Assigned identity Code certificate Identity TEE code hash Public device key

Device authentication, secure provisioning, Trust root Base identity Configuration TEE attestation register(s)

Crypto Library Device key Non-vol. memory TEE code or Boot sequence counter Secure boot (ROM)

TCB for platform software

Launch platform boot code TEE API

17 Prove device identity or properties to external verifier Hardware security Hardware platform security features: summary • Secure boot: Ensure only authorized boot image can be loaded • Authenticated boot: Measure and remember what boot image was loaded • Identity binding: Securely assign different identities to the device • Secure storage: protect confidentiality/integrity of persistent data • Isolated execution: Run authorized code isolated from the device OS • Device authentication: Prove device identity to external verifier • Remote attestation: Prove device configuration/properties to external verifier

18 Hardware security Architectural options for realizing TEEs

External External External Memories Memories Memories

Crypto On-SoC Crypto On-SoC Crypto On-SoC RAM Accelerators RAM Accelerators RAM Accelerators

Processor Processor Processor core(s) core(s) core(s)

ROM Peripherals ROM Peripherals ROM Peripherals

OTP Fields OTP Fields OTP Fields On-chip Security Subsystem

External Security Co-processor

External Secure Element Embedded Secure Element Processor Secure Environment

TEE component

19 Figures taken from “GlobalPlatform Device Technology, TEE System Architecture”, Version 1.0, December 2011 Hardware security Hardware security architectures (mobile)

ARM TrustZone and TI M-Shield

• Augments central processing unit: “Secure processor mode”

• Isolated execution with on-chip RAM: Very limited (<20kB)

• Secure storage: Typically with write-once E-fuses

• Usually no counters or non-volatile memory: Cost issue

Processor Secure Environment

20 Hardware security Hardware security architectures (TCG)

• Trusted Platform Module (TPM) −Standalone processor on PCs −Isolated execution for pre-defined algorithms −Arbitrary isolated execution with DRTM (“late launch”) −Platform Configuration Registers (PCRs) −Monotonic counters External Secure Element

• Mobile Trusted Module (MTM) −Mobile variant of TPM −Defines interface −Implementation alternatives: TrustZone, M-Shield, software

21 Hardware security 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? −an example in the second part of this seminar 22 Software platform security

23 Software Platform security Open mobile platforms

• Java ME ~2001 • Android ~2007 −For “feature phones” −-based OS −3 billion devices! −App development in Java −Not supported by most smartphone platforms • MeeGo ~2010 −Linux-based OS • ~2004 −App development in C++ (Qt) −First “smartphone” OS −MSSF (Intel ) −App development in C++ (Qt) • Windows Phone ~2010 −App development in .NET

24 Software Platform security Mobile platform security model

• Common techniques −Application signing −Permission-based access control architecture −Application isolation

• Common operations 1. Permission request 2. Application signing 3. Application installation 4. Application loading 5. Run-time access control enforcement

25 Step 1: Developer publishes an Platform security

Developer Developer requests permissions for his application Developer submits the application to a centralized marketplace

Centralized Auxiliary Some platforms marketplace marketplaces support auxiliary In some platforms the marketplaces application can be directly pushed to the mobile device

Mobile device

TCB

26 Step 2: Marketplace signs the application Software Platform security

Developer In some platforms the developer signs the application

Marketplace provider checks the application (and Centralized Auxiliary requested permissions) and marketplace marketplaces signs it

Mobile device

TCB

27 Step 3: Application installation Software Platform security Installer may request the Developer user to accept some of the requested permissions

User Centralized Auxiliary marketplace marketplaces Mobile device receives an application installation package from a marketplace (or developer)

Mobile device

Installer consults local After these checks, the policy database about installer assigns these TCB requested permissions permissions to the application

Application Policy permission Application Installer database database

Installer stores Installer checks application application signature and permissions Secure Platform requested storage integrity integrity permissions

Permission and policy Application installer databases need integrity component needs integrity 28 protection protection Step 4: Application loading Software Platform security

Developer

User Centralized Auxiliary marketplace marketplaces

Mobile device Loader attaches permissions to the Application started process

TCB

Application Policy permission Application loader Application Installer database database

Loader reads permissions from the permission database Secure Platform storage integrity integrity

Also loader component 29 needs integrity protection Step 5: Application execution Software Platform security

Developer

User Centralized Auxiliary marketplace marketplaces OS/HW isolate applications from one another at runtime

Mobile device Application Application Application

TCB Reference monitor

Application Reference monitor controls access to permission Policy Application Installer Application loader system resources database database Some applications need Some applications need device identification with permissions secrecy for their persistent (e.g., DRM) storage

secrecy Platform Secure Secure Device Random integrity storage state identification integrity Some applications may also need source of Some applications randomness need secure state 30 (e.g., DRM) Step 6: System updates Software Platform security

Developer

User Platform provider Centralized Auxiliary marketplace marketplaces

Platform providers issues (signed) system updates

Mobile device Application Application Application

System updater verifies TCB received update using policyReference database monitor

Application Application Installer Policy permission Application loader database database System updater System updater rewrites parts of system software

secrecy Platform Secure Secure Device RandomSystem updates may integrity storage state identification need device integrity identification

System updates need secure 31 state to prevent rollbacks to previous system version Recap – main techniques Software Platform security

Developer 1. Permission request

User Platform provider Centralized Auxiliary marketplace marketplaces 2. Application signing

5. Application isolation Mobile device Application Application Application

6. API to system functionality 4. Permission-based OS (e.g. secure storage) access control Reference monitor

Application Application Installer Policy permission Application loader 3. Permission database database assignment System updater

secrecy Platform Secure Secure Device Random integrity storage state identification integrity

32 Software Platform security Software platform security design choices

Device boot − How is platform integrity verified? Application development and installation − How finely are access control policies defined? − What is the basis for granting permissions? Application installation − What is shown to the user? Application runtime − How is the integrity of installed applications protected? − How can applications protect the confidentiality and integrity of their data? Application updates − How is a new version of an existing application verified?

33 Software Platform security OS bootstrapping

Is hardware security used to secure OS bootstrapping?

Symbian Java ME Android MSSF Windows Phone Secure boot Not applicable Typically no Authenticated boot: Secure boot “Normal mode” vs “Developer mode”

39 Software Platform security Permission granularity

How finely is access control defined?

Symbian Java ME Android MSSF Windows Phone Fixed set of Fine-grained Fine-grained Fine-grained Fixed set of “capabilities” (21) permissions permissions (112) resource-tokens “capabilities” (16) (many) Linux access Linux access control control

Android and MSSF: Each application is installed under a separate Linux UID

40 Software Platform security Permission assignment (basis)

What is the basis for granting permissions?

Symbian Java ME Android MSSF Windows Phone 4 categories Trusted signatures 4 protection Trusted signatures Trusted signatures for protection levels Trusted signature domains Local policy file (user prompt for (also user prompts) location) 4 permission modes

User Blanket, Normal (automatic) System, Session, Dangerous (user-granted) Restricted, One-shot, Signature (developer-controlled) Manufacturer No SystemOrSignature (Google-controlled)

41 Software Platform security Permission assignment (user prompting)

Symbian Java ME Android Windows Phone Capability description Function group Permission group User prompted only for • 21 capabilities description description location capability • 15 groups • 11 groups

E.g., LOCATION,

E.g.,Read user data, NETWORK, Use network, Access E.g., NetAccess ACCOUNTS, … positioning, … PhoneCall Location, …

Only LOCATION

42 What is shown to the user? Skip to “Application Updates” Software Platform security Permission assignment (timing)

When are permissions assigned to a principal?

Symbian Java ME Android MSSF Windows Phone Install-time Run-time prompts Install-time Install-time Install-time assignment assignment assignment assignment Run-time privilege shedding possible

Symbian and MSSF: Permissions of app loading a DLL is a subset of permissions of DLL

43 Software Platform security Access control policy

How does a resource declare the policy for accessing it? How is it enforced?

Symbian Java ME Android MSSF Windows Phone Declare in code [System resources] Declare in manifest Declare in manifest [System resources] Enforced by VM Enforced by VM Enforced by IPC Enforced by VM Enforced by Smack framework or code or via libcreds

44 Software Platform security Application identification

How are applications identified at install and runtime?

Symbian Java ME Android MSSF Windows Phone Install and run- Install: Install: Install: Install and run- time: • Signing key • Signing key • Software source time: • Protected range • Midlet attributes (signing key) • Unique ID SID and VID Runtime: • Package name (assigned by (managed) • Unix UID marketplace) • UID (unmanaged) • Package name Runtime: (locally unique) • Software source • Package name • Application ID

45 Software Platform security Application integrity

How is the integrity of installed applications protected?

Symbian Java ME Android MSSF Windows Phone Dedicated Java sandboxing Java sandboxing IMA, Smack .NET sandboxing directory Linux access Offline protection control with EVM and TEE

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

46 Software Platform security Application update

How is a new version of an existing application verified?

Symbian Java ME Android MSSF Windows Phone Protected SID/VID: Signed midlets: “Same origin” policy “Same or higher Trusted signature • trusted signature • “same-origin” origin” policy policy Rest: • no controls Unsigned midlets: • user prompt

47 Software Platform security Application data protection

How can applications protect the confidentiality and integrity of their data?

Symbian Java ME Android MSSF Windows Phone Runtime: Runtime: Runtime: Runtime: Runtime: • private • private record • dedicated UID • fine-grained • private directory stores • file system data caging directory

Off-line: Off-line: • private secure • private secure storage storage

48 Discussion

49 Discussion Recurring themes (hardware enablers)

• Hardware-support for platform security −Cambridge CAP etc. (~1970’s)  Extended to Processor Secure Environments

• Hardware-assisted secure storage • Secure and authenticated boot −Academic research projects (mid 1990’s) −TCPA and TCG (late 1990’s)  Extended (private secure storage for applications)  Adapted (normal vs. developer mode in MSSF)

50 Discussion Recurring themes (software platforms)

• Permission-based platform security architectures −VAX /VMS privileges for user (~1970’s)  Adapted for applications − (mid 1990’s) Used for application installation

• Application/process isolation

51 Discussion Open issues

• Permission granularity −Coarse-grained permissions vs. principle of least privilege

−Fine-grained permissions vs. user/developer confusion [Felt et al, CCS ‘12] • Permission assignment −Is it sensible to let end users make policy assignment decisions? [Chia et al, WWW ’12] [Felt et al, SOUPS ‘12]

• Centralized vetting for appropriateness −Can central authority decide what is offensive? −Can there be crowd-sourced alternatives? [Chia et al, Nordsec ’10, Amini et al, CMU ’12] • Colluding applications −How to detect/prevent applications from pooling their privileges? [Marforio et al, ETHZ ’11] [Schlegel et al, NDSS ’11] [Bugiel et al, NDSS ‘12]

52 Discussion Summary

• security −Requirements: operators, regulators, user expectations −Closed  open −Early adaptation of hardware security mechanisms

• Platform security architecture 1. Application signing 2. Permission based access control 3. Application isolation −Many features borrowed or adapted

• Open issues remain…

• This tutorial is based on an earlier survey paper [Kostiainen et al, CODASPY 2011]; expanded version in preparation. 53