← Back to context

Comment by paustint

16 hours ago

This is what I found regarding how it happened, but still not a full explanation - but there was some name confusion and obvious incompetence.

>According to eMudhra, proper strong keys were created in the HSM at the key ceremony on 30-04-2025. The script had been changed to test wrapping and unwrapping keys, because the intermediates were to be moved to data centres in the US and Europe, and a bug in that change created a second set of weak keys. The keys had almost identical names, and the weak ones were used for the certificate requests. The same request was signed by eMudhra's own root and sent to Sectigo, which cross-signed it. The strong keys never made it into any certificate (Bugzilla).

https://www.fairssl.se/en/articles/emudhra-ca-noegler-knaekk...

I wonder. Say I wanted to prevent something stupid like this from happening in the future. What would be a sensible check? The higher level authority doesn't see the private key itself, right? Just the certificate request. And I wouldn't want someone to manually inspect the keys to see that it looks random-ish. Perhaps there could be a small check script added to the generation of certificate requests that says "hey, your key a.) is mostly zeroes, b.) appears to be ASCII text, or c.) seems otherwise extremely non-random, please use -f to continue anyway".

  • I don't know if it will work on something as small as a private key, but you can compress the key. If the compressed key is significantly smaller then the original, it lacks entropy. Pure random data is mostly incompressible.

    Note that 32 0x00 is a possible output from a pure random generator while still being quite compressible, you would probably still want to throw that one out though. After buying a lottery ticket.

  • Do not allow devs to modify ceremonial hardware.

    • I was about to reply with "they didn't have a choice" but on second thought perhaps CAs are important enough that they should never be allowed to export keys from an HSM and should instead be required to physically deliver and install the HSM wherever it needs to be in the world. Inconvenient and expensive but likely for the best.