Understanding processor

security technologies and

how to apply them
Joseph Yiu | senior embedded technology manager

© 2017 Arm Limited Arm TechCon 2017

Agenda
• Quick overview of security technologies
• What are the differences?
• Why are there differences?
• Software development

2 © 2017 Arm Limited

 Quick overview of
Security Technologies

© 2017 Arm Limited

Security principles

Communication level Inside the chip

Processor
Encryption (e.g. TLS) Process isolation
technologies
Provisioning Data protection
Authentication Firmware protection
Debug authentication
Life Cycle State (LCS) management
Anti-tampering

4 © 2017 Arm Limited

All roads lead to Rome – but are there any differences?

There are many approaches to security in

processor system designs.
• Cortex-A processors: TrustZone for Armv7-A/Armv8-A
• Cortex-R processors: Virtualization (Armv8-R)
• Cortex-M processors: TrustZone for Armv8-M

5 © 2017 Arm Limited

Concepts of TrustZone
Non-trusted

Normal application environment

• Non-secure world
Trusted
• Access to non-secure memories, general peripherals Normal applications
General peripherals
Protected application environment USB
ADC /
DAC
GPIO Timer

• Secure world
Trusted software
• Access to secure and non-secure resources Trusted hardware
secure secure
crypto TRNG
Keys aspects system storage

Resources critical to security of

• Non-secure software cannot access to Secure resources the system are protected
• Secure software defines what Non-secure software can access to
• System-level protection - Security resources are placed in Secure address spaces
• Secure software provide services (APIs) to Non-secure software
6 © 2017 Arm Limited
TrustZone for Cortex-A processors - How it is used
Normal world code Trusted software

Payment
Apps
DRM Trusted_Apps
Global platform
Device drivers Secure device drivers standardization
EL1
Rich OS Trusted OS TrustZone-based
EL2 Hypervisor TEE
Arm SMCCC PSCI Payload Dispatcher
Trusted Common foundation
Firmware Trusted Boot
Hardware Interfaces

SoC Graphics CryptoCell

Arm Cortex-A
Subsystem Video Secure store Initial ROT and
Physical IP security subsystem
7 © 2017 Arm Limited
TrustZone on Cortex-M23 and Cortex-M33 processors

Armv8-M introduced TrustZone technology to Cortex-M processors

• Handler mode is privileged Secure Non-secure
• Thread mode can be privileged / unprivileged
Privileged
Enable TrustZone capabilities in smallest microcontrollers Secure Non-secure
Calls
handler handler
Many differences from TrustZone on Cortex-A processors mode mode
Secure Non-secure
• Both Secure and Non-secure worlds can have unprivileged level thread thread
Calls
mode mode
• Direct function calls between states are allowed
Unprivileged

8 © 2017 Arm Limited

TrustZone for Armv8-M enabling Root of Trust implementations

TrustZone benefits Customer application

• Protect software, data, keys/ID, and hardware
• Boot always in Secure software (secure boot)
TrustZone
• Secure software can recover an infected application
by re-flashing Firmware Update

Typical use cases Secure ID

Crypto keys
• Securing IoT connections
• Firmware update protection Drivers

• DRM RNG
• Payment Crypto Accelerators

9 © 2017 Arm Limited

IoT end points deployment with TrustZone

IoT services
Device management Trusted environment (Secure) Normal applications
Secure firmware update (Non-secure)
Flash Secure storage

API gateways
programming (certificates) App Middleware

Authentication Cryptography
App App App
& Provisioning (library & HW)
Secure IoT
cloud services Secure boot Health check RTOS

Hardware

Attacker

10 © 2017 Arm Limited

IoT end points deployment with TrustZone

IoT services
Device management Trusted environment (Secure) Normal applications
Secure firmware update (Non-secure)
Flash Secure storage

API gateways
programming (certificates) App Middleware

Authentication Cryptography
App App App
& Provisioning (library & HW)
Secure IoT
cloud services Secure boot Health check RTOS

Hardware

%#!?*@!?
Cannot reprogram flash memory Attacker
Cannot steal certificates/keys
Cannot clone device
Cannot stop Secure services
11 © 2017 Arm Limited
IoT end points deployment with TrustZone System health
detected abnormal
activities – trigger
system recovery

IoT services
Device management Trusted environment (Secure) Normal applications
Secure firmware update (Non-secure)
Flash Secure storage

API gateways
programming (certificates) App Middleware

Authentication Cryptography
App App App
& Provisioning (library & HW)
Secure IoT
cloud services Secure boot Health check RTOS

