This is sounding like a very good talk for the denver or dusseldorf coreboot conferences, would one of you who really understands this well be up for it?
On Thu, May 11, 2017 at 8:43 AM Trammell Hudson hudson@trmm.net wrote:
On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote:
[...] There are multiple keys
ME - public/private key pair - Fused in by Intel and checked by Intel silicon - Probably different across models
BIOS_ACM - public/private key pair - Fused in by Intel and checked by
Intel
silicon. May be common across all models.
Boot Guard public/private key pair - Fused by OEM (e.g., Dell, HP,
Lenovo),
checked by BIOS_ACM. Only checks Initial Boot Block (IBB) of legacy BIOS region of flash. IBB is responsible for extending policy from there.
That is my best guess as well. The key hierarchy is the ME, the ACM and then the bootguard key:
If an attacker can sign an ME binary, they can provide invalid fuses to the CPU microcode so that it won't check the ACM key (or provide their own bootguard key so that the TPM locality will be set for the IBB measurement).
If the attacker can sign the ACM, they can ignore the bootguard key on the IBB and provide invalid measurements to the CRTM.
And if they can sign an IBB they can implement their own policy (but not avoid TPM measurement of the IBB by the ACM).
So, back to AMT bug. I believe Boot Guard (by itself) doesn't help. An exploiter "may" be able to reflash only the ME region and enable AMT even if the OEM has disabled AMT and implemented Boot Guard. Not confirmed, just a educated hunch.
That might be possible, although ideally the startup ACM or IBB can ensure that the ME region is included in its measurements and this would cause key unsealing or remote attestation to fail. That's one of the reasons that I recommend changing the flash descriptor to allow the host CPU to read the ME region.
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot