Bulletproof TLS Newsletter #51
Trouble with a missing random bit in serial numbers
28 March 2019
Author: Hanno Böck

This issue was distributed to 49,816 email subscribers.

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space.

In this issue:

  1. Trouble with a missing random bit in serial numbers
  2. Short news

Trouble with a missing random bit in serial numbers

A seemingly minor issue is the cause of major trouble in the certificate industry: many certificate authorities have used serial numbers with sixty-three bits of entropy for their certificates, yet the Baseline Requirements say that they need sixty-four bits.

Originally this issue was discovered in certificates from the DarkMatter certificate authority based in the United Arab Emirates. As we reported last month, DarkMatter is controversial due to a report released by Reuters. Adam Caudrill was the first to make the issue public to a wider audience via a blog post.

The issue itself is subtle. The Baseline Requirements say that certificate serial numbers need to have sixty-four bits of entropy. The affected certificates use sixty-four-bit integer numbers, but an integer number can be negative, and the Baseline Requirements also say that certificate serial numbers need to be positive. This means that negative numbers are discarded, so effectively these certificates have a random sixty-three-bit serial number.

It turned out that this behavior was the default in EJBCA, free software for certificate authorities. Many certificate authorities use EJBCA, and thus a large number of certificates are affected by the same issue. In the past weeks, more and more certificate authorities came forward and sent reports to Mozilla’s security policy mailing list about this issue.

From a security perspective, the issue is almost meaningless. The entropy requirement was introduced due to attacks that became possible with the use of weak hash functions. A collision attack in MD5 allowed researchers to forge a certificate, as explained in a talk the researchers gave at the Chaos Communication Congress in 2008. This attack relied on the fact that the targeted certificate authority used sequential serial numbers for certificates, which meant the researchers were able to guess the most likely serial number for a certificate.

Such attacks are only possible with hash functions that are cryptographically broken and don’t provide collision resistance. Given that the weak hash functions MD5 and SHA1 are already deprecated in the certificate ecosystem, there’s little concern. The entropy requirement is still a useful defense-in-depth mechanism in case the modern hash function SHA256 turns out to have similar weaknesses in the future, but it seems unlikely to matter in practice. Even if there was a similar weakness, sixty-three bits are still enough to make such an attack almost certainly impossible.

But the Baseline Requirements have mechanisms that say that certificates violating the rules must be revoked, whether or not there’s a practical security risk. Many people in the TLS community are unwilling to endorse a lax handling of existing rules because doing so may create a bad precedent for other, more serious violations.

The Baseline Requirements demand a revocation of certificates violating the rules within five days of discovery. This window has already passed for many of the affected certificate authorities. It will be a challenge for them to inform their customers and replace all the affected certificates.

Short news