Key Revocation; Technical Details - Espressif ESP32-S2 Programming Manual

Chapter 4. API Guides
• While signing with multiple private keys, it is recommended that the private keys be signed independently, if
possible on different servers and stored separately.
• You can check the signatures attached to a binary using - espsecure.py signature_info_v2 datafile.bin

4.25.16 Key Revocation

• Keys are processed in a linear order. (key #0, key #1, key #2).
• Applications should be signed with only one key at a time, to minimize the exposure of unused private keys.
• The bootloader can be signed with multiple keys from the factory.
Conservative approach:
Assuming a trusted private key (N-1) has been compromised, to update to new key pair (N).
1. Server sends an OTA update with an application signed with the new private key (#N).
2. The new OTA update is written to an unused OTA app partition.
3. The new application' s signature block is validated. The public keys are checked against the digests programmed
in the eFuse & the application is verified using the verified public key.
4. The active partition is set to the new OTA application's partition.
5. Device resets, loads the bootloader (verified with key #N-1) which then boots new app (verified with key #N).
6. The new app verifies bootloader with key #N (as a final check) and then runs code to revoke key #N-1 (sets
KEY_REVOKE eFuse bit).
7. The API esp_ota_revoke_secure_boot_public_key() can be used to revoke the key #N-1.
• A similar approach can also be used to physically re-flash with a new key. For physical re-flashing, the boot-
loader content can also be changed at the same time.
Aggressive approach:
ROM code has an additional feature of revoking a public key digest if the signature verification fails.
To enable this feature, you need to burn SECURE_BOOT_AGGRESSIVE_REVOKE efuse or enable
FIG_SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE
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
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.

4.25.17 Technical Details

The following sections contain low-level reference descriptions of various Secure Boot elements:
Manual Commands
Secure boot is integrated into the esp-idf build system, so make or idf.py build will sign an app image and
idf.py bootloader will produce a signed bootloader if secure signed binaries on build is enabled.
However, it is possible to use the espsecure.py tool to make standalone signatures and digests.
To sign a binary image:
espsecure.py sign_data --version
signed.bin image-unsigned.bin
→
Espressif Systems
Verifying an Image
2 --keyfile ./my_signing_key.pem --output ./image_
1461
Submit Document Feedback
CON-
Release v4.4