Hardware

%#!?*@!?
Cannot reprogram flash memory Attacker
Cannot steal certificates/keys
Cannot clone device
Cannot stop Secure services
12 © 2017 Arm Limited
IoT end points deployment with TrustZone
System recovered

IoT services
Device management Trusted environment (Secure) Normal applications
Secure firmware update (Non-secure)
Flash Secure storage

API gateways
programming (certificates) App Middleware

Authentication Cryptography
App App App
& Provisioning (library & HW)
Secure IoT
cloud services Secure boot Health check RTOS

Hardware

Cannot take over the device 

Go somewhere else Attacker

13 © 2017 Arm Limited

TrustZone – a secure way to deliver on-chip software
Silicon from Development of Protection enabled Device with
production line secure firmware before device preloaded firmware
distribution

10101010001010010010 101010100010100100101 101010100010100100101

Secure firmware Secure firmware Secure firmware Secure firmware
10101010101010010100 010101010101001010010 010101010101001010010
flash (blanked) flash
10101010101001010101 flash
101010101001010101010 flash
101010101001010101010
01001010101010100101 010101010101001010101 010101010101001010101
01010111101001001011 011110100100101111101 011110100100101111101

User flash User flash User flash 101010100010100100101

User flash
010101010101001010010
(blanked) (example application) (example application) (User applications)
101010101001010101010
010101010101001010101
011110100100101111101

Debug access governed by debug authentication control Optional device level

read-out protection
14 © 2017 Arm Limited
TrustZone use case – Operation protection

Protection of critical operations Device with preloaded firmware

• When AIRCR.PRIS is set to 1, Secure interrupts can be
configured to have higher priority then Non-secure
interrupts

0x00 Levels 0x0 to 0x7F are always

Priority higher than Non-secure IRQ levels
level 0x00
101010100010100100101
Secure firmware
0xFF 0xFF 010101010101001010010
flash
101010101001010101010
Secure Non-secure 010101010101001010101
interrupts interrupts 011110100100101111101
101010100010100100101
• Critical secure operations cannot be affected by User flash
010101010101001010010
(User applications)
101010101001010101010
Non-secure operations 010101010101001010101
011110100100101111101
– Certified firmware requirements
Optional device level
– Functional safety requirements
read-out protection
15 © 2017 Arm Limited
Virtualization

Support Security Use cases

Supported in most Cortex-A Security Server Utilisation
and Cortex-R52 processors • Provides isolation between
• Bare metal (type 1) virtualization Virtual Machines

• Multiple guest OS
App1 App2 App3 App4 Unprivileged
Dashboard
Guest OS Guest OS
Privileged
#1 #2
Hypervisor (Virtualization) Privileged

16 © 2017 Arm Limited

 What are the differences?

© 2017 Arm Limited

TrustZone for Armv7/8-A ≠ TrustZone for Armv8-M
Similarities - both of them partition the software
environment into Secure and Non-secure.
Non-trusted
• Secure world can access both sides
(normal)
• Natively supports two states (further security domain partitioning with
additional software)
Trusted
• Boot-up in Secure state enables Root-of-Trust (secure)
• Supports debug authentication

There are differences.

• Partitioning of memory spaces Trusted software

• State transition mechanisms Trusted hardware

Secure Secure
Crypto TRNG
• Interrupts system storage

18 © 2017 Arm Limited

Differences in memory map

Cortex-A (up to 48-bit address) Cortex-M (32-bit address)

• Each address can have a Secure and Non-secure view • Address space partitioned by Security Attribution
Unit (SAU) & Implementation Defined Attribution
• Address space partitioned by MMU page Unit (IDAU) – 32 bytes granularity
descriptions – each page is 4KB minimum

Non-secure
Non-secure Secure address space
address address Secure
space space address
space

Address Address

19 © 2017 Arm Limited

 Security state switching on Cortex-A processors
4 levels of Exception Levels
• Level transitions using system calls instructions : SVC, HVC and SMC Secure software (can
access to Secure and
Non-secure memories)
Exception Levels
Applications Secure
EL0 Unprivileged Applications Applications SEL0
SVC Applications
Normal world
(access to Other guest
EL1 Privileged SMC Linux kernel
Non-secure HVC OS SEL1
Secure OS
memories only)
EL2 Hypervisor SMC Hypervisor (Virtualization)
Return
EL3 Secure world Secure boot, secure services
Use Secure MMU configuration – Select Secure/Non-secure view with MMU page description

