An eMudhra CA private key was literally 4

Local demo signed with a recovered eMudhra CA key. Chrome has an explicit certificate exception here. The comic is Randall Munroe’s XKCD #221, reproduced unchanged under CC BY-NC 2.5.

eMudhra wanted to deploy issuing authorities in its US and European datacenters. It says customers had data-sovereignty requirements. Moving encrypted keys between hardware security modules (HSMs) can also support recovery and business continuity. Those are ordinary reasons to plan a key transfer.

Then an approved change to the key-generation ceremony produced extra, weak keys. Operators accidentally used them for certificate requests, and the resulting certificates got signed and shipped. One of the private keys was the integer 4.

I want to understand why a legitimate deployment needed a departure from the usual ceremony, and how the approval process let the wrong keys become certified issuing authorities.

What eMudhra says happened

In Mozilla Bug 2083449, comment 11, eMudhra says the original ECC keys were created correctly inside its hardware security modules. It then introduced “an approved deviation to our usual KGC” to test wrapping and unwrapping keys intended for export. A script flaw created a second, weaker set. Similar labels led operators to use those keys for certificate-signing requests, or CSRs. eMudhra’s roots signed the resulting certificates, and the same weak public keys went to Sectigo for cross-signing.

The export test created a second set of keys, and the process lost track of which set was supposed to become the issuing authorities. The detailed coding error is still unpublished.

The company says the device doesn’t appear to be at fault. Its hardware mapping identifies Utimaco Se-Series Gen2 devices for the affected keys.

The model named in the incident’s hardware mapping. This is a product image, not a photograph of the ceremony equipment.

There was another opportunity to catch the mismatch. eMudhra says it initially signed revocation lists with the original strong keys. Those signatures failed against the certified public keys. It then re-signed the lists with the flawed keys. A discrepancy between the original keys and the issued certificates should have stopped the process for investigation.

Who approved the deviation?

The purpose of a key-generation ceremony is that nobody makes up the procedure as they go along. People follow reviewed steps, separate responsibilities, and leave a record that an auditor can compare with what was supposed to happen.

A procedure can change. The approval and validation of that change are part of the security boundary. Calling a deviation approved doesn’t tell us who reviewed the modified script, what they tested, or when the change was made. The public response doesn’t establish whether this was planned well in advance or introduced on the day.

I want to see the change request and the script diff. Who authorized the export test? Was it exercised with disposable keys before the ceremony? Why could its output be selected for a production CSR? Did the second reviewer compare the CSR’s public key with the original generation record, or just confirm that the request had a working signature?

Those questions matter even if every person involved had an ordinary business reason for the change. The ceremony allowed a test artifact to become a certified issuing authority. The later signature failures didn’t expose the mistake before the weak keys were used again.

eMudhra’s own FAQ describes intermediate and issuing CAs operating in HSM clusters. Hardware protection was supposed to be part of this system:

The company’s published description of its issuing-CA architecture.

An HSM can protect a key from being read out while still signing with it. That protection achieves very little if anybody can guess the key.

Export to where, under whose control?

The report gives a destination and a stated reason: eMudhra’s own US and European datacenters, to meet customers’ data-sovereignty needs. It doesn’t identify the facilities, destination HSMs, operators, or which copies would remain under which jurisdiction.

Wrapping encrypts a key for transfer into another cryptographic module. A CA may need copies for recovery or continuity. eMudhra’s November 2024 policy, §6.2.6, already described encrypted transfers between similar modules for those purposes. That document predates this ceremony.

Key transfer was already contemplated by the policy. The question is why this deployment needed a departure from the usual ceremony rather than an already tested export procedure.

Why generate the keys in India and transfer them, instead of generating separate issuer keys at the destination? Reusing a key can have operational reasons, but the report should state the reason here. What exactly did the customer sovereignty requirement cover: certificate-request data, signing operations, private-key custody, or all three? Would a copy remain in India? Who could authorize its use?

The same policy says CA private keys are not escrowed (§6.2.3). A recovery copy under the CA’s control is a different arrangement from giving another party access to the key. The report should document the intended custody without leaving readers to infer it from the word export.

