Last month we could read about the revocation of millions of SSL/TLS certificates. What could cause this incident in the PKI industry? This segment is particularly famous for the numerous requirements and regulations which are strictly enforced.
A Certificate Authority from the United Arab Emirates applying for an inclusion to Mozilla’s Root Store. As part of the inclusion request process experts discussed the issues that arose at one of Mozilla’s mailing lists named dev-security-policy. In this case political and security concerns come up and it generated a huge debate on the mailing list. This topic was really active for over a month with 161 replies and it also created many related topics as well.
The starting point of the issue was when Corey Bonnel pointed out 235 unique DarkMatter certificates had been mis-issued on 02.22.2019.
Those certificates do not meet the requirements in the Baseline Requirements, section 7.1. “CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.”
This means you have to generate positive numbers, so the leading bit has to be a 0, then it has to be followed by at least 64 bits generated by a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) tool. Also the RFC 5280 specifies the serial number must be no longer than 20 octets.
On 02.25.2019 Scott Rea who is DarkMatter’s representative gave a detailed answer about how they manage their serial number generation. They use the EJBCA which is an Open Source PKI Certificate Authority software. This tool had a default option for the CSPRNG generation which is exactly 64 bits, but it turned out it uses a bit for the positive number representation so it only has a 63-bit entropy.
On 03.02.2019 Ryan Hurst, Google’s representative wrote: "EJBCA serial number generation logic stood out to us". After this topic many more CAs started reviewing their serial number generation processes and those who use the EJBCA’s CSPRNG feature with the default option have to face the same certificate mis-issuance problem.
When the entropy requirement was added to the BRs, there was a proof of concept about a collision attack against MD5 hash algorithms. Nowadays SHA-2 algorithms are typically used and they are not vulnerable to collision attacks but the entropy is still in the serial numbers as a preventive measure.
The difference between 63 and 64 bits is 9,223,372,036,854,775,808. The 2^63 is still an incredibly high number and this 1 bit difference does not mean a security issue, but it violates the Baseline Requirements. A CA has to revoke its mis-issued certificates within 5 days (Section 22.214.171.124 of the CA/Browser Forum’s Baseline Requirements).
The preliminary analysis showed an enormous amount of involved certificates (millions), but some of them had already expired or had been revoked. It is still a huge amount of mis-issued certificates. The situation is also shaded by whom the certificate was issued to. If it is for internal use then it can be replaced more quickly than a certificate issued to an external customer. The affected CAs still had a lot to do and some of them indicated in advance — in their incident report — they will not be able to accomplish the revocations within 5 days, they are expected to take about 30 days to handle the revocation and the re-issuance.
The EJBCA has already released an update for this entropy issue. The default value of the entropy:
Here you can check the incident reports of the concerned CAs.
Rob Stradling made a spreadsheet which contains every CA that is trusted by Mozilla and issued at least one certificate which has a serial number smaller than 64 bit. When the value in the column E is 100, it means there is a high probability of noncompliance with BR 7.1.
So what caused this non-compliance? One side was that the requirements were only met at the absolute minimum level. The other side was a 3rd party tool that had a logical issue and it is interesting how many CAs used it for a long time.
Although this problem did not pose a security risk, several CAs were unable to solve the effects of the problem in the required time.
I look forward to seeing the conclusion drawn after the problem has been solved and of course what will happen to the inclusion request.
The Mozilla dev-sec-policy mailing list: https://lists.mozilla.org/listinfo/dev-security-policy
CA-Browser Forum Baseline Requirements: https://cabforum.org/baseline-requirements-documents/
© 2020 Microsec Ltd. | Company registration number: 01-10-047218 | Tax number: 23584497-2-41