Mobile Platform Security -- and emerging standards –

Nokia, Jan-Erik Ekberg 15.4. 2013

RoT for Storage

RoT for Verification

RoT for Measurement

RoT for Reporting

RoT for Integrity

Protected Storage

Isolation Device Integrity

Roots of Trust

Security Capabilities

Operating System

App

App

App App

Picture: Andrew Regenshield: NIST/Computer Security Division

Secure Device Capabilities are built from ”Roots-of-Trust”

Special Publication 800-164: Guidelines on HW rooted security in Mobile Devices

RoT are required (HW) security functions – misbehaviour cannot be detected

Roots of Trust

trust root identity

secure boot

Validate, then execute

- Secure boot is the conditional execution of further components, based on a validation based on a trust root and possibly a cryptographic mechanism.

- The boot sequence must unconditionally reach the validation step - The validation process / calculation must be trustworthy The collective of software booted by (recursive) application of secure boot can be called the trusted computing base.

cryptographic mechanism Booting starts at a trusted place

Boot (ROM) vector

Security enablers in the chip(set) 1/2

trust root identity

secure boot

The addition of a non-volatile device secret in the TEE domain, makes it possible to construct TEE code to - Securely store (secret) information outside the PSE and recover it e.g. during secure

boot or when needed by other TEE code - Perform services such as DRM or SIMLock In principle there can also be shared keys in the TEE. In that case device-specific secrets (encrypted blobs) can be bound to the device by including the device identity in them

cryptographic mechanism

Boot (ROM) vector

PSE

API register(s)

device secret

code

Security enablers in the chip(set) 2/2

References:

• ARM Security Technology: Building a Secure System using TrustZone® Technology (Whitepaper)

• ARM® Architecture Reference Manual: ARMv7-A and ARMv7-R edition

• CoreLink TrustZone Address Space Controller TZC-380 r0p1 Some pictures are from the above, non-confidential, but copyrighted material by ARM

ARM TrustZone ... is an existing hardware PSE ... is included in many / most mobile phone SoCs ... is a good example of how a few, selected HW primitives can boostrap a whole security architecture

PSE implementation

Isolation

ARM TrustZone + Secure Boot + Secrets ... is alone almost enough to fulfill the Roots of Trust:

1. Secure boot provides verification Root of Trust for Verification 2. The measuring function of secure boot is the Root of Trust for Measurement, you can trust that it works correctly 3. A device key + code in TZ Root of Trust for Reporting 4. What we report is Root of Trust for Integrity, we can keep them in SoC RAM between the time of measurement and time of reporting 5. We do have most of Root of Trust for Storage: We can shield off secrets in ROM, we can use such keys in the TZ to encrypt and store on flash. Rollback protection must be arranged separately.

Integrity Storage

Trusted Execution Environment (TEE)

Isolation boundary TEE

Trusted Operating System

Secure Storage Crypto I/O

NFC / UI

RPC

TEE Internal API v.1.0

Trusted Application

“Rich Execution Environment”

OS

TEE Client API v.1.0

“Normal” Application

Global Platform Device Architecture - An API to communicate with the TEE (shared memory-based) application and an UUID-based identification / session control for this access - A standard system interface library (libc ..) for trusted applications with RPC, crypto and necessary I/O functions

Eventually, these APIs may become the reference model for writing code for and interacting with a TEE. Missing pieces still include provisioning and compliance aspects

TEE standards

12

Legacy TEE OnBoard Credentials (ObC) – architecture for 3rd party TEE use

- TEE based on an isolating interpreter inside ARM TrustZone

- A Nokia-proprietary solution ( 100 mil. deployed devices 2012)

- Supports “open provisioning” for credential programs and secrets. i.e. “anybody can provision”

- Trusted applications are written in BASIC

- ported to 5 processor families from 3 chipset vendors with ARM TZ

- Interfaces available for 4 OSs (also Nokia Windows 8 phones)

- “survives” on 7.5 kB of secure TEE memory excluding crypto and signed loading support

13

TEE Use Cases

Public Transport Ticketing - 110 traveler trial in New York,

summer 2012. - Mobile ticketing / small value

mobile payment with NFC & TEE seems promising

Recent Nokia R&D TEE experiences

Car Head Unit Enforcement of driver distraction rules - Standard requires audited attestation function with TPM interfaces - Such a system could be efficiently and securely implemented based on TEE functionality

TEE interfaces relevant to users and applications

TPM Mobile: A TPM profile for Mobile Devices. Adds mechanisms for 1) Adaptation to TEEs:

New RoT definitions and requirements for TEE adaptation

2) Certified boot: Secure boot with TCG authorizations that leaves a PCR trace for binding and attestation

3) Multi-stakeholder model: - Platform- and Application TPMs co-exist in the TEE - Application TPMs can have an associated TEE secure application and an associated rich environment application - support for TEE application attestation and provisioning

TCG Trusted Platform Module (TPM) ... is an application(OS) interface to secure services ... For key generation, use, platform binding, attestation, secure storage ... is deployed to hundreds of millions of PCs and laptops (v1.2. chip + drivers) ... Possibly the way applications and OS services will interact with platform security

Chipset ROM

Nokia Lumia Secure Boot Flow

Primary Boot Loader

eMMC

TrustZone HW

eFuses

Trusted OS

UEFI

OS kernel

OS binary

Secondary boot loaders

UEFI

OS

OS binary

OS binary

1. Transitive trust chain begins (Platform RoT is in eFuse)

2. Trusted OS integrity is verified

3. Trusted OS verifies UEFI

Replay protected memory block

5. UEFI verifies OS boot manager using certificates from RPMB (Replay Protected Memory Block)

6. UEFI Boot Manager verifies OS kernel

7. OS kernel verifies OS binaries

TrustZone SW core

TrustZone HW TPM = Trusted Platform Module, TrustZone protected secure execution area with one time programmable memory (eFuses) TrustZone SW core = image providing core functionality for TrustZone usage, for example image signature verification eMMC = embedded MultiMediaCard UEFI = Unified Extensible Firmware Interface TPM app = Application running in Trusted OS providing the TPM service API for higher layers

TPM app

Platform Root Of Trust

TPM

UEFI certificates

4. UEFI loads TPM app into Trusted OS TPM provides services

for kernel boot

Architecture example presented at RSA conf. 2013

- Platform security fundaments converge around a well-defined(?) set of trust roots - A TEE is likely part of the future computing architectures - Standardization is taking place to achieve conformance across interfaces and functionality Open or partially open problems for TEEs:

- TEE application lifecycle, provisioning, certification - Programming interface - Evolution of technical fundaments:

Multi-processing. Non-volatile mass memory. Side-channel attack prevention.

Conclusions

Isolation Integrity Storage

Trusted Execution Environments (TEE)

RoT

Well-defined security functions

Thank you! Questions ?