old, new, borrowed, blue: a perspective on the evolution ...€¦ · reliability app. separation 2....

1

Kari Kostiainen

Nokia Research Center, Helsinki

TIW, June 2011

Joint work with N. Asokan, Jan-Erik Ekberg and Elena Reshetova

A Perspective on the Evolution of Mobile Platform Security Architectures

Nokia Research Center 2011

Introduction

2 Nokia Research Center 2011

Recent interest on “smartphone security”…

Is smartphone platform security different?

“Feature phones”

Yes (Java Me)

Yes

Yes

Yes

PCs

Yes

Yes

Yes

?

Smartphones

Open software platforms Third party software

Internet connectivity Packet data, WiFi

Personal data Location, contacts, communication log

Risk of monetary loss Premium calls

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


4

Background


5

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

6

Early adoption of security mechanisms


~2005 ~2002

~2001

Operators End users Regulators

Hardware-based mechanisms Software-based mechanisms

~2008

7

Hardware security enablers


Trust root Base identity

TCB for platform software

Crypto Library

Public key hash

Boot sequence (ROM)

E.g., serial number

Start of boot code

8

Hardware support for platform security


Basic elements in immutable storage


Secure boot

Crypto Library

Boot sequence (ROM)

Launch platform boot code

Code certificate

Boot code hash


Validate and execute

9

Secure bootstrapping


Ensure only authorized boot image can be loaded


Secure boot

Crypto Library

Boot sequence (ROM)

Base identity

Assigned identity

Identity certificate


Code certificate

Boot code hash


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

Validate and accept assigned ID

10

Identity binding


Securely assign different identities to the device


Secure boot

Crypto Library

Boot sequence (ROM)

TrEE

TrEE API

Device key

TrEE code

Base identity

Assigned identity



Code certificate

Boot code hash

TrEE code hash

Code certificate


Isolated execution

Validate and execute

Basis for secure external storage

11

Trusted execution

Nokia Research Center 2011 Authorized code execution, isolated from the OS


Secure boot

Crypto Library

Boot sequence (ROM)

TrEE

TrEE API

Configuration register(s)

Device key

TrEE code

Base identity

Assigned identity



Code certificate

Boot code hash

TrEE code hash

Code certificate


Securing TrEE sessions, authenticated boot

12

Secure state

Nokia Research Center 2011 Integrity-protected state within the TrEE

Non-vol. memory

or counter

Rollback protection for persistent secure storage

External trust root


Secure boot

Crypto Library

Boot sequence (ROM)

TrEE

TrEE API

Configuration register(s)

Device key

TrEE code

Base identity

Assigned identity


Identity

Public device key

Device certificate


Code certificate

Boot code hash

TrEE code hash

Code certificate


Device authentication, secure provisioning,

attestation

13

Device authentication

Nokia Research Center 2011 Prove device identity or properties to external verifier

Non-vol. memory

or counter

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

Nokia Research Center 2011 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


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


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?


18

Software platform security


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…


Mobile platform security model

• Three phases 1. Distribution

2. Installation

3. Run-time enforcement

• Common techniques −Code signing

−Permission-based access control architecture


21

Distribution


• Developer produces a software package

−Code

−Manifest

• May submit to a signer for a trusted signature

• Distributed to device via on-line stores (typically)

Software package

Software package

Signed software package

Developer

Installation

• Installer consults local policy and trusted signature

− Identify application

− Grant requested privileges

• Installer may prompt user


Installer

Software package

Signed software package

Policy

23

Run-time enforcement


• Monitor checks if subject has privileges for requested access

• Resource may perform additional checks

• User may be prompted to authorize access

Monitor

principal

resource

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?


1. OS bootstrapping

Symbian Java ME Android MSSF

Secure boot Not applicable No? Authenticated boot: “Normal mode” vs “Developer mode”


Is hardware security used to secure OS bootstrapping?

2. Application identification


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


How are applications identified at install and runtime?

3. Application update


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


How is a new version of an existing application verified?

4. Permission granularity


Fixed set of “capabilities” (21)

Fine-grained permissions (many)

Fine-grained permissions (112) Linux access control

Fine-grained resource-tokens Linux access control


How finely is access control defined?

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

5. Permission assignment (basis)


4 categories Trusted signature (also user prompts)

Trusted signatures for protection domains

4 permission modes

4 protection levels

Trusted signatures Local policy file


What is the basis for granting permissions?

User

System,

Restricted,

Manufacturer

Normal (automatic)

Dangerous (user-granted)

Signature (developer-controlled)

SystemOrSignature (Google-controlled)

Blanket,

Session,

One-shot,

No

6. Permission assignment (user prompting)


Capability description • 21 capabilities

Function group description • 15 groups

Permission group description • 11 groups


What is shown to the user?

E.g., LOCATION,

NETWORK,

ACCOUNTS, … E.g., NetAccess

PhoneCall

Location, …

E.g.,Read user data, Use network, Access positioning, …

7. Permission assignment (timing)


Install-time assignment

Run-time prompts Install-time assignment

Install-time assignment Run-time privilege shedding possible


When are permissions assigned to a principal?

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

8. Application integrity


Dedicated directory Java sandboxing Java sandboxing Linux access control

IMA, Smack Offline protection with EVM and TrEE


How is the integrity of installed applications protected?

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

9. Access control policy


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


How does a resource declare the policy for accessing it?

How is it enforced?

10. Application data protection


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


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

35

Discussion


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)


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


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] Nokia Research Center 2011 38

http://aurora.q2s.ntnu.no/tsi

On-board Credentials architecture


TrEE Credential program

Credential program

OS

Credentials Manager

Interpreter

Application

Credential issuer

Credential issuer

Kostiainen, Asokan, Ekberg and Rantala. “On-board Credentials with Open Provisioning”. ASIACCS 2009.

Available for experimentation!

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.

old, new, borrowed, blue: a perspective on the evolution ...€¦ · reliability app. separation 2....

Documents