Flash Encryption Disable

[rahul.b.patel]

Hello,
I am facing a issue after enabling flash encryption. My work flow is as below:
-> Enabled flash encryption with secure boot.
->Loaded bootloader and binary into flash.
->Now I want to disable encryption, so I did first disable flash encryption from make menuconfig.
->'Make flash' new bootloader and app
->burn efuse FLASH_CRYPT_CNT
Now i am getting count value of 0xff so its giving error of 0x1ff is large value and burn is fail. And off-course after 0xFF efuse count boot loader will halt.
so is there any solution to disable encryption and boot esp32 with new application..?
Its giving error of flash read err, 0x1000 and reboots.

[WiFive]

If secure boot is enabled, no physical re-flashes are possible.

[rahul.b.patel]

Hi WiFive,
I have disabled both secure boot and flash encryption from 'make menuconfig'.
I have concern that if efuse count is already 0xFF it means all 8 bits set by efuse right ?, then in this situation is it possible to flash new bootloader and app by disabling secure boot and flash encryption.? how it can be done..?
I have tried disabling both option from 'make menuconfig' and then efused FLASH_CRYPT_CNT, but efuse can not be possible as its already 0xFF and its also write protected.

Thanks.

[WiFive]

You cannot disable secure boot on the chip, even if you disable it in menuconfig. If you could disable it, it wouldn't be secure. Get a new chip.

[tobewinner]

Hello,
I am facing a issue after enabling flash encryption. My work flow is as below:
-> Enabled flash encryption with secure boot.
->Loaded bootloader and binary into flash.
->Now I want to disable encryption, so I did first disable flash encryption from make menuconfig.
->'Make flash' new bootloader and app
->burn efuse FLASH_CRYPT_CNT
Now i am getting count value of 0xff so its giving error of 0x1ff is large value and burn is fail. And off-course after 0xFF efuse count boot loader will halt.
so is there any solution to disable encryption and boot esp32 with new application..?
Its giving error of flash read err, 0x1000 and reboots.

as I understand it, when you enabled secure boot, no physical re-flashes are possible for the chip unless you enabled Re-Flashable option for the bootloader you flashed.
1, If you haven't enalbe Re-Flashable option for the bootloader you flashed, no physical re-flashes are possible. that is you couldn't disable flash encryption; Try a new chip!
2, If you have enalbe Re-Flashable option for the bootloader you flashed, Luckly, you can reflash bootloader(Flash Encryption disabled) with the pre-calculated digest. and the plantext partition tables, app. before reset, burn efuse FLASH_CRYPT_CNT to odd number of bits.

[tobewinner]

Hi WiFive,
I have disabled both secure boot and flash encryption from 'make menuconfig'.
I have concern that if efuse count is already 0xFF it means all 8 bits set by efuse right ?, then in this situation is it possible to flash new bootloader and app by disabling secure boot and flash encryption.? how it can be done..?
I have tried disabling both option from 'make menuconfig' and then efused FLASH_CRYPT_CNT, but efuse can not be possible as its already 0xFF and its also write protected.

Thanks.

After all 8 bits are set (efuse value 0xFF): Transparent reading of encrypted flash is disabled, any encrypted data is permanently inaccessible. Bootloader will normally detect this condition and halt. To avoid use of this state to load unauthorised code, secure boot must be used or FLASH_CRYPT_CNT efuse must be write-protected.
http://esp-idf.readthedocs.io/en/latest ... -cnt-efuse

[ESP_Angus]

Hi Rahul,

If the FLASH_CRYPT_CNT is already 0xFF then, as others have said, no further updates are possible - flash encryption is permanently enabled. This normally would only happen after 4 serial re-flash cycles, as described here:
http://esp-idf.readthedocs.io/en/latest ... ed-updates

However it is possible to manually burn FLASH_CRYPT_CNT to 0xFF via espefuse.py - in which case this will bypass any remaining re-flash steps and effective disable serial updating of that ESP32 chip. (This option is made available for factory setups where the factory knows for certain that only OTA updates will be used from that time forward.)

Can you please specify exactly which commands you have run with this ESP32, either "make flash" (with or without flash encryption) or "espefuse.py ..."? Also, can you please post the output of "espefuse.py summary"?

[WiFive]

If the FLASH_CRYPT_CNT is already 0xFF then, as others have said, no further updates are possible - flash encryption is permanently enabled.

Don't you mean permanently DISABLED, 8 bits are set? But if secure boot is set there is no way to patch the bootloader to not halt on this condition so the chip is still dead. Should it be possible to get to this state unless explicitly passed as a value to espefuse.py?

[ESP_Angus]

If the FLASH_CRYPT_CNT is already 0xFF then, as others have said, no further updates are possible - flash encryption is permanently enabled.

Don't you mean permanently DISABLED, 8 bits are set? But if secure boot is set there is no way to patch the bootloader to not halt on this condition so the chip is still dead. Should it be possible to get to this state unless explicitly passed as a value to espefuse.py?

Ah yes, you are correct - very sorry. I blame it on Monday morning.

Yes, with the bootloader locked by secure boot and all 8 bits of FLASH_CRYPT_CNT set then flash encryption is disabled but it is not possible to continue at all.

The only way to get to this situation should be via "espefuse.py burn_efuse FLASH_CRYPT_CNT" when the previous value had 7 bits set. For 1,3,5 bits then this will allow re-flashing with a plaintext image, but for 7 it does not if secure boot is enabled.

The bootloader message should be:

Code: Select all

E xxx Cannot re-encrypt data (FLASH_CRYPT_CNT 0xFF write disabled 0)

We can add a warning to espefuse.py if 7 bits of FLASH_CRYPT_CNT are already set and secure boot is also enabled, before the efuse is burned to 0xFF. However this doesn't give you a way to reflash that ESP32 with new firmware, it just prevents accidental bricking of this kind.

[WiFive]

We can add a warning to espefuse.py if 7 bits of FLASH_CRYPT_CNT are already set and secure boot is also enabled, before the efuse is burned to 0xFF. However this doesn't give you a way to reflash that ESP32 with new firmware, it just prevents accidental bricking of this kind.

Warning would be good, but if secure boot is set and encryption is toggled, then you still have a nonfunctional bootloader unless you can reflash digest?