Upload
linaro
View
340
Download
6
Embed Size (px)
Citation preview
© 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
Normal world code Trusted software
ARMTrustedFirmware Trusted boot
Payload dispatcherSMCCC PSCI
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
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
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
Normal world code Trusted software
Device drivers
Unprivileged
RTOS scheduler
Platform code
Secure Partitioning Manager
Trustedlibs
Crypto
Attestation
TrustZone-basedSPM
Comms stack
Apps/user TLS/Crypto libs
Initial RoT & security
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
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)
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