A secondary question about state access

India’s IT Act §§69 and 69B and Telecommunications Act 2023 §20 provide mechanisms for interception, decryption or traffic monitoring under their respective conditions. That makes state access a question to investigate when discussing key custody. It doesn’t establish a connection to this ceremony.

The hypothesis that an interception obligation influenced the export workflow remains conjecture. I haven’t found an order or rule requiring this CA-key export. Customer data sovereignty and business continuity are more plausible reasons on the evidence available. Neither the export itself nor the tiny scalars demonstrates a surveillance scheme.

Eight keys, sixteen certificates

There are eight distinct weak P-384 keys and 16 certificates containing them in the scanned snapshot. Each key appears in an emSign-issued certificate and in a cross-signed certificate under AAA Certificate Services. Two certificates, one public key, one recoverable private integer.

I checked these integers independently. Each CA name links to its exact fingerprint in eMudhra’s official repository; the download provides the emSign-issued certificate.

The Mozilla incident record lists the fingerprints, serial numbers and CCADB identifiers for the eight emSign-issued certificates and the eight cross-signed certificates.

Recovering the private keys

Fluepke’s recovery program tried the integers 1 through 255, calculated the public key for each, and compared it with the public keys in the certificates. That recovered all eight private keys. Anyone could then use them to sign certificates as those CAs.

I independently derived the public points, then used 4 to sign a demonstration certificate for example.com. The site ran on loopback; the real example.com wasn’t involved. Chrome rejected it without the explicit exception used for the screenshot.

The locally generated demonstration certificate, signed using the recovered CA key.

I also searched a pinned CCADB certificate snapshot: 10,317 distinct certificates, including 1,504 distinct EC public keys. Testing one-byte scalars on four curves found the 16 certificates sharing these eight keys and no additional matches. That covers the snapshot’s CA certificates, not all CT history or private PKI.

The clients that never get the fix

An attacker with one of these CA keys can sign a certificate for someone else’s hostname, subject to the CA’s constraints. The client still has to accept the chain. The victim doesn’t have to be an eMudhra customer: a forged certificate can name a service whose legitimate certificate comes from a different CA.

The Chrome Root Program blocked the six TLS keys through CRLSet on October 17. It also reports that no certificates under those intermediates had appeared in Certificate Transparency before the block, preventing default acceptance in CT-enforcing browsers. Mozilla distributed a OneCRL block on October 17 and announced an NSS root-store update on October 20.

My concern is the equipment whose trust store is whatever the manufacturer flashed into it years ago. If it accepts an affected chain and has no effective revocation or distrust update, it can keep accepting signatures made with a recovered key. An attacker who can intercept or redirect its connection can impersonate its expected server.

For a device sending a bearer token to a cloud API, that can mean handing the token to the attacker. For a device taking commands from an MQTT broker, it can mean trusting the attacker’s responses. A pin of the expected server public key, or a trust store limited to an unaffected private CA, can prevent that replacement.

No pinning and no OTA updates aren’t sufficient by themselves to prove exposure. The device must accept an affected certification path and lack another effective rejection mechanism. But a browser vendor’s emergency response doesn’t repair that device.

Espressif documents a CA bundle embedded in the application binary and updated through OTA. If the vendor has stopped shipping firmware, that update route may be gone. A revocation list the client never fetches won’t change its next handshake.

Expiry is path-specific too. The AAA-cross-signed CA certificate used in my demo expires on December 31, 2028. The emSign-issued certificate for the same 4 key expires on April 28, 2040. A correct clock rejects an expired path; another unexpired certificate for the same key can remain a problem if the device trusts its chain.

Impersonating an OTA server also threatens the repair channel. A separately enforced firmware signature still protects the image: a TLS CA key doesn’t provide the vendor’s firmware-signing key. Espressif describes signature checks during OTA and boot, and warns that trust changes can break the update connection itself.

These clients need a distrust decision they can actually receive and enforce. Meanwhile, I want eMudhra to publish the deployment requirement, the approved procedure change and the record connecting the generated keys to the CSRs. A legitimate reason to move keys still needs a procedure that keeps the right keys attached to the right certificates.