Beyond TrustZone PSA Rob Coombs Security Director Part1 - PSA Tech Seminars 2017
Agenda Platform Security Architecture Architecture overview Trusted Firmware-M IoT Threat models & security analyses Summary 2
Security cannot be optional Arm is announcing: The Platform Security Architecture (PSA) A framework for security for the smallest of connected devices Publically available holistic set of documents & specifications Trusted Firmware-M Open source reference firmware 3
Arm: The Industry s Architecture of Choice Extraordinary growth from sensors to server 50 billion chips shipped 50 billion chips shipped 2016 80% microcontrollers 100 billion chips expected to ship 4 years 22 years 4 years 1991 2013 2017 2021 4
Arm s growing investment in security Helping protect billions of devices 2000+ 2005+ 2010+ 2015+ Today Mbed, CryptoCell, Cortex-M33 TEE for Cortex-A TrustZone for Cortex-A SecurCore Smart Card for payment Apps processors gain TrustZone Enablement of premium content streaming & mobile payment PolarSSL & Sansa join Arm & TrustZone for Armv8-M Platform Security Architecture & Security enclave 5
Diversity is good but better with common ground rules A diverse collection of chips, device makers and services Needs a shared approach to security best practice OEM 1 OEM 2 OEM 3 6 SILICON PARTNER A SILICON PARTNER B SILICON PARTNER C SILICON PARTNER D
A framework to secure 1 trillion devices Announcing the Platform Security Architecture Analyse Threat models and security analyses PSA documents Architect Firmware architecture & hardware specifications Implement Source code & hardware IP Enabling products & contributions 7
Security is a shared responsibility Device SiPs Software Security Systems Cloud 8
Security starts with analysis Analysis leads to requirements System description Assets Threats Security Objectives Security Requirements Example Analyse Asset: metering data to be protected in integrity & confidentiality Threat: Remote SW attacks Security Objective: Strong Crypto Security Requirement: Hardware based key store Arm will deliver representative IoT device security analyses & requirements 9
Architecture incorporating common principles A recipe for building a secure system From analysis to architecture Identify key common principles Device identity Trusted boot sequence Secure over-the-air software update Certificate based authentication 10 Common principles across multiple use cases
PSA deliverables Security architecture derived from principles IoT Security analyses Wireless meter Asset tracker Connected camera Firmware specifications Firmware framework Secure update Boot sequence Hardware requirements 11 RNG Secure storage Crypto
Open source code to accelerate adoption Freely available reference implementation Trusted Firmware-M Reference firmware for the architecture specification Initially targeting Armv8-M In development now publically available first quarter 2018 Arm Mbed OS will provide an implementation of PSA Integrated with Mbed TLS and Mbed Cloud Client Targeting all Cortex-M processors Available in subsequent releases of Mbed OS 12
Platform Security Architecture Designed to secure low cost IoT devices where a full Trusted Execution Environment would not be appropriate. PSA protects sensitive assets (keys, credentials and firmware) by separating these from the application firmware and hardware. PSA defines a Secure Processing Environment (SPE) for this data, the code that manages it and its trusted hardware resources. PSA is architecture neutral and can be implemented on Cortex-M, Cortex-R & Cortex-A. The focus is Cortex-M based devices. Non-secure processing environment Application RTOS Platform hardware Secure processing environment Trusted Functions Secure partition manager Secure boot Root of Trust keys 13
PSA - Standardized Interfaces PSA specifies interfaces to decouple components. Enables reuse of components in other device platforms Reduces integration effort Partners can provide alternative implementations. Necessary to address different cost, footprint, regulatory or security needs PSA provides an architectural specification. Hardware, firmware and process requirements and interfaces Non-secure processing environment Application RTOS Secure IPC Platform hardware Secure processing environment Trusted Functions Secure partition API Secure partition manager Boot firmware Secure hardware requirements Root of Trust keys 14
Example IoT Device Implementation OEMs can choose their preferred implementations. Trusted Firmware-M will be a new OSS project. To reduce rework across our partners To speed up device or component validation against standards such as Common Criteria EAL Open to any RTOS and other partners. Non-secure processing environment Application Arm mbed OS Secure IPC Secure processing environment Device Management Secure partition API Arm Trusted Firmware v8-m TBSA-v8M Boot firmware Armv8-m based SoC Root of Trust keys 15
PSA Firmware Framework Concepts Secure Partition Manager (SPM) provides the boot, isolation and IPC services to the SPE Partition the unit of execution Secure function a set of related APIs invoked through secure IPC Trusted function a Secure Function that provides a Root of Trust service Non-secure Processing environment Non secure partition Application firmware OS libraries OS kernel Secure partition Secure function Secure function Secure Partition Manager Secure processing environment Secure partition Secure function Secure function Trusted partition Trusted function Trusted function Secure IPC Secure isolation Secure debug Isolation boundary 16
PSA Firmware Isolation Levels Level 2 Separate Root of Trust from Secure Partitions within SPE Level 1 Lower cost hardware only isolate the SPE Level 3 More robustness isolate all partitions from each other 17
Scaling IoT security From device to cloud 18
Key take-aways PSA provides security foundations for low cost IoT devices PSA makes security easier, quicker & cheaper to implement by providing: IoT Threat models & security analyses Architecture documents Source code: Trusted Firmware-M System IP, dev boards and tools Arm is helping our partners deliver security, deployable at scale Lead partner availability Now (NDA) General availability Q1 18 19
Thank You! Danke! Merci! 谢谢! ありがとう! Gracias! Kiitos! 20
Beyond TrustZone Security Enclaves Rob Coombs Security Director Part2 Security Enclaves Tech Seminars 2017
Agenda New security technology for IoT Security Enclaves CryptoIsland System IP for debug Dev boards & chips GlobalPlatform TEE OTA and RoT topics Summary 22
In a connected everything World What level of security robustness do you need? 23
Security is a balance Cost/effort to attack TrustZone based TEE/PSA Security enclave or subystem Secure Element SW & HW Attacks Physical access to device JTAG, Bus, IO Pins, Time, money & equipment TLS/SSL Communication Attacks Man In The Middle Weak RNG Code vulnerabilities Software Attacks & lightweight hardware attacks Buffer overflows Interrupts Malware Cost/effort to secure *Trusted Execution Environment / Secure Partitioning Manager 24
Beyond TrustZone - Security enclaves A programmable security enclave to extend fixed function CryptoCell family. TrustZone CryptoIslands - an additional family of security solutions by Arm. Aimed at providing on-die security services, in a physically isolated manner (host CPU agnostic). Axiom: less sharing of resources leads to smaller attack surface and fewer vulnerabilities. Certification, at a reasonable cost (i.e. reuse). Debug CoreSight SoC TrustZone Filters Flash Controller(s) Flash (internal / external) Host CPU Instruction cache interconnect System SRAM SRAM Cntl TrustZone filters CryptoIsland Isolating I/F Secure CPU Boot ROM Secure RAM Cryptography LCS Mgr Secure Always On Alarms Roots of Trust Debug control SoC Alwayson domain APB bridge APB peripherals Power Control 25
Example: PSA with CryptoIsland on Armv8-M CryptoIsland is providing services to the Trusted Partitions and/or implements some of these trusted functions. Arm v8-m: non-secure processing environment Arm v8-m: secure processing environment Non-secure processing Environment Secure processing environment (SPE) CryptoIsland security enclave 26
Example: PSA with CryptoIsland on Armv7-M The Secure Processing Environment (SPE) is in CryptoIsland. Arm v7-m: non-secure processing environment CryptoIsland security enclave 27
CryptoIsland-300: the first family member We are forming a 1st security enclave out of existing and mature HW components (CPU, CryptoCell, interconnect, filters, mailbox, power control ) The SW and tools is where a lot of the effort is going invested! Key point is preserve an identical touch and feel from the SW perspective, so the isolation/robustness choice explained earlier won t impact the higher layers. Allowing different implementations to be interchangeable Example target applications: LPWAN, Storage, Automotive, General purpose MCUs 28
New solution for authenticated debug access SDC-600 Hackers can abuse debug interfaces to gain access to the chip. Arm addressing this misuse by enabling debug authentication on our partners silicon. Alternative to blowing e-fuse on debug port. Socrates Debug Subsystem CoreSight SoC SoC Host CPU SDC-600 (Secure Debug Channel) enables certificate based authentication handshake with external agent. SDC-600 Secure Debug Channel Isolating I/F Secure CPU CryptoIsland Debug control Certificate Boot ROM Secure RAM Cryptography LCS Mgr Secure Always On Alarms Roots of Trust 29
The Secure Debug Manager knows how to do the crypto to generate an unlock certificate for CryptoCell or other unlock technology the target supports 30 Following certificate installation the APs are enabled, allowing external debug access
New dev board for PSA development - Musca-A1! Ready for PSA development Musca-A1 boards Cortex-M33 based dev board. Used for internal software development. Test chip built on PSA recommendations. Come to Arm booth to see Musca-A1! PSA development platform Prototype your system Available Q1 18 31
Musca-A1 PSA development platform Other Arm IP Secure Debug CoreSight SoC Cortex-M33 Instruction Cache IDAU Cortex-M33 Instruction Cache IDAU TrustZone Filters Local SRAM Always-on domain Power Control Arm CoreLink SDK-200 IP Cadence IP Other Multi-layer AHB5 interconnect AHB5 code interface TrustZone Filters SRAM Controller Code SRAM TrustZone Filters SRAM Cntl System SRAM TrustZone Filters TrustZone Cryptocell TrustZone Filters Cordio BLE / 802.15.4 (digital part) APB Bridge APB Peripherals CoreLink SSE-200 subsystem AHB5 interconnect APB Bridge QSPI GPIO PLL 32kHz oscillator 32MHz oscillator 32 khz 32 MHz Cordio BLE / 802.15.4 (RF part) RTC SPI I2S UART PWM I2C master Musca-A1 32
Agenda New security technology for IoT Security Enclaves CryptoIsland System IP for debug Dev boards & chips GlobalPlatform TEE OTA and RoT topics Summary 33
Arm TrustZone based TEE architecture A reminder of the architecture Normal world code Trusted software Apps EL1 EL2 Device drivers Rich OS Hypervisor Payment DRM Trusted_Apps Secure device drivers Trusted OS GlobalPlatform standardization TrustZone-based TEE Arm Trusted Firmware SMCCC PSCI Trusted Boot Payload Dispatcher Common foundation Key Trusted SW/HW Arm Cortex-A Hardware Interfaces SoC Subsystem Physical IP Graphics Video CryptoCell Secure store Initial ROT and security subsystem 34
GlobalPlatform & TEE GlobalPlatform is a Standards Defining Organisation: it is the home of TEE. OTA management of TEE is a market requirement Defines APIs and Trusted services Compliance program TEE Protection Profile Security certification program Over the Air TEE management Trusted Management Framework & Open Trust Protocol (PKI & JSON based) 35
A new capability standards based OTA TEE management OTrP* is being developed as an option in TMF & compatible with GlobalPlatform TEE System Architecture. Secure Code Image Dev Image Delivery Server TEE Device Main features: A specific PKI architecture and trust anchors TAM A high level (JSON-based) message protocol A REE Agent for communication with TAM/TSMs A set of mandatory services from the Boot TEE and Bootstrap Domain TEE Device Certificate Authority *Open Trust Protocol is being developed as an option for Trusted Management Framework 36
Root of Trust is the foundation for secure services TPM PC RoT = Trustworthy hardware & security functions Mobile & IoT TEE & / or Security subsystem / SE Cloud HSM A Root of Trust, is a hardware device and a runtime environment that provide a set of trusted functions from which an initial chain or trust can be derived. It is the trust anchor for the system 37
TrustZone based TEE + extended Root of Trust example Normal World IoT developer writes Apps on top of his/her chosen OS Secure World = Trusted code (Trusted OS/Libs) + Trusted Apps/functions + Trusted hardware 38 Security subsystem Reduced attack surface Protection from physical & side channel attacks Developed by security specialists
TrustZone based TEE + security subsystem option An additional security layer Applications Arm TrustZone based TEE for trusted functions RoT mgmt Rollback protection SW updates validation RNG Execution environment isolation Lifecycle management Data protection (off-line, runtime) SW validation & decryption Debug authentication Secure manufacturing Cryptography Persistent trusted storage Security subsystem e.g. Arm CryptoCell for RoT services TrustZone family of security IPs provides protection from physical & SW attacks 39
Summary
Key take-aways Arm has launched CryptoIsland - a new family of Security enclaves by Arm Provides a robust Root of Trust with some programmability Creates another layer of hardware security beyond TrustZone Arm has launched SDC-600 for certificate based control of debug The TrustZone based TEE for Cortex-A is gaining a simple OTA management protocol OTrP provides a PKI based trust architecture and high level JSON protocol Arm is making robust security easier, quicker and cheaper to implement! 41
Thank You! Danke! Merci! 谢谢! ありがとう! Gracias! Kiitos! 42
The Arm trademarks featured in this presentation are registered trademarks or trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. www.arm.com/company/policies/trademarks 43