LAS16-203: Platform security architecture for embedded devices Speakers: Mark Hambleton Date: September 27, 2016 ★ Session Description ★ Heads up on what ARM are doing with the new ARMv8-M architecture from a software perspective. ★ Resources ★ Etherpad: pad.linaro.org/p/las16-203 Presentations & Videos: http://connect.linaro.org/resource/las16/las16-203/ ★ Event Details ★ Linaro Connect Las Vegas 2016 – #LAS16 September 26-30, 2016 http://www.linaro.org http://connect.linaro.org

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

2. ©ARM 20162
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/Networkin
g
SW attestation and Secure Execution
Automotive Safety Critical systems

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

4. ©ARM 20164
TrustZone is defined and supported by existing standards and
reference implementations
Hardware
Interfaces
Normal world code Trusted software
ARM
Trusted
Firmware
Trusted boot
Payload dispatcherSMCCC PSCI
EL1
EL2
Apps
ARMv8A /
Cortex-A
SoC
subsystem
Graphics
Video
Crypto
Secure 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

5. ©ARM 20165
ARMv8-M brings TrustZone to the microcontroller market
Global platform
standardization
Initial RoT &
security subsystem
TrustZone-based
TEE
Common foundation
Hardware Interfaces
Normal world code Trusted software
ARM
Trusted
Firmware Trusted boot
Payload dispatcherSMCCC 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
ARMv8-A ARMv8-M

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

7. ©ARM 20167
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
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 APIs
3. Define a ‘sandbox’ security model
4. 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

8. ©ARM 20168
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
Device
Lifecycle
Boot ROM
Trusted
Boot code
Trusted
Firmware
Discovery
API
Provisioned
Key Store
FW
Update
Asymmetric
Crypto
Serv.
Symmetric
Crypto
Serv.
Secure
Storage
GP TEE
Disk
Encryption
PSAI/F

9. ©ARM 20169
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. ©ARM 201610
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

11. ©ARM 201611
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
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
)
CryptoAPI
mbed TLS
(libmbedtls)
mbed Crypto
(libmbedcrypto
)

12. ©ARM 201612
Summary
The 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 fragmentation
2. It builds on existing standards
3. 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

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