ESP32 Forum

Posted: **Mon Mar 08, 2021 9:21 am**

Hello!

I have problems with enabling Secure Boot V2 on my ESP32-WROOM-32E module.
I am developing firmware in PlatformIO and using commandline tools fo flash and enable SB2.

[*]I have generated SB2 keys

Code: Select all

espsecure.py generate_signing_key --version 2 sb2.pem
espsecure.py digest_rsa_public_key --keyfile sb2.pem --output sb2.bin

[*]Enabled SB2 and encryption in menuconfig
[*]Compiled and signed firmware and bootloader

Code: Select all

espsecure.py sign_data --version 2 --keyfile sb2.pem --output fw\firmware_sig.bin fw\firmware.bin
espsecure.py sign_data --version 2 --keyfile sb2.pem --output fw\bootloader_sig.bin fw\bootloader.bin

[*]Flashed key and binaries

Code: Select all

espefuse.py --port COM5 burn_key_digest sb2.pem
esptool.py --chip esp32 --port COM5 --baud 921600 --before default_reset --after no_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 fw\bootloader_sig.bin 0xC000 fw\partitions.bin 0x1D000 fw\ota_data_initial.bin 0x20000 fw\firmware_sig.bin 0x3e0000 fw\nvs_key.bin 0x3f0000 fw\mfg.bin

When booting I get errors that application doesn't have valid signature:

Code: Select all

I (644) secure_boot: Verifying with RSA-PSS...
W (653) secure_boot_v2: Using pre-loaded secure boot v2 public key digest in EFUSE block 2
I (943) secure_boot_v2: valid signature block found
E (948) secure_boot_v2: Application not signed with a valid private key.
E (948) boot: Secure Boot v2 failed (-1)
E (950) boot: Factory app partition is not bootable
E (955) esp_image: image at 0x160000 has invalid magic byte
W (962) esp_image: image at 0x160000 has invalid SPI mode 255
W (968) esp_image: image at 0x160000 has invalid SPI size 15
E (974) boot: OTA app partition slot 0 is not bootable
E (980) esp_image: image at 0x2a0000 has invalid magic byte
W (986) esp_image: image at 0x2a0000 has invalid SPI mode 255
W (993) esp_image: image at 0x2a0000 has invalid SPI size 15
E (999) boot: OTA app partition slot 1 is not bootable
E (1005) boot: No bootable app partitions in the partition table

[*]But I can verify on PC that bootloader and firmware bin files have valid signatures using command:

Code: Select all

espsecure.py verify_signature --version 2 --keyfile sb2.pem fw\bootloader_sig.bin

[*]And I see that block2 contains same content as I see in bin file generated by

Code: Select all

espsecure.py digest_rsa_public_key

[*]I have tried using PlatformIO tools generated bootloader and also IDF native generated bootloader and also firmware signing scripts.
[*]ESP32 had encryption enable before, but I don't think that could cause these problems.

My efuses:

Code: Select all

espefuse.py v3.1-dev
EFUSE_NAME (Block)                       Description  = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Calibration fuses:
BLK3_PART_RESERVE (BLOCK0):              BLOCK3 partially served for ADC calibration data   = False R/W (0b0)
ADC_VREF (BLOCK0):                       Voltage reference calibration                      = 1128 R/W (0b00100)

Config fuses:
XPD_SDIO_FORCE (BLOCK0):                 Ignore MTDI pin (GPIO12) for VDD_SDIO on reset     = False R/W (0b0)
XPD_SDIO_REG (BLOCK0):                   If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset    = False R/W (0b0)
XPD_SDIO_TIEH (BLOCK0):                  If XPD_SDIO_FORCE & XPD_SDIO_REG                   = 1.8V R/W (0b0)
CLK8M_FREQ (BLOCK0):                     8MHz clock freq override                           = 49 R/W (0x31)
SPI_PAD_CONFIG_CLK (BLOCK0):             Override SD_CLK pad (GPIO6/SPICLK)                 = 0 R/W (0b00000)
SPI_PAD_CONFIG_Q (BLOCK0):               Override SD_DATA_0 pad (GPIO7/SPIQ)                = 0 R/W (0b00000)
SPI_PAD_CONFIG_D (BLOCK0):               Override SD_DATA_1 pad (GPIO8/SPID)                = 0 R/W (0b00000)
SPI_PAD_CONFIG_HD (BLOCK0):              Override SD_DATA_2 pad (GPIO9/SPIHD)               = 0 R/W (0b00000)
SPI_PAD_CONFIG_CS0 (BLOCK0):             Override SD_CMD pad (GPIO11/SPICS0)                = 0 R/W (0b00000)
DISABLE_SDIO_HOST (BLOCK0):              Disable SDIO host                                  = False R/W (0b0)

