platform security architecture for embedded devices

© ARM 2016

LAS16-203:Platform Security Architecture for embedded devices

Linaro ConnectSeptember 2016

Mark HambletonSenior DirectorSystems and Software Group

© ARM 2016 2

Secure systems are being deployed everywhere Secure systems can already be found in diverse industries and markets,

although no security implementation can be perfect These secure systems provide mechanisms such as authentication, integrity

checking, and confidentiality to protect assets across multiple use-casesExample market Example use-casesMobile Identity, Payments, DRMIoT Device Management and IdentityEnterprise/Server/Networking

SW attestation and Secure Execution

Automotive Safety Critical systems

© ARM 2016 3

ARM TrustZone® enables the ecosystem on A-class secure systems

Global platformstandardization

Initial RoT & security

subsystem

TrustZone-basedTEE

Common foundation

Hardware Interfaces

Normal world code Trusted software

ARMTrustedFirmware Trusted boot

Payload dispatcherSMCCC PSCI

EL1

EL2

Secure device drivers

Hypervisor

Apps

ARMv8A / Cortex-A

SoCsubsystem

GraphicsVideo

CryptoSecure store

Physical IP

Trusted appsPayment

DRM

Rich OSDevice drivers

Trusted OS

Here’s a reminder of the architecture

Ecosystem

supplied

Trusted SW/HW

Key

© ARM 2016 4

TrustZone is defined and supported by existing standards and reference implementations

Hardware Interfaces




EL1

EL2

Apps

ARMv8A / Cortex-A

SoCsubsystem

Graphics

VideoCryptoSecure store

Physical IP

Trusted Board Boot Requirements (TBBR)

Defines a secure boot process to be compliant with GlobalPlatform TEE Protection Profile 1.2

Trusted Firmware (TF)Implements a trusted boot flow Trusted Base System

Architecture (TBSA)

Defines HW requirements for security functionality for TrustZone-based systems

© ARM 2016 5

ARMv8-M brings TrustZone to the microcontroller market

Global platformstandardization


subsystem

TrustZone-basedTEE

Common foundation

Hardware Interfaces




EL1

EL2

Secure device drivers

Hypervisor

Apps

ARMv8A / Cortex-A

SoCsubsystem

Graphics

Video

CryptoCell

Secure storagePhysical IP

Trusted apps

Payment

DRM

Rich OS

Device drivers

Trusted OS

ARMv8M / Cortex-M

Microcontroller

TRNG

Unique ID

CryptoCell

Secure storage

Physical IP

Privileged

Hardware Interfaces


Device drivers

Unprivileged

RTOS scheduler

Platform code

Secure Partitioning Manager

Trustedlibs

Crypto

Attestation

TrustZone-basedSPM

Comms stack

Apps/user TLS/Crypto libs


subsystem

CMSIS APIs

ARMv8-A ARMv8-M

© ARM 2016 6

We are defining TBSA for M-profile for SoC designers The Trusted Base System Architecture for M-profile (TBSA-M)

follows in the spirit of TBSA for A-profile TBSA-M will specify HW requirements for secure M-profile

based systems NVM, Cryptographic Keys, Trusted Boot, Trusted Timers, True Random

Number Generator (TRNG), Cryptographic Acceleration, etc.

ARMv8-M / Cortex-M

Microcontroller

TRNGUnique

ID

CryptoSecure storage

Physical IP

Hardware Interfaces

Trusted Base System Architecture for M-profile (TBSA-M)

Defines HW requirements for security functionality for TrustZone-based systems

© ARM 2016 7

ARM will define a Platform Security Architecture (PSA)Ecosystem need PSA requirementsReduce cost and complexity for the SW development ecosystem by reducing API fragmentation

Reduce cost and complexity for SoC designers by guiding security use-case decomposition onto the building blocks defined by the TBSA (A and M)

1. Define a standard higher-level functional SW interface between the TrustZone® Secure and Non-Secure worlds

2. Re-use of standard industry APIs3. Define a ‘sandbox’ security model4. Provide a reference implementation

to demonstrate good practice (like the A-class Trusted Firmware did)

5. Use the fundamental HW platform security functions that are specified in TBSA

Reduce partner

development cost

© ARM 2016 8

PSA will provide an interface to the functional building blocks of a secure system Providing access to existing industry standard APIs New functional-level APIs for Non-Secure code to call Discovery mechanism to describe functionality of the platform

Non-Secure Secure

OS Kernel

EL3 Monitor / Firmware

AppApp

T OS

TA TA

EL1

EL2 Hypervisor

OS Kernel

EL0 AppApp

Hardware

Symmetric

Crypto Accl

Asymmetric

Crypto Accl

TRNG(Entropy)

Counter / Fuse Logic

DeviceLifecycle

Boot ROM

TrustedBoot code

TrustedFirmware

DiscoveryAPI

Provisioned

Key Store

FWUpdate

Asymmetric

Crypto Serv.

Symmetric

Crypto Serv.

SecureStorage

GP TEE

Disk Encryption

PSA I/

F

© ARM 2016 9

A sandbox security model will allow mutually untrusted functions The Platform Security Architecture will use a ‘sandbox’ security

model Each security function can be placed in its own hardware

enforced partition Reducing the trusted compute base for each function Allowing functions to be mutually untrusting, to ease multiple

vendor sourcing

We generically refer to this functionality as the ‘Secure Partition Manager’

In mbed OS this is implemented by the uvisor On A-profile devices this could be implemented by a TEE

© ARM 2016 10

A discovery mechanism will enable re-use of existing secure APIs PSA will not replace or redefine existing secure interfaces

It is an interface to describe them It is envisioned that the secure discovery mechanism will:

Enable the uniform discovery of platform security functions, describing capabilities and access parameters

Provide a framework to add new functions in the future We expect that there will be segment-specific higher-level PSA

profiles built on a common API

© ARM 2016 11

ARM Cortex-Mv8-M Microcontroller

TRNG

Unique ID

CryptoCell

Secure storage

Physical IP

Privileged

Hardware Interfaces


Unprivileged

Platform code

mbed uVisor

PSA illustrated with mbed TLS in mbed OS mbed OS is prototyping PSA to reduce the

attack surface for secure components

mbed TLS library in mbed OS is currently in the Non-Secure world

In order to reduce the attack surface, we can now use PSA and split it into a critical and exposed part: Authentication and encryption keys are protected

against malware Malware can’t interfere without knowing the

encryption or signing keys

mbed Crypto

(libmbedcrypto)

Crypto APImbed TLS

(libmbedtls)mbed Crypto

(libmbedcrypto)

© ARM 2016 12

SummaryThe Platform Security Architecture (PSA) will build on existing security standards and technology to make SW developers’ lives easier:1. It is intended to prevent future SW fragmentation2. It builds on existing standards3. It will be proven by a reference implementation

Why are we telling you this now? As a heads-up that it’s coming To get your early feedback To help us all align on a common solution

Contact: Andrew Thoelke, Systems Architect

The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners.Copyright © 2016 ARM Limited

© ARM 2016

The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners.Copyright © 2016 ARM Limited

platform security architecture for embedded devices

Documents