Chapter 4. API Guides
4.25.6 Verifying an Image
An image is “verified”if the public key stored in any signature block is valid for this device, and if the stored
signature is valid for the image data read from flash.
1. Compare the SHA-256 hash digest of the public key embedded in the bootloader’s signature block with the
digest(s) saved in the eFuses. If public key’s hash doesn’t match any of the hashes from the eFuses, the
verification fails.
2. Generate the application image digest and match it with the image digest in the signature block. If the digests
don’t match, the verification fails.
3. Use the public key to verify the signature of the bootloader image, using RSA-PSS (section 8.1.2 of RFC8017)
with the image digest calculated in step (2) for comparison.
4.25.7 Bootloader Size
Enabling Secure boot and/or flash encryption will increase the size of bootloader, which might require updating
partition table offset. See Bootloader Size.
4.25.8 eFuse usage
• SECURE_BOOT_EN - Enables Secure Boot protection on boot.
• KEY_PURPOSE_X - Set the purpose of the key block on ESP32-S2 by programming SE-
CURE_BOOT_DIGESTX (X = 0, 1, 2) into KEY_PURPOSE_X (X = 0, 1, 2, 3, 4, 5). Example: If
KEY_PURPOSE_2 is set to SECURE_BOOT_DIGEST1, then BLOCK_KEY2 will have the Secure Boot
V2 public key digest. The write-protection bit must be set (this field does not have a read-protection bit).
• BLOCK_KEYX - The block contains the data corresponding to its purpose programmed in
KEY_PURPOSE_X. Stores the SHA-256 digest of the public key. SHA-256 hash of public key mod-
ulus, exponent, pre-calculated R & M’values (represented as 776 bytes –offsets 36 to 812 - as per the
Signature Block Format) is written to an eFuse key block. The write-protection bit must be set, but the
read-protection bit must not.
• KEY_REVOKEX - The revocation bits corresponding to each of the 3 key block. Ex. Setting
KEY_REVOKE2 revokes the key block whose key purpose is SECURE_BOOT_DIGEST2.
• SECURE_BOOT_AGGRESSIVE_REVOKE - Enables aggressive revocation of keys. The key is revoked as
soon as verification with this key fails.
To ensure no trusted keys can be added later by an attacker, each unused key digest slot should be revoked
(KEY_REVOKEX). It will be checked during app startup in esp_secure_boot_init_checks() and fixed
unless CONFIG_SECURE_BOOT_ALLOW_UNUSED_DIGEST_SLOTS is enabled.
The key(s) must be readable in order to give software access to it. If the key(s) is read-protected then the software
reads the key(s) as all zeros and the signature verification process will fail, and the boot process will be aborted.
4.25.9 How To Enable Secure Boot V2
1. Open the Project Configuration Menu, in“Security features”set“Enable hardware Secure Boot in bootloader”
to enable Secure Boot.
2. The “Secure Boot V2”option will be selected and the “App Signing Scheme”would be set to RSA by
default.
3. Specify the path to Secure Boot signing key, relative to the project directory.
4. Select the desired UART ROM download mode in “UART ROM download mode”. By default, it is set
to“Permanently switch to Secure mode”which is generally recommended. For production devices, the most
secure option is to set it to “Permanently disabled”.
5. Set other menuconfig options (as desired). Pay particular attention to the“Bootloader Config”options, as you
can only flash the bootloader once. Then exit menuconfig and save your configuration.
6. The first time you run make or idf.py build, if the signing key is not found then an error message will
be printed with a command to generate a signing key via espsecure.py generate_signing_key.
Espressif Systems 1458
Submit Document Feedback
Release v4.4