Secure Boot V2; Background; Advantages; Secure Boot V2 Process - Espressif ESP32-S2 Programming Manual

Table of Contents

Advertisement

Chapter 4. API Guides

4.25 Secure Boot V2

Important: This document is about Secure Boot V2, supported on the following chips: ESP32 (ECO3 onwards),
ESP32-S2, ESP32-S3 and ESP32-C3 (ECO3 onwards). Except for ESP32, it is the only supported Secure Boot
scheme.
Secure Boot V2 uses RSA based app and bootloader verification. This document can also be used as a reference for
signing apps using the RSA scheme without signing the bootloader.

4.25.1 Background

Secure Boot protects a device from running any unauthorized (i.e., unsigned) code by checking that each piece of
software that is being booted is signed. On an ESP32-S2, these pieces of software include the second stage bootloader
and each application binary. Note that the first stage bootloader does not require signing as it is ROM code thus cannot
be changed.
A new RSA based Secure Boot verification scheme (Secure Boot V2) has been introduced on the ESP32 (ECO3
onwards), ESP32-S2, ESP32-S3 and ESP32-C3 (ECO3 onwards).
The Secure Boot process on the ESP32-S2 involves the following steps: 1. When the first stage bootloader loads the
second stage bootloader, the second stage bootloader' s RSA-PSS signature is verified. If the verification is successful,
the second stage bootloader is executed. 2. When the second stage bootloader loads a particular application image,
the application's RSA-PSS signature is verified. If the verification is successful, the application image is executed.

4.25.2 Advantages

• The RSA public key is stored on the device. The corresponding RSA private key is kept at a secret place and
is never accessed by the device.
• Up to three public keys can be generated and stored in the chip during manufacturing.
• ESP32-S2 provides the facility to permanently revoke individual public keys. This can be configured conser-
vatively or aggressively.
• Conservatively - The old key is revoked after the bootloader and application have successfully migrated to a
new key. Aggressively - The key is revoked as soon as verification with this key fails.
• Same image format and signature verification method is applied for applications and software bootloader.
• No secrets are stored on the device. Therefore, it is immune to passive side-channel attacks (timing or power
analysis, etc.)

4.25.3 Secure Boot V2 Process

This is an overview of the Secure Boot V2 Process. Instructions how to enable Secure Boot are supplied in section
How To Enable Secure Boot
Secure Boot V2 verifies the bootloader image and application binary images using a dedicated signature block. Each
image has a separately generated signature block which is appended to the end of the image.
Up to 3 signature blocks can be appended to the bootloader or application image in ESP32-S2.
Each signature block contains a signature of the preceding image as well as the corresponding RSA-3072 public key.
For more details about the format, refer to
the eFuse.
The application image is not only verified on every boot but also on each over the air (OTA) update. If the cur-
rently selected OTA app image cannot be verified, the bootloader will fall back and look for another correctly signed
application image.
The Secure Boot V2 process follows these steps:
Espressif Systems
V2.
Signature Block
Submit Document Feedback
Format. A digest of the RSA-3072 public key is stored in
1456
Release v4.4

Advertisement

Table of Contents
loading
Need help?

Need help?

Do you have a question about the ESP32-S2 and is the answer not in the manual?

Questions and answers

Table of Contents

Save PDF