Efuse DISABLE_DL_DECRYPT

[Seungwhan]

Hi,

Let's say we
- enable flash encryption
- write 1 to DISABLE_DL_DECRYPT

What happens if we hold down GPIO0 and GPIO2 during reset?
Does the ROM Bootloader put the CPU into the state so that it can communicate with PC over UART?
(or in short, does CPU go into UART bootloader mode?)
Will the PC be able to send stub_code to CPU?
If so will the stub_code run?
Is it just that you can't read out Flash contents?
Or maybe you still can read the Flash contents but it will be just meaningless because of encryption.

Thanks for reading!

[ESP_Angus]

Hi Seungwhan,

Or maybe you still can read the Flash contents but it will be just meaningless because of encryption.

This is 100% correct.

On current ESP32 we don't prevent any other interactions in the UART download mode, but if DISABLE_DL_DECRYPT is set then flash decryption will not work in UART download mode, so the only data that can be read is the ciphertext (the same data could be read by attaching a SPI flash programmer to the flash chip and reading out this way.)

Note that it's important to burn both of the DISABLE_DL_ENCRYPT & DISABLE_DL_DECRYPT efuses to get this protection (otherwise attacker can write a small encrypted firmware that decrypts and dumps the rest of the firmware when booted). ESP-IDF should set these efuses automatically if you follow the flash encryption process in the docs.

[Seungwhan]

Thanks for the explanation, ESP_Angus.

But even with all the efuses like DISABLE_DL_DECRYPT, DISABLE_DL_ENCRYPT and DISABLE_DL_CACHE, the fact that attackers code can run on the CPU's RAM makes me a little nervous.
Wish you had capability to entirely block the uart bootloader.

[WiFive]

Yes, it is a valid point. There should be an efuse to completely disable uart... although researchers have also bypassed efuses with hardware attacks. Hopefully the new chip will have it along with the anti-glitch hardware.

[ChromaMaster]

Hi.

I've been doing some tests with a couple of modules. One of them has the DISABLE_DL_DECRYPT e-fuse enabled (set to 1) and the other one has that same e-fuse disabled (set to 0).

I've created a custom partition and I marked it as "encrypted" in the partitions.csv file. I've written some string data in it (using the --encrypt flag for the write_flash option on the esptool) and I've tried to read the data. This was done for both modules.

The thing is that the data is encrypted while it's written to the flash, right? (because of the --encrypt flag) but when I try to read it (using the read_flash command of the esptool) the data is still encrypted. If I write the data without the --encrypted flag the data inside the program is unusable (I guess the spi_flash_read_encrypted tries to decrypt unencrypted data or something).

I've been trying to figure out what that e-fuse does because it seems that doesn't care if its burn or not, the behaviour seems to be the same. Am I doing something wrong?

[WiFive]

I think that is just because esptool doesn't support encrypted flash readout