Eight web security keys of eMudhra firm used by Govt. and PSUs leaked

Eight private keys belonging to eMudhra, a certificate authority, were leaked or exposed. They were used to issue intermediate certificates, which help establish trust for website security certificates. The flaw mattered because private keys must remain secret. Anyone who obtains one may be able to impersonate a trusted certificate issuer.

The weak keys were not genuinely random 384-bit secrets. Instead, they contained numbers between 1 and 256. One key was simply the number 4, preceded by 383 zeroes. That made the keys trivial to infer, according to Dennis Jackson. Six affected certificates were for TLS and trusted by Chrome, Mozilla, Microsoft, and Apple root programs.

The affected certificates were revoked, and browser and root-store operators moved to stop trusting them. eMudhra said only one intermediate CA had been deployed in production, and none had issued end-entity certificates. The incident still matters because unpatched devices could retain outdated trust.

An intermediate certificate authority, or intermediate CA, sits below a root certificate authority in the trust structure used by web browsers. It is allowed to issue or sign certificates for websites and other services. This layered design lets a root authority delegate certificate issuance without using its own root key for every website.

When a website presents its certificate, the browser checks the certificate chain. The chain can lead from the website’s end-entity certificate to an intermediate CA and then to a trusted root CA. If the signatures and other checks succeed, the browser can accept the site’s identity for a secure connection. The article identifies eMudhra’s leaked keys as belonging to intermediate certificates.

This incident showed why intermediate keys must be protected. eMudhra said none of the affected intermediate CAs had issued end-entity certificates. However, one had been deployed in production, so browser and root-store operators still removed trust from the affected certificates.

The incident involved eight private keys used to issue web security certificates. Dennis Jackson said six of the impacted certificates were for TLS and trusted by the Chrome, Mozilla, Microsoft, and Apple root programs. The article does not give a separate total for all certificates beyond describing the eight affected keys and certificates.

The intended private keys were 384-bit values. Instead, the weak keys contained numerical values between 1 and 256. That is an extremely small possible range compared with the enormous range of values available to a proper 384-bit private key. The article describes the weak keys as orders of magnitude easier to infer. One key was the number 4 followed by 383 zeroes.

The weakness came from eMudhra’s key-generation ceremony. The company said a wrap/unwrap step produced a second set of weak keys alongside the original strong keys. The weak set, rather than the strong set, was published to browser root stores.

A private key is the secret that allows a certificate authority to sign certificates. If an attacker obtains a trusted intermediate CA’s private key, the attacker may be able to create certificates that appear to come from that authority. Browsers could then treat a fraudulent website certificate as part of a trusted chain.

For example, an attacker might create a certificate for a government portal or another familiar domain and use it on an impostor site. A browser checking the certificate chain could see a valid-looking signature from the compromised intermediate authority. The article does not report that such fraudulent end-entity certificates were issued, but it explains why the weak keys were considered trivial to exploit.

The response was to revoke the affected certificates and remove browser trust. eMudhra said none of the affected intermediate CAs had issued end-entity certificates, a claim supported by Certificate Transparency records. Risk could remain for devices and software that are not updated promptly.

Browsers and operating systems maintain collections of trusted root certificates, often called root stores. Their root programs and root-store operators decide which certificate authorities can anchor trusted certificate chains. These organizations assess incidents and can remove or disable trust when a certificate authority’s keys or practices are compromised.

In this case, Dennis Jackson said six affected TLS certificates were trusted by the Chrome, Mozilla, Microsoft, and Apple root programs. Those programs, along with other internet infrastructure firms, responded by patching systems or changing trust settings. eMudhra also worked with browser and root-store operators after discovering the problem.

The article also identifies India’s Controller of Certifying Authorities as a regulator of Indian certificate authorities, under MeitY. That is a different role from deciding global browser trust. The CCA regulates Indian certificate authorities, while browser and operating-system programs determine whether their certificates are trusted by users.

Browser patches can remove trust from compromised certificates on current computers and phones. They do not automatically update every device connected to the internet. Many IoT products, embedded systems, and older software receive updates rarely, or cannot be updated easily after deployment.

Yash Kakadia warned that the cleanup could be enormous for devices and software that cannot be easily updated. A device might retain an old certificate store even after browsers and operating systems have blocked the affected eMudhra certificates. It could therefore continue accepting a certificate that newer systems reject.

The article does not report exploitation on IoT devices. It identifies the risk as a forward-looking concern. eMudhra said none of the affected intermediate CAs had issued end-entity certificates, but the incident still shows that certificate compromise requires more than a browser fix. Operators may need to update devices, software, and trust stores across long-lived systems.

Public-key cryptography uses a mathematically related key pair. The private key must remain secret, while the matching public key can be shared. In HTTPS, a website’s certificate contains its public key and identifies the website. A trusted certificate authority signs that information to support the identity claim.

During a secure connection, the browser verifies the certificate chain and the authority’s digital signature using public information. The website then uses its private key in the connection’s authentication process. Because only the legitimate holder should know that private key, a successful proof helps show that the website controls the certificate. The secret key itself is not sent to the browser.

The eMudhra incident threatened this model because some intermediate private keys were predictable. Public-key cryptography depends on private keys staying unknown to outside entities under all circumstances. eMudhra revoked the affected certificates, and browser operators moved to stop trusting them.