Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]

[ESP_Angus]

Hi Angus,

Is it possible the flash chip has enabled hardware write protection somehow? Or that the FLASH_CRYPT_CNT efuse had been burned already before flashing of the plaintext firmware was done?

How we can enable Hardware write protection? From the menuconfig ? We have used the same binaries in all the 25 modules. Still, this can be the issue?

Hardware write protection isn't a feature that ESP-IDF or ESP32 currently supports, but many models of flash chip support some kind of write protection feature in the hardware. It's possible (although very unlikely) for electrical noise, voltage supply issues, or other hardware issues to cause the flash chip to go into a bad state.

Given your updated description of the problem, I no longer think this is the case for your hardware - it's only a possibility if you find that you actually can't change the flash contents at all (ie same bytes are found in the flash after each write attempt).

Sorry, I have written the wrong statement here. When I burn FLASH_CRYPT_CNT to disable flash encryption it's value was ox3, so flash encryption is disabled and then I have flashed the plain text binary. But then I am getting continuously "secure boot check fail" error. I am attaching Error logs and eFuse summary for the same.

Did you flash Secure Boot in "One-time flash" mode? If so then I'm afraid Secure Boot is behaving as designed and is preventing the device from booting a modified bootloader. It's not possible to disable flash encryption once Secure Boot is enabled in this mode.

If you wish to avoid bricking further chips this way, then you can pre-burn a Secure Boot eFuse key as described in the "reflashable bootloader" section of the Secure Boot docs. This will let you generate a new secure boot digest to match the new bootloader.

Alternatively, try flashing with Flash Encryption only first and then enable Secure Boot later.

eFuse Summary:

<snip>
BLK3 Variable Block 3
= 01 02 03 00 02 00 03 03 00 00 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Everything in the eFuse summary looks as expected apart from these unexpected values in eFuse BLK3. Were these manually burned here?

What are the possible hardware problems which may damage the board?

The most common possibilities would be an electrical noise problem, power supply stability, or a signal integrity problem on the board that's causing problems with the communication between the ESP32 and the flash chip, or causing the flash chip to "brown out" and erase/write invalid values to the flash.

If the power supply is particularly poor (ie the module is running sometimes or intermittently outside of its specified voltage range) while burning eFuses, then it is also possible for eFuses to mis-write.

[nikunj.patel]

Hi Angus,

Sorry for the late reply. As of now, we have replaced the esp32 chip.

Did you flash Secure Boot in "One-time flash" mode? If so then I'm afraid Secure Boot is behaving as designed and is preventing the device from booting a modified bootloader. It's not possible to disable flash encryption once Secure Boot is enabled in this mode.

Yes, we have configured secure boot in "one time flash mode". But what if we load the same bootloader.bin(In encrypted form) again ? Will it allow us to load it again.

Everything in the eFuse summary looks as expected apart from these unexpected values in eFuse BLK3. Were these manually burned here?

Yes, we have manually burned it.

If you wish to avoid bricking further chips this way, then you can pre-burn a Secure Boot eFuse key as described in the "reflashable bootloader" section of the Secure Boot docs. This will let you generate a new secure boot digest to match the new bootloader.

But for the production, a one-time flash option is preferable, correct?

I have one doubt, can you please clarify?
Suppose I have a configured the ESP module with Secure boot with one-time flash and flash encryption enable. Build the binary and load, it is working fine. Even checked eFuse that secure boot and flash encryption are burnt. Then if I want to erase the whole flash and load the same binaries(in encrypted form) which I have loaded earlier, can we do this? Will encrypted bootloader.bin make any issue?

Note: I have tried to load app binary and partitions binary in encrypted form but I have not tried to load again the same bootloader binary.

Thanks

[nikunj.patel]

Hi Angus,

Any update on this?

[WiFive]

You also have to burn and save a copy of the efuse secure boot key if you want to reflash signed and encrypted bootloader.

[ESP_Angus]

Hi Nikunj,

Sorry for the delay in getting back to you.

Did you flash Secure Boot in "One-time flash" mode? If so then I'm afraid Secure Boot is behaving as designed and is preventing the device from booting a modified bootloader. It's not possible to disable flash encryption once Secure Boot is enabled in this mode.

Yes, we have configured secure boot in "one time flash mode". But what if we load the same bootloader.bin(In encrypted form) again ? Will it allow us to load it again.

On the same ESP32 then this should work - just ensure that the 4KB flash sector at 0x0 is not erased or modified. Because this holds the secure boot digest for the bootloader, and this is dependent on the Secure Boot eFuse key which is generated on first boot (and in one time flash mode you don't have access to this key.)

Also make sure no bytes in the bootloader are changed between reading the encrypted bootloader.bin from the flash and flashing it back.

If you wish to avoid bricking further chips this way, then you can pre-burn a Secure Boot eFuse key as described in the "reflashable bootloader" section of the Secure Boot docs. This will let you generate a new secure boot digest to match the new bootloader.

But for the production, a one-time flash option is preferable, correct?

That's correct, we strongly recommend a different key on each device and one-time flash is the easiest way to achieve this.

However if you're still verifying the production process then you can pre-burn the secure boot key on one or two devices, and then follow the same process that you plan to use later for production.

I have one doubt, can you please clarify?
Suppose I have a configured the ESP module with Secure boot with one-time flash and flash encryption enable. Build the binary and load, it is working fine. Even checked eFuse that secure boot and flash encryption are burnt. Then if I want to erase the whole flash and load the same binaries(in encrypted form) which I have loaded earlier, can we do this? Will encrypted bootloader.bin make any issue?

Note: I have tried to load app binary and partitions binary in encrypted form but I have not tried to load again the same bootloader binary.

The only possible cause for concern is:

• The encrypted bootloader range in the flash has to end up 100% the same content as before so that the digest will match. However I don't see any reason this wouldn't happen, assuming the exact same binary and the same key (if encrypting off-device).
• The digest stored at offset 0x0 must match before and after. If erasing the entire flash chip, you'd need to read this data out before erasing and then write it back after.

Can I ask what your ultimate goal is here? There might be an easier way to achieve it.