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.

Sign up for GitHub

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

Jump to bottom

Secureboot - Failed to test the key revocation with virtual efuse (IDFGH-6618) #8260

Closed
Darsh-Dev opened this issue Jan 19, 2022 · 5 comments
Closed

Secureboot - Failed to test the key revocation with virtual efuse (IDFGH-6618) #8260

Darsh-Dev opened this issue Jan 19, 2022 · 5 comments
Assignees
@mahavirj
Labels
Awaiting Response awaiting a response from the author Resolution: Won't Do This will not be worked on Status: Done Issue is done internally

Comments

@Darsh-Dev
Copy link

Environment

  • Development Kit: ESP32-S2-WROVER
  • Module or chip used: ESP32-S2-WROVER
  • IDF version (run git describe --tags to find it): v4.4-beta1
  • Build System: idf.py
  • Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2) 8.4.0
  • Operating System: Linux
  • Power Supply: USB

Problem Description

I have tested the secure-boot v2 with the virtual efuse mechanism and it's working fine. Now I want to test the key revocation mechanism with the virtual efuse but failed to test the aggressive/conservative both key revocation with virtual efuse. So, is key revocation not supported with virtual efuse?

Expected Behavior

Revoke the key permanently and signature verification failed if FW signed with revoke key

Actual Behavior

Key not revoke with virtual efuse and signature verification is passed

Steps to reproduce

I follow below steps but it doesn't work

  1. “Security features” set “Enable hardware Secure Boot in bootloader” to enable Secure Boot.
  2. Enabled virtual efuse CONFIG_EFUSE_VIRTUAL and CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH and Enabled aggressive key revocation CONFIG_SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE.
  3. Generate secure boot signing keys using the below commands
    openssl genrsa -out my_secure_boot_signing_key.pem 3072
  4. Signed bootloader with all three private key(s) that are needed for the life of the device, using the below command
    espsecure.py sign_data -k secure_boot_signing_key2.pem -v 2 –append_signatures -o signed_bootloader.bin build/bootloader/bootloader.bin
  5. Flash signed bootloader image.
  6. Signed firmware application with invalid private key and flash that application
  7. bootloader shows the signature verification failed but doesn't revoke any key.
  8. I have verified by signing fw with any of three valid keys and the application signature verify successfully

Debug Logs

ESP-ROM:esp32s2-rc4-20191025 
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe63d0,len:0x290c
load:0x4004c000,len:0xa38
load:0x40050000,len:0x49d4
entry 0x4004c1f8
W (25) boot.esp32s2: eFuse virtual mode is enabled. If Secure boot or Flash encryption is enabled then it does not provide any security. FOR TESTING ONLY!
I (41) boot: ESP-IDF v4.4-beta1 2nd stage bootloader
I (41) boot: compile time 14:32:30
I (41) boot: chip revision: 0
I (44) boot.esp32s2: SPI Speed      : 80MHz
I (49) boot.esp32s2: SPI Mode       : DIO
I (53) boot.esp32s2: SPI Flash Size : 8MB
I (58) boot: Enabling RNG early entropy source...
I (64) boot: Partition Table:
I (67) boot: ## Label            Usage          Type ST Offset   Length
I (74) boot:  0 nvs              WiFi data        01 02 00013000 0003a000
I (82) boot:  1 otadata          OTA data         01 00 0004d000 00002000
I (89) boot:  2 phy_init         RF data          01 01 0004f000 00001000
I (97) boot:  3 esp_fw_a         OTA app          00 10 00050000 00230000
I (104) boot:  4 esp_fw_b         OTA app          00 11 00280000 00230000
I (112) boot:  5 tmp              OTA app          00 12 004b0000 00330000
I (119) boot:  6 reserved         unknown          40 80 007e0000 0001a000
W (127) efuse: Loading virtual efuse blocks from flash
EFUSE_BLKx:
0) 0x03800701 0x00068000 0xa9000000 0x0030000b 0x00000022 0x00000000 
1) 0xa10941f6 0x00007cdf 0x00000000 0x00000000 0x00000000 0x00000000 
2) 0x8be7868c 0x87fedc6c 0x03c512fa 0x9dce324d 0x0b09a810 0x0e0c120c 0x30c41610 0x0830c408 
3) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
4) 0x7fe4ee07 0x9ae7f179 0xabcdbf9f 0xb67aad19 0x3de5a387 0xa353c23c 0xd465c887 0xbb56f30f 
5) 0xc276335c 0x6c4091d1 0xeaf03728 0x6458862c 0x76fe6ed6 0xbb2ad4ca 0xa7da9a6d 0xd00fc640 
6) 0xf6bd3c54 0xcb048f43 0xcf44e8cf 0xde22463f 0x0e815b22 0x9ff5d4d6 0x5d48a000 0x7f85f817 
7) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
8) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
9) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
10) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 

