<div dir="ltr">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? </div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 11, 2017 at 8:43 AM Trammell Hudson <<a href="mailto:hudson@trmm.net">hudson@trmm.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote:<br>
> [...] There are multiple keys<br>
><br>
> ME -  public/private key pair - Fused in by Intel and checked by Intel<br>
> silicon - Probably different across models<br>
><br>
> BIOS_ACM - public/private key pair - Fused in by Intel and checked by Intel<br>
> silicon.  May be common across all models.<br>
><br>
> Boot Guard public/private key pair - Fused by OEM (e.g., Dell, HP, Lenovo),<br>
> checked by BIOS_ACM.  Only checks Initial Boot Block (IBB) of legacy BIOS<br>
> region of flash.  IBB is responsible for extending policy from there.<br>
<br>
That is my best guess as well.  The key hierarchy is the ME, the ACM<br>
and then the bootguard key:<br>
<br>
If an attacker can sign an ME binary, they can provide invalid fuses to<br>
the CPU microcode so that it won't check the ACM key (or provide their<br>
own bootguard key so that the TPM locality will be set for the IBB<br>
measurement).<br>
<br>
If the attacker can sign the ACM, they can ignore the bootguard key on<br>
the IBB and provide invalid measurements to the CRTM.<br>
<br>
And if they can sign an IBB they can implement their own policy (but<br>
not avoid TPM measurement of the IBB by the ACM).<br>
<br>
> So, back to AMT bug.   I believe Boot Guard (by itself) doesn't help.  An<br>
> exploiter "may" be able to reflash only the ME region and enable AMT even<br>
> if the OEM has disabled AMT and implemented Boot Guard.   Not confirmed,<br>
> just a educated hunch.<br>
<br>
That might be possible, although ideally the startup ACM or IBB can<br>
ensure that the ME region is included in its measurements and this would<br>
cause key unsealing or remote attestation to fail.  That's one of<br>
the reasons that I recommend changing the flash descriptor to allow<br>
the host CPU to read the ME region.<br>
<br>
--<br>
Trammell<br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>