Secure Firmware with David Brown of Linaro! David Brown is a Senior Engineer at Linaro who has been working on ARM Linux since about 2007, as well as general Linux and other kernels for many years before that. He also enjoys learning and working with new programming languages. With decades of experience, David is the perfect person to tackle the complex and technical topic that is “Secure Firmware”. In this week’s episode of OpenHours, we will get a general overview of trusted firmware, discuss the differences between Cortex A and M, and review both setups! A setup: boot, TF-A, OP-TEE and Linux M setup: mcuboot, TF-M, and work in progress

1. Bootloaders and
Trusted Firmware
David Brown
2019 April 24

2. Overview
● Signature introduction
● Two worlds: Cortex A and Cortex M
● Trusting your code: The root of trust
● Secure vs Non-secure
● Bootloaders, trusted firmware, and secure code, oh my

3. A Digital Signature
Image SHA256 Image Hash
32 bytes
EC Private Key
ECDSA
Sign Signature
32 bytes

4. Verify a Signature
Image
SHA256
Image Hash
32 bytes
EC Public Key
ECDSA
Verify
Signature
32 bytes
Good?

5. Cortex A vs Cortex M
Cortex A:
● “Big” CPUs
● Typically have:
○ GBs of RAM
○ GBs of storage: SSD/MMC/NAND
○ GHz CPU
○ Multiple cores common
● Think Raspberry Pi, Phones,
96Boards, Android, Linux, etc
Cortex M:
● “Small” CPUs
● Typically have:
○ KBs of RAM
○ MBs of ROM
○ 10-100s of MHz
○ Usually 1 core, some 2
● Think IoT: light bulbs, water meters
● Key here is to reduce cost and power
consumption

6. Root of trust
● How do we trust the code that is running?
● Chain of trust from first executed code on the system

7. Chain of Trust
Internal
boot code
Bootloader Trusted Firmware
Non-secure
Operating System
Trusted OS Application
Secure
Non-Secure
Optional

8. Internal
boot code
Bootloader
Trusted Firmware
Non-secure
Operating System
Trusted OS
Application
Secure Non-secure

9. Secure, Non-secure Interaction
● Strong memory protection
● Memory protection even of DMA
● Well defined and restricted communication
● Limits code that needs to be trusted

10. Bootloaders, Cortex-A
● Code resides in file or partition in a large device
● Each stage responsible for verifying the next state
○ BL1: Rom loader in SoC
○ BL2: Trusted firmware
○ BL3-1: Trusted OS/Platform
○ BL3-3: Non-trusted: U-Boot/UEFI
○ : Non-secure OS: Linux
○ : Apps

11. Bootloaders: Cortex-M
● Lives in a single flash space
● May execute right out of flash
● Fixed partitions and rigid upgrades
● Boot order:
○ Possible on-SoC init ROM
○ MCUboot: Validates 2 images
○ TF-M: Secure application
○ Application

12. Thank you
Join Linaro to accelerate deployment of your Arm-
based solutions through collaboration
contact@linaro.org