I (219) boot:  7 emul_efuse       efuse            01 05 007fa000 00002000
I (227) boot:  8 bkp_blid         unknown          40 10 007fc000 00001000
I (234) boot:  9 bkp_cert         unknown          40 11 007fd000 00002000
I (242) boot: 10 bkp_key          unknown          40 12 007ff000 00001000
I (249) boot: End of partition table
I (254) boot: No factory image, trying OTA 0
I (259) esp_image: segment 0: paddr=00050020 vaddr=3f000020 size=24280h (148096) map
I (297) esp_image: segment 1: paddr=000742a8 vaddr=3ffc6ae0 size=044a0h ( 17568) load
I (301) esp_image: segment 2: paddr=00078750 vaddr=40024000 size=078c8h ( 30920) load
I (310) esp_image: segment 3: paddr=00080020 vaddr=40080020 size=a00fch (655612) map
I (442) esp_image: segment 4: paddr=00120124 vaddr=4002b8c8 size=0b214h ( 45588) load
I (453) esp_image: segment 5: paddr=0012b340 vaddr=50000000 size=00010h (    16) load
I (453) esp_image: segment 6: paddr=0012b358 vaddr=00000000 size=04c78h ( 19576) 
I (463) esp_image: Verifying image signature...
I (464) secure_boot_v2: Verifying with RSA-PSS...
I (471) secure_boot_v2: Signature verified successfully!
I (485) boot: Loaded app from partition at offset 0x50000
I (500) boot: Set actual ota_seq=1 in otadata[0]
I (500) secure_boot_v2: enabling secure boot v2...
I (500) secure_boot_v2: secure boot v2 is already enabled, continuing..
I (507) boot: Disabling RNG early entropy source...
I (524) cache: Instruction cache : size 8KB, 4Ways, cache line size 32Byte
I (524) cache: Data cache : size 8KB, 4Ways, cache line size 32Byte
I (529) spiram: Found 16MBit SPI RAM device
I (534) spiram: SPI RAM mode: sram 40m
I (538) spiram: PSRAM initialized, cache is in normal (1-core) mode.
I (545) cpu_start: Pro cpu up.
I (947) spiram: SPI SRAM ��f����� ?� test OK
I (957) cpu_start: Pro cpu start user code
I (957) cpu_start: cpu freq: 160000000
I (957) cpu_start: Application information:
I (960) cpu_start: Project name:     panko_esp32
I (965) cpu_start: App version:      1
I (970) cpu_start: Compile time:     Jan 19 2022 14:32:18
I (976) cpu_start: ELF file SHA256:  e273bf7d65520238...
I (982) cpu_start: ESP-IDF:          v4.4-beta1
I (987) heap_init: Initializing. RAM available for dynamic allocation:
I (994) heap_init: At 3FF9E000 len 00002000 (8 KiB): RTCRAM
I (1000) heap_init: At 3FFDE8C0 len 0001D740 (117 KiB): DRAM
I (1007) heap_init: At 3FFFC000 len 00003A10 (14 KiB): DRAM
I (1013) spiram: Adding pool of 1984K of external SPI memory to heap allocator
I (1021) spiram: Adding pool of 51296 Byte(spiram .bss page unused area) of external SPI memory to heap allocator
I (1033) spi_flash: detected chip: gd
I (1036) spi_flash: flash io: dio
W (1040) cpu_start: eFuse virtual mode is enabled. If Secure boot or Flash encryption is enabled then it does not provide any security. FOR TESTING ONLY!
W (1055) efuse: Loading virtual efuse blocks from flash
EFUSE_BLKx:
0) 0x03800701 0x00068000 0xa9000000 0x0030000b 0x00000022 0x00000000 
1) 0xa10941f6 0x00007cdf 0x00000000 0x00000000 0x00000000 0x00000000 
2) 0x8be7868c 0x87fedc6c 0x03c512fa 0x9dce324d 0x0b09a810 0x0e0c120c 0x30c41610 0x0830c408 
3) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
4) 0x7fe4ee07 0x9ae7f179 0xabcdbf9f 0xb67aad19 0x3de5a387 0xa353c23c 0xd465c887 0xbb56f30f 
5) 0xc276335c 0x6c4091d1 0xeaf03728 0x6458862c 0x76fe6ed6 0xbb2ad4ca 0xa7da9a6d 0xd00fc640 
6) 0xf6bd3c54 0xcb048f43 0xcf44e8cf 0xde22463f 0x0e815b22 0x9ff5d4d6 0x5d48a000 0x7f85f817 
7) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
8) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
9) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
10) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 