20 © 2017 Arm Limited

Security state switching on Cortex-M processors
Based on proposed update to Arm C Language Extension (ACLE)

Non-Secure Callable (NSC) region(s) contains branch veneers

• Automatically generated by tool chains (linker)
Non-secure project Secure firmware project
Non-secure Secure APIs
main() callable
…. func1:
func1(); SG ….
B.W func1
Symbol file / SG func2:
export library B.W func2 ….
SG
func3:
B.W func3
….
…
Linkage

__attribute__((cmse_nonsecure_entry))
21 © 2017 Arm Limited
TrustZone interrupt handling
Both support Secure and Non-secure interrupts

TrustZone on Cortex-A TrustZone on Cortex-M

Interrupt assignment by Generic Interrupt Interrupt assignment by Nested Vectored
Controller (GIC) Interrupt Controller (NVIC)
• Each interrupt can be assigned as Secure/Non-secure • Each interrupt can be assigned as Secure/Non-secure

Cross domain interrupt handled by Secure Cross domain interrupt transitions

Monitor trapping managed by processor’s hardware
• A small software overhead needed • No software intervention – faster
• Additional stacking for “Secure background -> Non-
secure interrupt”, no leak of Secure information with
just a few extra clock cycles.

22 © 2017 Arm Limited

Armv8-R - Real-time virtualization for safety and security

Supported in Cortex-R52 (Armv8-R)

New Privilege Level (EL-2)
Bare metal hypervisor support (aka type 1)
• Support multiple OS, manage shared resources

Safety and security sandbox

Software separation for ‘golden’ code
Task consolidation onto fewer platforms
Accelerated interrupt response and
context switch
Enhanced AArch32 instruction set
23 © 2017 Arm Limited
Managing multiple SW environments with Cortex-R52

A single processor can switch rapidly

between Virtual Machine (VM) ‘sandboxes’
VMs have strong isolation with two-stage
memory protection and exported VMIDs Safety & Tier-1 OEM
Security software software
Complete OS and tasks can be virtualized,
enabling software consolidation
Hypervisor
Interrupts can be routed via the
hypervisor, or directly to virtual machines
Hypervisor, or the monitor program,
handles all safety and security activities

24 © 2017 Arm Limited

Using Exception Level 2 to enhance safety and security
Single 4GB address space
• S2 MPU (EL2) partitions memory for each OS
• S1 MPU (EL1) partitions memory for each task inside an OS
• Strong process isolation, also protects against random and systematic errors

High availability
• Handling of system safety events
• Safe and Secure Monitor can monitor and restart RTOS if necessary
• A failure in one VM does not affect timings in other VM

Consistent with EL2 in Cortex-A

• RTOS calls for support via HVC
• Run secure boot from EL2
• Safe and reliable mechanism for firmware updates

25 © 2017 Arm Limited

Managing interrupts with virtualization

Cortex-R52 + Generic Interrupt Controller Hardware

(GIC) interrupts

Cortex-R52 with single guest OS can take Control GIC distributor

registers
interrupts directly
• Very low latency

Memory mapped
Cortex-R52 with multiple guests have Interrupt GIC virtual
virtualized interrupts routing CPU interface
GIC CPU interface
• Managed by hypervisor
IRQ FIQ vIRQ vFIQ

Hypervisor Guest OS Guest OS

26 © 2017 Arm Limited

 Why are there differences?

© 2017 Arm Limited

Different processors, different application needs
Virtualization TrustZone

Cortex-R Cortex-A Cortex-M

Fast response, fast context Highest performance Lower power, low cost, low
switching latency
Multiple OS – consolidation Virtual memory Small memory footprint
of multiple devices IoT Security Data & firmware protection
Fast virtualized interrupts IP protection (e.g. DRM) Single OS – tightly coupled
Functional safety Multiple OS in servers software interface

28 © 2017 Arm Limited

TrustZone on Cortex-A vs. TrustZone on Armv8-M
Differences in state transitions

Cortex-A processors Cortex-M23 and Cortex-M33 processors

Transitions by Secure Monitor exception Transitions by function call/return,
• Highly flexible
exception sequences.
• Physical address NON-SECURE STATES SECURE STATES • Fast switching NON-SECURE STATES SECURE STATES

agnostic • No extra code size

Secure Non-
Rich OS, App/Libs Secure
• Easy to use secure
e.g.Linux App/Libs
App
• Real-time
Secure OS Non-
OS API /
secure
Secure OS
OS
Secure Monitor (EL3)
TrustZone for Armv7/8-A TrustZone for Armv8-M

