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

[fevang]

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!

[Sprite]

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.

[fevang]

Fascinating. Thanks for the quick feedback

[Dracarris]

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?

[Sprite]

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.