Secure boot and signed bins

[snahmad75]

I already flash my secure boot-loader. I want to do again. I reduce my debug level which reduce secure boot-loader size now, otherwise it over run my partition start address 0x8000.

What is the value of the ABS_DONE_0 efuse, as shown in "espefuse.py -p PORT summary"? If it's still 0 then you can start again from the beginning and follow the steps in the IDF Programming Guide for Secure Boot.

If ABS_DONE_0 has value 1 then secure boot has been enabled during a previous boot. You can still reflash the bootloader only if you used the "Reflashable" process to pre-burn the secure boot key ("espefuse.py burn_key SECURE_BOOT keyfile.bin"). In this case, you flash the bootloader+digest combination .bin file at offset 0x0 (if flashing only the bootloader, it flashes at offset 0x1000).

Once I have ABS_DONE_0 = 0 , I can start again. I can choice Reflashable bootloader option. but secure boot key I generated using esptool. Can I generate key using esptool which works with Reflashable bootloader not on-time Bootloader.
Is there option when generate key using esptool for Reflashable bootloader

[ESP_Angus]

Once I have ABS_DONE_0 = 0 , I can start again. I can choice Reflashable bootloader option. but secure boot key I generated using esptool. Can I generate key using esptool which works with Reflashable bootloader not on-time Bootloader.
Is there option when generate key using esptool for Reflashable bootloader

Secure Boot uses two keys:

• An AES-256 key (stored in efuse) is used to generate a digest of the software bootloader which is written to offset 0x0. This digest is used by the hardware to verify the software bootloader at offset 0x1000 is correct.
• A signing key (ECDSA key in PEM format) is used to sign apps. The software bootloader uses this key to verify the app signature.

The provides a "chain of trust" from the hardware to the bootloader to the signed app.

See also this summary of the two keys in the documentation

Both Secure Boot modes (Reflashable & One-Time) use the same signing key. This is used to sign apps and then the bootloader uses the public key to verify the ECDSA signature on boot. This key can be generated with "esptool.py generate_signing_key".

