Lecture 3 MOBILE PLATFORM SECURITY You will be

Lecture 3 MOBILE PLATFORM SECURITY

You will be learning: What techniques are used in mobile software platform security? What techniques are used in mobile hardware platform security? Is there a common general architecture? 2

Mobile platform security Recall classes of basic security techniques: Application isolation Permission-based access control Application signing Hardware-based security features 3

Ecosystem stakeholders Developer Platform provider Mobile device Device manufacturer Mobile operator Administrator User See also: Book section 2. 1. Marketplace operator Think about threat models! 4

Modeling threats Identify Assets and trust assumptions Potential adversaries Adversary capabilities/limitations Possible attack vectors Cf. Software Security course 5

Ecosystem stakeholders Developer Platform provider Mobile device Device manufacturer Mobile operator Administrator User See also: Book section 2. 1. Marketplace operator Think about threat models! 6

Mobile platform architecture Mobile Device Application Service Library Plugin Mobile Platform (OS) OS middleware System services (Inter-process ) communication (IPC) OS kernel System libraries Device resources Legend Mobile Platform Component Third-Party Software Component 7

Platform security architecture Mobile Device Third-party library System service Third-party service Application System library User Platform Security Architecture Reference Monitor Platform Provider System Updater Device Management Application Loader Application Database Boot Verifier Secure Storage Provider Boot Integrity Secure Storage Developer Application Installer Policy Database Execution Protection Legacy DAC Device Identification HW Security API Administrator Software Isolation IPC Isolated Execution Centralized Marketplace Operator Auxiliary Marketplace Operator Device Authentication Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality 8

Step 1 a: Developer publishes an application Mobile Device Developer requests permissions for his application Platform Security Architecture In some platforms the application can be directly “sideloaded” to the mobile device Legend Role Developer submits the application to a centralized marketplace Developer Centralized Marketplace Operator Auxiliary Marketplace Operator Some platforms support auxiliary marketplaces 9

Step 1 b: Marketplace signs the application In some platforms the developer signs the app package Mobile Device Platform Security Architecture Developer Marketplace provider checks the application (and requested permissions) and signs the app package Centralized Marketplace Operator Auxiliary Marketplace Operator Legend Role 10

Step 2: Application installation Installer checks application signature and requested permissions Installer consults local policy database about Mobile requested permissions Device Installer may prompt user to accept some of the requested permissions User Platform Security Architecture Application installer component needs integrity protection Installer stores assigned application permissions Boot Verifier Boot Integrity Developer Policy Database Secure Storage Provider Application Installer Application Database Secure Storage Legend Permission and policy Role databases need integrity protection Platform Security Component Hardware-Security Functionality Centralized Marketplace Operator Auxiliary Marketplace Operator Mobile device receives an application installation package from a marketplace (or developer) 11

Step 3 a: Application loading Mobile Device Loader attaches permissions to the started process Application Loader may prompt user to accept some of the requested permissions User Platform Security Architecture Developer Policy Database Application Database Loader component needs integrity protection Boot Verifier Secure Storage Provider Boot Integrity Secure Storage Platform Security Component Centralized Marketplace Operator Application Loader Auxiliary Marketplace Loader reads permissions from Operator the permission database Legend Role Application Installer Integrity of installed application binaries Third-Party Software Component Hardware-Security Functionality 12

Step 3 b: Application execution Some applications need secure state (e. g. , DRM) Mobile Device Third-party library Third-party service Application Platform Security Architecture System library Software Reference Monitor Isolation IPC Application Installer Policy Database Applications and platform need to communicate with each other and HW Application Loader Application Database Boot Verifier Secure Storage Provider Boot Integrity Secure Storage Legacy DAC Device Execution Protection Platform Security Component User Developer Centralized Marketplace Operator Auxiliary Marketplace Operator Some applications Device need device Authentication identification and authentication (e. g. , Hardware-Security Functionality provisioning) Isolated Execution Identification Legend Some applications Role need secrecy for their persistent storage System service HW Security API Reference monitor checks permissions to control access to system resources OS/HW isolate applications from one another at runtime Third-Party Software Component 13

