The esp_secure_boot_verify_sbv2_signature_block() and esp_secure_boot_verify_rsa_signature_block()
APIs need and use the verified_digest argument only for BOOTLOADER_BUILD, but the argument is
not used in the application code, and the value present in verified_digest is considered invalid.
Thus, allow passing NULL as the verified_digest parameter to help some save space.
- Secure boot V2 verification failed when multiple keys are used to sign the bootloader
and the application is signed with a key other than the first key that is used to
sign the bootloader.
- The issue was introduced as a regression from the commit `ff16ce43`.
- Added a QEMU test for recreating the issue.
- Made SECURE_BOOT_FLASH_BOOTLOADER_DEFAULT independent of SECURE_BOOT_BUILD_SIGNED_BINARIES.
Added an API to verify the bootloader and app image before revoking the key in Secure Boot V2.
This will help in preventing the device to be bricked if the bootloader/application cannot be
verified by any other keys in efuse
The following two functions in bootloader_support are private now:
* esp_secure_boot_verify_sbv2_signature_block()
* esp_secure_boot_verify_rsa_signature_block()
They have been moved into private header files
inside bootloader_private/
* Removed bootloader_reset_reason.h and
bootloader_common_get_reset_reason() completely.
Alternative in ROM component is available.
* made esp_efuse.h independent of target-specific rom header
1) Fix build issue in mbedtls
2) skip the public headers check in IDF
3)Update Kconfig Macros
4)Remove deprecated config options
5) Update the sha API according to new nomenclature
6) Update mbedtls_rsa_init usage
7) Include mbedtls/build_info.h instead of mbedtls/config.h
8) Dont include check_config.h
9) Add additional error message in esp_blufi_api.h
This commit fixes issue where empty (unprogrammed) digest slot out of
multiple supported (e.g. 3 for ESP32-C3) could cause issue in
workflow enablement process.
Notes:
1. This issue was applicable for chips supporting "secure-boot-v2"
scheme with multiple digests slots
2. This issue was affecting only manual workflow, where digest of
public was pre-flashed in efuse
3. Change in "flash_encrypt.c" is only for additional safety purpose
As this mode uses the public keys attached to the existing app's signatures to
verify the next app, checking that a signature block is found on boot prevents
the possibility of deploying a non-updatable device from the factory.
harshal.patil