29 © 2017 Arm Limited

Virtualization vs TrustZone for Armv8-M
Two different approaches for different usages

TrustZone for Armv8-M Virtualization

Lightweight, single OS possible Isolation between multiple OSes and software
environments (no/little interaction in between).
Allows direct interaction between applications Shared resources management.
and secure firmware
(No fixed ‘Secure context’ concept)
Partitioning of an application into Consolation of multiple systems into one system
Secure and Non-secure domains with isolation

Secure Non-secure

Isolation
Applications Applications
Secure
Applications
Firmware OS OS
OS/OS API OS Hypervisor
Processor hardware Processor hardware
30 © 2017 Arm Limited
 Software development

© 2017 Arm Limited

Creating the software
Cortex-A processors
• Trusted Execution Environment (TEE) defines APIs for security features – 3rd party TEEs available
• Arm Trusted Firmware provides reference implementation

Cortex-R processors
• Hypervisor software available from multiple vendors

Cortex-M processors
• Secure software development with Cortex-M Security Extension (CMSE)
• Supported by CMSIS, MbedOS (Armv8-M support in development) and 3rd parties
• Platform Security Architecture (PSA) in development

32 © 2017 Arm Limited

Mind the gap(s) – differences with writing Secure code
Cortex-A processors
Cortex-A processors
• Secure software needs to ensure that MMU page description has the correct
security attribute (otherwise potential coherency issues for shared data) Non-secure Secure
• Minimum page size 4KB address address
space space
Cortex-R52 processor
Address
• Single address space – partitioning using S1 and S2 MPU
Cortex-M23/M33 processors
• MPU region granularity 64bytes

Cortex-M23, Cortex-M33 processors

Non-secure Secure
• Each address can be Secure or Non-secure, but not both
address address
• Security attribute defined by SAU/IDAU space space
• SAU/IDAU and MPU region granularity 32bytes
Address

33 © 2017 Arm Limited

TrustZone debug authentication concepts
Different debug permissions in life cycle MCU Vendors
• Full access Both Secure and Non-secure debug are enabled.
• Non-secure access only Firmware developers can develop and add new on-
• Disable both chip firmware, and then lock down Secure memory
before shipping the chip.
In some cases
• MCU software developers can program MCU Software developers
Non-secure side only Only Non-secure debug is enabled. Software
• Non-secure software can call Secure APIs developers can utilize features provided in secure
APIs in their software but are not able to modify the
Secure code.
If allows Non-secure debug only
• Debugger cannot access Secure memories Completed products
• Cannot halt in Secure state Both Secure and Non-secure debug accesses
• Cannot step into Secure APIs disabled. Additional chip level read-out protection
• Cannot trace Secure operations might be deployed.

34 © 2017 Arm Limited

 Summary

© 2017 Arm Limited

Different technologies for different needs
Cortex-A – Supports TrustZone and virtualization
• Highly flexible TrustZone support for security requirements
• Virtualization extension for server virtualization requirements

Cortex-R – Real-time, complex systems with function safety

• Cortex-R52 supports virtualization for consolidation of multiple systems
• Virtualization as a protection mechanism for functional safety

Cortex-M – Lightweight software architecture

• TrustZone for Armv8-M is optimized for small, low-power devices with smaller memories
• Closely-coupled interaction between software

36 © 2017 Arm Limited

Protection requirements
TrustZone for Armv8-M
Virtualization
with Armv8-R Operations
protection

Software
systems
isolation Security Data & IP
protection

Debug
protection
TrustZone and
Virtualization on
Cortex-A processors
37 © 2017 Arm Limited
For further information…
Find demos and more information at the Arm booth (402) and Mbed booth (712)

At TechCon After TechCon

• Armv8-M TrustZone primer – Bob Boys
• Beyond TrustZone – Rob Coombs
• New approaches to connected device security – Erik
Jacobson
• New Arm security architecture for greater isolation
and ease of certification – Asaf Shen
• Arm case study: Implementing security at the core of
an IoT node – Mike Eftimakis
https://developer.arm.com
• Understanding processor security technologies and
how to apply them – Joseph Yiu
[email protected]

38 © 2017 Arm Limited

 Thank You!
Danke!
Merci!
谢谢!
ありがとう!
Gracias!
Kiitos!

39 © 2017 Arm Limited

 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.

www.arm.com/company/policies/trademarks

40 © 2017 Arm Limited