Flash Encryption Query

mpulis
Posts: 13
Joined: Mon Aug 07, 2017 7:53 am

Flash Encryption Query

Postby mpulis » Tue Feb 13, 2018 2:32 pm

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?

WiFive
Posts: 1677
Joined: Tue Dec 01, 2015 7:35 am

Re: Flash Encryption Query

Postby WiFive » Wed Feb 14, 2018 2:24 am

Did you successfully boot after step 4?

mpulis
Posts: 13
Joined: Mon Aug 07, 2017 7:53 am

Re: Flash Encryption Query

Postby mpulis » Wed Feb 14, 2018 10:23 am

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?

mpulis
Posts: 13
Joined: Mon Aug 07, 2017 7:53 am

Re: Flash Encryption Query

Postby mpulis » Wed Feb 14, 2018 10:35 am

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?

ESP_Angus
Posts: 888
Joined: Sun May 08, 2016 4:11 am

Re: Flash Encryption Query

Postby ESP_Angus » Thu Feb 15, 2018 12:07 am

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?

mpulis
Posts: 13
Joined: Mon Aug 07, 2017 7:53 am

Re: Flash Encryption Query

Postby mpulis » Thu Feb 15, 2018 9:02 am

So I tried the procedure on another chip.

The initial state of the fuses seems correct and is as seen in Figure 1.

1.PNG
Figure 1
1.PNG (42.53 KiB) Viewed 576 times

After this, I set the relevant security options in the project menu for Secure Bootloader and Flash Encryption, as seen in Figure 2.

4.PNG
Figure 2
4.PNG (8.05 KiB) Viewed 576 times

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.

2.PNG
Figure 3
2.PNG (57.78 KiB) Viewed 576 times

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.

WiFive
Posts: 1677
Joined: Tue Dec 01, 2015 7:35 am

Re: Flash Encryption Query

Postby WiFive » Thu Feb 15, 2018 6:36 pm

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

ESP_Angus
Posts: 888
Joined: Sun May 08, 2016 4:11 am

Re: Flash Encryption Query

Postby ESP_Angus » Thu Feb 15, 2018 11:01 pm

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.

mpulis
Posts: 13
Joined: Mon Aug 07, 2017 7:53 am

Re: Flash Encryption Query

Postby mpulis » Fri Feb 23, 2018 1:54 pm

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.

WiFive
Posts: 1677
Joined: Tue Dec 01, 2015 7:35 am

Re: Flash Encryption Query

Postby WiFive » Fri Feb 23, 2018 6:57 pm

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?

Who is online

Users browsing this forum: No registered users and 3 guests