I (51) boot: # Label Usage Type ST Offset Length I (30) boot: Enabling RNG early entropy source. Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H. idf_monitor on /dev/cu.SLAB_USBtoUART 115200. For details on these configurations, see Section Flash Encryption Configuration. Hence, two different flash encryption configurations were created: for development and for production.
#ENCRYPTO LOCK DOWNLOAD DOWNLOAD#
However, during manufacturing or production stages, Firmware Download mode should not be allowed to access flash contents for security reasons. This requires that Firmware Download mode is able to load new plaintext images as many times as it might be needed. The firmware bootloader calls the flash decryption block to decrypt the flash contents and then loads the decrypted contents into IRAM.ĭuring the development stage, there is a frequent need to program different plaintext flash images and test the flash encryption process. The device is then rebooted to start executing the encrypted image. To modify this behavior, see Enabling UART Bootloader Encryption/Decryption. It also write-protects the FLASH_CRYPT_CNT eFuse bits. Also, the FLASH_CRYPT_CNT eFuse bits are NOT write-protected.įor Release Mode, the firmware bootloader sets the eFuse bits DISABLE_DL_ENCRYPT, DISABLE_DL_DECRYPT, and DISABLE_DL_CACHE to 1 to prevent the UART bootloader from decrypting the flash contents. Odd number of bits is set.įor Development Mode, the firmware bootloader sets only the eFuse bits DISABLE_DL_DECRYPT and DISABLE_DL_CACHE to allow the UART bootloader to re-flash encrypted binaries. Encrypting in-place can take time, up to a minute for large partitions.įirmware bootloader sets the first available bit in FLASH_CRYPT_CNT (0b0000001) to mark the flash contents as encrypted. The flash encryption operations happen entirely by hardware, and the key cannot be accessed via software.įlash encryption block encrypts the flash contents - the firmware bootloader, applications and partitions marked as encrypted.
#ENCRYPTO LOCK DOWNLOAD SOFTWARE#
The key cannot be accessed via software as the write and read protection bits for the flash_encryption eFuse are set. įirmware bootloader uses RNG (random) module to generate an AES-256 bit key and then writes it into the flash_encryption eFuse.
#ENCRYPTO LOCK DOWNLOAD MANUAL#
For more information on the flash encryption block, see ESP32 Technical Reference Manual > eFuse Controller (eFuse) > Flash Encryption Block. It also sets the FLASH_CRYPT_CONFIG eFuse to 0xF. Since the value is 0 (even number of bits set), it configures and enables the flash encryption block.
The ROM bootloader loads the firmware bootloader.įirmware bootloader reads the FLASH_CRYPT_CNT eFuse value ( 0b0000000). On the first power-on reset, all data in flash is un-encrypted (plaintext). If odd number of bits set (1, 3, 5, 7) - do not encrypt flash at boot time.Īssuming 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: If even number of bits set (0, 2, 4, 6) - encrypt flash at boot time. If set, disables flash decryption while running in UART Firmware Download mode.Įnables/disables encryption at boot time. If set, disables flash encryption operation while running in Firmware Download mode. Final AES key is derived based on the FLASH_CRYPT_CONFIG value. Possible values: 0 for 256 bits, 1 for 192 bits, 2 for 128 bits. eFuses Used in Flash Encryption Ĭontrols actual number of block1 bits used to derive final 256-bit AES key. For usage in the eFuse API, modify the name by adding ESP_EFUSE_, for example: esp_efuse_read_field_bit(ESP_EFUSE_DISABLE_DL_ENCRYPT). The names in eFuse column are also used by espefuse.py tool. The list of eFuses and their descriptions is given in the table below. The flash encryption operation is controlled by various eFuses available on ESP32.
0 kommentar(er)