Step 4: System updates System updater verifies received update using policy database System updater rewrites parts of system software Platform providers issue (signed) system updates Mobile Device Third-party library Administrators may update device policies and applications Software Isolation IPC System Updater User Device Management Application Loader Application Database Boot Verifier Secure Storage Provider Boot Integrity Secure Storage Developer Application Installer Policy Database Execution Protection Legacy DAC Device Identification HW Security API Administrator System library Platform Security Architecture Reference Monitor Platform Provider System service Third-party service Application Isolated Execution Centralized Marketplace Operator Auxiliary Marketplace Operator Device Authentication Legend Role System updates need secure state to prevent rollbacks to previous system version Platform Security Component Third-Party Software Component System updates Hardware-Security may need device Functionality identification 14

Recap: main techniques Mobile Device 4. Permission-based access control Platform Provider Third-party library System service Third-party service Application 5. Application isolation Platform Security Architecture Reference Monitor System Updater Boot Verifier Application Loader Application Database Secure Storage Provider Centralized Marketplace Operator HW Security API Device Management 1. Permission request Application Installer Policy Database 2. Application signing Auxiliary Marketplace Operator Execution Protection Legacy DAC User Developer Software isolation IPC 3. Permission assignment Administrator System library 6. API to system functionality (e. g. secure storage) Boot Integrity Secure Storage Device Identification Isolated Execution Device Authentication Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality 15

Skip to other OSs Platform security architecture Mobile Device Third-party library System service Third-party service Application System library User Platform Security Architecture Reference Monitor Platform Provider System Updater Device Management Application Loader Application Database Boot Verifier Secure Storage Provider Boot Integrity Secure Storage Developer Application Installer Policy Database Execution Protection Legacy DAC Device Identification HW Security API Administrator Software isolation IPC Isolated Execution Centralized Marketplace Operator Auxiliary Marketplace Operator Device Authentication Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality 16

Mobile platforms revisited Android ~2007 Java ME ~2001 “feature phones”: 3 billion devices! Not in smartphone platforms Symbian ~2001 First “smartphone” OS 17

Mobile platforms revisited i. OS ~2007 i. P* devices; BSD-based Mee. Go ~2010 Linux-based MSSF (security architecture) Windows Phone ~2010 . . . 18

Skip to Model Mobile Device Android Application Java/Dalvik/ART Library native User OS Middleware Activity. Manager. Service/ Package. Manager. Service System Updater Administrator Remote Management Application Database Application Loader Boot loader Reference Monitor Boot Integrity Binder IPC Reference Monitor Execution Protection Binder IPC Execution Protection Auxiliary Marketplace Operator Google Play and others OS Kernel Legacy DAC Boot Verifier (optional) Application Installer Policy Database HW Security API (Java) Platform Provider eg. Google Developer SELinux MAC Reference Monitor Legacy IPC Secure Storage Skip to Big Picture Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality Android

Symbian First widely deployed smartphone OS EPOC OS for Psion devices (1990 s) Microkernel architecture: OS components as user space services Accessed via inter-process communication (IPC) 20

Symbian Platform Security Introduced in ~2004 Apps distributed via Nokia Store Sideloading supported Permissions are called ‘capabilities’, fixed set (21) 4 Groups: User, System, Restricted, Manufacturer 21

Symbian Platform Security Applications identified by: UID from protected range, based on trusted code signature Or UID picked by developer from unprotected range Optionally, vendor ID (VID), based on trusted code signature 22

Mobile Device Symbian OS Application (C++) Shared Library (C++) Service (C++) User OS Middleware System Updater Application Installer Service Policy Database Application Database Boot loader OS Kernel Boot Integrity Centralized Marketplace Operator (Nokia Store) IPC Reference Monitor Boot Verifier Developer HW Security API Platform Provider (Nokia) Application Loader Software isolation Execution Protection Secure Storage Device Identification Device Authentication Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality Symbian

Apple i. OS Native application development in Objective C Web applications on Webkit Based on Darwin + Trusted. BSD kernel extension Trusted. BSD implements Mandatory Access Control Darwin also used in Mac OS X 24

