ECDSA based Secure Boot V2 is not functional for certain input vectors on ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure Boot V2 is the recommended scheme where the SoC supports it. This issue will be fixed in a future hardware ECO revision; more details will be shared through the hardware errata document. A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default. The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not supported in their SoC capabilities instead of using the option above. As ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on it; ESP32-H21 retains RSA based Secure Boot V2. The security documentation keeps the ECDSA Secure Boot V2 content visible and adds a warning describing the limitation (including that ECDSA Secure Boot V2 on ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA accordingly.
| Supported Targets | ESP32 | ESP32-C2 | ESP32-C3 | ESP32-C5 | ESP32-C6 | ESP32-C61 | ESP32-H2 | ESP32-H21 | ESP32-P4 | ESP32-S2 | ESP32-S3 |
|---|
Secure Boot
The example checks if the secure boot feature is enabled/disabled and if enabled prints the secure boot version (Version 1 / Version 2) and FLASH_CRYPT_CNT eFuse value.
How to use example
Hardware Required
It is recommended to use Secure Boot V2 from ESP32-ECO3 onwards.
Configure the project
idf.py menuconfig
-
Set serial port under Serial Flasher Options.
-
Enable the
Enable hardware Secure Bootunder Security Features. Default version for ESP32 is Secure Boot V1. The chip revision should be changed to revision 3(ESP32- ECO3) to view the Secure Boot V2 option. -
To change the chip revision, set "Component Config" -> "ESP32- Specific"->"Minimum Supported ESP32 Revision" to Rev 3. Now, set Secure Boot V2 option can now be enabled under "Enable hardware Secure Boot in bootloader" -> "Secure Boot Version".
-
Specify the apt secure boot signing key path. If not present generate one using
espsecure generate-signing-key --version {VERSION} secure_boot_signing_key.pem -
Ensure Bootloader log verbosity is Info under Bootloader config.
-
Select Single factory app, no OTA under Partition Table options. Change the partition table offset to 0xb000 from 0x8000 since after enabling secure boot the size of bootloader is increased.
Build and Flash
-
The below steps can be used in any application to enable secure boot.
-
Secure Boot is an irreversible operation, please read the Secure Boot section in ESP-IDF Programming Manual.
-
Secure boot will be enabled on building the project after enabling hardware secure boot feature in Security features in menuconfig and flashing it to the board FOR THE FIRST TIME.
-
The bootloader will not be automatically flashed when secure boot is enabled. Running
idf.py bootloaderwill print a command to flash the bootloader on the ESP32. Run this command manually to flash the bootloader.
Run following command to program the partition table and application on the ESP32 and monitor the output:
idf.py -p PORT flash monitor
(To exit the serial monitor, type Ctrl-].)
See the Getting Started Guide for full steps to configure and use ESP-IDF to build projects.
- On subsequent boots, the secure boot hardware will verify the software bootloader has not changed and the software bootloader will verify the signed app image (using the validated public key portion of its appended signature block).
Example Output
Troubleshooting
Secure Boot tests (For internal use only)
Purpose of the test case (pytest_secure_boot.py) is to test the secure boot implementation and detect if it is broken. It consists of positive and negative test cases.
Hardware required
-
FPGA setup with the target image
-
COM port for programming and export it as ESPPORT e.g
export ESPPORT=/dev/ttyUSB0 -
Use another COM port for resetting efuses and connect its DTR pin to efuse reset pin on the FPGA board. Export it as EFUSEPORT e.g
export EFUSEPORT=/dev/ttyUSB1
Configure the project
export IDF_ENV_FPGA=1
idf.py set-target {target}
idf.py menuconfig
Under Security features
-
Enable the
Enable hardware Secure Boot -
Set the secure boot signing key
-
Set UART ROM download mode to ENABLED (Required for the script to read the EFUSE)
-
Install pytest requirements
bash $IDF_PATH/install.sh --enable-ci
Build and test
-
Build the example
idf.py build -
Run the example test
pytest --target {target}