New Approaches to Connected Device Security

Size: px

Start display at page:

Download "New Approaches to Connected Device Security"

Rosalyn Ellis
6 years ago
Views:

1 New Approaches to Connected Device Security Erik Jacobson Architecture Marketing Director Arm Arm Techcon 2017

2 - If you connect it to the Internet, someone will try to hack it. - If what you put on the Internet has value, someone will invest time and effort to steal it. Brian Krebs January

3 Agenda Securing IoT devices Introducing the Platform Security Architecture (PSA) The PSA Firmware Framework Trusted Firmware-M Summary 3

4 Securing IoT Devices Securing IoT devices

5 A diversity of device types OEM 1 OEM 2 OEM 3 SILICON PARTNER A SILICON PARTNER B SILICON PARTNER C SILICON PARTNER D 5

6 A diversity of device types needs common ground-rules OEM 1 OEM 2 OEM 3 SILICON PARTNER A SILICON PARTNER B SILICON PARTNER C SILICON PARTNER D 6

7 Security needs to be designed-in However, threat modelling and security analysis is often lacking Analyse Architect Need to avoid the illusion of security by just using components that we think makes a system more secure. Implement 7

Diverse implementations of each component.

8 The integration challenge Thousands of IoT device designs. Integrating components from multiple vendors. Diverse implementations of each component. Each device is a unique integration challenge. Integration work may not be reusable for other devices OEM Platform System on Chip Application RTOS Security firmware Device Management 8

9 The deployment challenge Connected devices require secure communication over insecure links. Cryptography and secret keys are required Software has bugs. Some are vulnerabilities that can be exploited to get secrets. Unpatchable software presumes no exploitable defects Connected devices must be in-field updatable Connected, secure, in-field updatable systems have high software complexity. High risk of remotely exploitable vulnerabilities that can expose the secret keys 9

10 The commercial challenge Designing-in and implementing best practice security is: Difficult + Expensive -> Often not addressed properly Or security features are implemented as a retro-fit 10

11 We need a process and enablers To help companies on tight timescales & budgets to build more secure systems Analyse Threat models and security analyses Architect Firmware & hardware architecture specifications Implement Source code & hardware IP 11

12 Introducing the Platform Security Architecture (PSA) Introducing the Platform Security Architecture

Introducing Platform Security Architecture (PSA)

analysis to implementation Analyse Threat models

Firmware & hardware architecture specifications

13 Introducing Platform Security Architecture (PSA) A recipe for building more secure systems from analysis to implementation Analyse Threat models and security analyses PSA documents Architect Firmware & hardware architecture specifications Implement Source code Enabling products & contributions 13

14 PSA will consist of three parts Platform Security Architecture Hardware system architecture Inform Threat Models and Security Threat Models and Security Threat Analyses Analyses Models and Security Analyses Trusted device initialization Asses Device Security Model Trusted boot & firmware update Implementation Implementation Implementation Firmware framework Specify Trusted functions 14

key store English-language Protection Profiles Example Asset: metering data to be protected in

15 Security starts with analysis System description 15 Assets Threats Threat: Remote SW attacks Security Objectives Security Objective: Strong Crypto Security Requirements Security Requirement: Hardware based key store English-language Protection Profiles Example Asset: metering data to be protected in integrity & confidentiality Arm will publish representative IoT device Threat Models and Security Analyses. Analyse

16 PSA architecture specifications A growing suite of specification documents Device Security Model (DSM). Overall security architecture for designing and deploying devices within ecosystems Device lifecycle and its implications on roots of trust Root of trust and associated security services Root secrets their storage, protection, and provisioning Hardware system architecture. SoC hardware requirements (TBSA-M) Trusted device initialization. Factory initialization process for firmware and cryptographic Roots of Trust Trusted boot and firmware update. Firmware integrity requirements Firmware Framework (PSA-FF). Secure Processing Environment architecture and API specification Trusted functions APIs for Root of Trust services, e.g. Attestation Data sealing Cryptographic operations Creation of device identity certificates 16

17 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

18 Security by separation / isolation PSA protects sensitive assets (keys, credentials and firmware) by separating these from the application firmware and hardware. Non-secure processing environment Secure processing environment PSA defines a Secure Processing Environment (SPE) for this data, the code that manages it and its trusted hardware resources. Application Device management The application firmware runs in the Non-secure Processing Environment (NSPE). RTOS Secure partition manager Secure boot PSA requires a secure boot process so only authentic, trusted firmware runs in the SPE. PSA depends on secure installation of the initial keys and firmware during manufacture. Platform hardware Root of Trust keys 18

