Weak CA Private Keys: How Poor Key Management Puts TLS Certificates at Risk

What happens when you generate keys with insufficient randomness?

At the end of last week, a security bulletin submitted by a user to Mozilla’s Bugzilla platform raised concerns across the PKI ecosystem. Within two hours, the user had discovered that private keys could be recovered from existing intermediate CA certificates issued through the eMudhra platform. 

The analysis appears to indicate that the integer selected during key-pair generation was not random. An error in the key ceremony meant that some CA certificates were issued using trivial private keys from a manual import, rather than private keys with the high entropy expected from the process. As a result, an external party could potentially guess those private keys.

If someone knows an intermediate CA’s private key, they can use it to issue certificates that appear to come from that CA. Those certificates could then be used to impersonate services that rely on the CA as part of their chain of trust.

The incident led the Common CA Database to remove the affected CAs from the root of trust, potentially affecting all certificates associated with them. The clean-up is ongoing and is disrupting some of the services involved.

Which systems are affected?

The issue was reported in a PKI platform used to generate certificates for securing website communications. The immediate security implications therefore centre on websites and web services.

In principle, however, a similar process failure could affect other services that depend on secure key generation and management. These include PKI for digital signatures, digital signature generation, digital seals, payment processing and other forms of digital security.

There is no reason for the wider market to panic. In many of these areas, established security practices and industry certifications help protect against this type of incident.

The issue appears to be linked to test keys being mixed with production keys. Test keys may have been assigned simple, memorable values to make debugging easier, then inadvertently left in place when the system went live. The keys in question reportedly had values that were mostly “0”, with only one or two digits changed from one key to the next. This points to a human error in the operation of the key-generation process.

The incident should remain within the scope of the affected systems. It does, however, raise questions about how key-generation processes are implemented, operated and audited. The platform provider lists compliance and certifications across GDPR, SOC 2, ISO 27001, CMMI Level 5 and HIPAA. These controls would ordinarily be expected to help prevent this type of issue.

We undergo some of these audits and certifications ourselves, as well as others not listed here. The fact that an issue of this kind could occur is surprising, particularly given the attention auditors generally give to key-import conditions.

What are we doing differently?

We do not know the full context behind this incident, and that detail is not essential to the broader lesson. Known-value keys are generally used to make testing easier or to allow data to be decrypted manually.

At Cryptomathic, our products have used secure, automated key-generation processes for decades. These processes draw on the true random number generation capabilities of the FIPS-certified HSMs we use. Where key import is supported, it is restricted by policy. Learn more about our Crypto Key Management System and Crypto Service Gateway.

We also believe that giving customers automated and scriptable ways to test key generation and data encryption reduces the temptation to introduce user-friendly cryptographic components manually. When testing can be done securely and reliably, there is less reason to use known-value keys.

This approach also helps keep test environments and practices as close to production conditions as possible, improving the quality of the overall process.

It is difficult to remove human judgement from security operations. One practical way to reduce risk is to limit the reasons and opportunities for people to take shortcuts.

Why are we responding?

There are several reasons for addressing this incident publicly.

First, one of the HSM vendors used by the affected PKI platform has responded to questions about its product. The vendor has emphasised that its HSM supports secure key generation with appropriate levels of entropy. As we use the same HSM product, we want to reinforce that point: the issue does not indicate a problem with the HSM itself. A FIPS-certified HSM, operated under suitable conditions, can provide secure key generation.

We also expect customers and prospects to ask about our own key-generation practices. Across our platforms - including Signer, CrystalKey 360, TrustView, CardInk, Obsidian and MASC - we use true random number generation from the HSMs with which our products integrate. Safeguards help ensure that products are operated securely and that these practices cannot be easily overridden. Advanced key policies are one part of that approach.

We also expect further discussion about mobile security. The incident has already been shared in security forums in the context of man-in-the-middle attacks. If an intermediate CA certificate has a known private key, an attacker can create certificates that appear to have been issued by that CA. Those certificates could be used to intercept TLS connections through a man-in-the-middle proxy, allowing the traffic to be inspected.

Certificate pinning can help protect mobile applications against this type of attack by allowing an app to trust only specified certificates. Customers using Cryptomathic’s Mobile Application Security Suite, MASC, can configure certificate whitelists within the tool. Find out more about MASC mobile application security.

We encourage other organisations to review their mobile application security posture. Our other articles explore how Astra has been used to attack code obfuscation more efficiently, and why this is increasing the need for runtime application self-protection (RASP) and more advanced security measures.