1. LAS16-203: Platform Security Architecture for embedded devices
Mark Hambleton
Senior Director
Systems and Software Group
Linaro Connect
September 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-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

3. 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

4. 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

5. 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

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.
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

7. 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

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
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

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

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

11. 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)

12. 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