Remote Signing Of Images; Secure Boot Best Practices; Key Management; Multiple Keys - Espressif ESP32-S2 Programming Manual

Chapter 4. API Guides

4.25.12 Remote Signing of Images

For production builds, it can be good practice to use a remote signing server rather than have the signing key on the
build machine (which is the default esp-idf Secure Boot configuration). The espsecure.py command line program can
be used to sign app images & partition table data for Secure Boot, on a remote system.
To use remote signing, disable the option "Sign binaries during build". The private signing key does not need to
be present on the build system.
After the app image and partition table are built, the build system will print signing steps using espsecure.py:
espsecure.py sign_data --version
The above command appends the image signature to the existing binary. You can use the –output argument to write
the signed binary to a separate file:
espsecure.py sign_data --version
BINARY_FILE BINARY_FILE
→

4.25.13 Secure Boot Best Practices

• Generate the signing key on a system with a quality source of entropy.
• Keep the signing key private at all times. A leak of this key will compromise the Secure Boot system.
• Do not allow any third party to observe any aspects of the key generation or signing process using espsecure.py.
Both processes are vulnerable to timing or other side-channel attacks.
• Enable all Secure Boot options in the Secure Boot Configuration. These include flash encryption, disabling of
JTAG, disabling BASIC ROM interpreter, and disabling the UART bootloader encrypted flash access.
• Use Secure Boot in combination with

4.25.14 Key Management

• Between 1 and 3 RSA-3072 public key pairs (Keys #0, #1, #2) should be computed independently and stored
separately.
• The KEY_DIGEST eFuses should be write protected after being programmed.
• The unused KEY_DIGEST slots must have their corresponding KEY_REVOKE eFuse burned to permanently
disable them. This must happen before the device leaves the factory.
• The eFuses can either be written by the software bootloader during during first boot after enabling "Secure
Boot V2"from menuconfig or can be done using espefuse.py which communicates with the serial bootloader
program in ROM.
• The KEY_DIGESTs should be numbered sequentially beginning at key digest #0. (i.e., if key digest #1 is used,
key digest #0 should be used. If key digest #2 is used, key digest #0 & #1 must be used.)
• The software bootloader (non OTA upgradeable) is signed using at least one, possibly all three, private keys
and flashed in the factory.
• Apps should only be signed with a single private key (the others being stored securely elsewhere), however they
may be signed with multiple private keys if some are being revoked (see Key Revocation, below).

4.25.15 Multiple Keys

• The bootloader should be signed with all the private key(s) that are needed for the life of the device, before it
is flashed.
• The build system can sign with at most one private key, user has to run manual commands to append more
signatures if necessary.
• You can use the append functionality of espsecure.py, this command would also printed at the end of the Secure Bo
espsecure.py sign_data
signed_bootloader.bin build/bootloader/bootloader.bin
Espressif Systems
2 --keyfile PRIVATE_SIGNING_KEY BINARY_FILE
2 --keyfile PRIVATE_SIGNING_KEY --output SIGNED_
flash encryption to prevent local readout of the flash contents.
-k secure_boot_signing_key2.pem
1460
Submit Document Feedback
-v 2 –append_signatures
Release v4.4
-o