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.
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.
Me doing whatever I want with stuff I bought is the definition of ownership.
I'm starting to think that these sort of "CVE bro" posts are part of an intentional campaign by manufacturers trying to hold on to their rent seeking scheme. John Deere et al was definitely trying to use those arguments recently.
Secure Boot was already very broken on these boards. By default it does nothing and even if you change settings so that it actually does validation, it should be possible to reset it back from the OS by updating the firmware from the OS as there are no locks for the firmware region.
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?
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.
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.
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.
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.
