Flash Encryption Disable

[rahul.b.patel]

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"?

Hi Angus

->I have first use 'make flash' with flash encryption with one time flash option.
->Then I was getting 'flash read err, 1000' on boot as expected.
->so I disabled flash encryption in make menuconfig, again 'make flash' the app.
->then used espefuse.py burn_efuse FLASH_CRYPT_CNT
summery of this efuse command is :

"A fatal error occurred: Value mask for efuse FLASH_CRYPT_CNT is 0xff. Value 0x1ff is too large."


Thanks.

[ESP_Angus]

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?

That's right. By the time 7 bits are set and secure boot is enabled your only options are to keep the current encrypted firmware, update via a different method (OTA/etc), or to brick the device.

EDIT: By the time any flash encryption bits are set.

(The only way around this problem is to pre-generate a digest that you can re-flash, with a bootloader that's modified to disable the check. However it may be easier/safer to pre-generate the bootloader flash encryption key instead, allowing reflashing without changing FLASH_CRYPT_CNT.)

[WiFive]

By the time 7 bits are set and secure boot is enabled your only options are to keep the current encrypted firmware, or to brick the device.

Even if one bit is set and encryption is toggled isn't it going to brick unless you have the bootloader key? So maybe warning should be more strict.

[ESP_Angus]

By the time 7 bits are set and secure boot is enabled your only options are to keep the current encrypted firmware, or to brick the device.

Even if one bit is set and encryption is toggled isn't it going to brick unless you have the bootloader key? So maybe warning should be more strict.

Right, yes - sorry. I wrote as much in the docs "If secure boot is enabled, no physical re-flashes are possible." but obviously not thinking straight today.

[ESP_Angus]

->I have first use 'make flash' with flash encryption with one time flash option.

Did you have secure boot enabled in the config as well?

->Then I was getting 'flash read err, 1000' on boot as expected.

If you only ran "make flash" once, then this is unexpected. You should expect to see the process described under "Process to enable flash encryption", here:
http://esp-idf.readthedocs.io/en/latest ... ialisation

Specifically, on the first boot everything is still unencrypted until the bootloader (which has been compiled with flash encryption features turned on) runs and encrypts all partitions in-place, and then burns FLASH_CRYPT_CNT to enable the encryption engine.

If this process somehow got interrupted (for example the ESP32 was reset during the process) then you will get the "flash read err" on the next boot (as the bootloader is encrypted but FLASH_CRYPT_CNT is still zero so the encryption engine is off.) But at this point you can re-flash and everything should continue normally.

EDIT: Note that if secure boot was turned on then the above "you can re-flash..." comment only applies if you still have the exact same (plaintext) bootloader binary that was flashed the first time. Otherwise the digest won't match and secure boot will reject the bootloader.

->so I disabled flash encryption in make menuconfig, again 'make flash' the app.
->then used espefuse.py burn_efuse FLASH_CRYPT_CNT
summery of this efuse command is :

"A fatal error occurred: Value mask for efuse FLASH_CRYPT_CNT is 0xff. Value 0x1ff is too large."

It's odd that this value is suddenly 0xFF, if the only things which happened are what you described. Could you please post the output of "espefuse.py summary"? Thanks.

[rahul.b.patel]

"Could you please post the output of "espefuse.py summary"? Thanks."[/quote]

Hi Angus,
Here is espefuse.py summary,

Code: Select all

Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 255 R/- (0xff)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/- (0x1)
ABS_DONE_0             secure boot enabled for bootloader                = 1 R/W (0x1)
ABS_DONE_1             secure boot abstract 1 locked                     = 0 R/W (0x0)
JTAG_DISABLE           Disable JTAG                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/- (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/- (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 0 R/- (0x0)
BLK1                   Flash encryption key
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
BLK2                   Secure boot key
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
BLK3                   Variable Block 3
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 33028 R/W (0x8104)
RD_DIS                 Efuse read disablemask                            = 2 R/W (0x2)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 0 R/W (0x0)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 0 R/W (0x0)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 0 R/W (0x0)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 0 R/W (0x0)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 0 R/W (0x0)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 0 R/W (0x0)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

Identity fuses:
MAC                    MAC Address                                       = c4:00:ca:6e:00:c9 R/W

Thanks.

[ESP_Angus]

Hi Rahul,

There are some unusual things in the efuse summary:

CONSOLE_DEBUG_DISABLE, JTAG_DISABLE, DISABLE_DL_ENCRYPT, DISABLE_DL_DECRYPT have all been burned (set). Normally these are automaticlly burned by the bootloader after it successfully finishes the first encryption pass and enables the flash encryption engine (unless you burned them via "espefuse.py burn_efuse" for some reason?)

Similarly, ABS_DONE_0 is burned which

Although oddly DISABLE_DL_CACHE is not burned, did you make any "potentially insecure" changes in menuconfig?

More odd, FLASH_CRYPT_CONFIG efuse has not been burned (has value 0). I would expect this to be burned to 0xF, as the bootloader does this before it sets the various xxx_DISABLE efuses.

Also unusual, FLASH_CRYPT_CNT has been write protected (note R/- at the end of the line not R/W). IDF doesn't do this automatically, did you write protect it manually?

Are there some other modifications to the bootloader,or additional "espefuse.py burn_efuse" commands, that may have been run at some point?

[rahul.b.patel]

Hi Angus thanks for your efforts.,

->DISABLE_DL_ENCRYPT and DISABLE_DL_DECRYPT were burned by me when I was checking this issue, after I got CRYPT_CNT value as 0xFF.
->yes I did enable test mode "potentially insecure" in menuconfig when I had CRYPT_CNT value of 0xFF to see if I can over come this issue.
->yes, FLASH_CRYPT_CNT was made write protected manually by me.
-> Although, there is no other modification in boot loader, while there might be possibility of espefuse.py burn_efuse command used after getting "flash read error,1000".

Thanks.

[ESP_Angus]

-> Although, there is no other modification in boot loader, while there might be possibility of espefuse.py burn_efuse command used after getting "flash read error,1000".

Which other efuses do you think you might have burned? FLASH_CRYPT_CNT?

[rahul.b.patel]

-> Although, there is no other modification in boot loader, while there might be possibility of espefuse.py burn_efuse command used after getting "flash read error,1000".

Which other efuses do you think you might have burned? FLASH_CRYPT_CNT?

No,I have not burned any other efuses. I was trying to burn FLASH_CRYPT_CNT to disable flash encryption as procedure provided at :
http://esp-idf.readthedocs.io/en/latest ... encryption

then I got error as FLASH_CRYPT_CNT burn count is already 0xFF.

Is there a way to make chip working again.? Or is it useless now.?