← Back to context

Comment by e28eta

5 hours ago

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).

Wrapping/unwrapping means the HSM would generate the private key and then encrypt it with a key only known to the other HSMs. Those other HSMs would then decrypt the key on import. The private key should still have been impossible to examine outside the HSMs.