3

My understanding is that secure boot works by verifying each stage in the boot process before proceeding. So first, UEFI or booting firmware will validate the signature of the bootloader, then kernel, applications etc. before loading.

When an OTA update occurs, I assume that the signature for the kernel and applications will change? How does the booting firmware then know how to validate the new kernel and applications on the next startup, as the signatures will have changed?

Now this brings me to the case when using a TPM for encryption and verification. Shouldn't the firmware be signed and encrypted by using a key which is specific for the individual machine which is stored in the TPM? After an OTA update, again how would the modified software boot for the first time when the new signatures are not known yet? Thanks in advance.

Engineer999
  • 257
  • 1
  • 8

1 Answers1

3

You are mixing secure boot with trusted boot. Secure boot can be achieved without trusted boot. Initially, secure boot verifies the digital signature of firmware and then passes the control to trusted boot. Now trusted boot verifies the hashes stored in PCR and pass the control further for, e.g., releasing the encryption key.

In the case of software update that includes updates in firmware/bootloader etc., PCR hashes needs to be updated during the updating procedure for the trusted boot to work and further actions like new encryption key generation etc.

So, it is not required to sign the updates with TPM key since TPM does not verify the digital signature that is a work of secure boot process. TPM provides trust in boot process. CRTM and TPM works together to provide measured boot, i.e., Secure boot + Trusted boot + attestation.

Now, regarding the certificates. Generally, certificates are stored in CMOS memory (NVRAM) and the following components works together to process secure boot.

  1. Platform key (PK)
  2. Key Exchange key (KEK)
  3. Allow DB (List of allowed certificates, keys or hashes)
  4. Disallow DB (List of disallowed certificates, keys or hashes)
  5. Secure Boot firmware update key (used to sign the firmware when it needs to be updated)

NOTE: In some cases, manufactures can store the data related to secure boot in TPM NVRAM as well for temper resistance. But most of the manufacturer don't do that because secure boot can be achieved without TPM as well.

Refer to below link for better explanation Windows Secure Boot Key Creation and Management Guidance

saurabh
  • 743
  • 1
  • 4
  • 12
  • Thanks for your reply. Indeed I am mixing up secure boot and trusted boot. Ok, so secure boot only deals with validating the signature of the firmware to know that it is actually from who we expect it is from. With regards to trusted boot, the boot up code should compare hashes of the bootloader and applications etc. So therefore , during the update process, the updater application must overwrite the hashes currently in the TPM? – Engineer999 Mar 14 '22 at 14:36
  • Secure boot can verify Digital Signature and Hashes as well. If the software/application hashes are stored in TPM PCR then yes during update process PCR hashes needs to be updated, or we can say extend. TPM PCR hashes cannot be overwritten, it can only be extended. – saurabh Mar 14 '22 at 14:44
  • Thank you for clearing this up:) – Engineer999 Mar 14 '22 at 15:09