Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304

© 2017 Arm Limited© 2017 Arm Limited
Demystifying
Security Root of
Trust
Suresh Marisetty
Security Solutions Architecture
IoT Device Security Summit

© 2017 Arm Limited22
Agenda
• The Landscape
• Problem Statement
• What’s RoT?
• RoT Models
• Beyond RoT
• IoT Offerings
• Conclusion

Connected IoT Devices – Everywhere
And more …
Security camera

© 2017 Arm Limited
Problem Statement

Robustness Against Malicious Attacks
 The three fundamental elements of security
 Confidentiality
 Integrity
 Availability
 Others
 Non-Repudiation
 Authentication

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

© 2017 Arm Limited
Hardware Enforced
Root of Trust (RoT)

Generic IoT 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
Healthcare
•Unique device
•Secure boot
•FOTA update
•Secure debug
•Secure HW key
storage
anti-counterfeiting
provisioning
•Data integrity
•Data Privacy (HIPPA)
•Functional safety
(actuators)
Industrial
•Unique device
•Secure boot
•FOTA update
•Secure debug
•Facility ops
•Secure video
monitoring
•Telematics/fleet
management
•Data Integrity
anti-counterfeiting
provisioning
•Functional safety
Wearables
•Unique device
•Secure boot
•FOTA update
•Secure debug
•User data
confidentiality
•Data integrity
anti-counterfeiting
Home
•Unique device
•Secure boot
•FOTA update
•Secure debug
•Privacy and data
confidentiality
•Data integrity
anti-counterfeiting
provisioning
?

Initial Root of Trust & Chain of Trust
Provisioned keys/certs
Initial Root of Trust: Dependable Security functions
Extended Root of Trust e.g. TrustZone based TEE
Trusted Apps/Libs
RTOS
Apps
OS/RTOS
Trusted Software
TrustZone
Extended Root of Trust
iROT
TrustZone
CryptoCell
Keys

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…
• Different market segments with various constraints: Cost, Power, Latency, Performance,
etc.
• IoT end point device constraints dictate the packaged solution

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
..
1
2
3

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 1M TPM-enabled laptops each month
 Core functionality
 Secure storage
 Platform integrity reporting  context for this discussion….
 Platform authentication

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
 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
..
1
2
3

Secure vs. Measured Boot – Same End Goal
Attribute Secure Boot Measured Boot
Software Integrity Assured Assured
Static Root of Trust for
measurement
Applies Applies
Digitally Signed
Software/Firmware Images
Yes No
HW RoT in SoC Required Required
Core Root of Trust Immutable boot
code in ROM
Immutable boot
code in ROM
TPM Required No Yes

© 2017 Arm Limited
RoT Models

Wide Applications Constrained Applications
Secure
Smart lock
Ultra
efficient
Smart bandage
Safe
Medical Nanorobot
Ubiquitous
Asset tracking
A
M
J A
M
J
Engine
Control
Airbag
Actuator
Power
Steering (EPS)
Transmission Stability
Control (ESC)
Sensor Cluster
GatewayIVI/Head Unit
(V2X)
Body
EVITA FULLEVITA MediumEVITA Light
HSM Security Level
Diverse IoT Endpoints – No One Size HW RoT Fits All
Within IoT Device – Diverse Function Endpoints
Diverse Security Requirements

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

What’s New? – TrustZone Extended to MCU-Family
Increased Root of Trust Robustness
non-trusted
trusted
 Confidentiality of SiP SW IP
 Confidentiality of 3rd parties SW
IP
trusted drivers
trusted hardware
valuable firmware
 Sandboxing
trusted drivers
trusted hardware
certified OS / functionality
trusted drivers
trusted hardware
trusted software
crypto TRNG
trusted hardware
secure
system
secure
storage
Motivation – Address IoT Device Robustness Requirement

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

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
Platform hardware
Secure partition
manager
Device
management
Application
Non-secure processing
environment (NSPE)
Secure processing
environment (SPE)
Secure boot
Root of
Trust keys
RTOS

Cortex-M33: Security for Diverse IoT Usages
Security foundation
 System-wide security with
TrustZone technology
Extensible compute
 Co-processor interface for
tightly-coupled acceleration
Enhanced memory protection
 Easy to program
 Dedicated protection for both
secure and non-secure states
32-bit processor of choice
 Optimal balance between
performance and power
 20% greater performance
than Cortex-M4
 With TrustZone, same energy
efficiency as Cortex-M4
Enhanced & secure debug
 Security aware debug
 Simplified firmware
development
Digital signal control
 Bring DSP to all developers
 FPU offering up to 10x
performance over software

Cortex-M23: Security for Ultra Low-Power IoT
Enhanced capability
 Increased performance
 Multi-core system support
 240 interrupts
 Hardware stack checking
Security foundation
 System wide security with
TrustZone technology
Ultra-high efficiency
 Flexible sleep modes
 Extensive clock gating
 Optional state retention
Enhanced & secure debug
 Security aware debug
 Simplified firmware
development
 Includes embedded trace
macrocell
Enhanced memory protection
 Easy to program
 Dedicated protection for both
secure and non-secure states
Smallest area, lowest power
 With TrustZone, same energy
efficiency as Cortex-M0+

Example RoT Models – ARM SoC Solutions
RoT - SE
 +Dedicated secure CPU
 + RoT within an isolated subsystem
 No Reliance on TrustZone for SE RoT
 RoT- TrustZone {Client,M}
 Reliant on TrustZone for RoT
 Other

Take Away – Executive Summary
 Hardware RoT is a fundamental requirement for any type of secure device
 Extend RoT 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 RoT Model insufficient
 Use case, device protection profile, cost and power constraints will dictate the chosen model
 M-Class TrustZone assist now allows flexible RoT solution choices across IoT
 Full range of solutions with preferred security robustness is possible
 Address global/national security issue of IoT robustness with enhanced RoT option – Ex: Mirai botnet

Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304

More Related Content

What's hot (20)

Similar to Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304 (20)

More from Linaro (20)

Recently uploaded (20)

Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304

Editor's Notes