0% found this document useful (0 votes)
89 views

Secure Boot, Chain of Trust and Data Protection

This document discusses secure boot, chain of trust, and data protection. It introduces secure boot and how it provides authentication and integrity through digital signatures. It describes the chain of trust from bootloaders to the operating system and applications. It also discusses techniques for protecting user data through encryption at the block level and filesystem level. Finally, it provides best practices around secure key storage, additional security measures, and hardware considerations.

Uploaded by

ban.zhang
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
89 views

Secure Boot, Chain of Trust and Data Protection

This document discusses secure boot, chain of trust, and data protection. It introduces secure boot and how it provides authentication and integrity through digital signatures. It describes the chain of trust from bootloaders to the operating system and applications. It also discusses techniques for protecting user data through encryption at the block level and filesystem level. Finally, it provides best practices around secure key storage, additional security measures, and hardware considerations.

Uploaded by

ban.zhang
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

Secure Boot, Chain of Trust and

Data Protection
Akshay Bhat

www.timesys.com ©2019 Timesys Corp.


2
Topics
▪ Introduction to secure boot
▪ Chain of trust
▪ Protecting data
• Secure key storage
▪ Best practices and lessons learnt
3
Secure boot overview
▪ Provides
• Authentication (unauthorized images not allowed to run)
• Integrity (authorized images can not be ‘tampered’ with)
▪ Digital signatures for authentication
• Private key -> used for signing
• Public key -> used to verify
▪ Image/data encryption
• Confidentiality
• Anti-cloning/counterfeit
– Unique keys required
4
Bootloader Authentication
▪ Microprocessors
• Performed by built-in ROM code
▪ Microcontrollers
• User implemented code (eg: mbed
TLS)
– Flash locked from modification
5
Components of Linux device
▪ Bootloader
• First stage (eg: SPL, SBL, ARM-TF)
• Second stage (eg: u-boot, barebox, little kernel)
▪ Kernel
▪ Device tree
▪ Root filesystem
• User data partition
▪ Optional
• Secure OS (eg: op-tee)
• Firmware (eg: FPGA, FreeRTOS on M3/M4)
6
Chain of trust
▪ SoC specific mechanism extended
7
Chain of trust
▪ Open source mechanisms
▪ FIT (Flattened Image Tree)
option in u-boot
8
Protecting userspace components
▪ Block level
• dm-crypt (encrypted)
• dm-verity (signed – read only)
• dm-integrity (encrypted and authenticated)
▪ Filesystem level
• fscrypt (ext4, ubifs etc)
• ecryptfs
9
Secure key storage
▪ No user input on most devices
▪ SoC specific mechanism
• Keys stored in secure fuses (OR)
• Keys encrypted using unique master key (eg: i.MX)
▪ Trusted Execution Environment
• ARM TrustZone
▪ TPM
• Seal keys using PCR registers
▪ Crypto chip
• Beware of I2C bus attacks
10
Additional Security Measures
▪ Hardware security
• JTAG
• Tamper protection
▪ Known vulnerabilities
• Processor specific (eg: CVE-2017-7936)
• Bootloader specific (eg: CVE-2018-18439)
▪ Secure OTA update process
• Signed and/encrypted OTA images
• Server authentication
11
Other considerations
▪ Trade-offs
• Boot time
• Filesystem performance
▪ Securing the private and encryption keys
• Consider dedicated signing server
▪ Key revocation strategy
12
Design documents and Test plan
▪ List of software components, protection mechanism
Component Scheme Crypto Key storage Key unique?
U-boot Signed, vendor RSA Public key in OTP No
Kernel Signed, openssl RSA Public key in u-boot No
RFS Encrypted AES AES key in OTP Yes

▪ Negative test cases


• Tampered images
• Unsigned images
• Signed with different key
13
Hardware considerations
▪ Microcontrollers
• User programmable flash locked regions
▪ Microprocessors
• ROM support for secure boot
▪ Nice to have
• Secure key storage
• Key revocation
• Hardware accelerated ciphers
• Customer programmable keys
• Easy access to signing tools
• Tamper protection
14
Take away
▪ Design in security early
▪ Select the right hardware components
▪ Implement security at all software layers
▪ Continue to monitor vulnerabilities
15

Questions ?

Thank you
Visit us:
STMicroelectronics Booth
Hall 4A | Stand 138

You might also like