Micro-Star International Signing Key Stolen

Micro-Star International—aka MSI—had its UEFI signing key stolen last month.

This raises the possibility that the leaked key could push out updates that would infect a computer’s most nether regions without triggering a warning. To make matters worse, Matrosov said, MSI doesn’t have an automated patching process the way Dell, HP, and many larger hardware makers do. Consequently, MSI doesn’t provide the same kind of key revocation capabilities.

Delivering a signed payload isn’t as easy as all that. “Gaining the kind of control required to compromise a software build system is generally a non-trivial event that requires a great deal of skill and possibly some luck.” But it just got a whole lot easier.

Posted on May 15, 2023 at 7:18 AM24 Comments


Tom May 15, 2023 8:03 AM

How hard it is depends on how much you care who and how many you infect. This makes a whole pile of fake support scams a lot easier to pull off.

Edward May 15, 2023 8:21 AM

There’s been a number of these stories in recent months, and it’s becoming a worrying trend. If hackers continue to get their hands on these signing keys, it severely undermines the security of our technology and the internet.

Would it be possible to implement such signing keys in hardware rather than software? Like a Yubi key or similar, but for generating digitally signed certificates. Maybe even require a number of physical keys to come together to generate a signed certificate. As an example, there are 10 physical devices in total, held by 10 different people, and any 5 of these 10 physical devices can come together to generate a new digitally signed certificate.

Marcus May 15, 2023 8:47 AM

“a computer’s most nether regions”
Huh? I did not know computers had nether regions.

“MSI doesn’t have an automated patching process”
Yes. But MSI also has no way of automatically pushing updates. So the only way this could work is if you go out of your way to download a compromised update.

Somebody with the ability to make a compromised update would have to also compromise the web server that hosts the downloadable firmware updates.

Or maybe there’s a way that a Trojan can update the firmware without your knowledge.

Clive Robinson May 15, 2023 8:47 AM

@ Edward,

“Would it be possible to implement such signing keys in hardware rather than software?”

The original idea behind code signing was,

“To cut distribution costs out of the system.”

Distributing hardware is a nightmare for most organisations and a small mistake can turn a small profit into a very very large loss. Because such systems are in effect “one way optimized”.

Have a think along the lines of 3USD or more to get a CD out -v- the cost of a moderate sized server farm users download from. Shipping discs can nolonger compete…

I can not see us going back to the days of,

“Get it right first time every time”

For software even in the “Embedded Systems” market place only in the simple “white goods” type systems for fridges, freezers, washing machines and similar. But Home entertainment has crossed the line to,

“You must have Internet”

Often enforced by function failure, because they want to get all that PII to try and get a back-door income by surveillance on a house hold…

Remember anything above very basic functionality will be used to gather data on you, oh and to force you to upgrade after a year or three…

I’ve an old TV I still watch DVD’s on that I’ve had for over thirty years. I know that when I have to get a replacment I’m going to get trouble…

Try walking into a retail outlet and buying a TV without Internet… It can prove a bit of an eye opener.

John Tillotson May 15, 2023 10:09 AM


Greybeards like me remember when the private key was kept on a disk or other storage locked in a safe when not is use: and ONLY turned on when a legitimate request to sign something was received. When it IS turned on, it’s air-gapped. Ransomware can’t hit a system that’s turned off.

Right now there’s a Raspberry Pi sitting on my desk that is a CA. It is kept turned off at all times when I don’t need to sign a cert. The only reason it’s not in a safe is because I’m behind multiple physical security barriers.

scot May 15, 2023 10:46 AM

Certificate authority private keys should be kept in a hardware security module. Data to be signed is sent in, and certificates come out, but the private keys are generated within the HSM, and never allowed out (save as multi-part, encrypted backups, stored in separate safes at separate locations, with no single person allowed access to more than one part).

iAPX May 15, 2023 1:08 PM

@Scot, ALL

Do you know how you are allowed establish a secondary HSM as a backup?
It’s because they are sharing the same keys, including private keys as the secondary could also transfer the generated keys the same way as the first one.

It’s what we witness: adding levels of trustiness over non-trustable key owners.
It is exactly what happened to MSI, keys have been leaked and thus every level of MSI motherboard security could no more be trusted.

Air-gapping is part of the solution, but as Iranian witnessed, it’s not fool proof!

Phillip May 15, 2023 2:06 PM

