1931515 - SECOM: Issuance of TLS server certificates using keys previously compromised

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[SECOM Trust Systems - ONO Fumiaki]

Attachment: 20241114-Revoked.txt

Comment 1

[SECOM Trust Systems - ONO Fumiaki]

Preliminary Incident Report

Summary

On 2024-11-13, we were informed by an Application Software Suppliers representative about a mis-issuance of TLS server certificates using compromised keys, in violation of Baseline Requirements, section "6.1.1.3 Subscriber Key Pair Generation" (4).

The following URL lists 19 certificates, of which 9 were valid.
https://crt.sh/?spkisha256=d3b3a2cc0cab970eb9e619bcafa4a852d4ccfde5d928be62105d2ee0b1b9d24e

We have taken the following steps.
In accordance with Baseline Requirements "4.9.5 Time within which CA must process the revocation request", we have started the Certificate Problem Report Process.
Although the contact we received was not the official contact point for the Certificate Problem Report published in CP/CPS and CCADB, we were able to start the investigation within 24 hours because we received the contact on a weekday.
We were able to contact the reporter and a subscriber within 24 hours of receiving the email.
We were also able to revoke valid certificates within 24 hours of confirming the violation.
The 9 valid TLS server certificates were revoked on 2024-11-14.
https://bug1931515.bmoattachments.org/attachment.cgi?id=9437930

We investigated whether there were any other valid certificates with compromised key regarding current CRLs, and we did not find any. So, we did not do additional revocation.

The CA that issued these certificates had a two-tiered mechanism to prevent the use of used public keys.
Compliance officers' understanding was that both of two mechanisms prevented any used public key, and therefore same public key could not be used, regardless of whether it had been compromised or not.
However, upon investigation, it was discovered that the public key check was only performed on past certificates with the same subject DN, so the same key could be used with a different subject DN.

Apart from above mechanism, we implemented an infrastructure mechanism to "prohibit issuance applications using public keys that have been compromised in the past" across our CAs on 2024-11-09.
Currently, that mechanism is prohibiting issuarance of certificates with compromised keys.
The nine revoked certificates were issued before the mechanism was put in place, so we were unable to prevent their issuance.

We will file a full incident report within two weeks.

Comment 2

[SECOM Trust Systems - ONO Fumiaki]

We plan to enhance "the mechanism to prevent the use of used public keys" by 2025-01-31.
As described in Comment 1, we implemented the infrastructure mechanism across CAs to prohibit issuance applications using public keys that have been previously compromised on 2024-11-09.
When a certificate is revoked due to compromise, there is a time lag before it is reflected in the weak key list, so "the mechanism to prevent the use of used public keys" measures can be used to supplement it.

We will prepare an incident report by 2024-11-28.

Comment 3

[SECOM Trust Systems - ONO Fumiaki]

Incident Report

Summary

On 2024-11-13, we were informed by an Application Software Suppliers representative about a mis-issuance of TLS server certificates using compromised keys, in violation of Baseline Requirements, section "6.1.1.3 Subscriber Key Pair Generation" (4).

Subject CA system has functions to restrict the use of used public keys when issuing certificates, but one
of functions was not working as we intended, which caused the misissuance.

Impact

We detected that the same user had issued nine TLS server certificates using the public key of one certificate that had been revoked due to compromise.
Each of the nine certificates had a different DN.
We revoked the nine certificates within 24 hours of their identification.
Our investigation revealed that other than the nine certificates listed above, no other certificates were issued using the public key of the compromised certificate.
The detailed certificate list is provided in the Appendix.

Timeline

All times are UTC.

2020-10-19:

• Baseline Requirements 1.7.3 became Effective. The following was added:
  6.1.1.3 Subscriber Key Pair Generation
  The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1.

2024-02-07:

• 07:21 One certificate was revoked due to being compromised.

2024-02-26:

• 02:12 One certificate was issued using the public key of a certificate that had been revoked for compromise reasons.
  The revoked user and the certificate issuing user were the same.
  After this, a total of seven certificates, including this one, were issued between then and 2024-10-31.
  In addition, two certificates issued with the same public key as the compromised certificate had already been issued on 2024-02-05 and were valid.

2024-11-13

• 13:59 A report about a potential violation of Baseline Requirements was received from a member of the Chrome Root Program Team.
  The contact we received was not the official contact point for the Certificate Problem Report published in CP/CPS and CCADB.

2024-11-14

• 00:30 Our compliance team concluded that it was an Incident in violation of Baseline Requirements.
• 02:30 We informed the subscriber that we were revoking 9 certificates.
• 09:22 We notified the Chrome Root Program Team that we planned to revoke the violating certificate.
• 11:11 Nine certificates were revoked.
• 11:36 We notified the subscriber that the revocation had been completed.

2024-11-15

• 11:24 We posted a Preliminary Incident Report to Bugzilla.
• 21:53 We notified Root Stores individually of the Bugzilla posting.

2024-11-22

• 08:00 We planned to update "the mechanism to prevent the use of used public keys" by 2025-01-31.
• 10:05 We posted the planned update to Bugzilla.

Root Cause Analysis

The CA that issued these certificates had a two-tiered mechanism to prevent the use of used public keys.
[A] Checks at the time of application acceptance
[B] Checks immediately before issuance

