4 ms·

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 Microsof

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.

mjg59 6y ago
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.
- monoideism 6y ago
  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. But yes, I should have been clearer.
  - mjg59 6y ago
    > 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.
    - monoideism 6y ago
      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? Have a look: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/security-technologies-4th-gen-core-retail-paper.pdf https://www.intel.com/content/dam/www/public/us/en/documents... 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?
      - mjg59 6y ago
        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. [1] The ME stores and parses some data files, which aren't verified. This resulted in https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy...

mjg59 6y ago

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.

monoideism 6y ago
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. But yes, I should have been clearer.
- mjg59 6y ago
  > 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.
  - monoideism 6y ago
    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? Have a look: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/security-technologies-4th-gen-core-retail-paper.pdf https://www.intel.com/content/dam/www/public/us/en/documents... 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?
    - mjg59 6y ago
      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. [1] The ME stores and parses some data files, which aren't verified. This resulted in https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy...