As you’ve no doubt heard, the India-based public-key infrastructure company eMudhra recently announced that eight of their global TLS intermedia certificate authorities were cryptographically weak: it was trivial to reconstruct the private key from the public key, which meant that attackers could easily forge digitally signed certificates. If you’re a terminally online person like I am, you’ve almost certainly seen the numerous jokes referencing the number four, which was a reference to one of these weak private keys:
I’m anxiously awaiting the report with the full story about what happened. eMudhra has contracted with KPMG to investigate the incident, and hopefully they’ll share some public form of the report once the investigation is complete. In the meantime, Lex Neva pointed me at this bugzilla ticket with some preliminary details about the incident. Here’s part of a comment from Naveen Kumar ML, which I am assuming from context is an eMudhra employee. I’ve made some small formatting adjustments below.
We have done some preliminary assessment, there appears to be a flaw in the KGC [Key Generation Ceremony] script that was used on that specific day to create these ECC [Elliptic Curve Cryptography] issuers.
As for these ECC keys, our review of the KGC, assessment of the code and view of HSM [Hardware Security Module] 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 [certificate signing request] (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).…
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).
We are still assessing the code to see except [sic] steps where this process went wrong.
And here’s some text from Q7 of the eMudhra_Response_to_Google PDF attachment on that ticket:
At Key Ceremony 1, the PKI Operations script generated each B and C key, then wrapped, unwrapped and re-imported it as a planned rehearsal. From that day there were two objects with the
same label for each CA, and the participants created them. What we did not understand then was that
the key objects contained different data, and the CA certificates had been issued over the re-imported
objects and not the originally generated ones.
This stuff is outside my personal area of expertise, but I’m going to do my best to describe in my words what happened at eMudhra back on April 30, 2025.
That day, eMudhra was creating a new certificate issuer. One of the steps involved in creating a new issuer is generating a public-private key pair, and the process for doing that is called a key generation ceremony. Nothing went wrong with the generation of this initial key pair: the private key was secure.
It’s not explicitly noted above, but my assumption is that the key pair was generated on Indian servers. Some of eMudhra’s customers have data sovereignty requirements: certain data has to be housed in a particular geographic region. eMudhra specifically calls out the need to house issuers in US and European data centers, so presumably these are American and European customers. As a consequence, eMudhra has to securely transmit the private key to servers based in U.S. and Europe.
One thing I learned from reading this is the process of encrypting a private key so it can be transmitted is called wrapping, and decrypting it is called unwrapping. During their key generation ceremony, they tested wrapping and unwrapping. And, somehow, (this appears to not yet be fully understand), a new (insecure) key was created rather than decrypting the original (secure) key.
What really jumped out at me here was that the insecure keys were introduced by a process change that was necessary due to data sovereignty customer requirements. Data sovereignty is itself a security concern; these customers imposed the requirement in order to increase security. And, yet, that requirement ultimately contributed to the creation of a security vulnerability. Even more ironically, this was described as a test of the wrap/unwrap process. Testing contributed to the introduction of a security vulnerability!
This is not to say “data sovereignty is bad” or “testing is bad”, even though both activities contributed here. Rather, it is yet another reminder that all of our actions involve risk and trade-offs, even if we are not explicitly aware of these. In particular, adding additional requirements, even security or reliability requirements, invariably means adding additional complexity to the system, which introduces new risks, whether we are aware of them in the moment or not. Never forget: all practitioner actions are gambles.
