UART bootloader security

[devanl]

Is the ROM serial bootloader for the ESP32 rev 3 reasonably secure if left enabled?
That is, if I set the efuses as follows:

Code: Select all

Efuse Name		Description					Value	R/W
FLASH_CRYPT_CNT		Flash encryption mode counter			127	R/-
UART_DOWNLOAD_DIS	Disable UART download mode			False	R/-
FLASH_CRYPT_CONFIG	Flash encryption config (key tweak bits)	15	R/-
CONSOLE_DEBUG_DISABLE	Disable ROM BASIC interpreter fallback		True	R/-
JTAG_DISABLE		Disable JTAG					True	R/-
DISABLE_DL_ENCRYPT	Disable flash encryption in UART bootloader	True	R/-
DISABLE_DL_DECRYPT	Disable flash decryption in UART bootloader	True	R/-
DISABLE_DL_CACHE	Disable flash cache in UART bootloader		True	R/-

Here, the flash decryption / encryption features are disabled (also not shown, secure boot v2 is enabled), but the UART bootloader is still able to download / upload the encrypted contents. I understand that the power supply glitching attack on rev 2 and earlier were able to bypass the decryption protection settings and that rev 3 has some mitigations and thus the absolute safest option would be to turn off the download mode entirely using UART_DOWNLOAD_DIS. However, if I want to retain the option to use the bootloader (using a saved per-device flash encryption key), is the rev 3 serial bootloader robust enough that flash encryption isn't thwarted by leaving the bootloader enabled?

For example, if someone were to use their own RAM flash programming stub, would it be able to read out the decrypted flash contents, or would it still be limited to seeing the encrypted flash the same way as the UART bootloader itself? Is it expected that an attacker would likely to be able to bypass the decryption protection settings on the rev 3 bootloader and that turning it off entirely is the only reliable way to preserve flash encryption, or can I trust that it is reasonably secure?

[ESP_Angus]

Hi devanl,

For example, if someone were to use their own RAM flash programming stub, would it be able to read out the decrypted flash contents, or would it still be limited to seeing the encrypted flash the same way as the UART bootloader itself?

This particular method doesn't work. With the DISABLE_DL_ENCRYPT and DISABLE_DL_DECRYPT efuses burned, the flash encryption module is disabled in hardware when the chip bootstraps into the download mode (based on the GPIO pins at SoC reset time). The only way to re-enable it is to trigger a full system reset into a different boot mode.

Is it expected that an attacker would likely to be able to bypass the decryption protection settings on the rev 3 bootloader and that turning it off entirely is the only reliable way to preserve flash encryption, or can I trust that it is reasonably secure?

Security researchers have shown that on ESP32 they can use the UART download mode to seed the internal RAM with some chosen values, and then reset and use fault injection to cause the CPU to skip some of the normal boot instructions and instead jump to the value seeded in RAM. See our advisory here for CVE-2020-13629 (PDF).

This research was using a revision 1 ESP32, and the ROM code function targeted with the fault is not used if Secure Boot V2 is enabled. We don't know of any similar vulnerability if Secure Boot V2 is used, the verification and loading process is different. If Secure Boot V2 is not being used then the same approach described in the advisory is probably reproducible in the same way on ESP32 V3.

The recommended approach for ESP32 V3 is to enable Secure Boot V2, Flash Encryption, and to disable the UART Download Mode. This maximizes the number of protections in place, and makes the smallest possible "attack surface" for an attacker. However enabling Secure Boot V2 & Flash Encryption is sufficient against all the attacks we know of.

You should consider how motivated/resourced someone attacking your particular product will be, and what tradeoffs of functionality vs security may be acceptable. Note that even if you don't disable UART Download Mode initially, if you have an OTA update mechanism or similar then it's possible to flash an app which disables this mode in the field.

[devanl]

Hi Angus,

Thanks for the explanation. Knowing more about how the security features work makes me a bit more comfortable making some of the tradeoffs between security and other requirements.