i. OS Platform Security Apps identified by unique “app IDs” Cf. Android package names Apps distributed via i. Tunes App Store One centralized signature authority Apple software vs. third party software Runtime protection All 3 rd party s/w sandboxed with same profile Permissions: ”entitlements” (post i. OS 6) Contextual permission prompts: e. g. location 25

Mobile Device i. OS Application Objective-C, C/C++ Application web User Platform Provider Apple System Updater Policy Database Application Installer Developer Administrator Apple Remote Management Application Database Application Loader Core OS Boot Verifier Boot Integrity Execution Protection Secure Storage Provider HW Security API (file system, key chain) Reference Monitor (Trusted. BSD MAC) Centralized Marketplace Operator Apple Secure Storage Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality i. OS

Mee. Go Linux-based open source OS Intel, Nokia, Linux Foundation Evolved from Maemo and Moblin Application development in Qt/C++ Partially buried, but lives on Linux Foundation shifted to HTML 5 -based Tizen Mee. Go -> Mer -> Jolla’s Sailfish OS 27

Mee. Go Platform Security Mobile Simplified Security Framework (MSSF) Permissions: “resource tokens” Enforced via “Smack” Apps identified by signatures from “software sources” Policy specifies privileges grantable by software sources 28

Mobile Device MSSF Application C/C++ Library C/C++ Plugin C/C++ Service C/C++ User OS Middleware System Updater Application Loader Application Database Boot loader OS Kernel IPC Smack MAC Reference Monitor Boot Verifier Boot Integrity Developer Application Installer Policy Database HW Security API (file system) Platform Provider Secure Storage (Integrity) Provider (IMA/EVM) Legacy DAC Reference monitor Software isolation Execution Protection Auxiliary Marketplace Operator Secure Storage Legend Role Platform Security Component Third-Party Software Component Hardware-Security Functionality MSSF

Skip to App Installation Model for platform security Skip to Big Picture Four processes to protect: 1. Software deployment 2. Application installation 3. Runtime operation 4. Platform management 30

1. Software deployment Developing and publishing Design choices: Distribution : centralized vs. decentralized App signing: certified vs. self-signed Developer Centralized Marketplace Operator Auxiliary Marketplace Operator 31

1. Software deployment Design choices: App identification: global vs. local … Developer Centralized Marketplace Operator More design choices discussed in book chapter 4. Auxiliary Marketplace Operator 32

Software deployment Android i. OS MSSF Symbian Distribution model Multiple marketplaces, sideloading Centralized marketplace, limited sideloading Application signing Developer signature Centralized signature Marketplace and developer signature Centralized or developer signing: affects set of permissions Application identifier Package ID, local Linux UID for permissions Application ID 3 -part ID: Marketplace package application Application ID, vendor ID 33

2. App installation Acquiring/installing a new app Design choices: Permission assignment: user vs. authority? Permission granularity? Application updates: same origin vs. centrally authorized? Policy Database Application Installer 34

Skip to Big Picture App permissions Ask user? Install or use time? Automatic granting? Revocation? What about libraries? Symbian i. OS Android 35

Skip to Big Picture App permissions Android i. OS MSSF Symbian Granularity Fine-grained Pre-defined profiles (i. OS 6 entitlements) Fine-grained Coarse-grained Assignment Ask user or app signature Fixed profile for all apps Marketplacespecific rights profiles Ask user or centralized signature Ask user: presentation by group (11), install time & runtime (6. 0) by name, runtime never ask by name (21), install time Both Android (> 6. 0) and i. OS allow revocation of granted permissions 36

Skip to Big Picture App permissions Runtime permission changes Android i. OS MSSF Symbian Changes in process permissions at runtime Pre 6. 0: Constant (except URI permissions) > 6. 0: User can change rights Rights can increase by plugin loading, decrease by request Constant (library loading can fail) Permissions of libraries App’s permissions Union of app and App’s library permissions (library perms must be a superset) 37

App updates Who can update an app? Same-origin: same dev. key Trusted marketplace(s) Allow anyone Updates allowed if… Android i. OS MSSF Symbian Same-origin: must match old version’s developer key Centrally signed Marketplace’s trust level high enough Protected? Same-origin; Unprotected? Anyone 38

