[coreboot] : AMT bug

Trammell Hudson hudson at trmm.net
Thu May 11 17:42:38 CEST 2017


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



More information about the coreboot mailing list