1535509 - HARICA: Insufficient serial number entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Dimitris Zacharopoulos]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Comment 1

[Dimitris Zacharopoulos]

Attachment: [e-mail]

Comment 2

[Dimitris Zacharopoulos]

Attachment: [e-mail]

Comment 3

[Dimitris Zacharopoulos]

Attachment: [e-mail]

Comment 4

[Dimitris Zacharopoulos]

Attachment: [e-mail]

Comment 5

[Dimitris Zacharopoulos]

Attachment: Incident Report for Mozilla Mar 2019 interim.pdf

CA/B Forum Baseline Requirements section 7.1 and Mozilla Policy section 5.2 requires serial numbers to include at least 64 bits of entropy from a CSPRNG.

“CAs MUST maintain current best practices to prevent algorithm attacks against certificates. As such, all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG”.

HARICA uses EJBCA CA software since May 9th 2018. EJBCA uses a default configuration that sets the size of the serial number to 8 bytes resulting in serial numbers with 64 bits. The public discussion in Mozilla-dev-security-policy mailing list (m.d.s.p.) revealed that because the serial number must be a positive number, which means the first bit must be zero, EJBCA effectively uses 63 truly random bits and not 64.

HARICA monitored the discussion in m.d.s.p. and detected that the configuration on EJBCA was using the default values for serial number size, even though this was identified as a compliance issue before migrating to EJBCA in March 2018. The investigation revealed that HARICA had evaluated the results of ballot 164 (that added the current language of section 7.1) and modified in July 2016 the custom -at-the-time- CA software to include 96 bits in the serial numbers of end-entity Certificates, exceeding the requirement of 64 bits. When HARICA migrated to EJBCA on May 9th 2018, it verified that the issued certificates used 64 bit serial numbers that seemed compliant with the requirements of BRs section 7.1. HARICA did not analyze the actual CA software code to evaluate the algorithm that the software vendor used to produce the serial numbers in order to reveal the fact that the first bit of replaced by a zero, thus effectively using 63 bits of entropy. This resulted in issuing certificates with a non-compliant serial number between 2018-05-04 and 2019-03-05.

A full certificate database scan was conducted and revealed that 461 SSL/TLS, 4157 S/MIME and 15 CA Certificates (unexpired and unrevoked) had improper serial numbers. In addition to these, 2 SSL/TLS and 62 S/MIME Certificates that had compliant serial numbers but were issued from a CA with improper serial number, are affected by this incident.

Mitigation measures to minimize the risk of re-occurrence have been identified and a timeline of the implementation is under discussion. More details in section 2.7 of this report.

The problematic SSL/TLS Certificates are planned to be revoked by March 16th, 2019 according to the revocation timeline of SSL/TLS Certificates mandated in the Baseline Requirements.

The problematic CA Certificates capable of issuing SSL/TLS Certificates are planned to be revoked by March 18th, 2019 (along with the compliant end-entity certificates that were issued by these CAs), according to the revocation timeline of SSL/TLS Certificates mandated in the Baseline Requirements.

Please let us know if you have any further questions or concerns about this incident.

Sincerely,

Dimitris Zacharopoulos.
PKI Manager

Comment 6

[Dimitris Zacharopoulos]

Attachment: Incident Report for Mozilla Mar 2019 interim v1.1.pdf

Correction in the executive summary:

"The investigation revealed that HARICA had evaluated the results of ballot 164 (that added the current language of section 7.1) and modified in May 2017 the custom -at-the-time- CA software to include 127 bits in the serial numbers of end-entity Certificates, exceeding the requirement of 64 bits."

Comment 7

[Dimitris Zacharopoulos]

Attachment: Incident Report for Mozilla Mar 2019 final v1.2.pdf

All scheduled revocations were performed as planned. The attached final version of the report includes this information.

Comment 8

[Wayne Thayer]

It appears that remediation is complete.