Skip to content

Commit 8ff3dbc

Browse files
committed
secure_boot: Added Kconfig option for aggressive key revoke
Applicable to S2, C3, and S3
1 parent c1d3b29 commit 8ff3dbc

File tree

2 files changed

+30
-0
lines changed

2 files changed

+30
-0
lines changed

components/bootloader/Kconfig.projbuild

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -614,6 +614,22 @@ menu "Security features"
614614

615615
Refer to the Secure Boot section of the ESP-IDF Programmer's Guide for this version before enabling.
616616

617+
config SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE
618+
bool "Enable Aggressive key revoke strategy"
619+
depends on SECURE_BOOT && (IDF_TARGET_ESP32S2 || IDF_TARGET_ESP32C3 || IDF_TARGET_ESP32S3)
620+
default N
621+
help
622+
If this option is set, ROM bootloader will revoke the public key digest burned in efuse block
623+
if it fails to verify the signature of software bootloader with it.
624+
Revocation of keys does not happen when enabling secure boot. Once secure boot is enabled,
625+
key revocation checks will be done on subsequent boot-up, while verifying the software bootloader
626+
627+
This feature provides a strong resistance against physical attacks on the device.
628+
629+
NOTE: Once a digest slot is revoked, it can never be used again to verify an image
630+
This can lead to permanent bricking of the device, in case all keys are revoked
631+
because of signature verification failure.
632+
617633
choice SECURE_BOOTLOADER_KEY_ENCODING
618634
bool "Hardware Key Encoding"
619635
depends on SECURE_BOOTLOADER_REFLASHABLE

docs/en/security/secure-boot-v2.rst

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -330,6 +330,9 @@ Secure Boot Best Practices
330330
* Applications should be signed with only one key at a time, to minimize the exposure of unused private keys.
331331
* The bootloader can be signed with multiple keys from the factory.
332332

333+
Conservative approach:
334+
~~~~~~~~~~~~~~~~~~~~~~
335+
333336
Assuming a trusted private key (N-1) has been compromised, to update to new key pair (N).
334337

335338
1. Server sends an OTA update with an application signed with the new private key (#N).
@@ -342,6 +345,17 @@ Secure Boot Best Practices
342345

343346
* A similar approach can also be used to physically re-flash with a new key. For physical re-flashing, the bootloader content can also be changed at the same time.
344347

348+
Aggressive approach:
349+
~~~~~~~~~~~~~~~~~~~~
350+
351+
ROM code has an additional feature of revoking a public key digest if the signature verification fails.
352+
353+
To enable this feature, you need to burn SECURE_BOOT_AGGRESSIVE_REVOKE efuse or enable :ref:`CONFIG_SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE`
354+
355+
Key revocation is not applicable unless secure boot is successfully enabled. Also, a key is not revoked in case of invalid signature block or invalid image digest, it is only revoked in case the signature verification fails, i.e. revoke key only if failure in step 3 of :ref:`verify_image`
356+
357+
Once a key is revoked, it can never be used for verfying a signature of an image. This feature provides strong resistance against physical attacks on the device. However, this could also brick the device permanently if all the keys are revoked because of signature verification failure.
358+
345359
.. _secure-boot-v2-technical-details:
346360

347361
Technical Details

0 commit comments

Comments
 (0)