3. Runtime operation Design choices: Permission enforcement: where? App data protection: how to secure storage? Reference Monitor IPC Hardware support: Later in Lecture 3, Lecture 4 Application Loader Application Database Secure Storage Provider Legacy DAC Execution Protection 39

Runtime operation Access control enforcement: where is ”reference monitor”? Android Where is access control enforced? i. OS UID/GID-based Centralized in kernel + IPC access control in Binder + application code MSSF Symbian D-Bus framework + socket IPC in kernel + application code Reference monitor for IPC calls + application code 40

Protecting data & code Applications: isolation for data access Platform: executables (see later) Application data integrity Android i. OS MSSF Symbian Own directory and Linux access control Access to own directory only Permissionbased policies Own directory 41

4. Platform management Bootup, platform integrity, updates Design choices: Boot integrity: secure vs. authenticated? Platform Provider System Updater Policy Database Boot Verifier Administrator Device Management Application Database 42

Secure boot vs. authenticated boot OS Kernel checker pass/fail Boot block checker pass/fail Firmware checker pass/fail Secure boot OS Kernel measurer Boot block measurer Firmware measurer state Authenticated boot 43

Boot integrity Secure boot Only authorized images can be booted Authenticated boot Access levels depend on booted image Android Platform boot integrity i. OS Vendor-specific, Secure boot verified boot Mee. Go Symbian Secure boot, authenticated boot Secure boot 44

Platform data integrity Android i. OS Mee. Go Symbian Linux A/C, SELinux, UIDbased sandboxing Dedicated directory, code signing enforcement Linux A/C, Smack, IMA, EVM Dedicated directory IMA: Integrity measurement architecture EVM: Extended validation module (see “An Overview of The Linux Integrity Subsystem”) 45

The big picture Recurring common themes Permission-based security architectures VAX /VMS privileges (~1970’s): adapted for applications Code signing (mid 1990’s): adapted for application installation Application/process isolation 46

The big picture Different choices in the design space lead to different architectures Open issues remain: can you think of some? 47

Platform security architecture Mobile Device Third-party library System service Third-party service Application System library User Platform Security Architecture Reference Monitor Platform Provider System Updater Device Management Application Loader Application Database Boot Verifier Secure Storage Provider Boot Integrity Secure Storage Execution Protection Legacy DAC Device Identification Isolated Execution Device Authentication Legend Role Platform Security Component Developer Application Installer Policy Database HW Security API Administrator Software isolation IPC Third-Party Software Component Hardware-Security Functionality Centralized Marketplace Operator Auxiliary Marketplace Operator

Hardware platform security Boot Integrity Secure Storage Device Identification Isolated Execution HW Security API Trusted Execution Environment Device Authentication

What is a TEE? Processor, memory, storage, peripherals Trusted Execution Environment Isolated and integrity -protected Chances are that: You have devices with hardware-based TEEs in them! But you don’t have (m)any apps using them From the “normal” execution environment (Rich Execution Environment) 50

TEE overview 1. 2. 3. 4. 5. Platform integrity (“boot integrity”) Secure storage Isolated execution Device identification Device authentication Verification root Boot sequence Platform integrity Trusted application TEE mgmt layer Device key KD App Mobile OS Trusted app Trusted OS Mobile device hardware Device certificate Cryptographic mechanisms Volatile memory TEE REE Identity Base identity Device pub key PKD Non-volatile memory Secure storage and isolated execution Device identification More information in the 2014 IEEE S&P article Device authentication 51

Secure boot vs. authenticated boot OS Kernel checker Boot block checker Firmware checker OS Kernel measurer pass/fail Boot block measurer pass/fail Firmware measurer state aggregated hash Why? Secure boot How will you implement a checker? - hardcode H(Boot block|checker) as reference value in checker (in Firmware)? Why? Authenticated boot State can be: - bound to stored secrets (sealing) - reported to external verifier (remote 53 attestation)

