Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secure boot check fails after reflashing bootloader (IDFGH-13425) #14331

Closed
3 tasks done
AmritpalSinghSarao opened this issue Aug 7, 2024 · 8 comments
Closed
3 tasks done
Assignees
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@AmritpalSinghSarao
Copy link

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I got new device and enabled the secure boot option and selected Secure bootloader mode (Reflashable) and attached the (secure_boot_signing_key.pem) Secure boot private signing key in menuconfig. Then I uploaded my firmware and everything worked fine.
My question, is key is automatically burned into chip of secure boot?
ABS_DONE_0 (BLOCK0) Secure boot V1 is enabled for bootloader image = True R/W (0b1)

if yes, in which BLOCK? Because in summary I don't see any BLOCK0
However, I faced some issue and mistakenly erased all the flash from 0x00 . According to docu, it should be fine as we have set re-flashable into config.
After that I run the following command
esptool.py --before default_reset --after no_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x0 build/bootloader/bootloader-reflash-digest.bin --force and works fine.
Then
esptool.py --before default_reset --after no_reset --chip esp32 write_flash --flash_mode dio --flash_size 4MB --flash_freq 40m 0x20000 build/partition_table/partition-table.bin 0x68000 build/ota_data_initial.bin 0x70000 build/iot_c.bin
After that I try to run with idf.py monitor but getting the following error.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x1b (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:0x3fff00b8,len:2280
load:0x40078000,len:21916
ho 0 tail 12 room 4
load:0x40080400,len:4
load:0x40080404,len:2856
secure boot check fail
ets_main.c 371
ets Jun 8 2016 00:22:57

@espressif-bot espressif-bot added the Status: Opened Issue is new label Aug 7, 2024
@github-actions github-actions bot changed the title Secure boot check fails after reflashing bootloader Secure boot check fails after reflashing bootloader (IDFGH-13425) Aug 7, 2024
@AmritpalSinghSarao
Copy link
Author

AmritpalSinghSarao commented Aug 7, 2024

I was forgetting, when I flashed first time bootloader on 0x1000, everything worked fine.
using ESP32

@AmritpalSinghSarao
Copy link
Author

@sachin0x18 Can you help me please. Because I saw that you answered the similar question.

@KonstantinKondrashov
Copy link
Collaborator

Hi @AmritpalSinghSarao!

My question, is key is automatically burned into chip of secure boot?

Yes, at the first boot, the bootloader burns the key into the BLOCK2.

secure boot check fail

Try to write the bootloader-reflash-digest.bin without the --flash_mode dio --flash_freq 40m --flash_size 4MB flags I suspect that they are different from what you have in the binary file and esptool changes the bootloader image on the fly and do not change the signature.

esptool.py --before default_reset --after no_reset write_flash  0x0 build/bootloader/bootloader-reflash-digest.bin --force

Follow instructions in the doc to get Reflashable Software Bootloader - https://docs.espressif.com/projects/esp-idf/en/stable/esp32/security/secure-boot-v1.html#reflashable-software-bootloader.

@AmritpalSinghSarao
Copy link
Author

AmritpalSinghSarao commented Aug 8, 2024

@KonstantinKondrashov
I run your command but have the same issue.
Erasing the flash could have had impact on device?
Just wondering is there any way to check if that bootloader was flashed with re-flashable mode not one-time?
I am quite sure that we did with re-flashable mode which is our default setting.

Also changing the partition-table could have impact on that?

@mahavirj
Copy link
Member

mahavirj commented Aug 9, 2024

@AmritpalSinghSarao

  • Can you please confirm if you had indeed flashed the secure boot key using espefuse.py burn_key command? The command gets auto-generated during the 1st build phase and its highlighted under title "Burn secure boot key to efuse using".
  • Re-flashable bootloader setting you can confirm from your sdkconfig - CONFIG_SECURE_BOOTLOADER_REFLASHABLE entry
  • Please share output of espefuse.py summary command and your project sdkconfig here

Side-note: If you are using ESP32 with rev >= 3.0 then its highly recommended to use secure boot v2 scheme.

@AmritpalSinghSarao
Copy link
Author

@mahavirj Thanks for your response.

  • I have never run espefuse.py burn_key. I have only run idf.py bootloader-flash
  • I know that, but wanted to confirm whether we can check or not, that which setting was set while flashing boot.
  • I can't provide that information soon, it might take 2 week.
    Please keep this issue open. I will espefuse.py summary once I have that device back.

@AmritpalSinghSarao
Copy link
Author

AmritpalSinghSarao commented Aug 26, 2024

@mahavirj

=== Run "summary" command ===
EFUSE_NAME (Block) Description = [Meaningful Value] [Readable/Writeable] (Hex Value)

Calibration fuses:
ADC_VREF (BLOCK0) True ADC reference voltage = 1156 R/W (0b01000)

Config fuses:
WR_DIS (BLOCK0) Efuse write disable mask = 256 R/W (0x0100)
RD_DIS (BLOCK0) Disable reading from BlOCK1-3 = 2 R/W (0x2)
DISABLE_APP_CPU (BLOCK0) Disables APP CPU = False R/W (0b0)
DISABLE_BT (BLOCK0) Disables Bluetooth = False R/W (0b0)
DIS_CACHE (BLOCK0) Disables cache = False R/W (0b0)
CHIP_CPU_FREQ_LOW (BLOCK0) If set alongside EFUSE_RD_CHIP_CPU_FREQ_RATED; the = False R/W (0b0)
ESP32's max CPU frequency is rated for 160MHz. 24
0MHz otherwise
CHIP_CPU_FREQ_RATED (BLOCK0) If set; the ESP32's maximum CPU frequency has been = True R/W (0b1)
rated
BLK3_PART_RESERVE (BLOCK0) BLOCK3 partially served for ADC calibration data = False R/W (0b0)
CLK8M_FREQ (BLOCK0) 8MHz clock freq override = 54 R/W (0x36)
VOL_LEVEL_HP_INV (BLOCK0) This field stores the voltage level for CPU to run = 0 R/W (0b00)
at 240 MHz; or for flash/PSRAM to run at 80 MHz.0
x0: level 7; 0x1: level 6; 0x2: level 5; 0x3: leve
l 4. (RO)
CODING_SCHEME (BLOCK0) Efuse variable block length scheme
= NONE (BLK1-3 len=256 bits) R/W (0b00)
CONSOLE_DEBUG_DISABLE (BLOCK0) Disable ROM BASIC interpreter fallback = True R/W (0b1)
DISABLE_SDIO_HOST (BLOCK0) = False R/W (0b0)
DISABLE_DL_CACHE (BLOCK0) Disable flash cache in UART bootloader = False R/W (0b0)

Flash fuses:
FLASH_CRYPT_CNT (BLOCK0) Flash encryption is enabled if this field has an o = 0 R/W (0b0000000)
dd number of bits set
FLASH_CRYPT_CONFIG (BLOCK0) Flash encryption config (key tweak bits) = 0 R/W (0x0)

Identity fuses:
CHIP_PACKAGE_4BIT (BLOCK0) Chip package identifier #4bit = False R/W (0b0)
CHIP_PACKAGE (BLOCK0) Chip package identifier = 1 R/W (0b001)
CHIP_VER_REV1 (BLOCK0) bit is set to 1 for rev1 silicon = True R/W (0b1)
CHIP_VER_REV2 (BLOCK0) = False R/W (0b0)
WAFER_VERSION_MINOR (BLOCK0) = 0 R/W (0b00)
WAFER_VERSION_MAJOR (BLOCK0) calc WAFER VERSION MAJOR from CHIP_VER_REV1 and CH = 1 R/W (0b001)
IP_VER_REV2 and apb_ctl_date (read only)
PKG_VERSION (BLOCK0) calc Chip package = CHIP_PACKAGE_4BIT << 3 + CHIP_ = 1 R/W (0x1)
PACKAGE (read only)

Jtag fuses:
JTAG_DISABLE (BLOCK0) Disable JTAG = True R/W (0b1)

Mac fuses:
MAC (BLOCK0) MAC address
= 94:3c:c6:b1:fe:10 (CRC 0x37 OK) R/W
MAC_CRC (BLOCK0) CRC8 for MAC address = 55 R/W (0x37)
MAC_VERSION (BLOCK3) Version of the MAC field = 0 R/W (0x00)

Security fuses:
UART_DOWNLOAD_DIS (BLOCK0) Disable UART download mode. Valid for ESP32 V3 and = False R/W (0b0)
newer; only
ABS_DONE_0 (BLOCK0) Secure boot V1 is enabled for bootloader image = True R/W (0b1)
ABS_DONE_1 (BLOCK0) Secure boot V2 is enabled for bootloader image = False R/W (0b0)
DISABLE_DL_ENCRYPT (BLOCK0) Disable flash encryption in UART bootloader = False R/W (0b0)
DISABLE_DL_DECRYPT (BLOCK0) Disable flash decryption in UART bootloader = False R/W (0b0)
KEY_STATUS (BLOCK0) Usage of efuse block 3 (reserved) = False R/W (0b0)
SECURE_VERSION (BLOCK3) Secure version for anti-rollback = 0 R/W (0x00000000)
BLOCK1 (BLOCK1) 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 R/W
BLOCK2 (BLOCK2) Security boot key
= ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
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

Spi Pad fuses:
SPI_PAD_CONFIG_HD (BLOCK0) read for SPI_pad_config_hd = 0 R/W (0b00000)
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_CS0 (BLOCK0) Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0b00000)

