Hi ChrisAlfred and Nespressif,
Please allow me to clear your doubts.
Here is my explanation for the questions raised above.
Question 1
(1) In step "5. Encrypt and flash the binaries." there is the command line:
CODE: SELECT ALL
espsecure.py encrypt_flash_data --keyfile my_flash_encryption_key.bin --address 0x8000 --output partition-table-enc.bin build/partition_table/partition-table.bin
This is INCORRECT AND WILL NOT WORK as your documentation states in
https://docs.espressif.com/projects/esp ... oader-size section "Bootloader Size", the partition table must be moved when encryption is used:
CODE: SELECT ALL
When Secure Boot V2 is enabled, there is also an absolute binary size limit of 48 KB (0xC000 bytes) (excluding the 4 KB signature), because the bootloader is first loaded into a fixed size buffer for verification.
Answer
The same offsets would not work because the offset would totally depend on your own firmware. You can find the following text just below these commands.
In the above command the offsets are used for a sample firmware, the actual offset for your firmware can be obtained by checking the partition table entry or by running idf.py partition-table.
These commands were performed for a firmware which only had flash encryption enabled and no secure boot, hence the offsets are different. Please replace the offset numbers with the correct values for your firmware.
Question 2
In "Enable Secure Boot V2 Externally" step "r. Sign and flash the binaries" you have the command line
Answer
I understand what your confusion. In this case the steps are given for independent operations and it was assumed that the encryption and signing would be done in order as required by the firmware.
If only secure boot is enabled then only signing is done and if both are enabled then first signing is done and then the firmware is encrypted.
But I see we need to update the document to make it more obvious about the sequence. Thanks for your inputs, I will raise an internal code-change request that would update the workflow when both of them are enabled together.
@Nespressif
Question 3
1.- In Enable Flash Encryption Externally:
- As I had already enabled it before, it didn't let me erase the flash, nor burn the encryption key. But I could change the value of the efuse FLASH_CRYPT_CNT to 127 indicating that the mode became release.
- After doing what it says in point 4, it says that FE is now enabled, and that it can be tested as indicated in step 5.
Note
At this point, the flash encryption on the device has been enabled. You may test the flash encryption process as given in step 5
Answer
Please note that step 5 is the step in which you flash the encrypted firmware. This step is not necessary for enabling flash encryption feature. This step is only necessary if you want to actually flash a firmware and use it. You can skip this step and directly go to step 6 if you only want to enable flash encryption feature in the factory and then flash the firmware in the future ( when the device is ready to go into the field).
Question 4
I ran the first four steps: generate the keys, burn them and burn the ABS_DONE_1 efuse.
Then I tried to continue with steps 5 and 6, but it wouldn't let me, as I burned ABS_DONE_1, the addresses below 0x8000 were protected and I couldn't flasher the signed bootloader, so another chip to hell. Since it doesn't let you change the value of the burned efuses either.
Answer
Please note that it is still possible to burn the bootloader after enabling ABS_DONE_1 in step 5. ( assuming you have not disabled the ROM_DL mode which comes later in step 7)
Can you let me know which command you have used and the snapshot of the error that you have observed.
Question 5
So, it is understood that it is not necessary to perform steps 5 and 6, as it says they are for testing, but I think this is wrong, as already in 4 SBv2 has been activated by burning the key and efuse, but the signed binaries have not been flashed.
Answer
Please note that this document is designed for all generic users who have different use-cases. The document clearly mentions that it only enables Secure Boot feature. If you only want to enable it for the chip then step 5 and 6 are not necessary. This use-case is applicable in manufactures which enable flash encryption and secure boot feature first and then prepare the devices in the factory itself. At this point the firmware for the product might not ready. In future when the firmware is ready, they prepare the firmware and flash it on the device.
Note that the workflow that you mentioned about enabling Secure Boot and Flash encryption through IDF application is still available and not removed. You can still enable it by enabling the menuconfig option as mentioned here. This is a different workflow in which Flash Encryption and Secure Boot is enabled externally.
Based on the discussion above, I think the document clearly needs to be improved and simplified further.
I have considered following points for improvement based on your discussion
1) Add appropriate warning when disabling ROM DL mode.
2) Add more details when enabling FE and SB together. i) For e.g., Make it clear that the firmware is to be signed first using SB key and then it needs to be encrypted before flashing.
Please let me know what else might need improving.
Additionally,
We have added support of esp32 in the qemu emulator.
you can emulate the esp32 on your host machine and test the security features there itself without worrying about the loss of hardware.
You can find more details here
https://github.com/espressif/esp-toolch ... qemu/esp32