Platform integrity Certified by device manufacturer: Sig. SKM(H(boot code)) Boot code certificate Boot code hash Device manufacturer public key: PKM Mobile device hardware TCB Legend Trust anchor (Hardware) Trust anchor (Code) TEE code External certificate Verification root Cryptographic mechanisms Volatile memory Boot sequence Platform integrity Device key KD Trusted Non. Application Stores measurements for volatile (TA)authenticated boot memory TEE management Launch boot code Secure storage and isolated execution Base Signature identity verification algorithm Device identification 54

Secure storage Insecure Storage Sealed-data = Auth. Enc. KD(data |. . . ) Mobile device hardware TCB Legend Verification root Trust anchor (Hardware) Trust anchor (Code) TEE code Encryption algorithm Cryptographic mechanisms Device key KD Volatile memory Boot sequence External certificate Trusted Application (TA) TEE management Platform integrity Nonvolatile memory Secure storage Base identity Protected memory Rollback protection Device identification 55

Isolated execution TA code certificate TA code hash Certified by device manufacturer Mobile device hardware TCB Legend Verification root Trust anchor (Hardware) Trust anchor (Code) TEE code Cryptographic mechanisms Volatile memory Boot sequence External certificate Controls TA execution Platform integrity Trusted Application (TA) TEE management Device key KD Base identity Nonvolatile memory Secure storage and isolated execution Device identification TEE Entry from Rich Execution Environment 56

Device identification Identity certificate Base identity Multiple assigned identities (Certified by device manufacturer) Assigned identity Mobile device hardware TCB Legend Verification root Trust anchor (Hardware) Trust anchor (Code) TEE code Cryptographic mechanisms Device key KD Volatile memory Boot sequence External certificate Trusted Application (TA) TEE management Platform integrity Nonvolatile memory Secure storage and isolated execution Base identity One fixed device identity Device identification 57

Device authentication (and remote attestation) External trust root Mobile device hardware TCB Legend Verification root Trust anchor (Hardware) Trust anchor (Code) TEE code External certificate Cryptographic mechanisms Volatile memory Boot sequence Sign system state in remote attestation Platform integrity Device key KD Trusted Non. Application volatile (TA) Used to protect/derive memory signature key TEE management Secure storage and isolated execution Device certificate Identity Device public key PKD Issued by device manufacturer Device authentication 58

Hardware security mechanisms (recap) 1. Platform integrity – Secure boot – Authenticated boot 4. Device identification 2. Secure storage 5. Device authentication 3. Isolated execution – Remote attestation – Trusted Execution Environment (TEE) Identity certificate Base identity Boot code certificate Assigned identity Boot code hash TA code certificate TA code hash External trust root Mobile device hardware TCB Legend Verification root Trust anchor (Hardware) Cryptographic mechanisms Volatile memory Trust anchor (Code) TEE code External certificate Device certificate Boot sequence Platform integrity Launch boot code Trusted application TEE mgmt layer Device key KD Identity Base identity Device pub key PKD Non-volatile memory Secure storage and isolated execution Device identification TEE Entry from Rich Execution Environment Device authentication 59

TEE system architecture Device Rich execution environment (REE) App TEE API Device OS App Trusted execution environment (TEE) Trusted app TEE management layer TEE entry Device hardware and firmware with TEE support Architectures with single TEE • ARM Trust. Zone • TI M-Shield • Smart card • Crypto co-processor • Trusted Platform Module (TPM) Architectures with multiple TEEs • Intel SGX • TPM (and “Late Launch”) • Hypervisor Figure adapted from: Global Platform. TEE system architecture. 2011. 60

Legend: So. C : system-on-chip OTP: one-time programmable TEE hardware realization alternatives TEE component External Peripherals Off-chip memory External Peripherals Off-chip Memory On-So. C RAM OTP Fields ROM Processor core(s) Internal peripherals On-chip Security Subsystem External Security Co-processor External Secure Element (TPM, smart card) Embedded Secure Element (smart card) Processor Secure Environment (Trust. Zone, M-Shield) Figure adapted from: Global Platform. TEE system architecture. 2011. 61

Did you learn: What techniques are used in mobile software platform security? What techniques are used in mobile hardware platform security? Is there a common general architecture? Contributors: Kari Kostiainen, N. Asokan, Sini Ruohomaa, Luca Davi, Ahmad-Reza Sadeghi 62