For One-Time Flashable mode, this is the only key which is provided by the host. The other key (256-bit AES key in efuse) is generated by the bootloader on first boot (using the RNG) and then written to efuse. This key is used to verify the bootloader digest. Because the key is randomly generated and protected once written to efuse, the bootloader cannot be changed (as it's not possible to produce a new valid digest).

For Reflashable mode, this 256-bit AES key in efuse can be pre-burned from the host using espefuse.py. By default, the ESP-IDF build system will calculate the SHA-256 digest of the ECDSA signing key and use this as the AES key (this way, you only need to keep track of a single key file - you can always regenerate the AES key from the signing key.) It's possible to use a different AES key if you want, though.

In Reflashable mode, when you run "make bootloader" for an ESP-IDF app, the build output will instruct you to flash this AES key (the SHA-256 digest of the signing key) using espefuse.py and then flash the bootloader.bin file:

Code: Select all

******************************************************************************
Bootloader built and secure digest generated. First time flash command is:
python /home/gus/esp/32/idf/components/esptool_py/esptool/espefuse.py burn_key secure_boot /home/gus/esp/32/idf/examples/get-started/hello_world/build/bootloader/secure-bootloader-key-256.bin
python /home/gus/esp/32/idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /home/gus/esp/32/idf/examples/get-started/hello_world/build/bootloader/bootloader.bin
*******************************************************************************

After the key is burned to efuse and the bootloader is flashed, if everything goes correctly then the secure boot digest will be generated by the bootloader on first boot and written to offset 0x0 and then ABS_DONE_0 efuse is set to 1 (permanently enabling secure boot). In your case so far, it seems like the bootloader has found problems with the partition table or the app so it's aborted the process instead of completing it.

After this first boot and once ABS_DONE_0 is set to 1, the digest at offset 0x0 always has to match the bootloader at offset 0x1000. Because in Reflashable Mode you have a copy of the AES key on the host, an updated digest can be pre-calculated on the host and flashed to the ESP32 at offset 0x0. The build system generates the updated digest automatically and this information is also printed in the "make bootloader" output:

Code: Select all

To reflash the bootloader after initial flash:
python /home/gus/esp/32/idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x0 /home/gus/esp/32/idf/examples/get-started/hello_world/build/bootloader/bootloader-reflash-digest.bin

(For easier flashing, bootloader-reflash-digest.bin is the digest and the bootloader together in one binary file.)

This information is also in the documentation, here: https://docs.espressif.com/projects/esp ... bootloader

[snahmad75]

Hi Angus,
Still not working. frustrated. kindly help we are stuck. I can send you in private message my
signing_key.pem and secure_boot_key.bin.
I can upload these some where. My colleague generate these files using esptool. Not sure which python script version. do you want know how we create these files. It could be due two different methods 256 or 192. My device coding scheme=0. not 3/4

I used on-time option.

When I do make bootloader. It generate bootloader.bin. I believe it is not secure. so I generate secured bootloader using step =1

1-
espsecure.py digest_secure_bootloader --keyfile secure_boot_key.bin --output ./build/secure_bootloader.bin ./build/bootloader/bootloader.bin

2-
espsecure.py sign_data --keyfile signing_key.pem --output ./build/signed_partitions.bin ./build/partitions.bin

3-
espsecure.py sign_data --keyfile signing_key.pem --output ./build/signed_W2K1-BootLoader-Release.bin ./build/W2K1-BootLoader-Release.bin


4-
espefuse.py --port COM184 burn_key secure_boot secure_boot_key.bin --no-protect-key
5-
espefuse.py --port COM184 burn_efuse ABS_DONE_0 1
6-
esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x10000 ./build/signed_W2K1-BootLoader-Release.bin

My config for security are these.

#
# Security features
#
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_ENABLED=y
CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH=y
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=
CONFIG_SECURE_BOOT_VERIFICATION_KEY="secure_boot_key.bin"
CONFIG_SECURE_BOOT_INSECURE=
CONFIG_FLASH_ENCRYPTION_ENABLED=



Getting this eror.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (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:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6412
load:0x40078000,len:14788
load:0x40080400,len:5972


Thanks,
Naeem

[WiFive]

I still don't see where you are writing the actual bootloader to 0x1000

[ESP_Angus]

WiFive, the output of "espsecure.py digest_secure_bootloader " is the digest with the image appended, so secure_bootloader.bin should be OK to flash at offset 0x0.

The steps you've outlined are not the recommended way to enable secure boot (the instructions recommend letting the bootloader burn ABS_DONE_0 itself during the first boot, as it can verify everything in the flash is correct before locking down the system.) But it should work.

• Do you get any errors from any of the commands?
• Can you please post the output of "espefuse.py -p PORT summary"? You may need to redact some key values if they're not read protected.
• What bootloader log level is set in sdkconfig?

Also, this does not look right:

CONFIG_SECURE_BOOT_VERIFICATION_KEY="secure_boot_key.bin"

If this is the same key file that was burned to efuse, this will cause a problem. The Secure boot public signature verification key is used for signature verification so it needs to be ECDSA public key, not a 256 bit AES key.

As "Sign binaries during build" is disabled in your sdkconfig, you'll need to extract this key from signing_key.pem using "espsecure.py extract_public_key ...", as shown here:
https://docs.espressif.com/projects/esp ... -of-images

(In the default configuration with "Sign binaries during build" enabled, this step is handled by the build system.)

I don't know if this is causing the current problem you're seeing, unless the bootloader log output level is set to NONE there should be some error output if this was the case.

[WiFive]

WiFive, the output of "espsecure.py digest_secure_bootloader " is the digest with the image appended, so secure_bootloader.bin should be OK to flash at offset 0x0.

Oh, that's not really clear in docs

To generate a bootloader digest:

Code: Select all

espsecure.py digest_secure_bootloader --keyfile ./securebootkey.bin --output ./bootloader-digest.bin build/bootloader/bootloader.bin

Keyfile is the 32 byte raw secure boot key for the device. To flash this digest onto the device:

Code: Select all

esptool.py write_flash 0x0 bootloader-digest.bin

[snahmad75]

Hi Angus,

Can you answer my this query. Waiting for your reply.

I appreciate your input. Sorry I was using wrong key for boot verification.

Now I generate signature_verification_key.bin from my .pem file.

CONFIG_SECURE_BOOT_VERIFICATION_KEY="signature_verification_key.bin"

Now all working with my current partition_table.

Current Table:
nvs,data,nvs,0x9000,16K,
otadata,data,ota,0xd000,8K,
phy_init,data,phy,0xf000,4K,
ota_0,app,ota_0,0x10000,1856K,
ota_1,app,ota_1,0x1e0000,1856K,
storage,data,fat,0x3b0000,128K,


Now we need to increase our nvs partition size.
which I did.

New Table :
nvs,data,nvs,0x9000,32K,
otadata,data,ota,0x11000,8K,
phy_init,data,phy,0x13000,4K,
ota_0,app,ota_0,0x20000,1856K,
ota_1,app,ota_1,0x1f0000,1856K,
storage,data,fat,0x3c0000,128K,

now I can flash insecure bootloader on device where secure boot is off. this also works.

but when I try to secure bootloader with new partition_table on my second device. It is not booting.

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x10000 ./build/signed_W2K1-BootLoader-Release.bin

My signed_partitions.bin size is 4K and NVS offset is 0x9000


Error:

E (57) boot: ota data partition invalid and no factory, will try all partitions
E (57) esp_image: image at 0x20000 has invalid magic byte
W (61) esp_image: image at 0x20000 has invalid SPI mode 38
E (67) boot: OTA app partition slot 0 is not bootable
E (73) esp_image: image at 0x1f0000 has invalid magic byte
W (79) esp_image: image at 0x1f0000 has invalid SPI mode 255
W (85) esp_image: image at 0x1f0000 has invalid SPI size 15
E (92) boot: OTA app partition slot 1 is not bootable
E (97) boot: No bootable app partitions in the partition table



Thanks,
Naeem

[ESP_Angus]

Hi snahmad75,

Working backwards from the error in the log:

Code: Select all

E (57) esp_image: image at 0x20000 has invalid magic byte
W (61) esp_image: image at 0x20000 has invalid SPI mode 38
E (67) boot: OTA app partition slot 0 is not bootable
E (73) esp_image: image at 0x1f0000 has invalid magic byte
W (79) esp_image: image at 0x1f0000 has invalid SPI mode 255
W (85) esp_image: image at 0x1f0000 has invalid SPI size 15
E (92) boot: OTA app partition slot 1 is not bootable
E (97) boot: No bootable app partitions in the partition table

Translation: The bootloader is trying to find an app which is suitable for booting (valid, signed). It looks in two possible app partitions - at 0x20000 and 0x1f0000 (as given in your partition table) and doesn't find one.

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x10000 ./build/signed_W2K1-BootLoader-Release.bin

According to this the only app flashed was at offset 0x10000. Is this the problem?

[snahmad75]

Hi snahmad75,

Working backwards from the error in the log:

Code: Select all

E (57) esp_image: image at 0x20000 has invalid magic byte
W (61) esp_image: image at 0x20000 has invalid SPI mode 38
E (67) boot: OTA app partition slot 0 is not bootable
E (73) esp_image: image at 0x1f0000 has invalid magic byte
W (79) esp_image: image at 0x1f0000 has invalid SPI mode 255
W (85) esp_image: image at 0x1f0000 has invalid SPI size 15
E (92) boot: OTA app partition slot 1 is not bootable
E (97) boot: No bootable app partitions in the partition table

Translation: The bootloader is trying to find an app which is suitable for booting (valid, signed). It looks in two possible app partitions - at 0x20000 and 0x1f0000 (as given in your partition table) and doesn't find one.

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x10000 ./build/signed_W2K1-BootLoader-Release.bin

According to this the only app flashed was at offset 0x10000. Is this the problem?

Thanks for finding oblivious issue. The offset should be now 0x20000 not 0x10000
This works now.

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x20000 ./build/signed_W2K1-BootLoader-Release.bin

[snahmad75]

Hi snahmad75,

Working backwards from the error in the log:

Code: Select all

E (57) esp_image: image at 0x20000 has invalid magic byte
W (61) esp_image: image at 0x20000 has invalid SPI mode 38
E (67) boot: OTA app partition slot 0 is not bootable
E (73) esp_image: image at 0x1f0000 has invalid magic byte
W (79) esp_image: image at 0x1f0000 has invalid SPI mode 255
W (85) esp_image: image at 0x1f0000 has invalid SPI size 15
E (92) boot: OTA app partition slot 1 is not bootable
E (97) boot: No bootable app partitions in the partition table

Translation: The bootloader is trying to find an app which is suitable for booting (valid, signed). It looks in two possible app partitions - at 0x20000 and 0x1f0000 (as given in your partition table) and doesn't find one.

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x10000 ./build/signed_W2K1-BootLoader-Release.bin

According to this the only app flashed was at offset 0x10000. Is this the problem?

Thanks for finding obvious issue. The offset should be now 0x20000 not 0x10000
This works now.

esptool.py --port COM184 --baud 921600 write_flash 0x0000 ./build/secure_bootloader.bin 0x8000 ./build/signed_partitions.bin 0x20000 ./build/signed_W2K1-BootLoader-Release.bin