Hmm, I imagine some technologist will be ousted. It would be worth knowing the backstory, also.

Jonathan R May 15, 2023 3:03 PM

Keys must be kept in hardware, either a secure token or smart card or an HSM.

Anonymous May 15, 2023 3:12 PM

P.S. And the signing must be performed within the hardware, and the hardware must be properly certified, e.g. FIPS 140-2 Level 3.

iAPX May 15, 2023 3:36 PM

@Jonathan R

“Hardware” ?!?
What does that means in 2023?!?
Even if private keys are in the silicium itself, they have been transmitted and they are stored somewhere, or the keys needed to generate them.

It is just onion rings.
At the heart you still have to manage keys, store them, and transmit them!

Anonymous May 15, 2023 4:14 PM

Hrm… I guess it depends on what you mean by UEFI secure. Since, regular GNU/Linux systems already have to bypass that to allow install onto a UEFI system, so that effectively allows one to get in via a signed UEFI (trusted) system that then bootstraps something else entirely.

A regular search online will show the various systems that can do this, but, the trick is that they ALL undo the security. So, not sure what this MSI problem really means in reality, is it bigger than the regular other wider abuses of the system that allow a trusted system to be bootstrapped into something not necessarily trusted by the installer/UEFI system?

Jonathan R May 15, 2023 5:40 PM

@iAPX: The key should be generated within the hardware, such that it does not allow it to be exported. The key is thus not transported not is it stored elsewhere. Of course, a proper HSM is preferable but it might be too expensive. It depends on how important the key is and whether it is replaceable.

Clive Robinson May 15, 2023 7:32 PM

@ Scot,

“Certificate authority private keys should be kept in a hardware security module[HSM]… …private keys are generated within the HSM, and never allowed out”

And what do you do when the hardware fails as it inevitably will do?

Ah yes,

“save as multi-part, encrypted backups, stored in separate safes at separate locations, with no single person allowed access to more than one part”

So the PrivKey is stored outside the HSM…

But what happens if you loose one of those multipart “encryption keys”?

Or any of the now rapidly increasing number of back up to backup systems fail?

At each layer of backup you actually do not reduce the risk of the PrivKey becoming “irretrievably lost” but you do rapidly increase the risk of the PrivKeu becomming “unavoidably disclosed”.

As the old saying has it,

“You can not have your cake and eat it.”

But worse as you divide the cake into ever smaller slices, the crumbs get everywhere… Thus people will be able to piece sufficient together to know all about the cake…

It’s just one of the very many failings of “code signing” that we’ve yet to resolve.

Another is the big fat pachyderm farting in the corner and letting out a terrible stink in this case…

“Certificate Revocation Procedures”

Apparently according to others in the industry who have spoken “off the record” to journalists Microsoft did not include such an idea in their system…

Which means if correct that MS was always going to be a hostage to the security, or lack there of in others… Opps.

Clive Robinson May 15, 2023 8:02 PM

@ Anonymous, ALL,

Re : Security or Pownership?

“Hrm… I guess it depends on what you mean by UEFI secure.”

What does “secure” actually mean with UEFI?

1, Secure for the user/owner
2, Secure for the HW industry
3, Secure for the SW industry
4, Secure for the IP industry

As has been demonstrated by the “walled gardens” of Apple and Google, such systems provide no security for the user/owner.

Nore as has been demonstrated by the “Games Industry” does it provide security for hardware or software industries.

All it realy does is give a very poor implementation of the “Fritz Chip” that first came up last century so that IP extorters could further their extortion…

I realy do wish people would stop using “security” and “UEFI” in the same context.

Oh… According to journalists, because of Microsoft’s inability to correctly design their system in the first place it’s apparently going to take a year to fix…

But when the fix does go in, all previous certificates will be revoked thus all the hardware and drivers you currently have will fail to work with Win11 and later…

So forced HW and SW upgrades all around, great news for the HW/SW industries, guarenteed new buisiness and more profit being slurped out of user/owners wallets… For new hardware they will not own but the industru will and users will not anylonger be “owners” so will have to pay, pay, pay…

Expect to see a whole load of tricks like HP pull with their “inkjet” and similar printers… If you think $6/month is exorbitant, wait untill every bit of hardware charges the same or more, $100/month could soon be the price gamers etc get gouged for simply because there is nothing to stop the HW/SW industry just “changing their business models”.

