ESP32 Forum

Hi all,

I've been trying to set up flash encryption using the following procedure:

1. Set Enable secure boot and Enable flash encryption on boot to true
2. Burn a pre-generated key to the flash-encryption eFuse block (BLK 1)
3. make
4. make flash
5. Encrypt app bin file using the same pre-generated key (encrypt_flash_data --keyfile my_flash_encryption_key.bin --address 0x10000 -
o appv2enc.bin appv2.bin)
6. Flash download new encrypted data (write_flash 0x10000 appv2enc.bin)

After this process, I get the following on the monitor:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

Can anyone tell me what I'm doing wrong?

Did you successfully boot after step 4?

No, I didn't manage to boot up successfully.

Looking at the eFuse summary, I've noticed that the FLASH_CRYPT_CNT fuse is write protected and set to 0. Could this have anything to do with the problem?

I've changed the chip to a new one which didn't have the FLASH_CRYPT_CNT fuse as write protected.

Following the same procedure, I'm still getting the error on booting up after step 4. I've noticed that the FLASH_CRYPT_CNT fuse remains as 0 after the first boot, event though if I'm understanding the documentation well it should have been set to 1.

As an aside; I haven't updated to the latest IDF version. Have there been any known issues with the previous IDF version and flash encryption?

Hi mpulis,

If flashing with a pre-generated key, for the first boot you should still boot a plaintext (not pre-encrypted) image (after flashing the flash encryption key to BLK1). On first boot, the bootloader will see that the FLASH_CRYPT_CNT efuse is unset, and the bootloader & app image is plaintext, and will encrypt everything and then flash the FLASH_CRYPT_CNT efuse to value 1.

(You can do this step manually if you like, and set FLASH_CRYPT_CNT yourself, but you also need to pre-encrypt the bootloader and the partition table in this case. It's easier to let the ESP32 do it itself.)

After this first boot, you can update the encrypted image (without any further changes to efuse necessary) by pre-encrypting the image yourself and flashing it.

The first boot encryption pass can take a little while (tens of seconds). If you interrupted it by resetting the board then it may have invalid flash contents (partially encrypted). You can confirm this by checking FLASH_CRYPT_CNT is still zero. If it's still zero and you're getting the "flash read err, 1000" then you can re-flash a plaintext image with "make flash", and reset to let it run the full initial encryption pass again.

I can't explain how an ESP32 came to have a write protected FLASH_CRYPT_CNT with value zero. Can you please post the output of "espefuse.py summary" for that device?

So I tried the procedure on another chip.

The initial state of the fuses seems correct and is as seen in Figure 1.
After this, I set the relevant security options in the project menu for Secure Bootloader and Flash Encryption, as seen in Figure 2.
I then burnt the pre-generated key to BLK 1 on the chip. The output fuse summary after this operation is shown in Figure 3.
After this, I ran 'make flash' to flash the plaintext bootloader, app and file partition table. After leaving this be for 5 minutes, I ran 'make monitor' to restart the device.

Unfortunately I'm still getting the same error as before. Checking the eFuse summary, FLASH_CRYPT_CNT is still set as 0x00.

Re: FLASH_CRYPT_CNT set to 0x01 for the previously mentioned device. That is my fault as I found a command to burn that fuse in my history of python commands. Forgive me for any confusion.

Were you able to boot a normal fw before burning the key?

As well as WiFive's question about burning a normal firmware, if you run "make flash monitor" for the first boot then what log output do you see from the first boot? You should see some messages about enabling flash encryption.

I am still able to boot up normal firmware even after burning the key. Erasing the flash and re-flashing with new firmware after disabling flash encryption allows the firmware to boot up normally, although the fuses remain burned.

I'm currently waiting for new chips to arrive as I'm currently out of ones with unburned fuses.

Doesn't make sense because if you can boot a firmware with enc/sb disabled then enabling it should boot the same way until it turns on enc/sb itself in the second stage bootloader. You didn't make any hardware changes or other menuconfig changes?