Demystifying Security Root of Trust Io T Device

Agenda • The Landscape • Problem Statement • What’s Ro. T? • Ro. T

Connected Io. T Devices – Everywhere Security camera 3 © 2017 Arm Limited And

Robustness Against Malicious Attacks § The three fundamental elements of security § Confidentiality §

Security: Threats, Attacks and Defenses Communication Attacks Threat Focus: Hardware enforced Defences: Man In

Hardware Enforced Root of Trust (Ro. T) © 2017 Arm Limited

Generic Io. T Security Requirements Automotive • Unique device identity provisioning • Secure boot

Initial Root of Trust & Chain of Trust Apps OS/RTOS Trusted Software Trust. Zone

Basic Security Requirement – Root of Trust § Embedded Boot ROM with the initial

Secure Boot – Assured Software Integrity FLOW: § Chain of trust starts with initial

Primer - Trusted Platform Module (TPM) Overview § Standard defined by the Trusted Computing

Measured Boot – Software Integrity Measurement FLOW: § § Chain of trust starts with

Secure vs. Measured Boot – Same End Goal Attribute Software Integrity Static Root of

Diverse Io. T Endpoints – No One Size HW Ro. T Fits All Wide

Ro. T – Myriad of Options Higher Cost Enhanced App CPU + standard SE

What’s New? – Trust. Zone Extended to MCU-Family Increased Root of Trust Robustness trusted

Beyond Ro. T – Basis for Secure/Protected Partitions 20 Ro. T No Explicit Secure

Security by Separation § Protect sensitive assets (keys, credentials and firmware) by separation from

Cortex-M 33: Security for Diverse Io. T Usages 32 -bit processor of choice §

Cortex-M 23: Security for Ultra Low-Power Io. T Smallest area, lowest power Security foundation

Example Ro. T Models – ARM So. C Solutions Ro. T - SE §

Take Away – Executive Summary § Hardware Ro. T is a fundamental requirement for

Slides: 28

Download presentation

Security: Threats, Attacks and Defenses Communication Attacks Threat Focus: Hardware enforced Defences: Man In The Middle § Weak RNG § Code vulnerabilities § Physical Attacks Fault injection: clock or power glitch, alpha ray § Side channel analysis § Probing, FIB § • Scalable Software Attacks Defences • Low Cost Hardware tampering • Economically Viable Attacks Software Attacks Life Cycle Attacks Code downgrade § Integrity vulnerabilities § Factory Oversupply § 6 © 2017 Arm Limited Buffer overflows § Interrupts § Malware §

Generic Io. T Security Requirements Automotive • Unique device identity provisioning • Secure boot • FOTA update • Secure debug • IP config/feature provisioning • IP protection/secure firmware validation • Data integrity • IP protection and anti-counterfeiting • Right to repair • User data confidentiality • DRM 8 © 2017 Arm Limited ? Healthcare Industrial Wearables Home • Unique device identity provisioning • Secure boot • FOTA update • Secure debug • Secure HW key storage • IP protection and anti -counterfeiting • IP config/feature provisioning • Data integrity • Data Privacy (HIPPA) • Functional safety (actuators) • Unique device identity provisioning • Secure boot • FOTA update • Secure debug • Facility ops • Secure video monitoring • Telematics/fleet management • Data Integrity • IP protection and anti-counterfeiting • IP config/feature provisioning • Functional safety • Unique device identity provisioning • Secure boot • FOTA update • Secure debug • User data confidentiality • Data integrity • IP protection and anti-counterfeiting • Unique device identity provisioning • Secure boot • FOTA update • Secure debug • Privacy and data confidentiality • Data integrity • IP protection and anti-counterfeiting • IP config/feature provisioning

Initial Root of Trust & Chain of Trust Apps OS/RTOS Trusted Software Trust. Zone Extended Root of Trust i. ROT Trust. Zone Crypto. Cell Keys 9 © 2017 Arm Limited RTOS Trusted Apps/Libs Extended Root of Trust e. g. Trust. Zone based TEE Initial Root of Trust: Dependable Security functions Provisioned keys/certs

Basic Security Requirement – Root of Trust § Embedded Boot ROM with the initial code needed to perform a Secure system boot in a secure environment – Initial boot block (aka IBB) § IBB executed by a trusted hardware engine by design § Execution environment fully contained to prevent altering of the boot flow § Crux of the Problem - One size does not fit all… 10 • Different market segments with various constraints: Cost, Power, Latency, Performance, etc. • Io. T end point device constraints dictate the packaged solution © 2017 Arm Limited

Secure Boot – Assured Software Integrity FLOW: § Chain of trust starts with initial boot block (IBB) that is immutable § IBB is a trusted entity owned by Si Vendor and/or OEM § All software images beyond IBB are digitally signed § X. 509 certificate is industry standard based on PKI (RSA or ECC) § IBB hash-verifies the first image that is loaded § Each subsequent image is hash verified by the prior to establish a chain of trust 11 © 2017 Arm Limited

Primer - Trusted Platform Module (TPM) Overview § Standard defined by the Trusted Computing Group § Availability § Hardware chip currently in 100+M laptops § HP, Dell, Sony, Lenovo, Toshiba, … § HP alone ships 1 M TPM-enabled laptops each month § Core functionality § Secure storage § Platform integrity reporting context for this discussion…. § Platform authentication 12 © 2017 Arm Limited

