Signal Watchtower Advisory SW-A004: eMudhra’s Certificate Keys Could Be Guessed in 255 Tries

01What Happened

Eight keys, recovered in under a second

On 17 October 2026, a security researcher who goes by Wayne reported a serious weakness in eight intermediate Certificate Authorities operated by eMudhra, an Indian company that provides digital certificates, electronic signatures and other trust services. He had recovered the private keys behind all eight. To prove it, he signed a message with each key and sent the proof to Apple, Google, Microsoft, Mozilla and eMudhra, as Mozilla’s incident record and the public disclosure site describe.

“We have a problem here – Wayne.“

Anyone holding those keys could create fake certificates and impersonate banks and other portals that millions of Indians use for business and regulatory work. Chrome and Firefox blocked the affected certificates on 17 October, within hours of the report. Apple followed on 19 October and Microsoft on 20 October. eMudhra revoked the eight certificates on 18 October, and Sectigo later revoked the cross-signed copies. On 21 October, eMudhra’s shares fell 20% to the lower circuit limit.

The keys were generated incorrectly at a key generation ceremony on 30 April 2025. Nobody stole them from a secure vault. They could be calculated from the certificates themselves, which are public.

Sources: Google Chrome and Android Security Teams, Mozilla Bug 2083449, disclosure site.

02Certificates and Keys

What a certificate vouches for

Most of us use digital certificates every day without noticing. When you open a banking website, a government portal or an app that talks securely over the internet, a certificate helps your software confirm that it is connected to the service it intended to reach.

A trusted Certificate Authority (CA) issues or authorises these certificates, using public-key cryptography. Every certificate relies on a pair of keys.

An intermediate CA sits between a trusted root authority and the certificates issued to websites and services. An attacker with an intermediate CA’s private key can issue fraudulent certificates in that authority’s name, and a vulnerable application may accept a fake website as genuine. For the system to hold, the private key must be extremely hard to work out from the public key.

03The Mathematics

A 116-digit range, and a one-byte key

The affected certificates used an algorithm built on the NIST P-384 elliptic curve. A properly generated P-384 private key is an integer picked unpredictably from about 3.94 × 10¹¹⁵ possible values, which is 394 followed by 113 more digits. The largest valid value is a 116-digit number. Someone who holds the public key should have no practical way to find the private key.

Researchers recovered the eight values eMudhra actually used. These are the actual private keys. One of them is the number 4. The values below match the table in Scott Helme’s analysis.

Each key fits in one byte. In its 48-byte form, the first 47 bytes are zero and only the last byte carries a value. A byte holds 0 to 255, and zero is not a valid P-384 private key, so an attacker had 255 candidates to test. An independent check shared on X reported generating all 255 candidate public keys in 49 milliseconds and matching them to all 16 certificates, cross-signed versions included.

The 49 milliseconds covers candidate generation, not the full certificate check. Scott Helme separately reported recovering all eight keys on his laptop in under a second. Mozilla’s Dennis Jackson recovered them independently without knowing the reporter’s method. Both also reported that an AI agent recovered the keys from a simple prompt.

A large number does not guarantee security on its own. The key must also be generated unpredictably, and a 116-digit number chosen by a predictable process would be just as weak. The P-384 algorithm remains secure against known practical classical attacks when it is implemented properly. The failure here lay in how the keys were generated and selected.

Technical references: NIST SP 800-186, NIST SP 800-57 Part 1, Scott Helme.

04How It Happened

A ceremony that produced the wrong keys

eMudhra’s preliminary account, posted in Mozilla’s public incident investigation, says the keys were generated on hardware security modules (HSMs) that it names as Ultimaco, most likely the vendor Utimaco. These devices protect cryptographic keys and perform sensitive operations, and eMudhra describes them as FIPS 140-2 Level 3 compliant. The company says it created the eight intermediates for its European and US operations, to address data sovereignty for some customers. Only one, EM DV TLS CA – G3C, is said to have gone into production, and eMudhra says no end-entity certificates were issued from any of the eight. The account describes this sequence:

1. The intended elliptic-curve key pairs were created on the HSM as expected.
2. An approved deviation from the usual ceremony, meant to test key wrapping and unwrapping because the keys were to be exported, added an extra step.
3. A flaw in the code created a second pair of weaker keys on the HSM.
4. The two sets had similar labels, so the weak keys were used by mistake to create the certificate-signing requests, and eMudhra’s root signed them.
5. The same requests went to Sectigo for cross-signing.
6. Certificate revocation lists were first signed with the intended keys and produced invalid signatures. They were then signed again with the weaker keys.

eMudhra acknowledged human errors at several stages and said it is examining its maker-checker controls, process gaps and the code. It said it would re-verify every key ceremony it has run, and that its other issuers use keys generated on different HSM vendors’ hardware. Mozilla’s investigator noted that archived data shows the revocation list signatures failing from 23 May 2025, earlier than the 29 May date eMudhra gave in an older report, so the sequence of that mismatch is not settled. The explanation is preliminary and the investigation continues.

