Following the saga of the MSI breach by Money Message. Intel’s KeyManifest for OEM’s has been leaked[0]. Unclear which other OEM’s have been affected as both Intel and MSI have up to this point have been mute. Lenovo, Supermicro, and Intel themselves are on the distribution list. Are any framework products affected by this?
[0] https://github.com/binarly-io/SupplyChainAttacks/blob/main/MSI/ImpactedDevices.md
What do you mean by “affected”?
Yes these are probably the keys used to sign the BIOS, but if your question is “is there a plausible security risk” then the answer is no.
Unless you download a BIOS “update” from a shady website that is not Framework and flash it to your machine without knowing what you are doing.
I’d say to the contrary, this leak opens the door to more possibilities for experimented users who want to bake their own firmware.
(disclamer: I’m not working for Framework nor Intel, and I could very well be talking nonsense)
@ Coreboot devs: you have a way in, I expect to see a lot of bricked ECs very soon from people flashing their own firmware signed by IBG keys…
@Be_Far I’m not sure it’s the same part of the firmware.
If it is, great, but I suspect that what is blocking Coreboot development is not the same thing as the part that this leak offers us access to.
All it takes is someone with EC knowledge to poke around to verify. The private keys are in that link, and the public key is hardcoded into the mainboard. If there’s a match, people will be able to sign their own firmware and make the board think it’s from Intel.
@Be_Far But isn’t there a register fused to lock the boot?
Isn’t it the reason why nrp had to provide unfused boards?
In this case I don’t see how the leak can help Coreboot dev.
I believe the fuse is for it to only accept IBG-signed firmware. Recently in the thread (now closed, sadly), NRP was looking to provide unfused boards for development of a ‘shim.’ A shim would be a small program that can be later signed by IBG keys and run on fused boards, which would use its trusted state to load an unsigned program like coreboot firmware. This skips that step entirely if a developer has OEM keys.
See also y-combinator comments
@Be_Far OK but you still need an unfused board to begin with, right?
Because even if today you develop such a shim, its signature (with the leaked IBG keys) will be different from anything existing, and it would need to be written in the board before it is fused.
So to me it looks like we haven’t advanced an inch about that problem…
Not quite. A fused board will only run firmware signed by IBG. The leaked keys allow you to make a program look like it was signed by IBG. Therefore, if the leaked keys are compatible with the mainboard, you can run anything you want even with the fuse as long as you sign it.
This isn’t exactly how signing works. For IBG, signing is about authentication: the board wants to know “Intel has said it’s okay to run this.” Basically, a hash of the binary is created (unsure what alg it uses), and that hash is encrypted with a private key. If the only people with that private key are trusted by intel, then anything that’s ever encrypted with that key is also trusted by intel. If a matching public key is on the mainboard, and that public key is able to decrypt the encrypted signature and have the result be the hash of the accompanying binary, then the board knows that the binary came from a trusted Intel source (who else would be able to encrypt the hash?).
If the keys don’t match, the result of decryption will be garbage, and the board knows Intel didn’t sign it since the result of the decryption and the hash of the binary don’t match.
If the binary doesn’t match the signature even if the signature was encrypted by Intel, the board knows Intel didn’t sign it since the result of the decryption and the hash of the binary don’t match.
The only way to defeat this sort of scheme cryptographically would be to create something with a colliding hash to an existing signature, which you pointed out. However, if the key works, then that’s moot.
I thought that it only allowed to run a specific firwmare signed by IBG?
I.e. I thought that the fused part was the signed hash of the firmware, instead of just the IBG key. So, am I wrong?
Yeah I know what signing is, sorry what I meant is “hash” (encrypted with the signature key) not “signature”. Except that unfortunate typo, I’m aware of all the basics of asymmetric and symmetric cryptography.
A signed message is not always encrypted. It can also be just the message with, appended to it, the result of its hash encrypted by the signature key.
Does Bootguard works by having the boot firmware encrypted?
…
Ok I’m reading that and I understand better:
https://binarly.io/posts/Leaked_Intel_Boot_Guard_keys_What_happened_How_does_it_affect_the_software_supply_chain/index.html
So, what was leaked was the KM private RSA key and the BPM private RSA key, for 4 lines of products (among which we don’t know yet if Framework is [2]).
To clarify what I tried to understand in the previous posts, Bootguard does indeed store the signed hash of the IBB in the BPM (so to modify the IBB one would have to modify the BPM), and the signed hash of the BPM in the KEYM (modifying the BPM involves modifying the KEYM), but fortunately only the hash of the KM RSA public key is stored in a fused CPU register (it’s not clear from the diagram, but it is what is implied in the text of the article [1]).
So, when the KM RSA private key is leaked, this system would allow us to just re-write the KEYM contents (keeping its RSA public key), the BPM completely, and the IBB completely (and thus the BIOS).
I’m just realizing that a skilled individual could unsolder a CPU from one of the compromised product lines and resolder it into a Framework mainboard, in order to have an “jailbreaked” dev board (e.g. for Coreboot development).
Or if it’s a company, they could ask their production line to exceptionally use the compromised key hash to write in the CPU register before fusing it, to create a small number of dev boards (although I’m not sure how legal that would be).
[1] and maybe they are wrong, so that needs confirmation nah, the article gives good details about how they found it out, so that’s pretty sure.
[2] and from the new understanding that the article provided to me, I can say that Framework laptops are probably not concerned by this leak, but as I said one could swap CPUs with a MSI laptop, or even use the leaked keys upstream in the production line to create Bootguard-free boards.
(@Be_Far I think I’ve mostly figured it out, please check out my post)
Holy cow, thank you for doing so much research on this! Yeah, if KM-BPM private key pairs are machine specific then nothing happens on Framework’s end.
Appreciate the feedback. Passing this thread along to the appropriate team.
Framework has generated our own boot-guard keys. And we generate new keys for new platforms.
The title of this is a little sensationalized based on my reading of the research, as these are not Intel keys. But are OEM keys for Intel platforms.
The intel bootguard process has a number of different keys. And verification of different firmware during the boot process.
There is a vendor key for the bootguard key which is fused onto the CPU at manufacturing time. This is used to verify the OEM key manifest.
The second stage is the oem key manifest holds hashes of various firmware regions. This is used to verify the firmware components of the bios region, dsp, etc.
Generating the OEM key manifest using the bootguard keys, and hashes of the other keys is something that you should do offline, and never needs to be done again unless you need to update the key for another bios region in the oem key manifest.
In Frameworks case, we generated our own bootguard key for the key manifest, as well as keys for the other bios regions.
Furthermore we rotate keys for each generation of CPU where we do not think we can share a BIOS to minimize the impact of a leak.
So 11th gen has a set of keys.
12-13 gen have a new set of keys.
At Framework we also store the bootguard keys to sign the key manifest in a offline HSM.
bios region signing keys stored are stored on a HSM, or signing bios regions as part of CI using github secrets.
The process is designed so that if any of the keys used to sign regions such as bios were compromised, we could generate a new key manifest with the bootguard key to roll the keys for the other regions.
@Kieran_Levin Thanks for the details!
According to the article I read (linked in my previous post), the KM private key (or private component of the public “vendor key” in your terminology) for MSI has been leaked, which could allow anybody to forge OEM key manifests at will.
So, the KM private key used in Framework CPUs is safe and is not included in the leaked material!
(i.e. you generated it from scratch and it is stored offline)
@Mapleleaf based on my understanding, they would only be able to create new key manifests for CPUs that were fused with the same KM public key.
Yes the KM private key we use is only used by Framework.
And this is one we generated ourselves, and is stored offline.
Shout out to Binarly. They do great security research.
Update: Compromised Microsoft Key: More Impactful Than We Thought | Wiz Blog
TLDR: Your framework is probably still safe, your Microsoft account…
