mcuboot icon indicating copy to clipboard operation
mcuboot copied to clipboard

ESP32(C3) Secure Boot options fail with missing signature errors

Open TheGarkine opened this issue 5 months ago • 4 comments

I was following this documentation. After a few hours, I have now just given up making this work.

I have added this fragment to my build config:

CONFIG_SECURE_BOOT=1
CONFIG_SECURE_BOOT_V2_ENABLED=1
CONFIG_SECURE_SIGNED_ON_BOOT=1
CONFIG_SECURE_SIGNED_APPS_RSA_SCHEME=1
CONFIG_SECURE_BOOT_SUPPORTS_RSA=1

I then generated a signing key with the espsecure tool:

espsecure generate_signing_key --version 2 bootloader_key.pem

I use this to sign the resulting binary:

espsecure sign_data --version 2 --keyfile bootloader_key.pem -a -o mcuboot.signed.bin build/mcuboot_esp32c3.bin

From here I flash the system:

esptool flash_erase
esptool --chip auto --baud 921600 --before default-reset --after hard-reset write-flash -u --flash-mode dio --flash-freq 80m --flash-size 4MB 0x0 mcuboot.signed.bin

This results in the following output:

[esp32c3] [INF] *** Booting MCUboot build v2.3.0-rc1-1-gd319cbc6 ***
[esp32c3] [INF] [boot] chip revision: v0.4
[esp32c3] [INF] [boot.esp32c3] SPI Speed      : 80MHz
[esp32c3] [INF] [boot.esp32c3] SPI Mode       : DIO
[esp32c3] [INF] [boot.esp32c3] SPI Flash Size : 4MB
[esp32c3] [INF] [boot] Enabling RNG early entropy source...
[esp32c3] [INF] enabling secure boot v2...
[esp32c3] [INF] [efuse] Batch mode of writing fields is enabled
[esp32c3] [INF] [esp_image] segment 0: paddr=00000020 vaddr=3fcdac00 size=03410h ( 13328) 
[esp32c3] [INF] [esp_image] segment 1: paddr=00003438 vaddr=403c7000 size=05b84h ( 23428) 
[esp32c3] [INF] [esp_image] segment 2: paddr=00008fc4 vaddr=403d0000 size=0446ch ( 17516) 
[esp32c3] [INF] [esp_image] Verifying image signature...
[esp32c3] [INF] [secure_boot_v2] Secure boot V2 is not enabled yet and eFuse digest keys are not set
[esp32c3] [INF] [secure_boot_v2] Verifying with RSA-PSS...
Sig block 0 invalid: Image digest does not match
[esp32c3] [ERR] [secure_boot_v2] Secure Boot V2 verification failed.
[esp32c3] [ERR] [esp_image] Secure boot signature verification failed
[esp32c3] [INF] [esp_image] Calculating simple hash to check for corruption...
[esp32c3] [WRN] [esp_image] image valid, signature bad
[esp32c3] [ERR] [secure_boot_v2] bootloader image appears invalid! error 8194
[esp32c3] [INF] [efuse] Batch mode of writing fields is cancelled

Dumping the image via esptool to a binary file and the using espsecure works though:

$> espsecure verify-signature -k bootloader_key.pem -v 2 flash_dump.bin
espsecure v5.1.0
Signature block 0 is valid (RSA).
Signature block 0 verification successful using the supplied key (RSA).
Signature block 1 invalid. Skipping.
Signature block 2 invalid. Skipping.

I checked the actual code, and I feel it should work, the only guess I have left is that there is some virtual size-limitation that I am unaware of, and actually the signature is not fully loaded? I am aware of the 64K limit.

$> du -h mcuboot.signed.bin 
56K    mcuboot.signed.bin

Pointers would be much appreciated, maybe my next step would be trying to find deeper information from espressif.

TheGarkine avatar Nov 20 '25 10:11 TheGarkine

