LAS16-203: Platform security architecture for embedded devices
Download as PPTX, PDF2 likes2,352 views
The document discusses the Platform Security Architecture (PSA) developed by ARM to standardize security functions for embedded devices. It outlines how PSA aims to reduce software fragmentation and guide security use-case decomposition while leveraging existing standards and creating a sandbox security model. The initiative also includes a discovery mechanism for secure APIs to streamline development for both software and hardware designers.
LAS16-203: Platform security architecture for embedded devices
- 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