Efuse fuses:
WR_DIS (BLOCK0):                         Efuse write disable mask                           = 384 R/W (0x0180)
RD_DIS (BLOCK0):                         Efuse read disable mask                            = 1 R/W (0x1)
CODING_SCHEME (BLOCK0):                  Efuse variable block length scheme
   = NONE (BLK1-3 len=256 bits) R/W (0b00)
KEY_STATUS (BLOCK0):                     Usage of efuse block 3 (reserved)                  = False R/W (0b0)

Identity fuses:
MAC (BLOCK0):                            Factory MAC Address
   = .............. R/W
MAC_CRC (BLOCK0):                        CRC8 for factory MAC address                       = 227 R/W (0xe3)
CHIP_VER_REV1 (BLOCK0):                  Silicon Revision 1                                 = True R/W (0b1)
CHIP_VER_REV2 (BLOCK0):                  Silicon Revision 2                                 = True R/W (0b1)
CHIP_VERSION (BLOCK0):                   Reserved for future chip versions                  = 2 R/W (0b10)
CHIP_PACKAGE (BLOCK0):                   Chip package identifier                            = 1 R/W (0b001)
MAC_VERSION (BLOCK3):                    Version of the MAC field                           = 0 R/W (0x00)

Security fuses:
FLASH_CRYPT_CNT (BLOCK0):                Flash encryption mode counter                      = 3 R/W (0b0000011)
UART_DOWNLOAD_DIS (BLOCK0):              Disable UART download mode (ESP32 rev3 only)       = False R/W (0b0)
FLASH_CRYPT_CONFIG (BLOCK0):             Flash encryption config (key tweak bits)           = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE (BLOCK0):          Disable ROM BASIC interpreter fallback             = True R/W (0b1)
ABS_DONE_0 (BLOCK0):                     Secure boot V1 is enabled for bootloader image     = False R/W (0b0)
ABS_DONE_1 (BLOCK0):                     Secure boot V2 is enabled for bootloader image     = False R/W (0b0)
JTAG_DISABLE (BLOCK0):                   Disable JTAG                                       = True R/W (0b1)
DISABLE_DL_ENCRYPT (BLOCK0):             Disable flash encryption in UART bootloader        = False R/W (0b0)
DISABLE_DL_DECRYPT (BLOCK0):             Disable flash decryption in UART bootloader        = True R/W (0b1)
DISABLE_DL_CACHE (BLOCK0):               Disable flash cache in UART bootloader             = True R/W (0b1)
BLOCK1 (BLOCK1):                         Flash encryption key
   = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLOCK2 (BLOCK2):                         Secure boot key
   = 43 33 3a af d6 f7 fb 05 e2 77 85 d7 85 70 f7 36 2c 4e 34 5f fc 26 95 11 7a db 65 6d d9 cd 0d 6e R/-
BLOCK3 (BLOCK3):                         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

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

Can anyone help me understanding where could be the problem?

Posted: **Thu Mar 11, 2021 8:21 am**

Can anyone help?
Did same thing with next ESP32-WROOM-32E module. This time only efuses changed are BLOCK2 and it's write protect, nothing else touched and still getting "Application not signed with a valid private key"
Any advices what to try?
Am I generating or writing key incorrectly?
@ESP_Angus ?

Posted: **Thu Mar 11, 2021 4:35 pm**

Say what branch and commit of esp-idf you are using

Posted: **Fri Mar 12, 2021 7:38 am**