19 Standardize 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 Device management Secure partition API Secure partition manager Boot firmware Secure hardware requirements Root of Trust keys 19

20 An example IoT device implementation PSA is agnostic across architecture, RTOS, trusted firmware, etc. OEMs can choose their preferred implementations/ Shown in this example: SoC using Armv8-M (e.g. Cortex-M33) Reference OSS partition manager Arm Mbed components APIs are equally open to other RTOSes. Non-secure processing environment Application Arm mbed OS Secure IPC Arm v8-m based SoC Secure processing environment Arm mbed Client Secure partition API Arm Trusted Firmware v8-m TBSA-v8M Boot firmware Root of Trust keys 20

21 The PSA Firmware Framework (PSA-FF)

22 PSA Firmware Framework (PSA-FF) concepts Non-secure Processing environment Secure processing environment Secure Partition Manager (SPM) Provides the boot, isolation and IPC services to the SPE Partition The unit of execution Secure function Non secure partition Application firmware Secure partition Secure function Secure function Secure partition Secure function Secure function Trusted partition Trusted function Trusted function A set of related APIs invoked through secure IPC Trusted function A Secure Function that provides a Root of Trust service OS libraries OS kernel Secure Partition Manager Secure IPC Secure isolation Secure debug Isolation boundary 22

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

24 Secure Partition Programming Model The SPE defines a standard programming model for Secure Partitions. Secure Partitions are declared using a manifest. Partition identity Resource requirements Implemented Secure Functions All Secure Partitions are created when the device boots. Each Secure Partition has a single non re-entrant thread of execution. Secure Partitions use a small runtime API to the SPM. IPC server and client Device access Memory allocation 24

25 Secure IPC IPC design principles Secure by design no shared memory buffers Enable efficient implementation for simple platforms Easy to develop secure services on top Channel-based client/server IPC Partition (client) IPC library Channel handle Secure IPC framework Channel Message Channel handle Secure Partition (server) Secure Function The server is a Secure Function in a Secure Partition The client might be a Secure Partition or a task in the Nonsecure Partition Send message Port Port handle Requests are made on a connected channel and synchronous for the client. Event queue Secure Functions can use the client identity to implement access control. 25

PSA In Action TLS Session Setup Example Non-secure partition Secure partition Secure partition Trusted partition Application Key store Data sealing Application network TLS library TLS

26 PSA In Action TLS Session Setup Example Non-secure partition Secure partition Secure partition Trusted partition Application Key store Data sealing Application network TLS library TLS secure function Crypto operations Network protocol Secure partition manager Secure IPC TLS session setup PSA IPC PSA h/w access Platform hardware Cryptographic acceleration Root of Trust keys 26

27 A reference OSS implementation: Trusted Firmware-M

28 Trusted Firmware-M Open source reference implementation Overview Reference firmware for the architecture specification Initially targeting Armv8-M In development now publically available first quarter 2018 Similar to existing Trusted Firmware project (-A) Details Constrained runtime isolation level 1 implementation Initial target SSE-200 (Arm Musca-A1 testchip board) OS support Mbed OS is the main target in first release RTX is being used for prototyping work and will be released with limited support 28

29 PSA is architecture agnostic but we have prioritised M-profile Specifications available today Hardware requirements (TBSA) Firmware framework (PSA-FF) Platform Security Architecture TBSA v8m In development Device Security Model (DSM) Device initialization Boot and firmware update Trusted Function APIs Device Security Model Trusted device initialization Trusted boot & firmware update Firmware Framework - M Trusted Functions 29

30 Summary Summary

31 Summary PSA is a recipe to consistently design-in the right level of security into connected devices. It consists of three parts: 1. Threat Models and Security Analyses 2. HW & FW architecture specifications 3. A reference OSS implementation (public Q1 2018) First specifications available now (under NDA, public in Q1 2018). More published through-out 2018 Trusted Firmware-M OSS code public in Q PSA: Shifting the economics of security Security.economics << 1; 31

32 Thank You! Danke! Merci! 谢谢! [Additional ありがとう Material]! Gracias! Kiitos! 32

33 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 Arm Limited

Beyond TrustZone PSA Reed Hinkel Senior Manager Embedded Security Market Development

Beyond TrustZone PSA Reed Hinkel Senior Manager Embedded Security Market Development Part1 - PSA Tech Seminars 2017 Agenda Platform Security Architecture Architecture overview Trusted Firmware-M IoT Threat