A key you could guess on your fingers

October is Cybersecurity Awareness Month, and this year, rather ironically, it brought a run of serious attacks and vulnerabilities. To help you make sense of them, we at AIDSET picked a few and will explain what happened, how each one worked and what you can do about it. First up: eMudhra, a trusted certificate authority that ended up with keys anyone could guess.

It's what stood between you and a fake banking site: a key you could guess on your fingers. Not a number starting with 4. Just 4. Its siblings weren't much better: 56, 115, and five more, all below 256.

But first, we have to meet eMudhra.

Who is eMudhra?

It is an Indian certificate authority (CA) whose certificates chain up to roots trusted by Mozilla, Microsoft, Apple and Chrome.

When your browser shows a padlock, it's trusting a certificate signed by a CA.

Think of it like your college reg ID: the website says I'm legit, and the certificate is the card issued by an authority everyone agreed to believe.

CAs don't sign everything with the crown jewels. A root key signs intermediate keys, and the intermediates sign the certificates that websites actually present. Each of those keys is protected by a private key, and the whole system rests on one assumption: nobody else can ever compute it.

It is like a Passport-office: the root authorises regional officers, the officers stamp passports, and border guards (your browser) accept any passport with a genuine stamp. The private key is the stamp.

The answer to life, the universe and everything is 42. For eMudhra, it was 4.

Why can nobody ever compute it?

These are elliptic-curve keys on P-384. A private key should be a random 384-bit number: roughly 1⁰¹¹⁵ possibilities, which dwarfs the ~1⁰⁸⁰ atoms in the observable universe. Some keys are ²²⁵⁶ strong. This one was ²² strong. eMudhra's eight keys were single-byte values: 4, 56, 66, 115, 155, 156, 230 and 237.

Security researcher Scott Helme recovered all eight from the public certificates on his laptop in under a second with Claude.

(The skill floor for attacking a certificate authority's signing key had dropped to… type a sentence?)

How could this happen?

eMudhra traced it to a key generation ceremony on 30 April 2025. A key wrap/unwrap step produced a second, weak set of keys alongside the intended strong ones, and the weak set ended up in the trust lists. The ceremony produced good keys. It also produced bad ones, and the bad ones got shipped.

For roughly a year and a half, nobody noticed. But then…

• 17 Oct: a researcher using the name Wayne reports the problem, proving it by signing a message with each key
• 17 Oct: Chrome blocks the keys the same day
• 19 Oct: Apple follows
• 20 Oct: Microsoft follows; Mozilla and Google publish details
• 21 Oct: eMudhra says its infrastructure wasn't breached, its root keys weren't affected, and these intermediates never issued any certificates
• 22 Oct: eMudhra announces it's leaving the public SSL/TLS business

Mozilla removes trust in the root that signed the intermediates; Google removes that root from Chrome and reviews eMudhra's remaining one

The report landed on a Saturday evening. By Monday, three of the four major browser vendors had shipped blocks.

Why does it matter?

Nobody had to steal these keys. Anyone could derive them, so in practice everyone held them. That means anyone could have forged a certificate for any website and intercepted traffic, plus two of the eight keys were for code signing, which is a separate kind of bad.

The mitigating fact is that, per eMudhra, these intermediates never issued real certificates. So no legitimate site was running on a compromised chain. The danger was purely that the trust was live: until browsers blocked the keys, the forgery path was open.

Key takeaways

• Trust is only as strong as the weakest key. The padlock in your browser depends on a CA's private keys being unguessable. Here, eight were guessable in under a second.
• Nobody had to hack anyone. The keys came out of a faulty key generation ceremony. A good process produced bad keys and shipped them, and nobody checked the output.
• For you: update your browser and OS. If you run a site on an eMudhra chain, plan a migration, since they're exiting public TLS.

Sources

• Mozilla-reported details via The Register
• Google: Protecting Chrome and Android users
• eMudhra's own statement
• Cloudflare analysis
• The Hacker News, Help Net Security, CyberScoop

Authors: AIDSET Cybersecurity Team (Rudrakshi Chincholkar) (Akshat Chauhan)