Mobile Platform Security Architectures A perspective on their evolution

Transcription

1 Mobile Platform Security Architectures A perspective on their evolution N. Asokan Kari Kostiainen 1 NA, KKo, JEE, Nokia Resarch Center

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

3 Introduction Recent interest in smartphone security 3 Oct 2012

4 Securing smartphone application platforms: challenges Introduction 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 Java ME PCs? Is smartphone platform security different? 4

5 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

6 6 Background

7 Platform 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. Background End users; 1. Reliability app. separation 2. Theft deterrence immutable ID 3. Privacy app. separation 4. Closed Open Different Expectations compared to the PC world 7

8 Early adoption of hardware and software security GSM 02.09, 1993 Background 3GPP TS , 2001 Different starting points: widespread use of hardware and software platform security ~2001 ~2002 ~2005 ~2008 8

9 9 Hardware security enablers

10 Hardware support for platform security Hardware security Public key hash Trust root Base identity E.g., serial number Crypto Library Boot sequence (ROM) TCB for platform software Start of boot code Basic elements in immutable storage 10

11 Secure bootstrapping Hardware security 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 11

12 Identity binding Hardware security 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 12

13 Trusted execution environment (TEE) Hardware security Identity certificate Base identity Assigned identity Code certificate Boot code hash Code certificate Validate and execute TEE code hash Why? How? Isolated execution Trust root Base identity TEE Crypto Library Device key Basis for secure external storage Secure boot Boot sequence (ROM) TEE code TCB for platform software Launch platform boot code TEE API 13 Authorized execution of arbitrary code, isolated from the OS; access to device key

14 Secure state Hardware security Identity certificate Base identity Assigned identity Code certificate Boot code hash Code certificate TEE code hash Authenticated boot Trust root Crypto Library Base identity Configuration register(s) Device key TEE Secure boot Boot sequence (ROM) TEE code TCB for platform software Launch platform boot code TEE API 14

15 Secure boot vs Authenticated boot Hardware security 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

16 Secure state Hardware security Identity certificate Base identity Assigned identity Code certificate Boot code hash Code certificate TEE code hash Authenticated boot, Securing TEE sessions Trust root Base identity Configuration register(s) TEE Why? How? Secure boot Crypto Library Boot sequence (ROM) Device key TEE code Non-vol. memory or counter TCB for platform software Launch platform boot code TEE API Rollback protection for persistent secure storage 16 Integrity-protected state within the TEE

17 Device authentication Identity certificate Code certificate Base identity Assigned identity Boot code hash Code certificate TEE code hash External trust root Device certificate Identity Public device key Hardware security Trust root Secure boot Crypto Library Base identity Boot sequence (ROM) TCB for platform software Configuration register(s) Device key TEE code TEE Device authentication, secure provisioning, attestation Non-vol. memory or counter 17 Launch platform boot code TEE API Prove device identity or properties to external verifier

18 Hardware platform security features: summary Hardware security 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

19 Hardware security Architectural options for realizing TEEs External Memories External Memories External Memories RAM Crypto Accelerators On-SoC RAM Crypto Accelerators On-SoC RAM Crypto Accelerators On-SoC Processor core(s) Processor core(s) Processor core(s) ROM Peripherals ROM Peripherals ROM Peripherals OTP Fields OTP Fields On-chip Security Subsystem OTP Fields 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

20 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 Hardware security Processor Secure Environment 20

21 Hardware security architectures (TCG) Hardware security 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

22 Uses of hardware security 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

23 23 Software platform security

24 Open mobile platforms Software Platform security Java ME ~2001 For feature phones 3 billion devices! Not supported by most smartphone platforms 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 (Intel Tizen) Windows Phone ~2010 App development in.net 24

25 Mobile platform security model Software Platform security 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

26 Step 1: Developer publishes an application Software Platform security Developer submits the application to a centralized marketplace In some platforms the application can be directly pushed to the mobile device Centralized marketplace Developer Auxiliary marketplaces Developer requests permissions for his application Some platforms support auxiliary marketplaces Mobile device TCB 26

27 Step 2: Marketplace signs the application Software Platform security Developer In some platforms the developer signs the application Marketplace provider checks the application (and requested permissions) and signs it Centralized marketplace Auxiliary marketplaces Mobile device TCB 27

28 Step 3: Application installation Developer Software Platform security Installer may request the user to accept some of the requested permissions Mobile device receives an application installation package from a marketplace (or developer) Centralized marketplace Auxiliary marketplaces User Mobile device TCB Installer consults local policy database about requested permissions After these checks, the installer assigns these permissions to the application Application permission database Policy database Application Installer Installer stores application permissions Secure storage integrity Platform integrity Installer checks application signature and requested permissions 28 Permission and policy databases need integrity protection Application installer component needs integrity protection

29 Step 4: Application loading Software Platform security Developer Centralized marketplace Auxiliary marketplaces User Mobile device Application Loader attaches permissions to the started process TCB Application permission database Policy database Application loader Application Installer Secure storage integrity Platform integrity Loader reads permissions from the permission database 29 Also loader component needs integrity protection

