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.