Chapter 4. API Guides
• R/W access control is available for all the eFuse bits listed in the table above.
• The default value of these bits is 0 afer manufacturing.
Read and write access to eFuse bits is controlled by appropriate fields in the registers WR_DIS and RD_DIS.
For more information on ESP32-S2 eFuses, see eFuse manager. To change protection bits of eFuse field using
espefuse.py, use these two commands: read_protect_efuse and write_protect_efuse. Example espefuse.py
write_protect_efuse DISABLE_DL_ENCRYPT.
4.13.3 Flash Encryption Process
Assuming that the eFuse values are in their default states and the firmware bootloader is compiled to support flash
encryption, the flash encryption process executes as shown below:
1. On the first power-on reset, all data in flash is un-encrypted (plaintext). The ROM bootloader loads the firmware
bootloader.
2. Firmware bootloader reads the SPI_BOOT_CRYPT_CNT eFuse value (0b000). Since the value is 0 (even
number of bits set), it configures and enables the flash encryption block. For more information on the flash
encryption block, see ESP32-S2 Technical Reference Manual > eFuse Controller (eFuse) > Auto Encryption
Block [PDF].
3. Firmware bootloader uses RNG (random) module to generate an 256 bit or 512 bit key, depending on the
value of Size of generated AES-XTS key, and then writes it into respectively one or two BLOCK_KEYN eFuses.
The software also updates the KEY_PURPOSE_N for the blocks where the keys were stored. The key can-
not be accessed via software as the write and read protection bits for one or two BLOCK_KEYN eFuses are
set. KEY_PURPOSE_N field is write-protected as well. The flash encryption operations happen entirely by
hardware, and the key cannot be accessed via software.
4. Flash encryption block encrypts the flash contents - the firmware bootloader, applications and partitions marked
as encrypted. Encrypting in-place can take time, up to a minute for large partitions.
5. Firmware bootloader sets the first available bit in SPI_BOOT_CRYPT_CNT (0b001) to mark the flash contents
as encrypted. Odd number of bits is set.
6. For Development Mode, the firmware bootloader allows the UART bootloader to re-flash encrypted bi-
naries. Also, the SPI_BOOT_CRYPT_CNT eFuse bits are NOT write-protected. In addition, the
firmware bootloader by default sets the eFuse bits DIS_BOOT_REMAP, DIS_DOWNLOAD_ICACHE,
DIS_DOWNLOAD_DCACHE, HARD_DIS_JTAG and DIS_LEGACY_SPI_BOOT.
7. For Release Mode, the firmware bootloader sets all the eFuse bits set under development mode as well as
DIS_DOWNLOAD_MANUAL_ENCRYPT. It also write-protects the SPI_BOOT_CRYPT_CNT eFuse bits. To
modify this behavior, see Enabling UART Bootloader Encryption/Decryption.
8. The device is then rebooted to start executing the encrypted image. The firmware bootloader calls the flash
decryption block to decrypt the flash contents and then loads the decrypted contents into IRAM.
During the development stage, there is a frequent need to program different plaintext flash images and test the flash
encryption process. This requires that Firmware Download mode is able to load new plaintext images as many times
as it might be needed. However, during manufacturing or production stages, Firmware Download mode should not
be allowed to access flash contents for security reasons.
Hence, two different flash encryption configurations were created: for development and for production. For details
on these configurations, see Section Flash Encryption Configuration.
4.13.4 Flash Encryption Configuration
The following flash encryption modes are available:
• Development Mode - recommended for use ONLY DURING DEVELOPMENT, as it does not prevent modi-
fication and readout of encrypted flash contents.
• Release Mode - recommended for manufacturing and production to prevent physical readout of encrypted flash
contents.
This section provides information on the mentioned flash encryption modes and step by step instructions on how to
use them.
Espressif Systems 1344
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General