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