I (1151) cpu_start: Starting scI (1153) uart: queue free spaces: 1

Other items if possible

  • [Y] sdkconfig file (attach the sdkconfig file from your project folder)
    sdkconfig.txt
@espressif-bot espressif-bot added the Status: Opened Issue is new label Jan 19, 2022
@github-actions github-actions bot changed the title Secureboot - Failed to test the key revocation with virtual efuse Secureboot - Failed to test the key revocation with virtual efuse (IDFGH-6618) Jan 19, 2022
@KonstantinKondrashov
Copy link
Collaborator

Hi @Darsh-Dev !
The revocation and the eFuse virtual mode do not work together because in bootloader for this purpose we call ets_secure_boot_verify_signature() (it is a ROM function), which does not care about eFuse virt mode.

For now, it is not supported, we are thinking about whether it should be supported or not. It is because adding this support will affect the behavior (it will not be the same as without the eFuse virt mode).

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Jan 27, 2022
@mahavirj
Copy link
Member

@Darsh-Dev

As @KonstantinKondrashov mentioned, key revocation is not supported with virtual EFuse mode. Moreover, features that are closely tied with ROM code, can not be easily supported with virtual Efuse scheme which pretty much operates on security workflow starting with bootloader only. Hence, if you would like to try out key revocation then I would recommend using actual chip target for this.

Note: I would have also recommended https://github.com/espressif/qemu/wiki for testing this but we do not have support for ESP32-S2 or (ESP32-C3) in qemu yet. We will try to prioritize on that front which can help in testing security features without using actual target chips.

@espressif-bot espressif-bot added the Awaiting Response awaiting a response from the author label Feb 8, 2022
@Darsh-Dev
Copy link
Author

Darsh-Dev commented Feb 14, 2022 •
edited
Loading

@mahavirj Thanks for the update and clarification.

I was testing the key revocation with multiple keys, and I would like to test the revocation methods, that's the reason I'm exploring it. Before blowing the actual fuse, I want to test with multiple boards - multiple key features.

Thanks.

@mahavirj
Copy link
Member

@Darsh-Dev

Thank you for confirming and agree with requirement as you suggested.

We will increase the priority of ESP32-S2/ESP32-C3 support in Qemu, that shall allow for testing security features easily. Closing this issue and linking espressif/qemu#9

@espressif-bot espressif-bot added Resolution: Won't Do This will not be worked on Status: Done Issue is done internally and removed Status: In Progress Work is in progress labels Feb 23, 2022
@ic-twist
Copy link

ic-twist commented Mar 26, 2024 •
edited
Loading

@Darsh-Dev Any luck in testing the aggressive key revoking feature on a real efuse?
One thing I noticed from the doc is that for the key to be revoked, the invalid image needs to fail at Step 3 of the image verification process see doc here.

And the Step 3 is only reached if step 1 and step 2 passes see doc here.
I'm not sure how you're generating your "Signed firmware application with invalid private key" but if someone is flashing the device with a different RSA key than what's in the efuse, it would not trigger a key revocation since it would have failed step 1 of that verification procedure and never reaches step 3.

And as it turns out, creating an image that would trigger a key revocation requires jumping through a few hoops. One needs to do the following:

  1. locate the signature block in a valid signed image
  2. locate the signature part of the signature block
  3. change a byte in the signature
  4. recalculate the CRC32 of the signature block.

I did not give this a try... But hope this is correct and helpful for someone.
@mahavirj @KonstantinKondrashov Please correct me if I'm wrong about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mahavirj mahavirj

Labels
Awaiting Response awaiting a response from the author Resolution: Won't Do This will not be worked on Status: Done Issue is done internally
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mahavirj @KonstantinKondrashov @Darsh-Dev @espressif-bot @ic-twist