Lecture 3 MOBILE PLATFORM SECURITY You will be learning:

. General model for mobile platform security  Key security techniques and general architecture . Comparison of four systems  Android, iOS, MeeGo (MSSF),

2 Mobile platforms revisited

. Android ~2007 . Java ME ~2001  “feature phones”: 3 billion devices!  Not in platforms . Symbian ~2004  First “smartphone” OS

3 Mobile platforms revisited

. iOS ~2007  iP* devices; BSD-based . MeeGo ~2010  -based  MSSF (security architecture) . ~2010 . ...

4 Symbian

. First widely deployed smartphone OS  EPOC OS for devices (1990s) . architecture:  OS components as services  Accessed via Inter-process communication (IPC)

5 Symbian Platform Security

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

6 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

7 Apple iOS

. Native application development in Objective  Web applications on Webkit . Based on Darwin + TrustedBSD kernel extension  TrustedBSD implements Mandatory Access Control  Darwin also used in Mac OS X

8 iOS Platform Security

. Apps distributed via iTunes App Store . One centralized signature authority  Apple software vs. third party software . Runtime protection  All third-party software sandboxed with same profile  Permissions: ”entitlements” (post iOS 6)  Contextual permission prompts: e.g. location

9 MeeGo

. Linux-based OS,  , Nokia,  Evolved from and . Application development in /C++ . Partially buried, but lives on  Linux Foundation shifted to HTML5- based  MeeGo -> Mer -> ’s Sailfish OS

10 MeeGo 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

11 Mobile platform security

. Recall three security principles:  Application isolation  Permission-based access control  Application signing

12 Ecosystem stakeholders

Developer Marketplace operator Platform provider Mobile operator Device manufacturer Administrator User

See also: Book section 2.1. 13 Mobile platform architecture Mobile Device Application Application Library Service Plugin

Mobile Platform (OS) OS middleware System System libraries services (Inter-process ) communication (IPC) OS kernel Device resources

Legend

Mobile Platform Component Third-Party Software Component 14 Platform security architecture

Mobile Third-party Third-party System System Application Device library service service library User

Platform Security Architecture

Developer Reference Monitor IPC Software Isolation

Platform Application System Updater Provider Policy Installer Database Centralized

HW Security API SecurityHW Marketplace Operator

Device Application Administrator Management Application Loader Database Auxiliary Marketplace Boot Secure Storage Execution Operator Legacy DAC Verifier Provider Protection

Boot Secure Device Isolated Device Integrity Storage Identification Execution Authentication

Legend

Platform Security Third-Party Software Hardware-Security Role Component Component Functionality

15 Step 1a: Developer publishes an application Developer submits the application to a centralized Developer requests marketplace Mobile Device permissions for his application Platform Security Architecture Developer

In some platforms the Centralized application can be Marketplace directly “sideloaded” to Operator the mobile device Auxiliary Marketplace Operator

Some platforms Legend support auxiliary Role marketplaces

16 Step 1b: Marketplace signs the application

In some platforms the developer signs the

Mobile app package Device

Platform Security Architecture

Developer

Centralized Marketplace provider Marketplace checks the application (and Operator requested permissions) Auxiliary and signs the app package Marketplace Operator

Legend Role

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

Loader attaches permissions to the Mobile Device started process Application User

Platform Security Architecture

Developer

Application Policy Installer Database Centralized Marketplace Operator

Application Application Loader Database Auxiliary Marketplace Boot Secure Storage Loader reads permissionsOperator from Verifier Provider the permission database

Loader Boot Secure Integrity Storage Integrity of installed component Legend application binaries needs Platform Security Hardware-Security Role integrity ComponentThird-Party Software Functionality protection Component 19 Step 3b: Application execution OS/HW isolate applications from one another at runtime Reference Mobile monitor Third-party Third-party System System Device Application library service service library checks User permissions Platform Security Architecture Software to control Reference Monitor IPC Isolation Developer access to

Application HW Security API system Applications andPolicy Installer Database Centralized resources platform need to Marketplace communicate with each Operator

Application other and HWApplication Loader Database Some Auxiliary Legacy Execution Marketplace applications Boot Secure Storage Operator need secure Verifier Provider DAC Protection state (e.g.,

DRM) Boot Secure Isolated Some applications Integrity Storage Device Execution Device need device IdentificationLegend Authentication identification and

Platform Security Third-Party Software Hardware-Security authentication Role Some applications need Component Component Functionality secrecy for their (e.g., provisioning)

