Trying to understand secure boot v2 and flash encryption
Posted: Sun Mar 22, 2026 8:11 pm
It's been a long time! I last seriously used IDF V4.0 for a large project. Now I'm working on securing the firmware of a current project developed under IDF V5.5.1, i.e. micropython app and my micropython scripts.
I have been reading ESP's docs on:
1. flash encryption
2. secure boot v2
I want to start this thread to get some help with my understanding.
Regarding flash encryption, it seems that it is using a symmetric 256-bit AES key. This key is stored in e-fuse block1. It is used to encrypt the plaintext bootloader, partition table, and app partition upon first boot after flashing. The second-stage bootloader does the encryption and then disables block1 read/write before resetting. So, it encrypts itself, and other partitions that need encrypting. If there's no key in block1, the bootloader generates one to save it there. After this process, nobody can read back an unencrypted partition including the developer. Is my understanding so far correct?
I have a concern after reading some details, regarding the MMU will always encrypt/decrypt any write/read. I don't know what functions micropython calls to access the VFS partition that I use to store python scripts and configs. I suppose they used the modules provided by ESP-IDF like I used to do. If that's the case, will the read/write correctly interpret an unencrypted partition? If I mark that partition as encrypted, I assume the second-stage bootloader encrypts it on first boot. Will it?
I have other questions but I'll wait for some answers to the above ones. Thanks for your time!
I have been reading ESP's docs on:
1. flash encryption
2. secure boot v2
I want to start this thread to get some help with my understanding.
Regarding flash encryption, it seems that it is using a symmetric 256-bit AES key. This key is stored in e-fuse block1. It is used to encrypt the plaintext bootloader, partition table, and app partition upon first boot after flashing. The second-stage bootloader does the encryption and then disables block1 read/write before resetting. So, it encrypts itself, and other partitions that need encrypting. If there's no key in block1, the bootloader generates one to save it there. After this process, nobody can read back an unencrypted partition including the developer. Is my understanding so far correct?
I have a concern after reading some details, regarding the MMU will always encrypt/decrypt any write/read. I don't know what functions micropython calls to access the VFS partition that I use to store python scripts and configs. I suppose they used the modules provided by ESP-IDF like I used to do. If that's the case, will the read/write correctly interpret an unencrypted partition? If I mark that partition as encrypted, I assume the second-stage bootloader encrypts it on first boot. Will it?
I have other questions but I'll wait for some answers to the above ones. Thanks for your time!