🔒 Enabling Secure Boot (V2) on ESP32 Platforms in Development and Production

DevCon 2023
https://thistle.tech/partnerships/espressif
Ning Shang (Thistle Technologies)

Speaker Intro


Ning Shang (VP of Engineering, Thistle Technologies)

  • Trained in mathematics and cryptography
  • Experienced in building, attacking and securing hardware devices and key management infrastructures in production systems
  • Working at Thistle to make hardware security easy for IoT device makers

Secure Boot Intro

  • A boot sequence of software images on a hardware device
  • Image is executed only when authorized by previously authorized software
  • Authorization boils down to a root of trust (RoT) in hardware
  • Needs chipset support: ESP32 platforms support it
Once enabled, secure boot ensures that only signed firmware run on hardware device, preventing malware persistence at boot time

Secure Boot Enablement

On hardware supporting secure boot, the process is usually
  • Creation and management of firmware signing keys or PKI
  • Fuse programming to configure security parameters and the root-of-trust (RoT)
  • Proper signing of firmware images, requiring signing infrastructures
Secure and easy-to-use signing key management is a challenge

ESP32: Secure Boot V2 (SBV2)

  • ESP32 chips support secure boot
  • The preferred secure boot scheme is Secure Boot V2
    • Available from ESP32 ECO 3 onwards, including ESP32-S2, ESP32-S3, etc
    • RSA-3072-PSS-based app and second-stage bootloader verification

ESP32: SBV2 Boot Flows

ESP32 SBV2 suports at least two boot flows: "ESP-IDF" and "MCUboot + ZephyrOS"
SBV2: ESP-IDF SBV2: MCUboot + ZephyrOS

How To Enable SBV2

  • Generate firmware signing key (one-time effort)
  • Determine efuse configuration and blow efuses (one-time effort)
  • Sign firmware (on-going effort)

SBV2: Signing Key Generation

  • For local development and testing, use OpenSSL (or espsecure.py) 
    
# Generate private key
openssl genrsa -out sbv2_private_dev.pem 3072
# Extract public key
openssl rsa -in sbv2_private_dev.pem -pubout > sbv2_public_dev.pem
  • For production releases, use a proper key management system (KMS)
    • E.g., AWS KMS, GCP KMS, Hardware Security Modules (HSMs)

SBV2: Efuse Config and Blowing

  • [Error-prone] Turn on SBV2 and other hardware security features by manually computing and blowing efuse bits using espefuse.py.
  • [Recommended] Sign a bootloader and app image bundle with the desired private key, and flash the signed images and a valid partition table to an unfused device. On first boot, efuse will be blown (by IDF bootloader) to enable SBV2
Once SBV2 is enabled, only signed images can boot on device

Firmware Signing

SBV2 enablement is largely a firmware signing and key management problem
  • Development signing: Signing key confidentiality is not crucial; signing process should be easy to allow fast feedback loop
  • Production signing: Signing key is highly confidential, and shall not be exposed; signing process should be easy to allow fast releases
  • Production firmware should be a nearly faithful mirror of development firmware, differing only on public keys and signatures

FW Signing in Development

Steps:
  • Generate file-based private signing key using OpenSSL or espsecure.py
  • Use `menuconfig` to enable SBV2, configure signing key file, and save "sdkconfig"
  • Use `idf.py build` to build and sign a void app with the saved "sdkconfig"
Development signing keys aren't usually security critical, and it's often OK to check them into a version control system for easy access and backup

"idf.py menuconfig"

idf menuconfig
We also recommend to disable JTAG but enable secure ROM download mode (when available)

The "void app"

An app that does not do anything (and thus is "void"), but can be flashed on an ESP32 chip to blow security related efuses according to the "sdkconfig" settings.
A minimum "fuseblower" void app is important for production signing.
Void App

SBV2 Signing "1-click" Setup

Thistle released developer tools including Dockerfiles, utility apps and pre-built Docker images to allow 1-click firmware signing in development
https://github.com/thistletech/esp32-devenvs
Fuseblower

Demo: Development Signing


Blog post: Enabling Secure Boot V2 on ESP32 Platforms in Development

FW Signing in Production

File-based signing keys can be exposed by humans or malware, and are not suitable for production firmware signing
MSI Firmware Signing Key Leak

FW Signing in Production

  • Requirements
    • Security: Production firmware signing keys not exposed to human operators or software
    • Usability: Day-to-day signing operations be frictionless
  • Thistle's solution: Firmware signing and patching as a service using KMS-backed production signing keys
    • No one, including Thistle, has access to the keys
ESP32 image patching

Prod Signing in a Nutshell

Production Image Maker
Thistle's ESP32 SBV2 production signing system supports both ESP-IDF and MCUboot/ZephyrOS secure boot flows

Demo: Production Signing


Blog post: Enabling Secure Boot V2 on ESP32 Platforms in Production

Acknowledgments

  • Thistle Technologies for supporting this work
  • My Thistle colleagues for their feedback
  • Pierre Dubouilh for telling me about Espressif DevCon
  • Toru Maesaka and Russell Chapin, for helping build the production firmware signing service
Thistle Technologies
This presentation is available at thistletech.github.io/esp-devcon23-sbv2-talk