persistent storage 20 Step 4: System updates

System updater System updater rewrites parts of verifies received system software update using policy database Mobile Third-party Third-party System System Platform Device Application library service service library providers issue User (signed) system updates Platform Security Architecture Developer Reference Monitor IPC Software Isolation

Platform Application System Updater Provider Policy Installer Database Centralized

HW Security API SecurityHW Marketplace Operator

Device Application Administrator Application Loader Management Database Auxiliary Marketplace Boot Secure Storage Execution Operator Legacy DAC Verifier Provider Protection Administrators may update

device policies Boot Secure Device Isolated Device and applications Integrity Storage Identification Execution Authentication

Legend System updates Platform Security Third-Party Software Hardware-Security Role may need device System updates need secure Component Component Functionality identification state to prevent rollbacks to previous system version 21 Recap: main techniques

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

Boot Secure Device Isolated Device Integrity Storage Identification Execution Authentication

Legend

Platform Security Third-Party Software Hardware-Security Role Component Component Functionality

22 Platform security architecture

Mobile Third-party Third-party System System Application Device library service service library User

Platform Security Architecture

Developer Reference Monitor IPC Software isolation

Platform Application System Updater Provider Policy Installer Database Centralized

HW Security API SecurityHW Marketplace Operator

Device Application Administrator Management Application Loader Database Auxiliary Marketplace Boot Secure Storage Execution Operator Legacy DAC Verifier Provider Protection

Boot Secure Device Isolated Device Integrity Storage Identification Execution Authentication

Legend

Platform Security Third-Party Software Hardware-Security Role Component Component Functionality

23 Why Generalize?

“The General Problem” http://xkcd.com/974/

24 Mobile Device Application Library Android Java/Dalvik native User

OS Middleware

ActivityManagerService/ Developer PackageManagerService

Platform Provider System Updater Policy Application Installer eg. Google Database

Remote HW Security API Administrator Application Management Database (Java) Auxiliary Marketplace Operator Google Play and others Binder IPC Application Execution Reference Loader Protection Monitor

Boot loader OS Kernel Legacy DAC Execution Reference Binder IPC Protection Monitor

SELinuxMAC Boot Verifier Reference Legacy IPC (optional) Monitor

Boot Secure Integrity Storage

Legend

Role Platform Security Third-Party Software Hardware-Security Component Component Functionality Mobile Application Application Device Objective-C, C/C++ web iOS User Platform System Application Provider Policy Updater Installer Apple Database Developer

Administrator Remote Application Application Apple Management Loader Database Centralized Core OS Marketplace

( Operator file file system,key chain Reference Monitor (TrustedBSD MAC) HW Security API Apple

Boot Secure Storage Execution Verifier Provider Protection )

Boot Secure Integrity Storage

Legend

Role Platform Security Third-Party Software Hardware-Security Component Component Functionality Mobile Application Shared Library Service Device (C++) (C++) (C++) Symbian OS User

OS Middleware

Platform HW Security API Developer System Application Installer Provider Policy Updater Service (Nokia) Database

Centralized Application Marketplace Database Operator (Nokia Store)

Boot OS Kernel IPC loader Reference Monitor Application Loader Boot Execution Software Verifier Protection isolation

Boot Secure Integrity Storage

Legend

Role Platform Security Third-Party Software Hardware-Security Component Component Functionality Mobile Application Library Plugin Service Device C/C++ C/C++ C/C++ C/C++ MSSF User

OS Middleware

Platform System Application HW Security API Developer Policy

Provider Updater Installer ( Database file system

Application Application ) Loader Database

Boot OS Kernel IPC loader Legacy DAC Smack MAC Reference Reference Monitor monitor Auxiliary Marketplace Boot Secure Storage Operator Verifier (Integrity) Provider Software Execution (IMA/EVM) isolation Protection

Boot Secure Integrity Storage

Legend

Role Platform Security Third-Party Software Hardware-Security Component Component Functionality Model for platform security

Four processes to protect: 1. Software deployment 2. Application installation 3. Runtime operation 4. Platform management

29 1. Software deployment

Developing and publishing . Design choices:  Distribution : centralized vs.

decentralized Developer  App signing: certified vs. self- Centralized Marketplace signed Operator

Auxiliary Marketplace 30 Operator 1. Software deployment

. Design choices:  App identification: global vs. local

 … Developer

Centralized Marketplace Operator

More design choices discussed in book chapter 4. Auxiliary Marketplace 31 Operator Software deployment

