> That's not how it works. You need the private key to sign the drivers. This is not a file that developers of those companies have access too.

No, you could unfortunately get around that very easily (or rather, ignore recommendations) at least a few years ago. So I bet there are a lot of certificates and private keys lying around on disks, build servers, version control systems and probably even on developer USB sticks.

The cert and key just needs to be something signtool can access. Signtool doesn't care whether it's relatively unprotected key in system software based key store or on a HSM.

Windows 10 1607+ enforces a much stricter standard, especially if you want your driver to work in Secure Boot mode. There are also stricter requirements for driver testing and static analysis, although those depend on the driver type. Microsoft requires and checks testing tool output as a part of the driver submission before finally signing it with their cert.

Tip: If you run Windows 10 and value security (and system stability), use Secure Boot.

(I've developed Windows kernel drivers.)

More likely they just spear phished the people who would have access that can be used to get the keys.

> I'd bet that they somehow had access to the HSM, to have it sign the driver for them.

Or were able to duplicate the HSM before it was delivered. You know, like how the NSA intercepted shipments of internet routers in transit and inserted backdoors.

That wouldn't work because HSMs are typically not delivered with keys, you generate the private key yourself.

Ok, makes sense. It could also be that the HSM was shipped from one office to another after keys had been loaded onto it. Dunno.

In "secure" places, HSM's are basically in a vault with armed guards.

I have seen HSMs in a concrete fireproof room, inside another concrete room, inside a regular room, inside a nondescript building. This one required the use of 3 persons (one to authorize entry past the 2 guys with rifles, one to unlock the vault rack with the hsm, another to authenticate to the HSM to perform work).

Company or agency?

a very large private company

HSMs are designed to resist exporting private key material. And to sign something, you normally have to enter a PIN or a password. :)

You don't ship HSM's with keys (you initialise them on-device yourself) nor can you read read keys out from one (at least in theory).

if the goal is to gain access to HSM’s signing functionality and you don’t need to know the HSM’s keys to gain access to its signing functionality then something else is being guarded that is essentially the key.. For example be it a machine locked in a room, then the room key is the key. Or maybe someone’s retina, or a sign-off from someone with clearance, etc. (at least in theory)

That’s a general theory though, but I’d think the same fundamentals apply

Also this only serves to prove that some powerful entity that operates on secrecy, like a government or mega corp, is likely who executed this. I’d like to fantasize some suave, determined black market salesman with a rough childhood and his band of cyber criminals broke into both of these facilities, but seeing how difficult it is to accomplish something like this, it seems more likely that someone just let them in through the front door.

In theory, theory and practice are the same, in practice they're not.

Well, an HSM that doesn't meet those requirements is essentially spoiled milk and of little value. I agree many HSMs are found vulnerable eventually.

> These keys are usually stored on a HSM. Even if you want to, you wouldn't be able to access the keys stored inside. This is specifically designed to protect against rogue/bribed personnel.

Sure now they often are - after many security failures 10 years ago before HSMs were widely deployed. A decade ago a much more common ‘secure’ mechanism was to store the keys on an airgapped machine that had never been connected to a network and use sneakernet to get binaries signed.

That`s how it should work in theory, in practice it was most likely how the parent has described it.

Sorry, this _IS_ how it works. These are usually stored on developers workstations with a weak password protected PKCS12 file (.pfx/.p12)

HSMs. Lol.

I'm genuinely interested in how you know this.

>You need the private key to sign the drivers. This is not a file that developers of those companies have access too.

The developers would need access to the private key to sign the drivers they're deploying. Convenience is the ultimate foil of most good security intentions.

> The fact that they pulled it of to break into not one, but two of those secrets is extremely impressive on it's own.

Did they break into them? Stuxnet had government backing, most articles I've read assume American or Israeli.

If it was the American government (on its own or on Israel's behalf), then it might have 'simply' applied its considerable influence to get the Taiwanese government to get Realtek and JMicron to hand over the HSMs.

IDK, pre-windows-10 didn't you just need a ~$200 [1] code signing certificate? Do people usually buy HSMs to store those?

[1] https://www.sslshopper.com/microsoft-authenticode-certificat...

You do not store certificates on an HSM, you generate the private key on it and use that to sign things. Certificates that end up in actual use are further many chains removed from the root keys.

> Do people usually buy HSMs to store those?

At the time Stuxnet was around, no, not really.

Isn't a national security letter enough to "break in" to any US company?

Oh realtek is Taiwanese, but I don't doubt they have reason to cooperate as well.