MSI firmware signing keys leaked
github.comIs it wrong that my immediate reaction to this is, "Sweet, so I can finally do things with my board I was prevented from before!"
Not at all, in this case.
There is a giant pile of hardware in the world that relies on unsigned hardware. Meanwhile, MSI uses its hardware signing to hurt its customers.
Will some MSI users get tricked into using malicious firmware? Doubtless, eventually. That's sad. But not nearly as sad as the millions of users who can't use their own computers in a manner of their choosing.
Celebrate, without remorse.
I get that argument, but I'm not sure you have the relative population sizes right. It seems a bit doubtful that millions of MSI users are interested in flashing custom firmware on their motherboards, but every user is potentially impacted by signed malware. Particularly since the firmware signing is a known thing and there's less restricted hardware available. People really interested in being able to do whatever they want with their hardware are presumably purchasing accordingly.
Like I said, I get the support for increased openness and freedom in hardware and the appeal that has to some users. But security is a feature that a lot of users (even power users) care about too, and it's bad when that feature breaks.
Not to mention the split brain of US/TW/CN support sides for computer hardware and actually finding the correct firmware/bios images to begin with, which would make it all that much more easy for third parties to get fake sites up/out.
Asus seems to have had several design issues, qc flaws and other support issues lately. MSI have had data breaches, and even then bully reviewers to the point you really can't trust a lot of their product reviews or them. Gigabyte treats their Linux using customers like hot garbage, and then there's the exploding PSU coverup/downplay. I'm not sure how many options that's leaving on the table at this point. I know there's ASRock for MBs and haven't seen anything bad about them lately.
It was mine as well.
They artificially limited both discrete and on board GPU being active at the same time in my GT72's BIOS.
Does this mean that we can now custom firmwares (e.g. coreboot) on those MSI boards?
It was already possible.
It's really fucked up that we can't disable secure boot on boards we've bought, and we have to hope their security is compromised instead. What would be the issue with requiring a very manual process to add my own CA to the board so I can load up whatever I want?
Ah, vendor lockin, got it.
Well you're in luck then because MSI will just ignore SecureBoot for you.
I'm interested as well in finding out about being able to flash custom firmware. Is there any other resources to follow?
I would love to learn more about that.
How would someone use those keys? What's beneficial, what could be useful possible cases for me? And Are my workstations in my company at risk?
If I recall correctly, at boot time CPUs retrieve the firmware along with a cryptographic signature that verifies the firmware came from the signer. Some boards choose to burn this signature into the hardware using e-fuses. If the signing key is leaked, that means someone can flash custom firmware into the chip and the CPU would be none the wiser, all while operating at Ring 0.
CPU firmware (microcode) is signed by Intel, so it would not be affected by this leak, only motherboard firmware.
Lenovo vendor locking Ryzen CPUs with AMD PSB https://news.ycombinator.com/item?id=29958247
Why were these keys not in a HSM I wonder..
It's possible they did, in any case keys can be exported from HSMs to ensure availability in the event that your HSM becomes inoperable and needs to be replaced.
For example here are instructions on how to do so with a Thales HSM https://thalesdocs.com/gphsm/ptk/5.4/docs/Content/PTK-C_Admi...
Whoa. Never would I have thought that a HSM allowed key exports.
I somehow assumed that real, non-toy HSMs involved dedicated generators as companion devices with heavily reduced attack surface, which generate and store private key material, are able to transfer it to the HSM proper (and to a paper backup), and are strictly kept offline after that.
Sometimes the world feels disappointing.
HSMs allows to have key stored with the option to disable key export. This means every cryptographic operation must be done by the HSM (commonly through pkcs 11 API).
HSMs have backup features and the data cannot be restored without a secret split among multiple secret holders (like https://en.m.wikipedia.org/wiki/Shamir%27s_secret_sharing). So a backup can be done on physical media and put in a safe.
It's a lot of things about key management, HSMs, pkcs interfaces to learn though.
What is possible with a HSM depends on the policies of the HSM and key objects (e.g. with PKCS#11). Vendors limit the "most open" policy that you can apply. For example, a FIPS 140-2 level 3 module can not offer unbounded key export (https://security.stackexchange.com/a/83981).
Using a HSM does _not_ guarantee that keys can not be exported. But the converse also holds, a key that is managed by a HSM can not necessarily be exported.
Yeah but if you invest in a HSM you're not going to leave the export passwords lying around of course. We have these Thales units too at work and there's a whole ritual around it. It's extremely unlikely that would happen.
Unfortunately this leak seems to be for Intel-based boards only, not the AMD ones :(
Intel BootGuard Keys? that sounds intriguing