STE WILLIAMS

A bunfight over a controversial UAE mobile security company led to the discovery that millions of TLS security certificates had been improperly issued – thanks to a dodgy default configuration in popular certificate authority (CA) key-generation software.

During a discussion on the mozilla.dev.security.policy group about Darkmatter’s application to become a fully fledged cert-issuing CA, netizens discovered that the company’s supposedly 64-bit certificate serial numbers were in fact one bit short, the top bit being always zero to indicate a positive integer. After other companies read the thread, they realised their own certificates were similarly affected.

The most l33t phone of MWC: DarkMatter’s Katim

READ MORE

The UAE firm is in the spotlight due to a January report by newswire Reuters alleging its involvement in state-backed hacking efforts, which it has denied. The report subsequently drew the attention of Firefox browser-maker Mozilla and prompted the Moz dev chatter.

Security researcher Adam Caudill summarised the problem in a blog post earlier this month: “During an analysis of certificates issued by DarkMatter, it was found that they all had a length of exactly 64 bits – not more, not less.”

As he explained, RFC 5280, which, among other things, governs the format of public key certificates, states that certificate serial numbers must be a “positive integer” of at least 64 bits and absolutely cannot be a negative number. However, in Caudill’s words: “Requiring a positive integer means that the high [order] bit can’t be set – if it is set, it can’t be used directly as a certificate serial number.”

In this implementation, the high order bit denotes whether the number is positive or negative. It must be zero to be a positive number, due the way the integer is stored using two’s complement. And seeing as it must be a positive integer, this top bit is always zero, reducing the effective length to 63 bits.

Caudrill speculated that Darkmatter may have used a particular open-source key-generation package, EJBCA, which defaults to outputting 64-bit certificate serial numbers from a random-number generator, with the top bit clear. This dramatically reduces the number of possible serial numbers. There is nothing to stop CAs using longer serial numbers, it’s just the default is misleading.

D’OH-fault settings

A recent MDSP mailing list response by SSL.com’s Fotis Loukos, its director of RD, as reproduced by Mozilla CA program manager Wayne Thayer here, suggested that EJBCA’s default settings may have been responsible for lulling CAs into a false sense of security. Ouch.

“EJBCA’s method of generating serial numbers has led to a discrepancy between expected and actual behavior and output, such that any CA using EJBCA with the default settings will encounter this issue,” he posted, noting that this would put those CAs into breach of Baseline Requirement 7.1, which is the CA rule (PDF, 65 pages) that states all certificate keys must have at least 64 bits of output from a cryptographically secure pseudo-random number generator (CSPRNG).

Other responses from Apple, Google and others shed light on the practical impact.

Apple admitted it had issued a total of 878,000 non-compliant TLS certificates, of which 558,000 were still in use five days ago, as well as 2,000 S/MIME certs. In a timeline appended to its report yesterday, it said that in April 2017 it had “mistakenly suppressed alerts detecting serial numbers suspected to be insufficient in length,” before starting to revoke the affected certificates last week.

Google Trust Services, the adtech monolith’s certificates arm, did not spell out precisely how many non-compliant certificates it had issued but did say that it comprised all certificates that its Google Internet Authority G3 trust chain issued between 30 September 2016 and 28 February this year.

GoDaddy was similarly affected from 2016 onward, according to its response, having issued a total of 285,936 non-compliant certificates, of which 12,152 are still live. It scaled this down from its original estimate of 1.8 million non-compliant certificates, adding: “We are looking to scope and roadmap upgrading our certificate serial number to a minimum of 128-bit, or the max possible.”

The controversy over Darkmatter continues. While the key security issue is largely theoretical – 63 bits is plenty of entropy against cryptographical attack, even if it’s not compliant with the spec – CAs will continue to have a minor headache as they identify, revoke and reissue affected certs. ®

Sponsored:
Becoming a Pragmatic Security Leader

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/03/13/63_bit_tls_cert_revoke_ejbca_config/