mobile platform security -- and emerging standards –
TRANSCRIPT
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