ESP32 Forum

I am preparing to go to mass production on an esp23s3 based device. I am trying to sort out the programming process for creating binary images that support secure boot, flash encryption, and setting all of the efuse bits.

espressif provides 2 workflows for enabling flash encryption and secure boot here:

https://docs.espressif.com/projects/esp ... flows.html

however, you cannot just follow these instructions in sequence as listed. Does anyone have a concise description of the exact sequence that needs to be followed to create a single binary image that supports both secure boot and flash encryption along with the sequence for programming both the flash and the necessary efuse locations?

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, I burn the efuses according to the workflow.

Hi @bram128 @Nespressif

Can you please let me know at what location did you face the issue? and what part is not working for your case ?

Thanks,
Aditya

I am looking for a single process that writes pre encrypted flash binaries, enables secure boot, and sets some other security related efuse bits. This needs to be used on the manufacturing line, so it cannot include compiling from source as part of the steps.

The closest thing I have found are the instructions here:

https://docs.espressif.com/projects/esp ... flows.html

BUT, what is described is not a single process, it is two separate processes: one to enable flash encryption, compile the project and write it to flash, and another for enabling secure boot, compiling the project, and writing it to flash. And, even if these instructions could be followed sequentially it would still require compiling the FW twice.

For example, step 8 of the "Enable Flash Encryption Externally" workflow (which is supposed to be performed first) is to burn the ENABLE_SECURITY_DOWNLOAD efuse. How could someone proceed to the "Enable Secure Boot v2 Externally" workflow (which requires manipulating multiple efuse settings) after setting this bit? The chip would be locked down at that point.

To further add to the confusion, step 8 of the "Enable Secure Boot v2 Externally" workflow is also to burn the ENABLE_SECURITY_DOWNLOAD efuse. Surely this should only be done once, at the very end of the process.

what I need is process something like the following

offline:
1) configure the project so that it generates signed binaries and has flash encryption enabled but does not automatically encrypt the binaries and compile

on the production line
2) generate an encryption key
3) encrypt the signed binary, bootloader, and any other encrypted partitions
4) merge all the binaries into a single file
5) write them to flash
6) write the secure boot key digest and flash enc key to efuse
7) configure all other security related efuses
8) reboot the board and it works

@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 section for enabling Secure Boot and Flash Encryption together.

Thanks for your feedback.

Regarding the set of instructions, You can also refer to https://github.com/espressif/esp-idf/tr ... atures_app but at this moment this only support esp32c3 and esp32s3 targets.

@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 section for enabling Secure Boot and Flash Encryption together.

Thanks for your feedback.

Regarding the set of instructions, You can also refer to https://github.com/espressif/esp-idf/tr ... atures_app but at this moment this only support esp32c3 and esp32s3 targets.

Good morning, I am very interested in being able to encrypt my projects and enable secure boot. But due to my ignorance and / or failures in the documentation, I have not obtained the desired results and I have damaged several chips (esp32).

Please, when you modify the documentation, comment it here, so we can test the workflow and ask you any question we have.

Thank you very much in advance.

@Nespressif

Sure, I will update here once I modify the documentation.

Please note that you can also try out the instructions on qemu emulation of respective target for e.g., qemu emulated esp32c3 or esp32s3.

This example https://github.com/espressif/esp-idf/tr ... atures_app

provides detailed instructions on that, this way you dont have to worry about wasting an actual hardware module.

Thanks,
Aditya

what I need is process something like the following

offline:
1) configure the project so that it generates signed binaries and has flash encryption enabled but does not automatically encrypt the binaries and compile

on the production line
2) generate an encryption key
3) encrypt the signed binary, bootloader, and any other encrypted partitions
4) merge all the binaries into a single file
5) write them to flash
6) write the secure boot key digest and flash enc key to efuse
7) configure all other security related efuses
8) reboot the board and it works

Are you sure you need the ecryption keys to be pre-generated rather than letting the device to generate its own?
With that my workflow looks like this btw:

1) configure the project so that it generates signed binaries and has flash encryption enabled using generated key on the device
2) generate NVS encryption keys ONLY and create nvs_keys partition
3) encrypt selected NVS paritions using generated nvs_keys
4) merge all the binaries into a single file (bootloader, partition table, encrypted NVS paritions and app)

on the production line:
5) Write merged binary to flash (addr 0x00)
6) skip
7) skip
8) reboot the board and WAIT for flash encryption process to finish

All boards that we managed to brick were due to someone's ignorance btw (colleague using debug app for OTA update on encrypted device and me not setting up secure version checks and anti-rollback, or someone not waiting for first start encryption process to finish).