2

I've been reading many research articles about RoT - Root of Trust - for establishing a chained root of trust going up from BIOS to the Kernel. However, most of the article go briefly on how RoT works for different brands. A good article on RoT is RoT: The Foundation of Security by Lawrence Liu.

However, one of the biggest questions I have is the mechanism on how trust is established with the boot, os, and application i.e. how does the RoT ensure their authenticity.

For example, say I compromised the boot loader, how does the RoT mechanism detect it? Does it check the hash of the Boot loader's code, but what if there was a company update?

Please refer me to related articles.

Tsundoku
  • 127
  • 1
  • 5
Omar Jarkas
  • 21
  • 2

1 Answers1

2

Great question! The article you link, to me, uses a lot of words to say very little (ie I find that it is lacking specific detail). Instead I will base my answer on this page:

This article uses different terminology from the article you linked. I will use the Microsoft terminology. I believe that "Secure Boot" == "Root of Trust (RoT)", but I'm not 100% sure.

Disclaimer1: below is my understanding of this complex process, I am still a student in this area. Corrections are welcome.

Disclaimer2: I'm going to be a bit sloppy with my use of the word "firmware" and use it mean anything pre-operating system kernel in the boot sequence.

Secure Boot

Secure Boot is a small piece of firmware code. It is the first thing to boot up. It is provided with a local database of:

  • Signature public keys that are allowed to sign firmware for this device (ie approved software vendors), and
  • hashes of allowed firmware code (ie approved software binaries).

This may or may not be backed by a hardware TPM, if one is available on the given platform.

Protection and updates of the Secure Boot firmware itself

The Secure Boot code itself is not verified at runtime, however since it is the first code to run on system startup, the only way to update or modify it is to ask it to update itself, and it will check the code signature on any update package before updating its own code in firmware storage. So assuming you trust the original Secure Boot code shipped on your device, you can trust all updates to it.

Detection of compromised firmware

When firmware in the boot sequence tries to load another firmware module, it will first ask the Secure Boot module "Is this allowed to run?". The Secure Boot module will perform checks something like the following:

  • Is there a code signature on this binary?
    • If yes, is it produced by one of the signing public keys in the database?
      • If yes, is this binary valid under this signature?
        • If yes, succeed; binary is trusted
        • If no, fail; binary has been modified / tampered with.
      • If no, fail; binary is signed by an untrusted vendor.
    • If no, hash this binary and check if it is directly listed in the database?
      • If yes, succeed; binary is trusted.
      • If no, fail; binary is not trusted.

This means that Secure Boot will only allow other firmware to run if it was either produced by a trusted vendor, or is explicitly trusted in Secure Boot local database.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207