EasyManuals Logo

Espressif ESP32-S2 User Manual

Espressif ESP32-S2
1695 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Page #1471 background imageLoading...
Page #1471 background image
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 2 --keyfile PRIVATE_SIGNING_KEY BINARY_FILE
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 2 --keyfile PRIVATE_SIGNING_KEY --output SIGNED_
,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 flash encryption to prevent local readout of the flash contents.
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 V2from 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 Boot V2 enabled bootloader compilation.
espsecure.py sign_data -k secure_boot_signing_key2.pem -v 2 append_signatures -o
signed_bootloader.bin build/bootloader/bootloader.bin
Espressif Systems 1460
Submit Document Feedback
Release v4.4

Table of Contents

Questions and Answers:

Question and Answer IconNeed help?

Do you have a question about the Espressif ESP32-S2 and is the answer not in the manual?

Espressif ESP32-S2 Specifications

General IconGeneral
BrandEspressif
ModelESP32-S2
CategorySingle board computers
LanguageEnglish