ESP32 Forum

I scanned through the datasheet and the ESP32 Technical Reference Manual and couldn't find any description of how Flash Encryption or Secure Boot work.

I've assumed that Flash Encryption and Secure Boot refer to the same feature. Is that true, or if not, what is the difference?

How does a developer take advantage of this feature? How are keys managed and how is protection assured?

Thanks,
-J.P.

I haven't had time to dive into this yet myself, but the source in https://github.com/espressif/esp-idf/tr ... r/src/main would hopefully explain a few things.

They're both aspects of the same thing, although you can use them separately. (Not sure how much sense that would make, though.) We're preparing documentation on that, at least an abstract of the hardware will be probably in the next techdoc.

Most likely... when enabled, the ROM loader will only boot a signed firmware image. The key and enable bit are stored in the efuse otp memory. Because the key is stored in the efuse and you can't boot an unsigned firmware and you can't turn off secure boot and you can't ask the ROM loader to dump it then it is secure. Then you can add encryption so that even directly reading the flash chip protects the data, which is only decrypted on load to ram/cache. Now whether you can have a mixture of encrypted and unencrypted sectors/partitions on the flash and where that is defined I'm not sure.

I assume you could use secure boot without encryption if you are only worried about preventing unsigned code from running. But using encryption without secure boot wouldn't be very secure since someone could replace the flash chip and run unsigned code to dump the encryption key.

WiFive wrote:
..
The key and enable bit are stored in the efuse otp memory.
Because the key is stored in the efuse and you can't boot an unsigned firmware and you can't turn off secure boot and you can't ask the ROM loader to dump it then it is secure.
..

..But using encryption without secure boot wouldn't be very secure since someone could replace the flash chip and run unsigned code to dump the encryption key.

Am not sure that you can dump the encryption key from stored in the efuse otp memory without secure boot if you try boot unsigned code.

I wait for the modul to do exact this example to try this.
Theoretically the efuse otp memory is secure - or do you think not? ( its a question )

the bootloader code is a fine start in esp-idf -
will try to "get/put more" from/to this

best wishes
rudi

edit:
the question is too,
how we handle plaintext code to crypt it with the key -
there must be stored the key in flash prozess - esptool does not support this just in time - or i am wrong -
sry - have not deeper read in this theme just in time - but think, there comes an "extended" for this in compile / link / flash prozess
- to encrypt firmware
- to signing firmware

rudi ;-) wrote:Theoretically the efuse otp memory is secure - or do you think not? ( its a question )

No I don't think so it is used for Mac address and general purpose. Maybe also have to disable JTAG to be secure.

Some parts of OTP, such as flash encryption key, are not readable from application. It is generated by hardware and stored in OTP. Flash decryption engine can load encryption key directly from OTP.

While you can't dump encryption key directly, you can use bootloader mode to dump contents of flash memory by uploading a small piece of code directly into IRAM. There are no provisions for code signing of code uploaded into IRAM.

So to make use of flash encryption one must also disable uart bootloader using one of the OTP bits.

If encryption flag in OTP is set, all code in flash will be encrypted. It is not possible to have one application binary in unencrypted form and another in encrypted form.

Encryption of uploaded code works on the chip itself. Second stage bootloader will check whether an application has already been encrypted. If it's not encrypted yet, bootloader will encrypt it in-place. It will also encrypt itself if necessary.
The reason this is implemented in the 2nd stage bootloader is to support mass-programming of flash chips (they can be programmed with the plaintext firmware and then will automatically be encrypted on first start).

All this will be described in more detail in the documentation.

Sounds good. So if enabled all flash r/w are encrypted including data? Is there a performance penalty?

There are normal spi_flash_read/write APIs which allow data to be read and written without encryption, and there are also spi_flash_read_decrypt/write_encrypt APIs (not merged into master yet), which decrypt/encrypt data. So you (or the one who implements a filesystem, for example) can decide. Encryption has some performance penalty, but i don't have any quantitative data on this. Decryption is handled by reading via cache, so there is not penalty in this case.

One thing to note: if you do use encryption, everything read via cache (ICACHE or DCACHE) will be decrypted. So it is not possible to read unencrypted data using cache if encryption is used.