eMudhra exits TLS business after weak keys found

Certificate authority eMudhra is exiting the global SSL/TLS market after researchers discovered the company issued eight intermediate certificates with private encryption keys so weak they could be cracked in milliseconds. The India-based firm generated just 1 percent of its revenue from the business, while facing mounting compliance costs and intense competition from free certificate providers.

Defective Keys And Cryptographic Entropy

NIST P-384 elliptic curve cryptography private keys are supposed to contain roughly 384 bits of entropy. However, the eight compromised certificates issued by eMudhra featured key sizes ranging from 3 to 8 bits. This reduction meant the strongest defective key had a maximum of 256 possibilities, compared to the 2384—a number with 116 digits—expected from potential combinations.

Researchers found that anyone taking the time—which was measured in milliseconds—could crack them. The resulting credentials could then be used to generate TLS certificates trusted by major browsers, email servers, IoT devices, Docker containers, forgotten Linux machines, and unmaintained CLI tools.

Compliance Costs And Social Media Scrutiny

V. Srinivasan, chairman of eMudhra Limited, pointed to rising compliance expenses and low returns as primary factors behind the exit. The availability of free TLS certificates from competing organizations further eroded the company’s return on investment compared to its other products and services.

However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business,” the company continued in a Thursday post. “In view of this, after detailed deliberations our board has concluded that withdrawing from global SSL/TLS is the right decision for eMudhra and its shareholders.

eMudhra

Board Decision Follows Disclosures

The board’s formal withdrawal announcement arrived two days after security researchers revealed the cryptographic flaws in the eight intermediate credentials. The specific private keys identified in the incident were 4, 56, 66, 115, 155, 156, 230, and 237.