What Is Secure Boot and How to Enable It for Your ESP32 Devices

In this Security Tuesdays article, learn more about secure boot and how to enable it for ESP32 devices in just a few steps.

4 months ago • Security / Internet of Things

Secure boot is a boot sequence on a hardware device in which each software (AKA firmware) image loaded is authorized to execute using software previously authorized by this system.

The sequence is designed to prevent unauthorized or modified code from being run by ensuring that all code is checked before it's executed, during device boot-up time.

The authorization is normally done through attestation of one or more valid digital signatures associated with the firmware image.

The first piece of software in the boot sequence that performs such image attestation is called a root of trust (RoT). Usually, when people talk about "secure boot," the RoT is part of a chipset's hardware, e.g. in read-only memory (ROM). As a corollary, secure boot (with hardware-based RoT) needs hardware support.

For a secure boot mechanism to be effective, once enabled on a device, it shall not be possible to turn it off. For this reason, secure boot enablement is usually done by configuring one-time programmable (OTP) memory, e.g. eFuse.

A secure boot enabled device runs only signed firmware images, which makes secure boot a fundamental hardware security countermeasure against malware persistence. This countermeasure is strong if and only if the firmware signing keys are secure.

Secure boot enablement: As mentioned above, secure boot requires hardware support. On hardware supporting secure boot, the process to enable secure boot is normally as follows.

Create and manage firmware signing keys or a public-key infrastructure (PKI).
Program (AKA "blow") eFuse to configure the RoT and device security parameters.
Properly sign firmware images to run on fuse-blown devices, using a signing infrastructure.

ESP32: Secure Boot v2 (SBV2)

ESP32 platforms (e.g. ESP32, ESP32-S, ESP32-C, ESP32-H2 series) support secure boot with a hardware-based root-of-trust: The first stage bootloader is in ROM, which uses a verification key anchored in eFuse to authorize the second-stage, firmware bootloader. The preferred secure boot scheme is Secure Boot v2 (SBV2).

Secure Boot v2 is largely available on ESP32 series, ESP32-S series, ESP32-C series, and ESP32-H series — on certain chipsets, SBV2 is only available in newer revisions (e.g. ESP32 ECO3 and ESP32-C3 ECO3 onward). SBV2 employs digital signatures (RSA-PSS- or ECDSA-based) for bootloader and app firmware authorization. RSA-PSS is more widely supported for SBV2 among ESP32 chipsets, and is the SBV2 digital signature algorithm available on chipsets Thistle currently provides support for: ESP32, ESP32-S2, and ESP32-S3. Therefore, we will only talk about RSA-PSS as the SBV2 digital signature.

How to enable SBV2, at a high level

Generally speaking, the steps to enable Secure Boot V2 on an ESP32 platform and maintain this state are as follows.

1. Generate firmware signing key(s). This is usually a one-time effort during the lifecycle of a type of devices.

The two digital signature schemes Thistle's solution supports are RSA-3072-PSS and ECDSA-P256, which have good ecosystem support, and thus maximize interoperability while ensuring cryptography strength. Therefore, one can use software tools, e.g. OpenSSL and espsecure.py, and a key management system (KMS), e.g. AWS KMS, GCP KMS, and hardware security modules (HSMs).

2. Determine eFuse configuration and get eFuse bits blown. This is typically a one-time effort.

One can turn on SBV2 and other hardware security features by manually computing and blowing eFuse bit using the espefuse.py tool. While it provides more flexibility and allows for more advanced eFuse configurations, we found this approach more error-prone, and more cumbersome to setup during manufacturing testing. Therefore, we don't recommend it.
Our preferred method to blow eFuse for SBV2 enablement is to sign a bootloader and app image bundle with the desired private key, and flash the signing images (together with a valid partition table) to the unfused unit. On first successful boot, eFuse bits will be blown by the IDF bootloader to enable SBV2. This way, eFuse blowing and image flashing can also be combined into one step during manufacturing. With this method, SBV2 eFuse configuration is reduced to the problem of firmware signing.

3. Sign firmware using the firmware signing key(s). This is an ongoing effort that is required for each new firmware release.

In all the above three steps, the firmware signing keys plays an important role. Firmware signing keys need to be appropriately managed, depending on the security requirements. In this regard, Thistle recommends to distinguish two scenarios: key management in development and in production.

If one would like to have SBV2 enabled on production devices, it's a good idea to perform firmware development and testing on SBV2-enabled development units. Ideally, production firmware should be a nearly faithful mirror of development firmware, where the two differ only in bits associated with public keys and signatures.

Production and development firmware should be similar, so that after development testing is completed, a minimum level of additional testing would be needed on production firmware. Production and development firmware should be signed with different keys, because the security and operational requirements on them are different.

Development signing: Development firmware is typically flashed onto only a handful devices during earlier phases of hardware development. Signing key confidentiality in this case is usually not crucial, because development hardware is supposed to be physically more tightly controlled, and not plugged into production systems. The development signing process should be easy to allow fast feedback loops.
Production signing: Production firmware runs on production devices, which usually ship in large volumes, and are used in the real world by end users. For this reason, production signing keys are often highly confidential, and shall not be exposed to software or human operators. The production signing process in many cases should be easy to allow fast firmware releases.

How to enable SBV2, step-by-step with Thistle Technologies

Thistle has published a step-by-step guide for enabling ESP32 Secure Boot V2, which walks though the commands and procedures to enable secure boot in development and production, using ESP32-DevKitC-32E as an example. In his wonderful Retro-Logger project, Mukesh Sankhla also showcased how to use Thistle Technologies to protect an ESP32 device from unauthorized access and firmware tampering.