Verify signauture of UEFI Firmware - UEFI Platform Vendor Key Feature

[developer244]

My question is regarding the UEFI firmware itself:

The root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads.

Secure Boot — NVIDIA Jetson Linux Developer Guide

Q1. So is the UEFI Firmware blob itself not verified/it isn’t signed? (I understand the payloads are signed/encrypted but the UEFI firmware/image itself isn’t) Assuming we ARE using Secure Boot (Fuses + UEFI Secure Boot)

I then see the feature “UEFI Platform Vendor Key Feature” that can “deploy UEFI that is signed and encrypted by PV-owned keys without involving the solution providers”.

Q2. Is this feature the only way to actually sign and encrypt the UEFI firmware itself?

Q3. I am not working with a 3rd party but would like MB2 to verify the UEFI firmware, is this the correct feature to use?

So I will end up with Secure Boot (fuses) → UEFI Platform Vendor Key (verifies signature of UEFI firmware) → UEFI Secure Boot (verifies signatures of payloads)

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

I’ll address each of your questions (Q1, Q2, and Q3) regarding the UEFI firmware and Secure Boot process on NVIDIA Jetson devices.

Q1: Is the UEFI Firmware blob itself not verified? It isn’t signed.

According to the provided context, the UEFI firmware itself is not directly verified by the solution provider’s fused PKC (Public Key Cryptography). Instead, the MB2 ( Bootloader) uses a built-in public key to verify the PV (Platform Vendor) authenticate key for key verification and signature authentication. This allows the platform vendor to independently sign and update the UEFI image without involving the solution provider.

However, when using the UEFI Platform Vendor Key feature, the UEFI firmware can be signed and encrypted by the platform vendor-owned keys. This implies that the UEFI firmware itself can be verified, but only through the platform vendor’s keys, not the solution provider’s fused PKC.

Q2: Is this feature (UEFI Platform Vendor Key) the only way to actually sign and encrypt the UEFI firmware itself?

Based on the provided context, the UEFI Platform Vendor Key feature is the only mentioned way to sign and encrypt the UEFI firmware itself. This feature allows the platform vendor to deploy UEFI firmware that is signed and encrypted by their own keys, without involving the solution provider.

Q3: I am not working with a 3rd party, but would like MB2 to verify the UEFI firmware. Is this the correct feature to use?

If you want MB2 to verify the UEFI firmware, the UEFI Platform Vendor Key feature is the correct feature to use. This feature allows the platform vendor (in this case, you) to sign and encrypt the UEFI firmware, which can then be verified by MB2 using the platform vendor-owned keys.

To summarize:

• Secure Boot Fuses: verify the signature of components before UEFI using the solution provider’s fused PKC.
• UEFI Platform Vendor Key: sign and encrypt the UEFI firmware using platform vendor-owned keys, which can be verified by MB2.
• UEFI Secure Boot: verify the signatures of payloads.

By using the UEFI Platform Vendor Key feature, you can ensure that the UEFI firmware is signed and encrypted, and its signature can be verified by MB2.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[JerryChang]

hello developer244,

as mentioned by Topic 342393, post #5, here’re bootloader SecureBoot and UEFI SecureBoot.
t​he root-of-trust uses the fuses to authenticate boot codes for bootloader secureboot, and it ends at the UEFI.
after this, the UEFI secureboot will use UEFI’s security keys scheme to authenticate its payloads.

the UEFI image’s authentication and encryption can be protected by fused key PKC and SBK, and the variable authentication key (i.e. auth_t234.key) is in the EKS which is also protected by the PKC/SBK/OEM_K2.

according to developer guide, UEFI Secure Boot.
--uefi-keys option to provide signing keys.
--uefi-enc options to enable UEFI payload encryption.
UEFI Payload Encryption it uses the key (sym_t234.key) that stored in EKB (encrypted key blob), which is flash onto the EKS (encrypted key store) partition.

besides, UEFI Variable Protection feature is always enabled,
you should provide UEFI variable authentication key (auth_t234.key) in EKS image as well, otherwise UEFI will block the booting.

[JerryChang]

hello developer244,

>> Q1
To support PV key derivation, we also need an OEM key, it’s the OEM_K2 used for PV key derivation, the purpose is KDK.
OEM_K2 is used as the root key to derive an encryption key to encrypt CPUBL with PV key.
When system boots, MB2 derives from OEM_K2 to get the PV key and decrypt CPUBL accordingly.
PscOdmStatic will affect the function of PV Key Encrypt/Decrypt UEFI.
see-also Jetson Orin Fuse Specification.

>> Q2
it’s solution provider fused PKC/SBK..etc onto the module.
UEFI platform vendor to use PV without involving the solution providers.
just clarify, PV it’s another new key instead of the same PKC key from solution provider.

[JerryChang]

hello developer244,

UEFI image (uefi_jetson.bin) it’s writing to A_cpu-bootloader partition on QSPI,
as you can see per flashing message..

[ 284.2142 ] Writing partition A_cpu-bootloader with uefi_jetson_with_dtb_aligned_blob_w_bin_sigheader.bin.encrypt [ 3318352 bytes ]

assume you’ve fused a target, this binary file will be signed by PKC key, and then encrypted by SBK key for flashing to A_cpu-bootloader partition.

[JerryChang]

hello developer244,

The UEFI image flashed to partition is the combination of UEFI binary and appended DTBs (payload).
PV is the abbreviation of Platform Vendor, the UEFI PV key feature allows PVs to deploy UEFI that is signed and encrypted by PV-owned keys without involving the solution providers.

Please refer to developer guide for more details,

Secure Boot — NVIDIA Jetson Linux Developer Guide

please refer to below Q&As per your post #15 questions.
>> Q1
If PV keys are not provided, the UEFI image will be encrypted and signed using the fuse key (SBK/PKC).
If PV keys are provided, the PV keys (pv-crt/pv-enc) will be used for signing and encryption.

>> Q2
UEFI firmware is already signed, please refer to Q1 for the difference.

>> Q3
It is recommended to use OEM_K2 as the fuse key for PV-ENC key. Because now, MB2 can decrypt PV encrypted UEFI using OEM_K2 through the security engine without knowing the actual key.

[JerryChang]

hello developer244,

it looks okay,
besides.. please note that per developer guide, Burn Fuses with the Fuse Configuration file.

NVIDIA recommends burning all the fuses you need in a single operation.

it looks you’ve another thread to enable the security features
let’s using Topic 345054 for following up.