Measured Boot – Software Integrity Measurement FLOW: § § Chain of trust starts with IBB that is immutable All software images beyond IBB is dynamically measured at boot time § § 13 SHA-1 or SHA-2 Computation/Measurement recorded in TPM PCR Each subsequent image is measured to produce a combined hash chain value Changes in the executing code can be detected by comparing measurement of executing code against golden recorded value The measurements themselves must be protected from undetected manipulation © 2017 Arm Limited

Secure vs. Measured Boot – Same End Goal Attribute Software Integrity Static Root of Trust for measurement Secure Boot Assured Applies Digitally Signed Software/Firmware Images HW Ro. T in So. C Core Root of Trust Yes In TPM Required 14 © 2017 Arm Limited o i at m r Required o f l a n Immutable boot code in ROM No Measured Boot Assured Applies No Required Immutable boot code in ROM Yes

Diverse Io. T Endpoints – No One Size HW Ro. T Fits All Wide Applications Constrained Applications Secure Ultra efficient Within Io. T Device – Diverse Function Endpoints Diverse Security Requirements Smart lock Safe Medical Nanorobot 16 © 2017 Arm Limited Smart bandage Ubiquitous Asset tracking

Ro. T – Myriad of Options Higher Cost Enhanced App CPU + standard SE Ro. T Enhanced App CPU + Enhanced SE Ro. T Trust. Zone PE + Trust. Zone SE (4) TZ PE + Non- Trust. Zone SE (3) Security Enclave Ro. T Standard Ro. T Non- Trust. Zone PE + Trust. Zone SE (3) No Explicit Ro. T Non- Trust. Zone PE + Non- Trust. Zone SE (2) Single PE with Trust. Zone (2) PE, No SE or Trust. Zone (1)** Lower Cost Less Robust ** Hardware state-machine or CPU microcode extensions 17 (x) no. layers of security © 2017 Arm Limited More Robust Key Options • No Explicit Ro. T • Trust. Zone Ro. T • SE w/ Trust. Zone Ro. T

What’s New? – Trust. Zone Extended to MCU-Family Increased Root of Trust Robustness trusted software trusted hardware secure system crypto secure storage TRNG § Confidentiality of Si. P SW IP trusted drivers trusted hardware 18 © 2017 Arm Limited trusted drivers trusted hardware non-trusted § Confidentiality of 3 rd parties SW IP valuable firmware § Sandboxing certified OS / functionality trusted drivers trusted hardware Motivation – Address Io. T Device Robustness Requirement

Beyond Ro. T – Basis for Secure/Protected Partitions 20 Ro. T No Explicit Secure Partition Isolation Dependency Memory Management MPU and MMU Hypervisor Trust. Zone Hardware Enforced Secure and Non-Secure Worlds with multiple protected partitions Security Enclave (SE) Trust. Zone PE and Security Enclave with Trust. Zone Secure Container with Secure Monitor or RTOS Two mechanism co-exist, more flexibility, more complexity Highest level of robustness with multiple secure partitions © 2017 Arm Limited

Security by Separation § Protect sensitive assets (keys, credentials and firmware) by separation from the application firmware and hardware § Define a Secure Processing Environment (SPE) for this data, the code that manages it and its trusted hardware resources § The Non-secure Processing Environment (NSPE) runs the application firmware § Use a secure boot process so only authentic trusted firmware runs in the SPE § Install the initial keys and firmware securely during manufacture 21 © 2017 Arm Limited

Cortex-M 33: Security for Diverse Io. T Usages 32 -bit processor of choice § Optimal balance between performance and power § 20% greater performance than Cortex-M 4 § With Trust. Zone, same energy efficiency as Cortex-M 4 Digital signal control § Bring DSP to all developers § FPU offering up to 10 x performance over software Extensible compute § Co-processor interface for tightly-coupled acceleration 23 © 2017 Arm Limited Security foundation § System-wide security with Trust. Zone technology Enhanced memory protection § Easy to program § Dedicated protection for both secure and non-secure states Enhanced & secure debug § Security aware debug § Simplified firmware development

Cortex-M 23: Security for Ultra Low-Power Io. T Smallest area, lowest power Security foundation § With Trust. Zone, same energy efficiency as Cortex-M 0+ § System wide security with Trust. Zone technology Ultra-high efficiency Enhanced memory protection § Flexible sleep modes § Extensive clock gating § Optional state retention Enhanced capability § § 24 Increased performance Multi-core system support 240 interrupts Hardware stack checking © 2017 Arm Limited § Easy to program § Dedicated protection for both secure and non-secure states Enhanced & secure debug § Security aware debug § Simplified firmware development § Includes embedded trace macrocell

Example Ro. T Models – ARM So. C Solutions Ro. T - SE § +Dedicated secure CPU § + Ro. T within an isolated subsystem § No Reliance on Trust. Zone for SE Ro. T 25 © 2017 Arm Limited § Ro. T- Trust. Zone {Client, M} § Reliant on Trust. Zone for Ro. T § Other

Take Away – Executive Summary § Hardware Ro. T is a fundamental requirement for any type of secure device § § Extend Ro. T functionality for isolated and secure partitions to assure robustness against attacks Security Enclave (aka HSM) option can be implemented to increase robustness against attacks § Many end point connected devices exist with inherent constraints § § High to low cost – enterprise servers to disposable devices High to low power consumption – wall plugged to harvested power devices § One size does not fit all – one Ro. T Model insufficient § Use case, device protection profile, cost and power constraints will dictate the chosen model § M-Class Trust. Zone assist now allows flexible Ro. T solution choices across Io. T § § 27 Full range of solutions with preferred security robustness is possible Address global/national security issue of Io. T robustness with enhanced Ro. T option – Ex: Mirai botnet © 2017 Arm Limited