More than a million trusted digital certificates were issued erroneously by the likes of Google, Apple, GoDaddy, and several other certificate authorities recently. While the erroneously-issued certificates do not present any security issues, revoking all of them and issuing fresh certificates could take over a month.
According to the Baseline Requirements for certificate-issuing authorities, trusted certificates issued by authorities cannot have serial numbers of fewer than 64 bits. To abide by this requirement, all certificate authorities use specialised software to generate trusted certificates with 64-bit or 72-bit encryption.
However, there is another baseline requirement that needs to be adhered to by all certificate issuers- that serial numbers assigned to each certificate by an issuer "MUST be a positive integer" and must be unique for each certificate.
To adhere to this requirement, the open-source EJBCA software, which is used by many certificate authorities to generate trusted certificates, has been modified to use 0 as the 64th bit, using random numbers to fill up the remaining 63 slots.
According to Adam Caudill, a director of Application Security Testing, researcher and software developer, thanks to the modification, trusted certificates generated using EJBCA always give 63 effective bits of output, thereby violating the very baseline requirement it intended to fulfill.
The use of 63 effective bits also reduces the number of possible values by half considering that the difference between 2^64 and 2^63 is over 9 quintillion, says Caudill, but despite that, trusted certificates in the SHA2 family have no known vulnerabilities that could be exploited and they still have 63-bits of encryption which is still quite substantial.
"Entropy in the serial number is required as a way to prevent hash collisions from being used to forge certificates; this requires an ability to predict or control certificate contents and the use of a flawed hashing algorithm, adding a random value makes this more difficult.
"This type of issue has been exploited with MD5, and could someday be exploited with SHA1; there’s no known flaws in the SHA2 family (used in all current end-entity certificates) that would allow such an attack. In addition, while due to this issue, the level of protection is reduced by half, 2^63 is still a large number and provides a substantial amount of safety margin," he wrote in a blog post.
Even though the risk factor is minimal, certificate issuers such as Google, Apple, and GoDaddy have to revoke a little over a million certificates issued using the EJBCA software as the 63-bit outcome is in violation of baseline requirements.
According to yet another Baseline Requirement, if a certificate is not in accordance with baseline requirements or the CA's Certificate Policy, it has to be revoked within five days. Abiding by this rule would involve all certificate issuers revoking over a million certificates within five days which is a next-to-impossible task.
"Google was able to revoke approximately 95 percent if their mis-issued certificates within the five days, Apple announced that they wouldn’t be able to complete the process within five days, and GoDaddy stated that they would need 30 days to complete the process.
"The same reason was cited by all three: minimising impact. Without robust automation, changing certificates can be complex and time-consuming, leaving the CA to choose between complying with requirements or impacting their customers," Caudill added.
Commenting on the erroneous issuance of over a million trusted certificates, Kevin Bocek, VP of Security Strategy and Threat Intelligence at Venafi told SC Magazine UK that replacing a single digital certificate can take hours and most firms don’t have automated processes in place to replace large numbers of them when problems like this occur. As a result, many businesses are going to feel a lot of pain.
"Even worse, if the replacement process isn’t completed by experts it’s very error-prone, and the ‘cure’ can introduce new vulnerabilities or cause business systems to fail. This is a huge third party risk that CISOs and board members don’t understand," he added.