Session ID: SFO17-304 Session Name: Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304 Speaker: Suresh Marisetty Track: LHG,LITE,Security ★ Session Summary ★ The current trend of IoT market segment is expected to enable and deploy about 50 billion connected devices by year 2020. IoT devices will be deployed across the board to cater to multiple use cases like Home/building Automation, Automotive, a highly fragmented embedded segment: gateways, set top boxes, security cameras, industrial automation, digital signage, healthcare, etc. This trend will bring about a great challenge of securing the connected end point IoT devices from a myriad of physical and remote attacks ex: DDOS Mirai botnet launched through IoT devices like digital cameras and DVR players Problem Statement: Each use cases has its own IoT device constraints like: Cost, Power, Performance, memory footprint, security objectives, etc. The fundamental basis for any secure IoT and Embedded solution is the Root of Trust (RoT), which provides assurance of the integrity of the system software from: boot and runtime firmware, to OS loader, to the Kernel, to the user Applications. This poses a serious issue and challenges the one-size fits all RoT solution model. ARM has taken on this challenge head on to come up with a microcontroller security architecture solution that caters to the various IoT devices constraints, by offering ARM Cortex-M family of processors. ARM’s flexible and scalable architecture solution will allow an OEM or Silicon partner to adapt the base security architecture and to extend it in a seamless way. This caters to the requirements of different market segments through add-on hardware, firmware and software security enhancements. The session will present the ARM’s base security system and software architecture based on the upcoming Cortex V8M solution that will provide a hardware and firmware assisted Trust Zone based Security RoT aka TBSA-M for a range of markets, to include the highly constrained IoT devices. Furthermore, the session will discuss about how the base RoT capability can be extended in a seamless way with additional hardware assisted mechanisms to offer high levels of functionality and/or robustness for less constrained IoT devises with options like TBSA-M+, TBSA-HSM and platform level security software abstraction framework to decouple the chosen RoT capability for various OSes and the Cloud security frameworks. --------------------------------------------------- ★ Resources ★ Event Page: http://connect.linaro.org/resource/sfo17/sfo17-304/ Presentation: Video: https://www.youtube.com/watch?v=aIwmRXFOshs --------------------------------------------------- ★ Event Details ★ Linaro Connect San Francisco 2017 (SFO17) 25-29 September 2017 Hyatt Regency San Francisco Airport

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

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

3. © 2017 Arm Limited33
Connected IoT Devices – Everywhere
And more …
Security camera

4. © 2017 Arm Limited
Problem Statement

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

6. © 2017 Arm Limited66
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

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

8. © 2017 Arm Limited88
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
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)
Industrial
•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
Wearables
•Unique device
identity provisioning
•Secure boot
•FOTA update
•Secure debug
•User data
confidentiality
•Data integrity
•IP protection and
anti-counterfeiting
Home
•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
?

9. © 2017 Arm Limited99
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

10. © 2017 Arm Limited1010
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. © 2017 Arm Limited1111
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

12. © 2017 Arm Limited1212
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. © 2017 Arm Limited1313
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

14. © 2017 Arm Limited1414
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

15. © 2017 Arm Limited
RoT Models

16. © 2017 Arm Limited1616
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

17. © 2017 Arm Limited1717
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

18. © 2017 Arm Limited1818
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

19. © 2017 Arm Limited
Foundation - RoT

20. © 2017 Arm Limited2020
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

21. © 2017 Arm Limited2121
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

22. © 2017 Arm Limited
IoT Offerings

23. © 2017 Arm Limited2323
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

24. © 2017 Arm Limited2424
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+

25. © 2017 Arm Limited2525
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. © 2017 Arm Limited
Summary

27. © 2017 Arm Limited2727
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. © 2017 Arm Limited2828
Q & A