Secure boot problem

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Secure boot problem

Postby dmitryga » Mon Jul 30, 2018 4:35 pm

I've used procedure described in https://docs.espressif.com/projects/esp ... -boot.html# to enable reflashable bootloader. I generated private key, run make bootloader, which generated secure-bootloader-key.bin, which was later written to Efuse, bootloader also was flashed with appropriate command. But ESP32 is not booting with following error in console:

Code: Select all

rst:0x10 (RTCWDT_RTC_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:6816
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:20872
secure boot check fail
ets_main.c 371 
ets Jun  8 2016 00:22:57
I've tried both first time flash command and reflash command accompanied with flash_erase - result was the same. Also I've dumped first 32Kbytes of flash to compare them with bootloader-reflash-digest.bin - contents are the same.
Contents of Efuses looks good:

Code: Select all

Security fuses:
FLASH_CRYPT_CNT        Flash encryption mode counter                     = 0 R/W (0x0)
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                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 1 R/W (0x1)
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 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 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 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)
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                                       = 30:ae:a4:1c:82:8c R/W
CHIP_VERSION           Chip version                                      = 8 -/W (0x8)
CHIP_PACKAGE           Chip package identifier                           = 0 -/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
I have already run out of ideas of what could be the problem.
Please, help!
Last edited by dmitryga on Tue Jul 31, 2018 9:31 am, edited 1 time in total.

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

Re: Secure boot problem

Postby ESP_Angus » Tue Jul 31, 2018 12:03 am

Based on your description and the efuse summary it sounds like you've done everything correctly. However the error indicates that the secure boot digest in flash doesn't match - either the bootloader contents or the key are different.

Can you please provide the full commands you've run in order to flash, burn keys, any other efuse commands, etc?

Also, is it possible the new bootloader is too large? If it's larger than the size limit and you flash the bootloader before flashing the partition table, the partition table will overwrite the end of the bootloader and the digest will be invalid (leading to error you're seeing). See here for more details about this: https://docs.espressif.com/projects/esp ... oader-size

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Re: Secure boot problem

Postby dmitryga » Tue Jul 31, 2018 7:41 am

Here is list of commands (I've stripped some file paths to simplify reading):
1. Generate signing key:

Code: Select all

python espsecure.py generate_signing_key /d/Source/.../Firmware/secure_boot_key.pem
espsecure.py v2.1
ECDSA NIST256p private key in PEM format written to D:/Source/.../Firmware/secure_boot_key.pem
2. make bootloader
3. Write Efuse block 2:

Code: Select all

python espefuse.py --port COM5 --before default_reset burn_key secure_boot /d/Source/.../Firmware/build/bootloader/secure-bootloader-key.bin
espefuse.py v2.1
Connecting.....
Write key in efuse block 2. The key block will be read and write protected (no further changes or readback). This is an irreversible operation.
Type 'BURN' (all capitals) to continue.
BURN
Burned key data. New value: aa 35 48 fa fe ac bd ce ce 83 92 b2 28 24 f2 f8 58 5b aa 18 05 27 33 00 77 ff cb d4 a1 9d 51 f0
Disabling read/write to key efuse block...
4. Write bootloader:

Code: Select all

python esptool.py --chip esp32 --port COM5 --baud 230400 --before default_reset --after no_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x1000 /d/Source/.../Firmware/build/bootloader/bootloader.bin
esptool.py v2.1
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 230400
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 27792 bytes to 16788...
Wrote 27792 bytes (16788 compressed) at 0x00001000 in 0.8 seconds (effective 291.1 kbit/s)...
Hash of data verified.

Leaving...
Staying in bootloader.
5. Also I've tried to write bootloader + digest with same result (as I mentioned earlier):

Code: Select all

python esptool.py --chip esp32 --port COM5 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x0 /d/Source/.../Firmware/build/bootloader/bootloader-reflash-digest.bin
esptool.py v2.1
Connecting.....
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 32000 bytes to 17049...
Wrote 32000 bytes (17049 compressed) at 0x00000000 in 0.2 seconds (effective 1126.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...
Bootloader is not large, it is only 27792 bytes.

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Re: Secure boot problem

Postby dmitryga » Tue Jul 31, 2018 7:44 am

I also suppose that there is some problem with digest generation but cannot find out how can I validate its correctness. Algorithm described in docs is rather complex to find some sort of validation utility.

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

Re: Secure boot problem

Postby ESP_Angus » Wed Aug 01, 2018 5:33 am

Hi dmitryga,

This all looks correct to me.

What version of ESP-IDF are you using? (You can check by running "cd $IDF_PATH" then "git describe --tags --dirty")

A bug was fixed in esptool v2.5.0 where digest_secure_bootloader could produce an incorrect digest under some circumstances.

You can check if this is the case without updating IDF by updating the esptool submodule only:

Code: Select all

cd $IDF_PATH/components/esptool_py/esptool
git fetch origin
git checkout v2.5.0
Then delete bootloader-reflash-digest.bin, do a "make" to regenerate it from the newer esptool, and try flashing it again.

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Re: Secure boot problem

Postby dmitryga » Wed Aug 01, 2018 10:02 am

ESP_Angus, thank you for this idea!

My ESP-IDF version is 3.0.2
esptool.py has version 2.1
I will try to update it to newer version.

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Re: Secure boot problem

Postby dmitryga » Wed Aug 01, 2018 1:34 pm

I've updated esptool.py to 2.5.0 and now everything works like a charm!
Bootloader is booting, application is starting, flash is encrypted.

ESP_Angus, thank you for your help!

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Re: Secure boot problem

Postby dmitryga » Wed Aug 01, 2018 7:05 pm

ESP_Angus, could you please clarify one question?
I've enabled both secure boot and flash encryption. Now bootloader and app partition are encrypted. And I want to update bootloader for some reasons (new IDF version or something else). Should I encrypt bootloader-reflash-digest.bin before writing it to chip?
I don't want to increment FLASH_CRYPT_CNT efuse so I'm using pregenerated key and can manually encrypt firmware before uploading. This technique works perfectly for application partition but I don't know if I can do the same things with bootloader...

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

Re: Secure boot problem

Postby ESP_Angus » Wed Aug 01, 2018 11:25 pm

Hi Dmitry,

Glad you got everything working. Sorry I didn't think of the digest bug when I first replied. ESP-IDF v3.1 includes esptool v2.5.0, but there's no reason why using IDF 3.0.2 + esptool v2.5.0 won't keep working.
dmitryga wrote: I've enabled both secure boot and flash encryption. Now bootloader and app partition are encrypted. And I want to update bootloader for some reasons (new IDF version or something else). Should I encrypt bootloader-reflash-digest.bin before writing it to chip?
I don't want to increment FLASH_CRYPT_CNT efuse so I'm using pregenerated key and can manually encrypt firmware before uploading. This technique works perfectly for application partition but I don't know if I can do the same things with bootloader...
That's exactly correct, if you don't increment FLASH_CRYPT_CNT then you can still generate bootloader-reflash-digest.bin, then encrypt it, then flash it.

As you've probably noticed, encrypting in place isn't currently integrated with the build system so you have to do this part by hand. But it should work fine, using the commands in the docs.

dmitryga
Posts: 29
Joined: Sat Jan 14, 2017 8:36 pm

Re: Secure boot problem

Postby dmitryga » Thu Aug 02, 2018 11:04 am

ESP_Angus, thank you very much for you advice!

Who is online

Users browsing this forum: No registered users and 116 guests