Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

mamaheshwari
Posts: 10
Joined: Fri Oct 23, 2020 4:53 am

Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby mamaheshwari » Wed Nov 25, 2020 5:39 am

Platform: ESP32 WROVER(ESP32D0WDQ5 (revision 1))
ESP IDF: ESP IDF 4.0

I enabled Secure boot and Flash encyption using following options in menuconfig:

Code: Select all

Enable hardware secure boot in bootloader->  Enabled
Secure bootloader mode -> Reflashable
Sign binaries during build --> Not selected
Secure boot public signature verification key --> /home/mydir/secure_boot_signing_key_pub)
Enable flash encryption on boot-->Selected
Enable usage mode -->Development
Bootloader log verbosity --> No output

Boot loader size is less that 0x7000

Build and flashed bootloader and applicaiton using following commands:

Code: Select all

openssl ecparam -name prime256v1 -genkey -noout -out secure_boot_signing_key.pem

python espsecure.py extract_public_key --keyfile secure_boot_signing_key.pem secure_boot_signing_key_pub

espsecure.py digest_private_key --keylen 256 --keyfile secure_boot_signing_key.pem secure-bootloader-key-256.bin

idf.py bootloader
python espefuse.py burn_key secure_boot secure-bootloader-key-256.bin
python esptool.py --before default_reset --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB  -u 0x1000 bootloader.bin
python esptool.py --before default_reset --after no_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 16MB  -u 0x0 bootloader-reflash-digest.bin (On subsequent flash)
idf.py build
python espsecure.py sign_data --keyfile secure_boot_signing_key.pem myApp.bin
python espsecure.py sign_data --keyfile secure_boot_signing_key.pem partition-table.bin


Following is output of "espefuse.py --port /dev/ttyUSB0 summary" command:

Code: Select all

EFUSE_NAME             Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 3 R/W (0x3)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 1 R/W (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                                      = 0 R/W (0x0)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 0 R/W (0x0)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 0 R/W (0x0)
BLK1                   Flash encryption key                              
  = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/- 
BLK2                   Secure boot key                                   
  = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/- 
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 00 R/W 

Efuse fuses:
WR_DIS                 Efuse write disable mask                          = 384 R/W (0x180)
RD_DIS                 Efuse read disablemask                            = 3 R/W (0x3)
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)
CLK8M_FREQ             8MHz clock freq override                          = 51 R/W (0x33)
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                    Factory MAC Address                               
  = 24:0a:c4:47:36:6c (CRC 0xea OK) R/W 
CHIP_VER_REV1          Silicon Revision 1                                = 1 R/W (0x1)
CHIP_VER_REV2          Silicon Revision 2                                = 0 R/W (0x0)
CHIP_VERSION           Reserved for future chip versions                 = 2 R/W (0x2)
CHIP_PACKAGE           Chip package identifier                           = 1 R/W (0x1)

Calibration fuses:
BLK3_PART_RESERVE      BLOCK3 partially served for ADC calibration data  = 0 R/W (0x0)
ADC_VREF               Voltage reference calibration                     = 1093 R/W (0x11)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
Board booted fine after first flash. I mades some changes in application and flashed bootloader, partition table and applicaiton again.
Board failed to boot and prints following message:

Code: Select all

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1504
ho 0 tail 12 room 4
load:0x40078000,len:19184
load:0x40080400,len:3608
[b]secure boot check fail
ets_main.c 371 
ets Jun  8 2016 00:22:57[/b]
I had used following commands to verify that partition table and application is properly signed:

Code: Select all

python espsecure.py verify_signature --keyfile secure_boot_signing_key.pem partition-table.bin
python espsecure.py verify_signature --keyfile secure_boot_signing_key.pem pmyApp.bin

mamaheshwari
Posts: 10
Joined: Fri Oct 23, 2020 4:53 am

Re: Falied to boot after enabling secure boot and flash encrytion

Postby mamaheshwari » Thu Nov 26, 2020 4:57 am

Can anyone pleaase help? @WiFive @ESP_Angus

ESP_Alvin
Posts: 195
Joined: Thu May 17, 2018 2:26 am

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby ESP_Alvin » Thu Nov 26, 2020 6:19 am

Moderator's note: edit the topic title for issue tracking, thanks for reporting.

mamaheshwari
Posts: 10
Joined: Fri Oct 23, 2020 4:53 am

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby mamaheshwari » Mon Nov 30, 2020 5:45 am

Can someone help on recovering the board and point the mistake that I made.

mamaheshwari
Posts: 10
Joined: Fri Oct 23, 2020 4:53 am

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby mamaheshwari » Wed Dec 02, 2020 12:12 pm

Any update?

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

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby ESP_Angus » Thu Dec 03, 2020 5:59 am