Compliance officers' understanding was that both mechanisms prevented any used public key, and therefore the same public key could not be used, regardless of whether it had been compromised or not
(The primary mechanism to prevent reuse is addressed in [A], and there is also a secondary check in [B] to ensure it is doubly enforced.).
However, upon investigation, it was discovered that the public key check was only performed on past certificates with the same subject DN, so the same key could be used with a different subject DN.
The compliance officer should have made the decision based on what was being implemented.
The compliance officer made above judgment with information posted on the QA site for subscribers of that CA, which says, "you can not used keys" without any assumption. However, there were discrepancies with what was actually implemented. The documents (ex: QA site) and policies other than CP/CPS were not clearly understood.

Apart from the above mechanism, we updated an infrastructure mechanism which works across our CAs on 2024-11-09.
(The scope of that infrastructure includes all of our public trusted CA for server-authentication usage)
That update [C] "prohibits issuance for applications using public keys that have been compromised in our infrastructure before" .
Currently, that mechanism [C] is prohibiting issuance of certificates with compromised keys.
However, there is a time lag before the public keys of compromised certificates are reflected in the blocklist [C] and operational difficulties for making it more agile, we are planing to update [A] to cover that time lag with prohibiting reuse of blocked key before it were reflected to blocklist [C].

The nine revoked certificates were issued before the mechanism was put in place, so we were unable to prevent their issuance.

We should have updated [A] or [B], or implemented the [C] system four years ago.
We overlooked and missed 6.1.1.3 of Baseline Requirements v.1.7.3.
At the time, the Compliance Team had not yet been formed.
Our compliance team started in 2021-06.

Lessons Learned

What went well

• We completed the revocation of the erroneously issued certificates within 24 hours.

What didn't go well

• There was a gap between the compliance officers' understanding and implementation, which was one of the reasons for the misissuance. Compliance Officers believed that any reuse was prevented by [A] and [B].

• The compliance officers made above judgment with information posted on the QA site for subscrivres, but there were discrepancies with what was actually implemented. The documents (ex: QA site) and policies other than CP/CPS were not clearly understood.

Where we got lucky

• Although there will be a time lag before the public keys of compromised certificates are reflected in the blocklist, issuance will be suppressed from 2024-11-09 onwards.

• The CA's system searched for previously issued certificates with the same DN, checked the public keys, and prevented their use. On the other hand, most of subscribers seems to recognized that any reuse of the same keys are prohibition from QA site. As a result, number of requests with public keys which had been compromised was very limited.

Action Items

Action Item	Kind	Due Date
Update the mechanism [A] to prevent the reuse of previously used public keys	Prevent	2025-01-31
Organize documents and policies other than those defined in CP/CPS, and confirm implementations	Prevent	2024-12-27

Appendix

Details of affected certificates

Here is a list of 9 certificates.
https://bug1931515.bmoattachments.org/attachment.cgi?id=9437930

Comment 4

[SECOM Trust Systems - ONO Fumiaki]

No updates.

Comment 5

[SECOM Trust Systems - ONO Fumiaki]

Both Action Items have been completed.

Action Items

Action Item	Kind	Due Date
Update the mechanism [A] to prevent the reuse of previously used public keys	Prevent	Completed
Organize documents and policies other than those defined in CP/CPS, and confirm implementations	Prevent	Completed

We have completed the ”Update the mechanism [A] to prevent the reuse of previously used public keys” ahead of the target deadline on 2024-12-25, which is earlier than the initial target of 2025-01-31.

By checking the documents and policies other than those defined in CP/CPS and implementation of the application, we have confirmed that there is no discrepancy between the compliance officers' understanding and implementation.　
This is not limited to the following, but to be specific, let us provide you with five points.

1. We are using a linting tool specialized in the alphabetic representation of Japanese proper nouns.

2. The validity period is a maximum of 397 days or less, but it is issued for a maximum of 396 days (plus one second).

3. Some CAs that reuse organizational validation information have an option to check the WHOIS organization name each time before issuing a TLS server certificate.

4. The prohibition of RSA key reuse is determined not by exact key match, but by both the hash value of the modules and the key length matching.

5. To prevent phishing fraud, requests that include the names of financial institutions are controlled separately.

Incident Report Closure Summary

• Incident Description:
  A mis-issuance of TLS server certificates using compromised keys, in violation of Baseline Requirements, section "6.1.1.3 Subscriber Key Pair Generation" (4).
  Subject CA system has functions to restrict the use of used public keys when issuing certificates, but one of functions was not working as we intended, which caused the misissuance.

• Incident Root Cause(s):
  Compliance officers' understanding was that both of two mechanisms prevented any used public key, and therefore same public key could not be used, regardless of whether it had been compromised or not.
  However, upon investigation, it was discovered that the public key check was only performed on past certificates with the same subject DN, so the same key could be used with a different subject DN.
  The compliance officer should have made the decision based on what was being implemented.

• Remediation Description:
  Updated the mechanism [A] to prevent the reuse of previously used public keys.
  When a certificate is revoked due to compromise, there is a time lag before it is reflected in the weak key list, so "the mechanism [A] to prevent the reuse of previously used public keys" measures can be used to supplement it.

• Commitment Summary:
  We have implemented the infrastructure mechanism across CAs to prohibit issuance applications using public keys that have been previously compromised on 2024-11-09.
  In terms of measures can be used to supplement, we have completed the “Update the mechanism [A] to prevent the reuse of previously used public keys” on 2024-12-25.
  We will continue to organize documents and policies other than those defined in CP/CPS and confirm their implementations on a regular basis.

We would like to note that next week marks Japan's year-end and New Year holidays.
Responses may be delayed except in emergencies from December 28, 2024, to January 5, 2025.

Comment 6

[Ben Wilson]

I intend to close this on or about Thursday, 2-Jan-2025, unless there are additional issues or questions to discuss.