1. Demystifying Security Root of Trust
IoT Device Security Summit
Suresh Marisetty
Security Solutions Architecture

2. Agenda The Landscape Problem Statement What’s RoT? RoT Models
Beyond RoT
IoT Offerings
Conclusion

3. Connected IoT Devices – Everywhere
Security camera
Privacy / personal data
Premium content protection (movies, shows)
User identification/
Loose control of device
Credit / payment fraud
Safety / ADAS
Corporate espionage
And more …

4. Problem Statement ss

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

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

7. Hardware Enforced Root of Trust (RoT)

8. 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
Secure HW key storage
Data Privacy (HIPPA)
Functional safety (actuators)
Industrial
Facility ops
Secure video monitoring
Telematics/fleet management
Data Integrity
Functional safety
Wearables
Home
Privacy and data confidentiality
TBSA-M

9. Initial Root of Trust & Chain of Trust
Apps
OS/RTOS
Apps
OS/RTOS
Trusted Software
TrustZone uVisor or TEE iROT TrustZone CryptoCell
Keys
RTOS
Trusted Software
Trusted Apps/Libs
Lots of definitions for ROT – GlobalPlatform doing some good work in the Security Task Force = ROT Definitions & Requirements
Initial Root of Trust (e.g. CryptoCell) is a computing engine & executable code on same platform
ROT may require data / keys to be securely provisioned at the factory e.g. RSA key pairs and storage of private keys
ROT provides security services to next item in chain of trust e.g. authenticating boot code, crypto, confidential key store/ management
iROT ususally has one identifiable owner e.g updates & controlled mutability
One iROT per platform
Small security boundary
Extended ROT is next level in chain e.g. TrustZone based TEE
Extended ROT is a set of code and data whose integrity can be verified prior to execution Provide additional security functions
Often from different vendor to iROT
iROT & Extended ROT = Primary ROT
Typical security services:
Confidentiality, Integrity, Auth, Identification, Measurement
TrustZone Extended Root of Trust
Extended Root of Trust e.g. TrustZone based TEE
iROT TrustZone CryptoCell
Initial Root of Trust: Dependable Security functions
Keys
Provisioned keys/certs

10. 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

11. 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

12. 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

13. 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

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

15. RoT Models ss

16. Diverse IoT Endpoints – No One Size HW RoT Fits All
Wide Applications
Constrained Applications
Secure
Ultra efficient
Within IoT Device – Diverse Function Endpoints
Diverse Security Requirements
Smart lock
Smart bandage
Safe
Ubiquitous
Medical Nanorobot
Asset tracking

17. RoT – Myriad of Options Key Options No Explicit RoT 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
Enhanced
SE RoT
App CPU +
standard
(x) no. layers of security
No Explicit
Key Options
No Explicit RoT
TrustZone RoT
SE RoT
SE w/ TrustZone RoT
** Hardware state-machine or CPU microcode extensions

18. What’s New? – TrustZone Extended to MCU-Family
Increased Root of Trust Robustness
Confidentiality of 3rd parties SW IP
trusted software
valuable firmware
trusted hardware
trusted drivers
non-trusted
crypto
secure system
secure
storage
TRNG
trusted hardware
TrustZone for ARMv8-M helps enforcing various security use cases, that address scenarios/requirements of the different embedde sub-segments.
Go through each 4 quickly, adding whose property it is helping to secure.
trusted
Sandboxing
Confidentiality of SiP SW IP
certified OS / functionality
trusted drivers
trusted drivers
trusted hardware
trusted hardware
Motivation – Address IoT Device Robustness Requirement

19. Foundation - RoT ss

20. Beyond RoT – Basis for Secure/Protected Partitions
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

21. 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

22. IoT Offerings

23. Cortex-M33: Security for Diverse IoT Usages
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
Security foundation
System-wide security with TrustZone technology
Highlight energy efficiency vs M4
Depends on the configuration but at least as an energy efficient as an M4, in some cases more efficient
Enhanced memory protection
Easy to program
Dedicated protection for both secure and non-secure states
Digital signal control
Bring DSP to all developers
FPU offering up to 10x performance over software
Enhanced & secure debug
Security aware debug
Simplified firmware development
Extensible compute
Co-processor interface for tightly-coupled acceleration

24. Cortex-M23: Security for Ultra Low-Power IoT
Smallest area, lowest power
With TrustZone, same energy efficiency as Cortex-M0+
Security foundation
System wide security with TrustZone technology
Ultra-high efficiency
Flexible sleep modes
Extensive clock gating 
Optional state retention
Enhanced memory protection
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
Enhanced capability
Increased performance
Multi-core system support
240 interrupts
Hardware stack checking

25. 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

26. Summary

27. 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

28. Q & A