The findings put the ceremony script, key verification and approval controls in question. An HSM is a valuable control, and it does not remove the need to check the results of the process that uses it.

Source: Mozilla Bug 2083449, comments 5, 10 and 11.

05What It Means in India

Which systems are affected, and which are not

eMudhra is widely known in India for Digital Signature Certificates (DSCs), electronic signing and related trust services. It is a licensed Certifying Authority under the Controller of Certifying Authorities (CCA). Individuals and businesses use it for income-tax filings, GST compliance, MCA filings and contracts, so news of compromised eMudhra keys is a reasonable worry. The affected certificates cover far less than eMudhra’s whole business.

The 30,000 figure counts certificates that need migration. It does not count compromised Indian DSCs.

Sources: Mozilla Bug 2083449, Google, Scott Helme, Business Standard.

The market reaction: shares down 20% in a day

eMudhra’s shares fell 20% on 21 October 2026 and locked at the lower circuit limit, from a previous close of ₹540 to about ₹432 on the NSE, according to OfficeChai. The same report puts the loss at roughly ₹900 crore of market value in one session. Business Standard notes the stock is down 35% over the past month. The420.in reports it now trades about 58% below its December 2024 peak of ₹1,024, and cautions that the available information does not tie the whole decline to the security disclosure alone.

06Exploitation

No confirmed attacks, and no way to rule them out

As of this advisory, there is no confirmed public evidence that anyone used these keys to intercept customer traffic. Google reported that no TLS certificates issued through the six affected website certificate authorities appeared in Certificate Transparency logs before it blocked them on 17 October. Certificate Transparency records certificate issuance in public, auditable logs, and Chrome enforces it for all publicly trusted certificates by default. Google concluded that no fraudulent certificate from these CAs could have been used against clients that enforce it. Cloudflare reports that its own security review found no active exploitation on its services.

07Individuals

What most people should do

08Organisations

What businesses, banks and vendors must do

Sources: Cloudflare, disclosure site, Google, Go issue 82345.

09Signal Watchtower Assessment

The algorithm was sound, and the key generation was not

Generating keys is among the most basic duties of a Certificate Authority. A key generation ceremony exists to establish that keys were created securely, under controlled conditions, and can be trusted for their whole working life. This ceremony had specialised hardware and experienced staff, and it still produced eight private keys that were generated or selected wrongly, signed into intermediate CA certificates and left exposed for about seventeen and a half months. The defect was simple enough that researchers recovered the keys almost at once.

The keys were mathematically valid, so standard certificate processing succeeded even though the secrets gave almost no protection. eMudhra must answer these five questions:

1. How did the key generation process allow private keys with so little randomness?
2. Why did validation not catch the weak keys before the certificate-signing requests were approved?
3. What independent checks were run during and after the ceremony?
4. How could the wrong private keys be used to re-sign the revocation lists without anyone noticing the weakness?
5. What assurance exists for other keys and certificates produced by comparable processes?

eMudhra has acknowledged failures in its controls and is continuing its investigation. Its final findings and corrective measures will decide how confidence can be rebuilt.

Certificate users tend to trust the presence of a certificate, the strength of the algorithm and the certifications of the infrastructure behind it. The whole key lifecycle deserves the same scrutiny. A strong algorithm protects nothing if key generation, operating procedures or independent verification fail.

For the general public in India, there is no evidence at present that ordinary DSCs, UPI credentials or bank accounts were compromised through this incident. Organisations running internet-facing services and applications have an immediate task: verify certificate dependencies, apply updates and migrate affected certificates.

The algorithm allowed 3.94 × 10¹¹⁵ possible keys. The ceremony used only 255.

10Sources

1. Google Chrome and Android Security Teams: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates, 20 October 2026
2. Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20 October 2026
3. Mozilla Bugzilla 2083449: Private key compromise of eMudhra Intermediate Certificates
4. eMudhra: Certificate security incident statement
5. eMudhra Intermediate CA Compromise: disclosure site published by Dennis Jackson, 20 October 2026
6. Scott Helme: Eight Bits of Trust, eMudhra’s CA keys cracked in milliseconds, 20 October 2026
7. Cloudflare: 8 eMudhra certificates are compromised, 20 October 2026
8. NIST SP 800-186: Recommendations for Discrete Logarithm-based Cryptography, Elliptic Curve Domain Parameters
9. NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management
10. Government of India, Controller of Certifying Authorities: CA services
11. Go project: issue 82345, crypto/x509 mitigation, CVE-2026-111943, 19 October 2026
12. Ubuntu: eMudhra CA compromise fixes available, 20 October 2026
13. Business Standard: eMudhra tanks 20%, 21 October 2026
14. OfficeChai: eMudhra’s stock hits 20% lower circuit, 21 October 2026
15. The420.in: eMudhra shares plunge 20 percent to lower circuit, 21 October 2026
16. TradingView: NSE EMUDHRA

This advisory is based on information publicly available as of 21 October 2026. Investigation and remediation are continuing, and findings may be revised as further verified information appears.