LAS16-203: Platform Security Architecture for embedded devices Mark Hambleton Senior Director Systems and Software Group Linaro Connect September 2016

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-cases Example market Example use-cases Mobile Identity, Payments, DRM IoT Device Management and Identity Enterprise/Server/Networking SW attestation and Secure Execution Automotive Safety Critical systems

ARM TrustZone® enables the ecosystem on A-class secure systems Here’s a reminder of the architecture Normal world code Trusted software Apps Trusted apps Payment DRM Global platform standardization EL1 EL2 Device drivers Secure device drivers Rich OS Trusted OS TrustZone-based TEE Key Hypervisor Trusted SW/HW ARM Trusted Firmware SMCCC PSCI Payload dispatcher Common foundation Ecosystem supplied Trusted boot Hardware Interfaces ARMv8A / Cortex-A SoC subsystem Graphics Video Crypto Secure store Physical IP Initial RoT & security subsystem

TrustZone is defined and supported by existing standards and reference implementations Normal world code Trusted software Apps Trusted Board Boot Requirements (TBBR) Defines a secure boot process to be compliant with GlobalPlatform TEE Protection Profile 1.2 EL1 EL2 Trusted Firmware (TF) Implements a trusted boot flow ARM Trusted Firmware SMCCC PSCI Payload dispatcher Trusted boot Trusted Base System Architecture (TBSA) Defines HW requirements for security functionality for TrustZone-based systems Hardware Interfaces ARMv8A / Cortex-A SoC subsystem Graphics Crypto Video Secure store Physical IP

ARMv8-M brings TrustZone to the microcontroller market Hardware Interfaces Normal world code Trusted software ARM Trusted Firmware Trusted boot Payload dispatcher SMCCC PSCI EL1 EL2 Secure device drivers Hypervisor Apps ARMv8A / Cortex-A SoC subsystem Graphics Video CryptoCell Secure storage Physical 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 Normal world code Trusted software Device drivers Unprivileged RTOS scheduler Platform code Secure Partitioning Manager Trusted libs Crypto Attestation TrustZone-based SPM Comms stack Apps/user TLS/Crypto libs Initial RoT & security subsystem CMSIS APIs Global platform standardization TrustZone-based TEE Similar, but different Common foundation Initial RoT & security subsystem ARMv8-A ARMv8-M

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. Trusted Base System Architecture for M-profile (TBSA-M) Defines HW requirements for security functionality for TrustZone-based systems ARMv8-M / Cortex-M Microcontroller TRNG Unique ID Crypto Secure storage Physical IP Hardware Interfaces

ARM will define a Platform Security Architecture (PSA) Ecosystem need PSA requirements Reduce cost and complexity for the SW development ecosystem by reducing API fragmentation Define a standard higher-level functional SW interface between the TrustZone® Secure and Non-Secure worlds Re-use of standard industry APIs Define a ‘sandbox’ security model Provide a reference implementation to demonstrate good practice (like the A-class Trusted Firmware did) Use the fundamental HW platform security functions that are specified in TBSA Reduce cost and complexity for SoC designers by guiding security use-case decomposition onto the building blocks defined by the TBSA (A and M) Reduce partner development cost

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 Disk Encryption Secure Storage EL0 App App App App TA TA GP TEE EL1 OS Kernel OS Kernel PSA I/F T OS Trusted Firmware Provisioned Key Store FW Update Discovery API EL2 Hypervisor Asymmetric Crypto Serv. Symmetric Crypto Serv. Trusted Boot code Monitor / Firmware EL3 Asymmetric Crypto Accl Symmetric Crypto Accl Device Lifecycle Counter / Fuse Logic TRNG (Entropy) Boot ROM Hardware

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

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 Linkage between PSA and the TEE?

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 ARM Cortex-M v8-M Microcontroller TRNG Unique ID CryptoCell Secure storage Physical IP Privileged Hardware Interfaces Normal world code Trusted software Unprivileged Platform code mbed uVisor mbed TLS (libmbedtls) mbed Crypto (libmbedcrypto) Crypto API mbed Crypto (libmbedcrypto)

Summary The Platform Security Architecture (PSA) will build on existing security standards and technology to make SW developers’ lives easier: It is intended to prevent future SW fragmentation It builds on existing standards 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