The only thing UEFI secures is profit models…

Ethan May 16, 2023 1:56 AM

It’s dated news (2020) but I still find it interesting:

MSI CEO Charles Chiang Dies Suddenly at 56

“MSI didn’t elaborate on the circumstances surrounding Chiang’s death.”

“Foul play not suspected” (LOL, sure!)

— More —



denton scratch May 16, 2023 5:27 AM

I can’t figure out what happened here. The Goodin article is pretty opaque.

Hackers stole a signing key, which appears to have been stored on a networked computer. Somehow or other, the hackers must have been able to reach that computer from the internet; so it wasn’t on an isolated network. That’s amazingly stupid. How often does a motherboard maker have to sign firmware? Once a month, maybe?

So you take the firmware to the isolated machine where the signing key is kept, sign the firmware, and then take the signed firmware to wherever it needs to go for distribution. This is so elementary and obvious that I don’t believe it’s what happened. It seems more likely that it was an inside job: someone at MSI stole the signing key.

I’m not sure how certificate revocation comes into it. If I’m updating motherboard firmware, I’m not going to be doing it while I’m online (if that’s even possible); so I’m not going to be consulting CRLs.

So how do you tell whether you’ve got an MSI motherboard with hacked firmware? Do you check the firmware revision before buying it? How do you do that, if the firmware itself could be lying to you? The only sensible choice is to assume that any MSI motherboard could be running hacked firmware, and avoid MSI. I don’t see how the MSI brand can survive.

Winter May 16, 2023 5:53 AM


I can’t figure out what happened here. The Goodin article is pretty opaque.

That is not very important. I heard it be described as follows:

Intel distributes the private key (ie, copied) to all OEMs. Note, Intel did not sign private OEM keys, they all got a copy of this specific private key.

MSI used the very same private key they obtained from Intel for all their products. They did not sign special private keys for every product/every year/whatever.

So, the way the attackers got the private key is entirely immaterial. The whole system was already broken in ways that would ensure this master private key would leak catastrophically some time for some reason.

Clive Robinson May 16, 2023 7:44 AM

@ ALL,

Some are aware this MSI key issues is not the only “bur in the fur” with booting etc… There is Microsoft doing it’s anti “Blacklouts” thing…

Well some are getting nervous about just how many issues are goingvto arise over MS and the massive pile of problems it’s going to raise…

When I saw this comment from someone who has been “wrestling the beast” for some years, the second paragraph made me laugh,

“For some reason the no. 2 DDG result for disabling Windows’ patchguard is still a page I haven’t updated in 6 years. And the top stackexchange result for disabling kernel patch protection sends people to the same page all the time.

Maybe I should add some instructions for signing winload.exe with the leaked MSI keys, seems even easier than the new kid on the block, EfiGuard.”

K.S. May 16, 2023 9:28 AM

I am not sure why a number of posters here want to push a false narrative that secure key storage and key injection is ‘too difficult’ to be feasible. PCI DSS defined and refined practices for doing just that, to summarize/simplify – use dedicated hardware (e.g., HSM) and key split for backup.

iAPX May 16, 2023 10:43 AM


My “false narrative” is that we observe in real world that it doesn’t work.
I understand that you disagree, but there’s the reality, key management, storage and usage is still a problem.

And don’t push me on PCI-DSS, it’s not meant to ensure security, it’s meant to give a base framework for those that need guidance (and shouldn’t be in payment business at first). Some rules are counter-productive if not laughable.

My point is that whatever you do, at first, at the heart, someone have to manage, store and use keys.
HSM needs these keys (or generated derivative), it’s just a onion layer, and if the manufacturer keys leaks, without knowledge of that point, they are all useless. If known they are all to be replaced ASAP.

There’s no trust in chain of trust, it’s just a belief…

vicar May 16, 2023 2:42 PM

“Gaining the kind of control required to compromise a software build system is generally a non-trivial event”

I am sure you do not need to gain control over someone else’s build systems.

Besides some folks seem to have an endless amount of time on their hand.

redux May 17, 2023 9:34 PM

mid late 80s had something reported of this, intel keys and maybe msi.


live free or die hard, 1990 filmings.

Jonathan R May 26, 2023 5:43 AM

@iAPX For example the PCI rules on passwords contradict the NIST guidelines.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.