Ah before I forget: I thought about removing CONFIG_SECURE_SIGNED_ON_BOOT causing it to skip inital verfication (ROM should do this on subsequent boots anyways. But then of course the signature is missing on the next step.

[esp32c3] [INF] *** Booting MCUboot build v2.3.0-rc1-1-gd319cbc6 ***
[esp32c3] [INF] [boot] chip revision: v0.4
[esp32c3] [INF] [boot.esp32c3] SPI Speed      : 80MHz
[esp32c3] [INF] [boot.esp32c3] SPI Mode       : DIO
[esp32c3] [INF] [boot.esp32c3] SPI Flash Size : 4MB
[esp32c3] [INF] [boot] Enabling RNG early entropy source...
[esp32c3] [INF] enabling secure boot v2...
[esp32c3] [INF] [efuse] Batch mode of writing fields is enabled
[esp32c3] [INF] [esp_image] segment 0: paddr=00000020 vaddr=3fcdac00 size=0313ch ( 12604) 
[esp32c3] [INF] [esp_image] segment 1: paddr=00003164 vaddr=403c7000 size=05b84h ( 23428) 
[esp32c3] [INF] [esp_image] segment 2: paddr=00008cf0 vaddr=403d0000 size=03dd0h ( 15824) 
[esp32c3] [INF] [secure_boot_v2] Secure boot digests absent, generating..
[esp32c3] [ERR] [secure_boot_v2] No valid bootloader signature blocks found.
[esp32c3] [INF] [efuse] Batch mode of writing fields is cancelled

TheGarkine avatar Nov 20 '25 10:11 TheGarkine

And last comment: If I blow the efuses manually with:

espefuse --port <MY_PORT> --chip esp32c3 burn-key-digest BLOCK_KEY0 bootloader_key.pem SECURE_BOOT_DIGEST0
espefuse.py --port <MY_PORT> --chip esp32c3 burn-efuse SECURE_BOOT_EN 1

Secure Boot is setup correctly, and requires my signed bootloader to work (this is my current workaround).

TheGarkine avatar Nov 20 '25 10:11 TheGarkine

Hi @TheGarkine please try to flash the signed bootloader using this flash frequency parameter (--flash-freq 40m):

esptool --chip esp32c3 --baud 921600 --no-stub --before default-reset --after no-reset write-flash --flash-mode dio --flash-freq 40m --flash-size 4MB 0x0 mcuboot.signed.bin

I recently bumped into similar behavior, and it was because when building the Espressif Port, the esptool elf2image step that generates the bootloader binary uses some "default" flash parameters, however when flashing it manually with different parameters esptool may try to change the binary header before writing it, resulting a different calculated image digest when Secure Boot is enabled. I still need to improve the readme-espressif with more accurate instructions to point that.

Please let me know if the above suggestion worked.

almir-okato avatar Nov 20 '25 13:11 almir-okato

Hey @almir-okato ! Thank you for your quick response:

Wow, I never expected the flashing tool to change the image I am writing, really good pointer! Would you happen to know why it does that? Is it important for a written Image how it was flashed?

(Found it here)

So yeah this is working now, but I am running straight into a panic:

[esp32c3] [INF] *** Booting MCUboot build v2.3.0-rc1-1-gd319cbc6 ***
[esp32c3] [INF] [boot] chip revision: v0.4
[esp32c3] [INF] [boot.esp32c3] SPI Speed      : 40MHz
[esp32c3] [INF] [boot.esp32c3] SPI Mode       : DIO
[esp32c3] [INF] [boot.esp32c3] SPI Flash Size : 4MB
[esp32c3] [INF] [boot] Enabling RNG early entropy source...
[esp32c3] [INF] enabling secure boot v2...
[esp32c3] [INF] [efuse] Batch mode of writing fields is enabled
[esp32c3] [INF] [esp_image] segment 0: paddr=00000020 vaddr=3fcdac00 size=03410h ( 13328) 
[esp32c3] [INF] [esp_image] segment 1: paddr=00003438 vaddr=403c7000 size=05b84h ( 23428) 
[esp32c3] [INF] [esp_image] segment 2: paddr=00008fc4 vaddr=403d0000 size=0446ch ( 17516) 
[esp32c3] [INF] [esp_image] Verifying image signature...
[esp32c3] [INF] [secure_boot_v2] Secure boot V2 is not enabled yet and eFuse digest keys are not set
[esp32c3] [INF] [secure_boot_v2] Verifying with RSA-PSS...
[esp32c3] [INF] [secure_boot_v2] Secure boot digests absent, generating..
[esp32c3] [INF] [secure_boot_v2] Digests successfully calculated, 1 valid signatures (image offset 0x0)
[esp32c3] [INF] [secure_boot_v2] 1 signature block(s) found appended to the bootloader.
[esp32c3] [INF] [secure_boot_v2] Burning public key hash to eFuse
[esp32c3] [ERR] [efuse] Range of data does not match the coding scheme
Guru Meditation Error: Core 0 panic'ed (Illegal instruction)
Core 0 register dump:
PC      : 0x00000000  RA      : 0x00000000  SP      : 0x3fcde2e0  GP      : 0x00000000
TP      : 0x00000000  T0      : 0x403d1d44  T1      : 0x00000000  T2      : 0xc4aa4d69
S0      : 0x00000007  S1      : 0x00000000  A0      : 0x0000000c  A1      : 0x0000000a
A2      : 0x0000002e  A3      : 0x00000002  A4      : 0x0000000d  A5      : 0x00001604
A6      : 0xa0000000  A7      : 0x0000000a  S2      : 0x0000000a  S3      : 0x3fcde330
S4      : 0x3fcde3a8  S5      : 0x00000001  S6      : 0x3fcde3c8  S7      : 0x00000003
S8      : 0x000000e7  S9      : 0x3fcdab28  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x00000000  T6      : 0x00000080
MSTATUS : 0x00001881  MCAUSE  : 0x00000002  MTVAL   : 0x00000000  INTLEVEL: 0x00000001
...

Didn't have time to investigate this further yet. Maybe you already have a clue what's happening? I read about coding schemes in the documentation at least.

When we are done, I hope its fine if I feel free to append the documentation a little!

TheGarkine avatar Nov 21 '25 08:11 TheGarkine