@WiFive
Using ESP-IDF v4.2-0-gc40f2590b

I noticed reading SB2 documentation is that there is no word about when and how SB2 key is burned in efuses: https://docs.espressif.com/projects/esp ... nerate-key

Can it be that bootloader contains digest and burns it to BLOCK2?
Maybe that's the problem because I burn BLOCK2 myself.

Code: Select all

I (31) boot: ESP-IDF v4.2-dirty 2nd stage bootloader
I (31) boot: compile time 10:36:32
I (31) boot: chip revision: 3
I (35) boot.esp32: SPI Speed      : 40MHz
I (39) boot.esp32: SPI Mode       : DIO
I (44) boot.esp32: SPI Flash Size : 4MB
I (48) boot: Enabling RNG early entropy source...
I (54) boot: Partition Table:
I (57) boot: ## Label            Usage          Type ST Offset   Length
I (64) boot:  0 nvs              WiFi data        01 02 0000d000 00010000
I (72) boot:  1 otadata          OTA data         01 00 0001d000 00002000
I (79) boot:  2 phy_init         RF data          01 01 0001f000 00001000
I (87) boot:  3 factory          factory app      00 00 00020000 00140000
I (94) boot:  4 ota_0            OTA app          00 10 00160000 00140000
I (102) boot:  5 ota_1            OTA app          00 11 002a0000 00140000
I (109) boot:  6 nvs_key          NVS keys         01 04 003e0000 00001000
I (117) boot:  7 fctry            WiFi data        01 02 003f0000 00010000
I (124) boot: End of partition table
I (129) boot: Defaulting to factory image
I (133) esp_image: segment 0: paddr=0x00020020 vaddr=0x3f400020 size=0x3c55c (247132) map
I (236) esp_image: segment 1: paddr=0x0005c584 vaddr=0x3ffb0000 size=0x03a94 ( 14996) load
I (243) esp_image: segment 2: paddr=0x00060020 vaddr=0x400d0020 size=0x9f0ac (651436) map
I (491) esp_image: segment 3: paddr=0x000ff0d4 vaddr=0x3ffb3a94 size=0x001e8 (   488) load
I (492) esp_image: segment 4: paddr=0x000ff2c4 vaddr=0x40080000 size=0x00404 (  1028) load
I (498) esp_image: segment 5: paddr=0x000ff6d0 vaddr=0x40080404 size=0x172ac ( 94892) load
I (548) esp_image: segment 6: paddr=0x00116984 vaddr=0x00000000 size=0x0964c ( 38476)
I (563) esp_image: Verifying image signature...
I (563) secure_boot: Secure Boot eFuse bit(ABS_DONE_1) not yet programmed.
I (565) secure_boot: Verifying with RSA-PSS...
I (586) boot: Loaded app from partition at offset 0x20000
I (587) secure_boot_v2: enabling secure boot v2...
I (587) esp_image: segment 0: paddr=0x00001020 vaddr=0x3fff0030 size=0x00004 (     4)
I (595) esp_image: segment 1: paddr=0x0000102c vaddr=0x3fff0034 size=0x02c50 ( 11344)
I (608) esp_image: segment 2: paddr=0x00003c84 vaddr=0x40078000 size=0x044f0 ( 17648)
I (619) esp_image: segment 3: paddr=0x0000817c vaddr=0x40080400 size=0x011d8 (  4568)
I (623) esp_image: Verifying image signature...
I (627) secure_boot: Secure Boot eFuse bit(ABS_DONE_1) not yet programmed.
I (634) secure_boot: Verifying with RSA-PSS...
W (643) secure_boot_v2: Using pre-loaded secure boot v2 public key digest in EFUSE block 2
I (945) secure_boot_v2: valid signature block found
E (950) secure_boot_v2: Application not signed with a valid private key.
E (950) boot: Secure Boot v2 failed (-1)
E (951) boot: Factory app partition is not bootable
E (957) esp_image: image at 0x160000 has invalid magic byte
W (963) esp_image: image at 0x160000 has invalid SPI mode 255
W (970) esp_image: image at 0x160000 has invalid SPI size 15
E (976) boot: OTA app partition slot 0 is not bootable
E (982) esp_image: image at 0x2a0000 has invalid magic byte
W (988) esp_image: image at 0x2a0000 has invalid SPI mode 255
W (995) esp_image: image at 0x2a0000 has invalid SPI size 15
E (1001) boot: OTA app partition slot 1 is not bootable
E (1007) boot: No bootable app partitions in the partition table

