Posted by hkc 15 hours ago
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.
What next, googling the public key finds a 2 year old pastebin with the private key?
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.
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.
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.
oh here
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.
The write-up from eMudhra mentions something about wrapping/unwrapping ceremony failing.
Any sufficiently advanced stupidity is indistinguishable from malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
This is assuming the CT logs no longer issue SCTs for these CAs. If they do then you just need to the CT dance and publish that certificate there.
Of course this assumes the app/device isn't using certificate pinning.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
