Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.

amoss 5 hours ago | parent | next [-]

Given the usefulness of this to anybody who knew about it between the ceremony and now - assume malice.

▲

dist-epoch 7 hours ago | parent | prev | next [-]

And an equal amount of stupidity in the whole ecosystem, apparently there are no "unit-tests" for trivial failure modes, like 8 bits of entropy, before adding a CA to the trusted list.

What next, googling the public key finds a 2 year old pastebin with the private key?

▲

silvestrov 7 hours ago | parent [-]

Even just a human glancing at the private key should do it.

Don't they even test script changes on a staging server? How could there be such a script error in production that was not caught in testing/staging?

This sounds very like a fundamental organization error, not an innocent whoopsie. It should lead to a permanent ban of the organization.

▲

karel-3d 6 hours ago | parent [-]

Well humans should NOT glance at private keys! That is the whole point of HSMs!

▲

consp 5 hours ago | parent | next [-]

I'm still flabergasted the HSM allowed this key to be generated. Then again, I've worked with HSMs, there are always many mistakes in the firmware, usually less severe though.

▲

karel-3d 5 hours ago | parent [-]

It seems there was some issue with the ceremony with some wrapping/unwrapping scripts.

They explicitly said they wanted to export the keys from the HSM; the keys were intended for USA/Europe (for sovereignty reasons) but were never actually used.

It seems the HSM itself worked, their ceremony around wrapping/unwrapping didn't.

▲

consp 5 hours ago | parent [-]

Makes more sense.

I'm sure the Utimaco's used (haven't worked with one) also allow all slots to contain the same name or keys with the same name and the device always selecting the first one if you only provide the name and not the slot ID or token identifier. Don't ask how I found out the hard way.

	▲	karel-3d 4 hours ago \| parent [-]
		Yes there was something about key names in the write-up (which I cannot find now) oh here https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11

▲

silvestrov 4 hours ago | parent | prev [-]

But eMudhra wanted to (was required to) export the keys.

So using an HSM in the first place is a security theater. Or that this HSM isn't really an HSM since it allows for export of the private key.

The trusted enclave in a MacBook is more secure than this HSM.

	▲	karel-3d 4 hours ago \| parent \| next [-]
		There is something called "wrapping/unwrapping" - you encrypt the key, move it to the other HSM, and it unwraps it. So what moves around is encrypted. I don't know enough about HSMs to tell you if it's done using symetric or asymetric crypto, but no the key should not move around in the plaintext. The write-up from eMudhra mentions something about wrapping/unwrapping ceremony failing.
	▲	xvector 4 hours ago \| parent \| prev [-]
		Most HSMs used by CAs are pretty trash tbh.

▲

sobkas 7 hours ago | parent | prev [-]

Any sufficiently advanced malice is indistinguishable from stupidity.

	▲	RetroTechie 4 hours ago \| parent \| next [-]
		The reverse is also true: Any sufficiently advanced stupidity is indistinguishable from malice.
	▲	SAI_Peregrinus 4 hours ago \| parent \| prev [-]
		Never assume stupidity for what can adequately be explained by profitable malice. Never assume unprofitable malice for what can adequately be explained by stupidity.