Vdd fuses:
XPD_SDIO_REG (BLOCK0) read for XPD_SDIO_REG = False R/W (0b0)
XPD_SDIO_TIEH (BLOCK0) If XPD_SDIO_FORCE & XPD_SDIO_REG = 1.8V R/W (0b0)
XPD_SDIO_FORCE (BLOCK0) Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = False R/W (0b0)

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

#Security features

CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_V1_SUPPORTED=y
CONFIG_SECURE_SIGNED_APPS_ECDSA_SCHEME=y
CONFIG_SECURE_BOOT=y
CONFIG_SECURE_BOOT_V1_ENABLED=y
#CONFIG_SECURE_BOOTLOADER_ONE_TIME_FLASH is not set
CONFIG_SECURE_BOOTLOADER_REFLASHABLE=y
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=y
CONFIG_SECURE_BOOT_SIGNING_KEY="secure_boot_signing_key.pem"
CONFIG_SECURE_BOOTLOADER_KEY_ENCODING_256BIT=y
#CONFIG_SECURE_BOOTLOADER_KEY_ENCODING_192BIT is not set
#CONFIG_SECURE_BOOT_INSECURE is not set
#CONFIG_SECURE_FLASH_ENC_ENABLED is not set
#end of Security features

I went through the documentation again, if we run idf.py bootloader-flash, it will will generate the hardware generated key and will burn it, even though, we have selected the re-flashable option. To have, the re-flashable, I should have used my own key.
I think, this might have created some confusion.

@mahavirj
Copy link
Member

@AmritpalSinghSarao

The step to burn secure boot v1 specific key is highlighted in the documentation section here (step 4): https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v1.html#reflashable-software-bootloader. If you have missed out on that then it is not possible to update the bootloader on this device.

FWIW, we are trying to integrate different security workflows through qemu (emulator) port for different targets. This will allow to establish the workflow under emulator setup and then it can be moved to real hardware. Please keep an eye on the documentation guide here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/qemu.html

Closing the issue, please feel free to re-open if you have more questions

@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: Opened Issue is new labels Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

4 participants