ESP32 Forum

Is there a possible workflow to combine Secure Boot with Flash encryption while in Release Mode and be able to reuse same chip for multiple releases (for example we botched OTA update and have to recover the chip on site)? From my current understanding, even if you use reflashable bootloader, if you burn DISABLE_DL_ENCRYPT and DISABLE_DL_DECRYPT then such workflow is impossible.

Is there a way to keep DISABLE_DL_ENCRYPT unset while keeping the flash secure?

If secure boot is enabled then not burning DISABLE_DL_ENCRYPT is partially secure since only signed apps will be booted. However if used in combination with a timing attack to defeat secure boot it could allow arbitrary code execution and recovery of flash contents.

darkenkade wrote: ↑

Mon Nov 18, 2019 8:44 am

Is there a way to keep DISABLE_DL_ENCRYPT unset while keeping the flash secure?

In ESP-IDF V4.0 we added "development mode" for flash encryption which keeps DISABLE_DL_ENCRYPT unburned and allows writing new encrypted flash contents without needing the flash encryption key. This is not considered secure for production devices, but for the record you can use the same approach on earlier ESP-IDF if you configure it to not burn the DISABLE_DL_ENCRYPT efuse and then use "esptool.py .. write_flash --encrypt ..." to write new encrypted flash.

There are two reasons this setup is not secure:

1) A time-of-check-time-of-use attack as described by WiFive, possibility of substituting different flash contents after verification is done, while the firmware is running.
2) On current ESP32 revisions, fault injection attacks can be used to bypass secure boot. However this attack is not useful if flash encryption is permanently enabled. Therefore we recommend permanently enabling flash encryption when secure boot is in use. ESP32-D0WD-V3 will patch the fault injection vulnerability, but still advised to keep flash encryption fully enabled due to (1).

Depending on the size of your production deployment, the other option is to pre-generate and burn each device's flash encryption key before first boot, and record these keys somewhere.

Thank you for your response.
We wanted to avoid storing keys ourselves if possible, as it's one more thing to worry about. With your answers we will consider our options.