What I don’t understand is, how did that not completely nullify the security promises of SecureBoot, rendering the whole exercise pointless in the end ?
> Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
Because each stage of the boot sequence is still verified:
- the root of trust is in the TPM
- by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel
Grub also has its own trust store it can use, if I recall.
The root of trust is not in the TPM, it's in the system firmware. On Intel, the firmware itself is verified by the Management Engine. Measurements of these roots of trust may be passed to the TPM, but the TPM isn't in a position to do much with that information other than report it back at a later point in time - otherwise firmware updates would invalidate your root of trust.
OK, I probably should have just left this as a "cryptographic co-processor" rather than TPM (or else used "a TPM"). But I believe there is some blurring here:
- My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT, which is essentially a software-implemented TPM with some extra features (so right, "system firmware"). It's true that PTT is part of the ME. But it's still a firmware-based TPM.
- With AMD, they use a cryptographic coprocessor whose name I forget but which is similar to PTT and which contains either a hardware or firmware-based TPM.
- With ARM, I'm pretty sure they use TrustZone, which is analogous to a TPM.
> My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT
No. The public keys used for verifying secure boot payloads are in the system firmware and are validated on the CPU. If you have a feature like Boot Guard enabled then the Management Engine will verify the firmware bootblock with a key that's flashed into the chipset, but that's not required by the UEFI spec and has nothing to do with PTT. Under no circumstances is the TPM used. On ARM the initial firmware validation will be carried out by the SoC, but there's no TrustZone involved.
Well, that's how Intel describes for 4th gen, and I had assumed more recent gens: "Intel Platform Protection Technology with Bootguard works with Intel PTT..." on page 8. They mention both Windows and boot protection. How does it work with Bootguard? Does that mean bootguard bootstraps PTT trust?
If you have more recent documentation, I'd be interested. It's hard to learn about this semi-internal Intel and AMD stuff.
Edit: Also, you write "with a key that's flashed into the chipset". Do you mean chipset (which could be on the motherboard) or on the CPU itself? Where do you find this information?
Bootguard isn't UEFI Secure Boot, and it works with Intel PTT in that the bootguard data is measured into the TPM. The signing keys used for Bootguard aren't in the TPM. Bootguard only protects system firmware, it does nothing to protect the ME firmware (which is where PTT lives). The flow is:
1) You apply power. The ME is powered up and reads its firmware out of flash. Most components of this firmware have signatures verified[1] and the ME then boots
2) The ME examines the state of the fuses in flash in order to determine whether to impose a Bootguard policy. If so, it verifies the signature of the firmware bootblock against a key fingerprint that's been blown into the chipset fuses. Depending on policy, a failed validation will either block the system from booting, allow the system to boot but cut power after 30 minutes (in order to allow remediation to occur) or do nothing. If the policy specifies that measurements should be performed, a measurement will be generated and pushed to the TPM (PTT, if you're using it)
3) The system firmware bootblock (running on the system CPU) will perform validation of the rest of the firmware, generating additional TPM measurements. The TPM is a passive component here - no key material is stored in the TPM, and the TPM cannot prevent boot proceeding if the signatures don't match. It's up to the firmware code itself to do that.
4) Once the firmware is up and running, it'll end up loading a bootloader. If UEFI Secure Boot is enabled, the signature on the bootloader will be verified against a set of permitted certificates stored in a UEFI variable in flash. The bootloader will be measured into PCR 4 and the certificate used will be measured into PCR 7, but again the TPM doesn't hold any key material and isn't able to block the system from booting.
5) If you're booting Windows and Bitlocker is enabled, the OS will ask the TPM to hand over the disk encryption key. The TPM will only do so if the PCR values match the policy associated with the key (usually just the value of PCR 7). This is the first time the TPM can do anything that would stop the system from booting, and also the first time we're using any key material that's in the TPM. But at this point, we're well past UEFI Secure Boot.
> Do you mean chipset (which could be on the motherboard)
Yes, otherwise you wouldn't be able to move CPUs between boards that have firmware signed by different vendors. The exception is the U and Y series mobile parts, where the chipset is on-package with the CPU. But those are only available as SMT parts, so it's less of an issue.
Very cool, that's you then that figured that out, presumably (along with your friend/colleague)? I was initially skeptical of your correction, because 99.9% of programmers have no idea how this stuff works (and I clearly don't either, in detail). But clearly you've got bona fides here.
So thank you for taking the time to explain this all to me. I've never been able to find out much published on this online by Intel.I assume you had to figure most of this out on your own through reverse engineering techniques?
Do you have any other good links on how trust is bootstrapped in modern Intel CPUs, other than your Blackhat presentation (which is very helpful, already 1/2 through)?
Have people/you figured out as much about trust is bootstrapped in AMD CPUs? I'm reading that the ME equivalent is an embedded ARM core using TrustZone? Is that right?
Thank you, again.
Edit: Knowing all that you know about what comes before TPM, and the associated vulnerabilities, do you still think hardware TPM modules are worth it for securing the OS boot process?
