I have follow the ducument to enable ESP32-WROOM-32D secure boot and flash encryption
Follwoing error message occurs during first boot
ets Jun 8 2016 00:22:57
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:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5748
load:0x40078000,len:16132
ho 0 tail 12 room 4
load:0x40080000,len:5420
0x40080000: _iram_start at /media/sf_ESP32/esp/esp-idf-v3.1/components/freertos/xtensa_vectors.S:1685
entry 0x400802a0
0x400802a0: _DebugExceptionVector at ??:?
E (312) secure_boot: Embedded public verification key has wrong length 227
E (312) esp_image: Secure boot signature verification failed
E (520) boot: Factory app partition is not bootable
E (521) esp_image: image at 0x110000 has invalid magic byte
E (521) boot: OTA app partition slot 0 is not bootable
E (527) esp_image: image at 0x210000 has invalid magic byte
E (533) boot: OTA app partition slot 1 is not bootable
E (539) boot: No bootable app partitions in the partition table
Fatal exception (0): IllegalInstruction
epc1=0x400b7687, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
ESP32-WROOM-32D secure boot and flash encryption
Re: ESP32-WROOM-32D secure boot and flash encryption
Hi Fiskelin,
The build system embeds a ECDSA public key into the bootloader for use verifying the app.
If binaries are signed as part of the build (default behaviour) then this key should be extracted from the signing key during the build process.
This verification key is stored as raw binary data (not in PEM or DER format), so the bootloader doesn't need to include parsing code for these formats.
If the extraction was successful, you should see a file build/bootloader/bootloader_support/signature_verification_key.bin which is a 64 byte binary file.
If the verification key binary is different, one possibility is the signing key is not suitable. If you have openssl installed you can run a command to view the signing key parameters:
Check the key size (256 bit), ASN1 OID and NIST CURVE values all match what's shown here.
Because verification failed on the first boot, hardware secure boot should not be enabled yet - so you can rebuild and reflash the bootloader to try again.
The build system embeds a ECDSA public key into the bootloader for use verifying the app.
If binaries are signed as part of the build (default behaviour) then this key should be extracted from the signing key during the build process.
This verification key is stored as raw binary data (not in PEM or DER format), so the bootloader doesn't need to include parsing code for these formats.
If the extraction was successful, you should see a file build/bootloader/bootloader_support/signature_verification_key.bin which is a 64 byte binary file.
If the verification key binary is different, one possibility is the signing key is not suitable. If you have openssl installed you can run a command to view the signing key parameters:
Code: Select all
$ openssl ec -in ./secure_boot_signing_key.pem -text
read EC key
Private-Key: (256 bit)
priv:
(private key bytes here)
pub:
(public key bytes here)
ASN1 OID: prime256v1
NIST CURVE: P-256
writing EC key
(PEM formatted key here)
Because verification failed on the first boot, hardware secure boot should not be enabled yet - so you can rebuild and reflash the bootloader to try again.
Who is online
Users browsing this forum: No registered users and 169 guests