Secure Downlaod mode & Secure Boot efuses on the ESP32-S3

[espresso64]

Hi,

I was wondering what are the risks if an ESP32-S3 device had ENABLE_SECURITY_DOWNLOAD set to False, but SECURE_BOOT_EN set to True. This would mean that Secure Download mode is disabled, but secure boot is enabled. For the sake of the argument, let's also say that ICACHE and DCACHE aren't readable (the necessary efuses are set).

What are the risks of running this setup? One will be able to read the efuses using efuses.py, write & read the SRAM, and read the encrypted flash. But running code loaded in RAM (using esptool.py load_ram) won't be possible without signing due to secure boot, right?

All I could think of, for now, is that one could read potential sensitive information from the SRAM, if it isn't cleared before entering the Download mode. I think the documentation does say that the SRAM isn't cleared when a non-Chip reset is performed, according to the Technical Reference Manual:

ESP32-S3 provides four reset levels, namely CPU Reset, Core Reset, System Reset, and Chip Reset.
All reset levels mentioned above (except Chip Reset) maintain the data stored in internal memory.

But can someone issue one of these resets and enter the Download mode without a chip reset? Will the BOOT button's state be read on a non-chip reset?

I've seen that the Technical Reference Manual and the ESP32-S3 Datasheet say the following:

The chip allows for configuring the following boot parameters through strapping pins and eFuse bits at power-up or a hardware reset, without microcontroller interaction.

Hardware reset is directly triggered by the circuit.

So I'm not really sure if there's any security issue with leaving ENABLE_SECURITY_DOWNLOAD to false or not.

Thanks in advance!

[Sprite]

Note that the SRAM technically isn't cleared at all; it's just that pulling down reset will power it down, degrading the contents of it. An attacker could potentially find some way (very short reset pulse, maybe something which triggers the wdt, ...) to keep the SRAM contents mostly intact.

[espresso64]

Makes sense. Thanks! So I guess it’s safe to assume that this setup isn’t very safe at all, so one better doesn’t leave non-Secure download mode enabled in production devices.

I was actually thinking of that, like a voltage glitch of some sort (even if the brownout-type of reset occurs, doesn’t really matter as it will read the strapping pins and enter download mode from that), but I was thinking there may be some clear-at-chip reset sequence. Couldn’t find it in the ESP ROM, though (I thought hmm, maybe it’s a hardware clear of some sort).

Maybe even pressing the reset button could constitute such a reset (does clicking the reset button stop power delivery to the internal SRAM?).

[espresso64]

Edit: I meant non-secure Download mode - people shouldn’t leave it in production