4 ms·

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..."

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...
- monoideism 6y ago
  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?
  - monoideism 6y ago
    Sorry, scratch that last question in the edit - it makes an incorrect assumption. I hadn't fully assimilated what you said.

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...

monoideism 6y ago
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?
- monoideism 6y ago
  Sorry, scratch that last question in the edit - it makes an incorrect assumption. I hadn't fully assimilated what you said.