Private Key Set to 4? CA's Elementary Mistake Leaves TLS Exposed

A Single Digit That Shattered Trust

Last Wednesday, the security world was rocked by a revelation: a certificate authority (CA) named eMudra had set its private keys to the number "4." This isn't a metaphor—it's literally "4"—an elliptic curve private key that should have 384 bits of strength (about 120 decimal digits) reduced to a single digit. This episode of Computerphile breaks down the whole fiasco and demonstrates firsthand how to forge certificates using this elementary error.

To grasp the severity, we need to revisit the trust chain of public key infrastructure (PKI). When you visit your bank or the BBC, the little lock icon in your browser's address bar is backed by a TLS connection. The server presents a certificate containing the domain name and public key, signed by an intermediate CA, which in turn is signed by a root CA. Your operating system or browser has the root CA's public key baked in, so the entire chain can be verified. The sole responsibility of a private key is to generate signatures—once leaked, an attacker can issue arbitrary certificates in that CA's name, including forging the BBC's public key to launch a man-in-the-middle attack.

From "4" to "115": A Brute-Force Case Study

According to eMudra's press release, the problematic private keys weren't just "4"—they also included 56, 151, 66, 155, 156, 230, and 237. What these numbers share is that they're absurdly small. If you randomly pick a 120-digit number, it's virtually impossible for it to have only one or two digits. As the video puts it: "If you say you randomly picked 4, no one's going to believe you."

To verify whether these certificates could actually be cracked, the host downloaded the publicly disclosed bad certificates and began brute-forcing with OpenSSL and a Python script. The core idea: for a given elliptic curve algorithm (secp384r1), each private key uniquely corresponds to a public key. So by incrementally generating private keys starting from 1, computing the public key, and comparing it against the certificate's public key, you can find the correct private key within a finite number of attempts.

The first obstacle in practice is that OpenSSL by default doesn't allow users to specify a private key—it only accepts randomly generated ones. The host manually constructed a key file with a small-value private key by modifying the Base64 encoding in the PEM file. Then he used an "ugly Python script" to loop through OpenSSL generating public keys and comparing them. The script was highly inefficient—about one second per operation—but even so, it found the private key "115" (the key for the certificate demonstrated in the video, corresponding to one of the bad certificates) in a short time.

Elliptic Curve Keys and secp384r1

In elliptic curve cryptography (ECC), a private key is a randomly selected integer, and the public key is the result of multiplying that integer by a fixed base point on the elliptic curve. secp384r1 is a NIST-standardized elliptic curve whose private key space is 2^384, approximately 1.15×10^115. Since deriving the private key from the public key requires solving the elliptic curve discrete logarithm problem (ECDLP), for which no feasible algorithm exists on classical computers, the randomness of the private key is critical. If the private key is restricted to an extremely small set (e.g., single digits or three-digit numbers), an attacker only needs to traverse the entire small space to quickly find the corresponding private key. The brute-force search demonstrated in the video exploits exactly this: incrementally generating private keys from 1, computing public keys, and comparing them against the certificate's public key until a match is found. Because the space is so tiny, even an inefficient script can crack it quickly.

Certificate Forgery and the Current State of Fixes

After obtaining private key "115," the host demonstrated the complete attack chain: using that private key to sign a certificate containing "BBC's public key," then having an older system verify it. The verification passed—because the signature genuinely used the correct private key. This means that before the vulnerability was patched, an attacker could forge certificates for any website.

Of course, mainstream browsers and operating systems have now revoked these problematic intermediate certificates, so verification will fail. But the issues exposed go far beyond a technical blunder: CAs are supposed to use hardware security modules (HSMs) to generate keys, and HSMs are designed precisely to prevent private keys from being exported or specified in any form. eMudra claimed to use dedicated hardware—so how exactly did they set a private key to 4? The host speculates they may have written their own cryptographic tools, bypassing standard procedures.

The Role of Hardware Security Modules (HSMs)

A hardware security module is a dedicated cryptographic device used to securely generate, store, and manage keys. Its core design principle is that private keys never leave the HSM in plaintext; all signing operations are performed inside the module, and the outside world can only call interfaces without being able to export the private key. HSMs also incorporate high-quality random number generators to ensure key randomness. In a CA's key generation process, using an HSM is industry best practice and part of audit requirements. eMudra claimed to use dedicated hardware, yet its private keys were set to small values like 4—suggesting it may have misconfigured the HSM or written software tools that bypassed the HSM and directly specified private keys. This vulnerability highlights the importance of process compliance and auditing.

Why Randomness Is So Critical

The 384-bit private key space is roughly 2^384—even at a billion attempts per second, it would take far longer than the age of the universe. But once a private key is drawn from a small set (say, single digits or three-digit numbers), brute-forcing becomes trivial. The video emphasizes that even with an inefficient script, cracking took only "about the time for a cup of coffee." With optimized tools, it could be thousands of times faster.

This case is a wake-up call for every system that relies on PKI: key generation must use a cryptographically secure random source, and the entire lifecycle of a private key should take place within controlled hardware. Any process that allows "manually specifying a private key" is a dangerous step backward. For developers, OpenSSL's default refusal to accept user-supplied private keys may seem inconvenient, but it's actually the last line of defense.

Cryptographically Secure Random Sources

A cryptographically secure pseudorandom number generator (CSPRNG) is the foundation of key generation. It must satisfy two conditions: statistical randomness, meaning the output appears uniformly distributed; and unpredictability, meaning even knowing all previous outputs, one cannot predict the next output. Common CSPRNGs include the operating system's /dev/urandom, CryptGenRandom, etc., which gather randomness from hardware entropy sources (such as interrupt timing and disk jitter). Non-cryptographically secure random sources (like the standard library's rand()) may be predictable or biased and must never be used for key generation. In the eMudra incident, private keys were set to small numbers like 4, indicating that the random source may have completely failed or been deliberately bypassed, causing the key space to collapse and making brute-forcing feasible.

The Fragility and Resilience of the Trust Chain

The PKI system depends on the integrity of a handful of root CAs. Once a CA errs, all relying parties along the entire chain are affected. The good news is that modern browsers and operating systems have certificate revocation mechanisms (such as CRL and OCSP) that can isolate problems relatively quickly. But this incident also reminds us: security is not a product, but a process. CA audits, standardized key generation, and public vulnerability disclosure are all indispensable.

For ordinary users, keeping systems and browsers updated remains the most effective protection. For security professionals, this case is an excellent cautionary tale—it vividly demonstrates that even a single digit's negligence is enough to make a carefully constructed edifice of trust totter.