I also noticed " Using pre-loaded secure boot v2 public key digest in EFUSE block 2" is shown as warning - probably bootloader wanted to burn key itself, but why would that matter if I burn digest correctly.
Will try resoldering new ESP32 module and try without burning sb2 digest manually.
Would

Posted: **Fri Mar 12, 2021 3:26 pm**

OK i successfully enabled SecureBoot V2 by alowing bootloader to burn secure boot digest to BLOCK2
This is kind of OK, but I don't understand why manual digest burning didn't work. I can't see the values burned by bootloader now after Secure Boot and encryption are enabled.

Posted: **Sat Mar 13, 2021 4:22 am**

kristaps_r wrote: ↑
Fri Mar 12, 2021 3:26 pm
I can't see the values burned by bootloader now after Secure Boot and encryption are enabled.

The public key digest should not be read protected with secure boot v2

Posted: **Tue Mar 16, 2021 7:55 am**

Turns out it isn't read protected but bootloader isn't responding to UART after SecureBoot V2 and Flash encryption enabling.
Can't read any efuses or upload anything using bootloader.

I took next module and flashed with software that reads BLOCK2 and it is exactly the same as on those 2 modules where I burned BLOCK2 manually. So I don't understand why bootloader fails to verify same binaries in case when BLOCK2 is burned manually.
Seems like a bug to me.

When I will work on next boards will gather more information.

Posted: **Tue Mar 16, 2021 8:11 am**

https://github.com/espressif/esp-idf/issues/6050

Posted: **Tue Mar 16, 2021 1:54 pm**

I saw this but this seemed as problem with espsecure.py digest_rsa_public_key writing reverse order bytes but I observed that byte order was ok for me.
Just tried that patch and it worked on esp32 where i burned BLOCK2 previously.

Thanks for help

Posted: **Tue Mar 23, 2021 2:52 am**

kristaps_r wrote: ↑
Tue Mar 16, 2021 7:55 am
Turns out it isn't read protected but bootloader isn't responding to UART after SecureBoot V2 and Flash encryption enabling.
Can't read any efuses or upload anything using bootloader.

By default, when you enable Secure Boot V2 it also enables the config option to disable the ROM UART loader mode. This isn't necessary to protect against any known vulnerability, but it significantly reduces the "attack surface" for an attacker.

You can prevent this from happening by changing two config options:

Select Don't automatically restrict UART download mode

And then de-select Permanently disable ROM download mode

This default has caused some confusion for other users, so we're going to change the next release so it doesn't do this by default - it's a recommended additional step, but it will be "opt-in" rather than "opt-out". Sorry for the hassle caused.

(Even if you keep ROM download mode enabled now, it's possible to set "Permanently disable ROM download mode", OTA update to a new app version built with this config, and it will disable download mode when it boots. So you can close the download mode off later, once you're convinced everything is working as expected.)

kristaps_r wrote: ↑
Tue Mar 16, 2021 7:55 am
I took next module and flashed with software that reads BLOCK2 and it is exactly the same as on those 2 modules where I burned BLOCK2 manually. So I don't understand why bootloader fails to verify same binaries in case when BLOCK2 is burned manually.
Seems like a bug to me.

This does seem very unexpected. Could you post the code you used to read BLOCK2 and the output it displayed, please?

If you dump the hex contents of "sb2.bin", what is output? (On Linux can use "hexdump sb2.bin" for this, similar tools are available for Windows.)

In general, there isn't any downside to waiting until the first boot for the device to burn the digest itself. But it should be possible to do it manually as well.

ESP32 Forum

Problem with Secure Boot V2 enabling

Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling

Re: Problem with Secure Boot V2 enabling