30 Step 5: Application execution Software Platform security Developer Centralized marketplace Auxiliary marketplaces User OS/HW isolate applications from one another at runtime Mobile device Application Application Application TCB Reference monitor Application permission database Policy database Some applications need secrecy for their persistent storage Application loader Application Installer Some applications need device identification (e.g., DRM) Reference monitor controls access to system resources with permissions 30 Platform integrity Secure storage secrecy integrity Secure state Some applications need secure state (e.g., DRM) Device identification Random Some applications may also need source of randomness

31 Step 6: System updates Software Platform security Developer Platform provider Centralized marketplace Auxiliary marketplaces User Platform providers issues (signed) system updates Mobile device Application Application Application TCB System updater verifies received update using policy Reference database monitor Application permission database Policy database Application loader Application Installer System updater System updater rewrites parts of system software Platform integrity Secure storage secrecy integrity Secure state Device identification Random System updates may need device identification 31 System updates need secure state to prevent rollbacks to previous system version

32 Recap main techniques Software Platform security Developer 1. Permission request Platform provider Centralized marketplace Auxiliary marketplaces User 2. Application signing Mobile device 5. Application isolation Application Application Application OS 6. API to system functionality (e.g. secure storage) Reference monitor 4. Permission-based access control Application permission database Policy database Application loader Application Installer System updater 3. Permission assignment Platform integrity Secure storage secrecy integrity Secure state Device identification Random 32

33 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

34 OS bootstrapping Software Platform security Is hardware security used to secure OS bootstrapping? Symbian Java ME Android MSSF Windows Phone Secure boot Not applicable Typically no Authenticated boot: Normal mode vs Developer mode Secure boot 39

35 Permission granularity Software Platform security How finely is access control defined? Symbian Java ME Android MSSF Windows Phone Fixed set of capabilities (21) Fine-grained permissions (many) Fine-grained permissions (112) Linux access control Fine-grained resource-tokens Linux access control Fixed set of capabilities (16) Android and MSSF: Each application is installed under a separate Linux UID 40

36 Permission assignment (basis) Software Platform security What is the basis for granting permissions? Symbian Java ME Android MSSF Windows Phone 4 categories Trusted signature (also user prompts) Trusted signatures for protection domains 4 permission modes 4 protection levels Trusted signatures Local policy file Trusted signatures (user prompt for location) User System, Restricted, Manufacturer Blanket, Session, One-shot, No Normal (automatic) Dangerous (user-granted) Signature (developer-controlled) SystemOrSignature (Google-controlled) 41

37 Permission assignment (user prompting) Symbian Java ME Android Windows Phone Capability description 21 capabilities Function group description 15 groups Permission group description 11 groups Software Platform security User prompted only for location capability E.g.,Read user data, Use network, Access positioning, E.g., NetAccess PhoneCall Location, E.g., LOCATION, NETWORK, ACCOUNTS, 42 What is shown to the user? Skip to Application Updates Only LOCATION

38 Permission assignment (timing) Software Platform security When are permissions assigned to a principal? Symbian Java ME Android MSSF Windows Phone Install-time assignment Run-time prompts Install-time assignment Install-time assignment Run-time privilege shedding possible Install-time assignment Symbian and MSSF: Permissions of app loading a DLL is a subset of permissions of DLL 43

39 Access control policy Software Platform security How does a resource declare the policy for accessing it? How is it enforced? Symbian Java ME Android MSSF Windows Phone 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 [System resources] Enforced by VM 44

40 Application identification Software Platform security How are applications identified at install and runtime? Symbian Java ME Android MSSF Windows Phone Install and runtime: 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 Install and runtime: Unique ID (assigned by marketplace) 45

41 Application integrity Software Platform security How is the integrity of installed applications protected? Symbian Java ME Android MSSF Windows Phone Dedicated directory Java sandboxing Java sandboxing Linux access control IMA, Smack Offline protection with EVM and TEE.NET sandboxing 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

42 Application update Software Platform security How is a new version of an existing application verified? Symbian Java ME Android MSSF Windows Phone Protected SID/VID: trusted signature Rest: no controls Signed midlets: same-origin policy Unsigned midlets: user prompt Same origin policy Same or higher origin policy Trusted signature 47

43 Application data protection Software Platform security How can applications protect the confidentiality and integrity of their data? Symbian Java ME Android MSSF Windows Phone Runtime: private directory Runtime: private record stores Runtime: dedicated UID file system Runtime: fine-grained data caging Runtime: private directory Off-line: private secure storage Off-line: private secure storage 48

44 49 Discussion

45 Recurring themes (hardware enablers) Discussion 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

46 Recurring themes (software platforms) Discussion Permission-based platform security architectures VAX /VMS privileges for user (~1970 s) Adapted for applications Code signing (mid 1990 s) Used for application installation Application/process isolation 51

47 Open issues Discussion 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

48 Summary Discussion Mobile phone 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