ESP32 Forum

Posted: **Thu Aug 29, 2019 12:50 am**

By "config", do you mean by modifying sdkconfig? Are you referring to functions like "esp_partition_write" and "esp_spi_flash_write"? What about reading encrypted? (Not from the cache).

Sorry for not being clear, that's correct I mean the project config in the sdkconfig file.

Yes, the write functions need to follow a different code path to write encrypted data and this isn't compiled in if support is disabled.

Some different code is also compiled in for encrypted partition reads - in order to be transparently decrypted, the data needs to be mapped via the MMU flash cache feature (spi_flash_mmap). Whereas the plain "spi_flash_read" will read the exact contents of flash, which in this case would be the ciphertext.

Posted: **Thu Aug 29, 2019 1:37 am**

Great. Thanks again for the response.

Posted: **Fri Aug 19, 2022 7:51 pm**

Hi, I actually have a question related to this point. Regarding the first boot for flash encryption, are there any disadvantages to the following workflow? For the record, I am using ESP-IDF v3.2.

Generate flash encryption key, write to eFuse

Set FLASH_CRYPT_CNT to 1, FLASH_CRYPT_CONFIG to 15, set other relevant eFuses (DISABLE_DL_*, JTAG)

Pre-encrypt bootloader, app, and partition table, then flash everything to the chip

Hi Gerry,

The only disadvantage is that it's time consuming to burn all these efuses and easy to get this sequence wrong. If you miss one of the other relevant efuses then the device may not end up configured as you expect.

If you have some use cases for it being easier for doing it like this then we could add additional host-side support as well (for example a one-step espefuse.py command which sets everything correct). For now to keep things simple there's one supported method, and it's the "first boot" method.

(Also related: Is it still necessary to enable flash encryption for the bootloader if the above steps are followed?)
It's not supported/tested but I think the bootloader will work even without this config. The app needs to built with encryption enabled in the config, otherwise some of the SPI flash code to write encrypted is not compiled in.

The use case for this is simple: Pre encrypting the binary saves about 1.5 minutes of programming time on the factory floor which means I can spend about $200k less on programming fixtures.

I didnt find the documentation for preencrypting binaries very clear (it took me about two hours to figure out the right sauce)

Generate the key using the espsecure tool
Encrypt all binaries using espsecure (the bootloader, the application, the initial ota data, any binaries you are loading into pre encrypted memory)
Burn the key using espefuse
Set the rest of the fuses according to the way the firmware would have done it: https://docs.espressif.com/projects/esp ... on-process
Set the fuses to disable all the things you dont want your user to be able to do (jtag etc..)
Burn your encrypted binaries

Posted: **Sat Apr 19, 2025 5:38 pm**

I'm joining to this topic.
I used the process described in docs, and on factory we had one bricked device of 150 (which I finally managed to restore).
My process is supposed the factory device testing after flashing.
Device was bricked because the operator pressed the Reset button before flash encryption process finished.
And I wonder if it's possible to prepare the flash encryption key and whole device flash image encrypted with this key, flash the key on device, set the appropriate efuses and flash the prepared image to skip the onboard flash encryption and cause the device to work at once.

Which efuses values should be set in ESP32 and ESP32S3?

ESP32 Forum

Flash encryption - flashing pre-encrypted app.bin

Re: Flash encryption - flashing pre-encrypted app.bin

Re: Flash encryption - flashing pre-encrypted app.bin

Re: Flash encryption - flashing pre-encrypted app.bin

Re: Flash encryption - flashing pre-encrypted app.bin