1539307 - Buypass: Insufficient Serial Number Entropy

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Mads Henriksveen posted the following incident report to the mozilla.dev.security.policy list:

This is an incident report for two intermediate certificates issued by Buypass in December 2016 noncompliant with BR 7.1.

===How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We were following a discussion on mozilla.dev.security.policy (MDSP). On March 18th a list of CAs noncompliant with the entropy requirement in BR 7.1 was published and two Root CAs from Buypass was included. We became aware of this on March 21st and sent immediately a Pre-Incident Report to MDSP [1].

===A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

We did some analyses and identified that we had issued two intermediate CA certificates on December 2nd 2016 without the required entropy in the certificate serial number. At this point in time, the application software on our offline Root CA system did not support the inclusion of random values in the certificate serial number.

===Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The application software on our offline Root CA system was later updated with support for random values in certificate serial numbers. No more intermediate certificates was issued in the meantime and we have since then not issued any certificates noncompliant with BR 7.1 on the offline Root CA system.

===A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Two intermediate certificates were issued December 2nd 2016. The intermediate certificates are used for CAs issuing TLS certificates, i.e. Buypass Class 2 CA 2 and Buypass Class 3 CA 2.

===The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

The two certificates are:

•      Buypass Class 2 CA 2 - https://crt.sh/?id=76748940
  

•      Buypass Class 2 CA 3 - https://crt.sh/?id=76740810
  

===Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

This entropy requirement was effective from September 30th 2016. At this point in time we were not very concerned about the risk of using certificate serial numbers with low entropy in certificates issued in our Root CA system [2]. The Root CA system is operated offline/airgapped in a strictly controlled environment by three security officers. Therefore, we focused on implementing support for the entropy requirement in Subscriber certificates. At the time we issued the intermediate certificates, in December 2016, our Root CA system did not yet support random values in the certificate serial number.

===List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

The following actions has been taken:

•      On March 25th we issued two new intermediate certificates for the affected CAs with certificate serial numbers compliant with BR 7.1 on the offline Root CA system
  

•      These certificates replaces the two affected intermediate certificates and are distributed to our customers together with all new TLS certificates issued after March 25th
  

We have identified the next actions to be taken:

•      We will communicate with existing customers and advise them to replace the affected intermediate certificates with the new intermediates
  

•      We will revoke the affected intermediate certificates when the risk of introducing any main issues to our customers are considered to be acceptable
  

The offline Root CA system used has been updated and it will not be possible to issue certificates noncompliant with BR 7.1 in the future.

Comment 1

[Mads Henriksveen]

We have contacted all our customers using our managed PKI solution and advised them to replace the intermediate certificates.

Comment 2

[Wayne Thayer]

Mads: what is the expected timing for having the affected intermediates replaced, and then eventually having them revoked?

Comment 3

[Ryan Sleevi]

Mads: Can you also provide information about what software your offline Root CA system runs? Can you also explain further what it means by

At this point in time, the application software on our offline Root CA system did not support the inclusion of random values in the certificate serial number.

Comment 4

[Mads Henriksveen]

(In reply to Wayne Thayer [:wayne] from comment #2)

Mads: what is the expected timing for having the affected intermediates replaced, and then eventually having them revoked?

We have advised our customers to replace the intermediate certificates immediately. However, we have not yet set an explicit deadline for our customers. We will have an internal discussion and define a deadline and timeline for the next steps tomorrow (Monday). We intend to revoke the affected intermediate certificates based on this timeline.

I will be able to provide some more details tomorrow.

Comment 5

[Mads Henriksveen]

(In reply to Ryan Sleevi from comment #3)

Mads: Can you also provide information about what software your offline Root CA system runs? Can you also explain further what it means by

At this point in time, the application software on our offline Root CA system did not support the inclusion of random values in the certificate serial number.

Buypass develops most of its software in house, this includes the application software on the offline Root CA system.

The application software of the Root CA system was not updated with support for the required entropy at the time we performed the ceremony in December 2016. The offline Root CA system is usually locked down and updates of application software must be planned and performed either in conjunction with a ceremony or as a separate update ceremony. Unfortunately this was not done before we had this ceremony. The application software on the offline system is based on the same code as we use for our "online systems". The support for required entropy was implemented in our online systems, but not updated in the offline Root CA system at this point in time.

Comment 6

[Mads Henriksveen]

(In reply to Mads Henriksveen from comment #4)

(In reply to Wayne Thayer [:wayne] from comment #2)

Mads: what is the expected timing for having the affected intermediates replaced, and then eventually having them revoked?

We have advised our customers to replace the intermediate certificates immediately. However, we have not yet set an explicit deadline for our customers. We will have an internal discussion and define a deadline and timeline for the next steps tomorrow (Monday). We intend to revoke the affected intermediate certificates based on this timeline.

I will be able to provide some more details tomorrow.

We have set May 15th as a deadline for our customers to replace the intermediate certificates. We will revoke the certificates shortly after.

Comment 7

[Mads Henriksveen]

We have reached out to all our customers and asked them to replace the intermediate certificates before the deadline. As of today (May 15th) we see that more than 90% of our customers has updated the intermediate certificates, but as there still is a lot of customers and websites vulnerable to a revocation of the affected intermediate certificates, we have decided not to revoke them immediately. We have not yet set the final date for revocation of the intermediate certificates, but this will be no later than end of June 2019. This will give our customers some more time and hopefully reduce the risk of introducing any main issues for affected customers to an acceptable level.

Comment 8

[Mads Henriksveen]

We revoked the two affected intermediate certificates yesterday, Thursday 27-June 2019.

Comment 9

[Wayne Thayer]

It appears that remediation has been completed.