Comment by eqvinox

Someone answering “questions for emudhra” also say the keys were intended to be exported to US and EU data centers. I don’t know if that would have precluded inspection (hopefully it’s encrypted some way, but why not have the destination HSM generate the CSR?)

Edit: I see the below paragraph is quoted extensively below. I hadn’t seen those comments yet. Oh well

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11

Content:

We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)

The RSA issuers went through a different path as per our assessment of the code and are therefore not impacted. Some additional context - these issuers created were meant for export to our US and European data centers to solve data sovereignty issues for some of our customers (but never ended up operationally in production except for one).

i wonder how many keys they thought it had. reading them byte by byte xD 'this HSM is excellent we can litterally put _all_ our keys in it!'

and thx for the context. i rly wonder now how it went down lol

Random number 0-255

Chosen by fair dice roll

The Web PKI uses certificate transparency, so we’ll have a definitive answer about whether this is/was exploited soon.

(But in any case, CT ensures that it can’t be “quiet.”)

I admittedly don't know much about how CAs work but why would a state actor care about such an exploit? Wouldn't they just ask any local cert issuer and receive a "legitimate" cert?

organized crime is generally as or more capable these days. they have bigger budgets than most nation states.

A grumpy state actor today.

Nope. You can find this from the Chrome Root Program.

> Because no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17, no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers.

I'm not exactly sure which of the roots from eMudra were compromised, but the "emSign ECC Root CA - G3" which is mentioned in the OP site as one you should blacklist, is present on my phone which is running Android 12 with the last security update from three years ago. Having a better timeframe for when the impacted certificates appeared really would have been nice.

They chain up to emSign & Comodo:

https://groups.google.com/a/mozilla.org/group/dev-security-p...

> an approved deviation to our usual KGC to test

The whole point of a key ceremony is that you're not going off-script and YOLOing random crap.

Ultimaco HSMs! Well Ultimaco today published a marketing blog post entitled Global Encryption Day: Encryption Is Only as Strong as the Keys Behind It. It seems like a subtle dig at their customer’s incompetence.

https://utimaco.com/news/blog-posts/global-encryption-day-en...

Reading further, it seems like they say they first generated some keys on-HSM, but then used 'test keys' (that were used to test wrap/unwrap of key material) instead by accident. Fishy.

Why is that a way bigger problem? Windows will happily run unsigned binaries. Code signing just decreases the friction for users slightly, but is in no way required. TLS is definitely a way bigger problem.

For their own stuff, Mozilla has talked in the past about specifically just only trusting intermediates they've seen. Their modern root agreement says the CA will disclose all relevant intermediates, so arguably they have a complete list and further if that CA "forgot" about a few of them whether that's because your firm is too disorganised ("Oh, right, the one on Barry's laptop, forgot that one") or an actual attempt to sidestep this rule - then we certainly don't want to trust these undisclosed intermediates, do we ? They're either purposefully shady, or they're forgotten about and likely never have been audited.

  > One of the issues with sub-CAs (well, X509 certs in general) is that they
  > can be ghosts in that there's no way you'll ever get it as a response
  > on a TLS connection, so automated scanners on that won't find it.

Could you expand on this? I don't have a full grasp of what you're saying (I'm not super knowledgeable in CA stuff).

My understanding is that if something, like a browser, connects to a SSL site, they will either have or can obtain, one way or another, a complete chain all the way up to the root, so there can be no "ghost" certificate. And I would imagine a scanner could do all those same steps, and thus access all the same certs.

Is this a deficiency in scanner software? You seem to indicate it is a fundamental weakness in X509; I'm just trying to understand what.

Could you maybe describe a specific example of what you're describing?

That was inspired by the PS3 signing key PRNG. Sony Computer Entertainment, you have been redeemed.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 they actually did use an HSM? Though some of the jargon is a bit beyond me, maybe this will finally get me to learn more PKI stuff.

> The hardware used for each of the issuers is in the attached file. These HSMs are FIPS 140-2 Level 3 compliant.

> no HSM would ever generate these

You trust the magic black box far more than I do.

My big fear about HSM is that they are inscrutable by design. There is no way to verify they are working as advertised. Plus side, all sorts of fancy hardware to protect your keys. Down side, all sorts of fancy hardware that obscures flaws in the implementation.

How could you prove it was not a fair random generation? It's totally possible.

The algorithms don't care because it doesn't make sense to care, the same reason a "smallest non-interesting number" wouldn't make sense - now that number is interesting precisely because it was cited as the smallest non-interesting number.

However practical applications do care, and so e.g. the "Debian Weak Keys" are a relatively small set of keys which would have been generated if you used a particular patched OpenSSL to generate "random" key pairs after a mistake patched out most of the randomness. Many of them were used by Debian sysadmins particularly in the window between the patch and the discovery - and so all CAs are expected to check that you're not trying to get a certificate for the public half of one of those pairs.

There's nothing "bad" about those keys except that well, we know some people used them so bad guys will try the private halves of those keys just in case. Likewise there are a few apps which shipped with a baked in "default" private key, and all the paperwork to apply for a certificate but obviously a user may not realise that if they just fill it out with their name and details, they're now vulnerable to attack by literally any other user of that software. They were supposed to generate a random key pair and re-generate the paperwork for the resulting random values. If they don't realise we need the CA to say "Nope, that's a bad idea, not issuing" even though these keys aren't special in any other way than they're given to every single user of that software.

IIRC when I worked for a famous US corporation their middleboxes relied on such a well-known key and at some point I asked "Hey, this seems wrong. Why did you do this?" and as often has happened in my career I got no actual reply to my question but magically the issue was fixed in short order. The first clumsy attempt to fix it broke some things, but they gradually figured it out. Glad I could help, I guess.

I have no idea but I can imagine why you'd want to bias things away from principled randomness to avoid picking 0 or 4 or whatever.