Hello, I believe that if you enable it following the security guide workflows and do not burn any security efuses, both for SBv2 and FE, you do not disable any cache, but if you have SB and FE enabled, when everything is working, you burn the security efuses to properly protect the device.

Best ...

I am not sure if you have already checked it https://github.com/PBearson/ESP32_Secure_Boot_Tutorial? This may help you to some extent.


Hi @lichurbagan, this tutorial is great, everything is very well explained and it also links to another one about FE. Now I understand that I have to burn in ...

Hi, did you check this thoroughly? https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v1.html


Hello, I have read it carefully, which is why I find it difficult to carry out the Secure Boot version 1 activation and flash encryption process using a workflow with ...

Issue
The initial issue is that changing SPI_BOOT_CRYPT_CNT from 0b001 -> 0b011 changing my device from normal operation to getting invalid header: 0xeecc68ce which is quite unexpected since values 1 and 3 should have the same behavior.

Hello, flash encryption is active when the number of CNT ...

Hello everyone, I already know how to enable SB v2 and FE externally quite well. But now I want to take advantage of some chips I have, esp32 rev1.1, for which I want to enable, but externally, that is, using burn, sign, encrypt and flash commands, Secure Boot version 1, and I have some questions ...

@bram128,

I see,
there is no need to compile the firmware twice. It only needs to be compiled once.
The issue that you face is because, we combined the two workflows Secure Boot and Flash Encryption together to avoid duplicate instructions. I will update it once again to keep the separate ...

You are absolutely right, I tried to do it according to those workflows and all I managed to do was to spoil the boards. The documentation is wrong and they don't seem to have much interest in fixing it (IDF 5.4).
Now what I do is to encrypt in development mode and when I see that everything works ...

Interesting, I will keep it in mind. Thank you.

Specifically, an attacker could use the UART to overwrite a tiny bit of your code with their own program, in plaintext. The bootloader would notice, and (because developer mode) encrypts this tiny program; the ESP32 will happily run from it (because secureboot is not enabled). The tiny program can ...

the hacker could also read the contents of the flash both encrypted and unencrypted,
[...]
because what the hacker could not decrypt the app that is encrypted without having the key and that is what is important to me in this project.


I don't get your reasoning. Given the fact that the app is ...