Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds
A major Indian certificate authority, eMudhra, was found to have generated several elliptic-curve CA private keys with effectively only 8 bits of entropy, including one with the value “4,” making them crackable in milliseconds from their public certificates. Commenters explore how this could slip past audits and into browser trust stores, what it reveals about the fragility of the web’s certificate authority model, and the limits of safeguards like Certificate Transparency. They also highlight the long tail of impact on unpatchable IoT and embedded devices, which may now be trivially vulnerable to HTTPS man‑in‑the‑middle attacks—or opportunistically jailbroken—until their trust stores are updated or the devices are retired.
Cause of the Weak Keys
- Commenters dissect the Mozilla bug report: eMudhra blames a “KGC script” deviation used to wrap/unwrap ECC keys for export.
- A second, much weaker key pair was apparently generated due to a code flaw, and confusingly similar key labels led operators to use the wrong keys for CSRs and cross-signing.
- Several find it alarming that the HSM or ceremony tooling could generate keys in such a tiny range at all; they view “test/weak key” capabilities as a fundamental design smell.
Malice vs. Incompetence
- Many argue this is gross negligence or “advanced stupidity,” not malice: if you already control the CA, you don’t need a weak key to abuse it.
- Others note that deliberate weakness could provide deniability, but most still find the “bug + sloppy procedures” explanation more plausible.
Systemic CA and Audit Problems
- Strong sentiment that the CA ecosystem is over-trusted and under-verified: hundreds of roots and thousands of intermediates, but no basic entropy/unit tests for CA keys.
- Audits are criticized as box-ticking exercises that can miss trivial failures like 8‑bit keys.
- Some suggest this incident should be firm-ending; others note many CAs are “grandfathered” and political/eIDAS-style requirements make drastic pruning unlikely.
Impact and Mitigation
- Immediate advice: update OS CA bundles, language runtimes, and rebuild container images; note that Flatpak and some runtimes may still ship their own stores.
- Big concern over unpatchable or rarely updated devices (routers, TVs, printers, IoT, embedded Java keystores) that will trust these intermediates until 2039.
Discovery and Search for Other Weak Keys
- The weak keys were reportedly found by running Google’s paranoid_crypto over CCADB certificates; further scanning of that corpus found no similar cases.
- Several propose broader automated checks (“luggage code entropy”) across all roots/intermediates, including for truncated or timestamp-seeded keys.
Debates on PKI Alternatives
- Long subthreads argue about replacing or constraining CAs via DNSSEC/DANE, name constraints, or content-signing and user-controlled trust graphs.
- Counter-arguments stress deployment failures (DNSSEC), political/control issues with TLD operators, usability for non-experts, and the persistence of legacy clients.
IoT and Opportunistic Use
- Multiple people are already using the broken CA keys to MITM traffic and jailbreak locked-down devices (smart speakers, appliances, ESP32 hardware).
- This dual-use aspect is seen as both a rare “upside” and a serious confidentiality risk while devices remain unpatched.