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.
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
Hello Trammell,
Thursday, May 11, 2017, 5:42:38 PM, you wrote:
TH> 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
It's a little simpler than that: the ME ROM has a hardcoded list of pubkey hashes and accepts ME manifests signed by any of them. I think (but haven't checked) that the keys change with each major ME version.
TH> If an attacker can sign an ME binary, they can provide invalid fuses to TH> the CPU microcode so that it won't check the ACM key (or provide their TH> own bootguard key so that the TPM locality will be set for the IBB TH> measurement).
I'm don't think this is possible. the OEM keys (or rather, their hashes) are set in the data area of ME and are copied to the PCH/MCH fuses on first boot. These fuses are one-time programmable so can't be overwritten (supposedly) even if you manage to get ME codeexec.
TH> If the attacker can sign the ACM, they can ignore the bootguard key on TH> the IBB and provide invalid measurements to the CRTM. TH> And if they can sign an IBB they can implement their own policy (but TH> not avoid TPM measurement of the IBB by the ACM).
This sounds correct (I did not look into BootGuard in much detail).
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.
TH> That might be possible, although ideally the startup ACM or IBB can TH> ensure that the ME region is included in its measurements and this would TH> cause key unsealing or remote attestation to fail. That's one of TH> the reasons that I recommend changing the flash descriptor to allow TH> the host CPU to read the ME region.
In fact I think this is exactly the reason why flashing cleaned ME fails on BootGuard-protected systems - they check ME's hash (which ME provides in the PCI register space) and fail when it changes. Though that makes me wonder how they handle ME firmware updates...
On Thu, May 11, 2017 at 10:08:12PM +0200, Igor Skochinsky wrote:
TH> 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
It's a little simpler than that: the ME ROM has a hardcoded list of pubkey hashes and accepts ME manifests signed by any of them. I think (but haven't checked) that the keys change with each major ME version.
That makes sense and would require far less die space.
TH> If an attacker can sign an ME binary, they can provide invalid fuses to TH> the CPU microcode so that it won't check the ACM key (or provide their TH> own bootguard key so that the TPM locality will be set for the IBB TH> measurement).
I'm don't think this is possible. the OEM keys (or rather, their hashes) are set in the data area of ME and are copied to the PCH/MCH fuses on first boot. These fuses are one-time programmable so can't be overwritten (supposedly) even if you manage to get ME codeexec.
You're right that the fuses are OTP, although my understanding (which is not supported by any documentation and very well may be wrong) is that the ME copies the bootguard profile and hashes to the x86 during the reset initialization and that the x86 can't read them directly. If this is the case, it would allow a ME binary to potentially copy their own set of fuses to the host with a different policy or different OEM hash.
If the x86 reset microcode reads the fuses directly, then this particular attack would not be feasible.
[...] In fact I think this is exactly the reason why flashing cleaned ME fails on BootGuard-protected systems - they check ME's hash (which ME provides in the PCI register space) and fail when it changes. Though that makes me wonder how they handle ME firmware updates...
This definitely requires further analysis.
-
Igor Skochinsky -
ron minnich -
Trammell Hudson