ESP32 Forum

Posted: **Wed Apr 28, 2021 12:02 am**

After reading the Flash Encryption and Secure Boot documents here https://docs.espressif.com/projects/esp ... ption.html and https://docs.espressif.com/projects/esp ... t-v1.html , I am rather confused on the benefits of secure boot.

I understand the benefits of using flash encryption + secure boot over just secure boot as explained here:

If secure boot is used without Flash Encryption, it is possible to launch “time-of-check to time-of-use” attack, where flash contents are swapped after the image is verified and running. Therefore, it is recommended to use both the features together.

Which attacks are protected against by enabling flash encryption + secure boot over just flash encryption?
Does it act simply as a backup incase the flash encryption key is determined?

Thank you!

Posted: **Wed Apr 28, 2021 5:51 am**

Without secure boot, if there's a flaw in the firmware, an attacker may be able to achieve persistence (as in: having the ability to keep the device infected even after power-off/power-on) by injecting code that the ESP32 will run somehow, then using that to re-write the program on the flash. As the code runs on the ESP32, the flash encrypts the attackers code automatically on the fly; flash encryption is moot that way. If secure boot is enabled, after a reboot the signature check it does will fail and the ESP32 will refuse to boot the infected code.

Posted: **Thu Apr 29, 2021 4:40 pm**

Fascinating. Thanks for the quick feedback

Posted: **Fri Mar 28, 2025 9:41 am**

Without secure boot, if there's a flaw in the firmware, an attacker may be able to achieve persistence (as in: having the ability to keep the device infected even after power-off/power-on) by injecting code that the ESP32 will run somehow, then using that to re-write the program on the flash. As the code runs on the ESP32, the flash encrypts the attackers code automatically on the fly; flash encryption is moot that way. If secure boot is enabled, after a reboot the signature check it does will fail and the ESP32 will refuse to boot the infected code.

Interesting - But in that scenario, why would an attacker even need to reboot the chip at all? If the flash is compromised, the attacker can just jump to his binary and achieve arbitrary code execution?

So in short, the only thing secure boot really achieves is preventing flash-persistent attacks?

Posted: **Sat Mar 29, 2025 7:08 am**

So in short, the only thing secure boot really achieves is preventing flash-persistent attacks?

Yep, but note that this is not a small thing. It's the difference between an attack that cannot be stopped and festers in a device for as long as it lives, and an attack that is gone the first time the user switches off the power (e.g. because the attack breaks user functionality) with (hopefully) the device reverting to factory firmware.

ESP32 Forum

Security benefits of enabling secure boot if flash encryption is already enabled

Security benefits of enabling secure boot if flash encryption is already enabled

Re: Security benefits of enabling secure boot if flash encryption is already enabled

Re: Security benefits of enabling secure boot if flash encryption is already enabled

Re: Security benefits of enabling secure boot if flash encryption is already enabled

Re: Security benefits of enabling secure boot if flash encryption is already enabled