UEFI Secure Boot and the TPM
KentYoder 270001NFM8 Comment (1) Visits (9261)
blog posts outlining how it works and Matthew Garrett also has many excellent posts on the logistics of implementing secure boot.
One issue that continues to pop up though is how UEFI secure boot relates to TPM support.
To be clear, UEFI secure boot doesn't have anything to do with a TPM. Secure boot is simply an architecture for loading and verifying signed firmware images, bootloaders, kernels and modules.
The TPM does relate to UEFI secure boot in one important way - they can both be used to create a root of trust.
UEFI secure boot works like this: as the boot process executes, each piece of code verifies that the signature on the next piece of code is valid and if so, passes execution on to it. The process of verifying the signature involves creating a cryptographic digest of the code, then testing that against a cryptographic signature included with it.
The TPM method of creating a root of trust is different than UEFI secure boot. As code executes, it too creates a cryptographic digest of the next piece of code but instead of verifying it, it sends it to the TPM, where its appended to a chain. At any point in the boot process, the TPM holds the current state of this chain, and using a TPM command, you can then sign the current state with a key. The process using a TPM is commonly referred to as "Trusted" boot, as opposed to UEFI "Secure" boot.
There are some important differences between the two methods:
1. UEFI secure boot requires a key database to be accessible during the boot process. Since secure boot must verify signatures during the boot process, it needs access to a key database at the time of boot. No key database is required to use the TPM for boot measurements.
2. If a signature verify fails during a UEFI secure boot, the boot process stops. This is because secure boot's signature checking process includes the act of both measuring the code and verifying that the digest is signed by a key you trust. The TPM on the other hand only measures the code and stores its digest in the TPM during the boot process. The verification step is left for a later time.
And some possibly less important differences:
1. A TPM's measurements are much more fine grained than those being made by a secure boot system. This can be a positive or negative - a more fine grained chain of trust means better understanding what piece of software in the chain of trust isn't in the right state. The downside is maintaining that state can be a huge burden.
2. The need to be able to boot *something* out of the box means that a UEFI secure boot system will have to ship from the factory with some keys you may or may not trust. I put this in the less important category because you likely trust your platform vendor already - on the flip side you may not trust Microsoft, who will have a key included on all UEFI systems with the Windows 8 logo. Responsible setup of a UEFI secure boot system should include the step of auditing the keys in your key database and removing those you don't trust.
I'll go into more detail on secure boot versus trusted boot in later blog posts.