Android iOS MSSF Symbian Distribution Multiple Centralized Multiple Centralized model marketplaces, marketplace marketplaces, marketplace, sideloading sideloading limited sideloading Application Developer Centralized Marketplace Centralized or signing signature signature and developer developer signature signing: affects set of permissions Application Package ID, Application ID 3-part ID: Application identifier local Linux Marketplace - ID, vendor ID UID for package - permissions application 32 2. App installation

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

Application Database 33 App permissions

. Ask user?  Install or use time? . Automatic granting? . What about libraries?

Symbian Android 34 App permissions

Android iOS MSSF Symbian Granularity Fine-grained Pre-defined Fine-grained Coarse- profiles (iOS6 grained entitlements) Assignment Ask user or Fixed profile Marketplace- Ask user or app signature for all apps specific rights centralized profiles signature Ask user: by group (11), by name, never ask by name (21), presentation install time runtime install time

35 App permissions

. Runtime permission changes Android iOS MSSF Symbian Changes in Constant Rights can Rights can Constant process (except URI increase by increase by (library loading permissions at permissions) user approval plugin loading, can fail) runtime decrease by request Permissions of App’s App’s Union of app App’s libraries permissions permissions and library permissions permissions (library perms must be a superset)

36 App updates . Who can update an app?  Same-origin: same dev. key  Trusted marketplace(s)  Allow anyone

Android iOS MSSF Symbian Updates Same-origin: Centrally Marketplace’s Protected? allowed if… must match signed trust level Same-origin; old version’s high enough Unprotected? developer key Anyone 37 3. Runtime operation

. Design choices:  Permission enforcement: where?  App data protection: how to secure storage?

Application Application Loader Reference Monitor IPC Database

Secure Storage Execution Legacy DAC Provider Protection Hardware support: Lecture 4 38 Runtime operation

. Access control enforcement: where is ”reference monitor”?

Android iOS MSSF Symbian Where is UID/GID- Centralized D-Bus Reference access control based in framework + monitor for enforced? kernel + socket IPC in IPC calls + IPC access kernel + application control in application code Binder + code application code 39 Protecting data & code

 Applications: isolation for data access  Platform: executables (see later)

Android iOS MSSF Symbian Application Own directory Access to own Permission- Own directory data integrity and Linux directory only based policies access control

40 4. Platform management

Bootup, platform integrity, updates . Design choices:  Boot integrity: secure vs. authenticated? Platform System Updater Policy Provider Database

Boot Verifier

Device Administrator Application Management Database 41 4. Platform management

. Design choices:  Platform updates: trust roots, update policy  Device management: administrator access Platform System Updater Policy Provider Database

Boot Verifier

Device Administrator Application Management Database 42 Secure boot vs. authenticated boot

OS Kernel checker pass/fail OS Kernel measurer <

checker Boot block pass/fail Boot block measurer

pass/fail Firmware checker Firmware measurer state

Secure boot Authenticated boot

43 Boot integrity

. Secure boot . Only authorized images can be booted . Authenticated boot . Access levels depend on booted image

Android iOS MeeGo Symbian Platform Vendor- Secure boot Secure boot, Secure boot boot integrity specific authenticated boot

44 Platform data integrity

Android iOS MeeGo Symbian Platform data Linux A/C, Dedicated Linux A/C, Dedicated integrity SELinux, UID- directory, Smack, IMA, directory based code signing EVM sandboxing enforcement

. IMA: Integrity measurement architecture . EVM: Extended validation module

(see “An Overview of The Linux Integrity Subsystem”)

45 Updates and administration

Android iOS MeeGo Symbian System Centrally Centrally Multiple Centrally updates signed signed repositories signed

Remote Built-in Built-in Built-in As third-party management features features features solutions only

46 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

47 The big picture

Different choices in the design space lead to different architectures

Open issues remain: can you think of some?  More in Lecture 6

48 Did you learn:

. Generalization of mobile software platforms  Key security techniques and general architecture . Comparison of four systems  Android, iOS, MeeGo (MSSF), Symbian

Contributors: Kari Kostiainen, N. Asokan, Sini Ruohomaa 49 Plan for the course

. Lecture 1: Platform security . Lecture 2: Case study – Android . Lecture 3: Mobile software platform security in general . Lecture 4: Hardware security enablers . Lecture 5: Usability of platform security . Invited lecture: SE Android policies . Lecture 6: Summary and outlook

50