Hi mamaheshwari,

Sorry for the delay in getting back to you.

I don't see a problem with the sequence of commands that you ran.

The error you're seeing is due to the ROM failing to verify the digest of the bootloader, so it's not to do with signing - it's to do with the digest not matching based on the bootloader binary in flash and the secure boot key in eFuse.

The build system should be producing a valid digest+bootloader file automatically, using the same key that was written to eFuse. However to be certain can you please try processing the bootloader.bin manually with espsecure.py:

Code: Select all

espsecure.py digest_secure_bootloader --keyfile secure-bootloader-key-256.bin --output bootloader-digest.bin build/bootloader.bin

esptool.py -p PORT -b BAUD --after no_reset write_flash 0x0 bootloader-digest.bin
Angus

EDIT: removed an incorrect question

mamaheshwari
Posts: 10
Joined: Fri Oct 23, 2020 4:53 am

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby mamaheshwari » Thu Dec 03, 2020 10:02 am

Hi ESP_Angus
I executed the commands suggested by you however I still have the same problem.

Code: Select all

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:11068
load:0x40078000,len:23840
load:0x40080400,len:4644
secure boot check fail
ets_main.c 371 
ets Jun  8 2016 00:22:57
Do I need to run any command for encrypting the binaries before flashing them?

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

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby ESP_Angus » Thu Dec 03, 2020 11:23 pm

Hi mamaheshswari,

Just to double check, you didn't flash anything else after flashing the bootloader+digest binary - you immediately tried to boot the ESP32? (This is correct, just checking nothing else was written to flash afterwards.)
Do I need to run any command for encrypting the binaries before flashing them?
No, you don't. According to your efuse dump, Flash Encryption is disabled (two bits are set in the efuse register):

Code: Select all

FLASH_CRYPT_CNT        Flash encryption mode counter                     = 3 R/W (0x3)
And the bootloader image is reading from flash OK (all of the "load: ... len: ..." lines come from the bootloader binary.)

It looks like somehow the key burned in the eFuse ("secure-bootloader-key-256.bin") doesn't match the key you have on your host. Is it possible that a Secure Boot bootloader might have booted on this ESP32 before the "burn_key" command was used? If so then it would have written a randomly generated key (but the burn_key command would have failed with an error.)

I'll double-check the same configuration works locally with the same IDF version, but this is the only explanation I have for now.

mamaheshwari
Posts: 10
Joined: Fri Oct 23, 2020 4:53 am

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby mamaheshwari » Fri Dec 04, 2020 4:55 am

Hi ESP_Angus

Thanks for quick reply.
Just to double check, you didn't flash anything else after flashing the bootloader+digest binary - you immediately tried to boot the ESP32? (This is correct, just checking nothing else was written to flash afterwards.)
That is correct. I did not flash anything after flashing bootloader+digest.
Do I need to run any command for encrypting the binaries before flashing them?
No, you don't. According to your efuse dump, Flash Encryption is disabled (two bits are set in the efuse register):
But I have enable Flash encyption(Development mode) in sdkconfig. Shouldn't efuse values change after reboot?
Is it possible that a Secure Boot bootloader might have booted on this ESP32 before the "burn_key" command was used?
I had burnt key before flashing secure bootloader.

Appreciate your help

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

Re: Falied to boot after enabling secure boot and flash encrytion [IDFGH-4327]

Postby ESP_Angus » Sun Dec 13, 2020 10:40 pm

Hi mamheshwari,

I can't explain the results you're seeing based on the steps you ran, sorry. You're using the ESP-IDF v4.0 release exactly, not a pre-release or some other version? (can double-check by opening a terminal in the IDF directory and running "git describe --tags").
mamaheshwari wrote:
Fri Dec 04, 2020 4:55 am
Do I need to run any command for encrypting the binaries before flashing them?
No, you don't. According to your efuse dump, Flash Encryption is disabled (two bits are set in the efuse register):
But I have enable Flash encyption(Development mode) in sdkconfig. Shouldn't efuse values change after reboot?
Yes, on first boot the bootloader should set a number of efuses in a sequence depending on the configuration. However the efuse summary you have doesn't match the bootloader behaviour, I can't explain it:
  • FLASH_CRYPT_CNT has value 0x3 - an even numbers of bits means encryption is re-disabled. Normally the only way to get to this state is to run "espefuse.py burn_efuse FLASH_CRYPT_CNT" in order to manually disable flash encryption.
  • Some other efuse bits such as DISABLE_DL_DECRYPT, DISABLE_DL_CACHE are not set. Normally these are set by bootloader before flash encryption is enabled at all (unless the corresponding "Potentially insecure options" are enabled in the project configuration.)

Who is online

Users browsing this forum: Google [Bot], Remenyo and 220 guests