Certificate Incident

[sanja...@symantec.com]

On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1 certificates in support of one customer’s application to submit SHA-1 TBS Certificates to the CA/B Forum for a SHA-1 exception. Symantec has revoked the certificates. An internal process review is underway.

All signed by VeriSign Class 3 International Server CA - G3, the serial numbers of the certificates are as follows:

7d:62:b4:8f:f5:62:f2:f3:56:83:75:40:1a:37:34:db
51:41:55:dd:2d:9c:52:27:4e:3a:fe:c4:48:de:b9:36
6f:34:f0:d2:ea:b4:e5:35:18:10:64:bd:f1:b8:74:5b
1a:d5:d4:56:88:e1:c0:e4:e4:69:0e:1b:4c:a6:e5:11
05:8c:84:5f:66:f9:f8:af:a6:c8:02:11:ed:e5:da:45
54:dd:b2:78:57:b1:c9:78:cf:7f:7e:1f:1c:69:9b:86
03:d1:8f:29:0f:23:bf:da:08:c5:fc:22:3b:2e:ea:c5
27:62:da:fa:af:89:39:44:4d:5a:45:fa:d0:e3:f6:95


Sanjay Modi
Symantec

[Andrew Ayer]

On Wed, 13 Jul 2016 20:02:58 -0700 (PDT)
sanja...@symantec.com wrote:

> On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1
> certificates in support of one customer’s application to submit SHA-1
> TBS Certificates to the CA/B Forum for a SHA-1 exception. Symantec
> has revoked the certificates.

Revocation does not address the risk that this mis-issuance has caused
to the ecosystem, since collided certificates (the ones we cannot see,
and need to be worried about) have different serial numbers and
therefore do not appear revoked.

To help the community assess the risk of these certificates, can you
please describe how the key pairs certified by these certificates were
generated, who generated them, and when they were generated? Have the
key pairs been used previously?

Regards,
Andrew

[Rob Stradling]

On 14/07/16 05:17, Andrew Ayer wrote:
> Have the key pairs been used previously?

Hi Andrew.

All 8 of these SHA-1 precertificates are known to CT and crt.sh. The
same 8 public keys appear in a further 8 SHA-256 precertificates that
were issued 5 days earlier by a different Symantec issuing CA.

7d:62:b4:8f:f5:62:f2:f3:56:83:75:40:1a:37:34:db

https://crt.sh/?id=24445566
- same key as https://crt.sh/?id=24120938

51:41:55:dd:2d:9c:52:27:4e:3a:fe:c4:48:de:b9:36

https://crt.sh/?id=24445529
- same key as https://crt.sh/?id=24120937

6f:34:f0:d2:ea:b4:e5:35:18:10:64:bd:f1:b8:74:5b

https://crt.sh/?id=24445614
- same key as https://crt.sh/?id=24120934

1a:d5:d4:56:88:e1:c0:e4:e4:69:0e:1b:4c:a6:e5:11

https://crt.sh/?id=24445598
- same key as https://crt.sh/?id=24120932

05:8c:84:5f:66:f9:f8:af:a6:c8:02:11:ed:e5:da:45

https://crt.sh/?id=24445656
- same key as https://crt.sh/?id=24120929

54:dd:b2:78:57:b1:c9:78:cf:7f:7e:1f:1c:69:9b:86

https://crt.sh/?id=24445643
- same key as https://crt.sh/?id=24120928

03:d1:8f:29:0f:23:bf:da:08:c5:fc:22:3b:2e:ea:c5

https://crt.sh/?id=24445695
- same key as https://crt.sh/?id=24120926

27:62:da:fa:af:89:39:44:4d:5a:45:fa:d0:e3:f6:95

https://crt.sh/?id=24445682
- same key as https://crt.sh/?id=24120923

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Nick Lamb]

On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:
> Revocation does not address the risk that this mis-issuance has caused
> to the ecosystem, since collided certificates (the ones we cannot see,
> and need to be worried about) have different serial numbers and
> therefore do not appear revoked.

Unless I'm missing something if Symantec produced these certificates in a sensible way, any potential attacker outside Symantec (including TSYS) will not have known the serial numbers of the certificates in advance of their being produced, let alone been able to choose them. Without knowing the serial numbers in advance there is no way to perform the MD-style chosen prefix collision attack on SHA-1 that I can see. Do you suppose that attackers might have a pre-image attack instead?

[Kathleen Wilson]

Added to OneCRL...
https://bugzilla.mozilla.org/show_bug.cgi?id=1286752

Kathleen

[Andrew Ayer]

On Thu, 14 Jul 2016 02:52:41 -0700 (PDT)
Nick Lamb <tiala...@gmail.com> wrote:

> On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:

> > Revocation does not address the risk that this mis-issuance has
> > caused to the ecosystem, since collided certificates (the ones we
> > cannot see, and need to be worried about) have different serial
> > numbers and therefore do not appear revoked.
>

> Unless I'm missing something if Symantec produced these certificates
> in a sensible way, any potential attacker outside Symantec (including
> TSYS) will not have known the serial numbers of the certificates in
> advance of their being produced, let alone been able to choose them.
> Without knowing the serial numbers in advance there is no way to
> perform the MD-style chosen prefix collision attack on SHA-1 that I
> can see. Do you suppose that attackers might have a pre-image attack
> instead?

I'm concerned about collision attacks. A truly unpredictable serial
number does prevent chosen prefix attacks, but Mozilla and the other root
store operators have decided that the correct way to deal with collision
attacks is to deprecate the hash algorithm instead of relying on serial
number entropy. This is the prudent approach. Cryptographically-secure
random number generation is easy to get wrong, and mistakes are hard to
spot. Symantec's CPS only guarantees 20 bits of entropy, which provides
a poor security margin, and Symantec has a history of using predictable
serial numbers even during a period when Microsoft's root program required
64 bits of entropy. We should therefore consider the possibility, even
if slight, that an attacker was able to predict at least one of these
serial numbers.

Regards,
Andrew

[Matt Palmer]

On Thu, Jul 14, 2016 at 02:52:41AM -0700, Nick Lamb wrote:
> On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:

> > Revocation does not address the risk that this mis-issuance has caused
> > to the ecosystem, since collided certificates (the ones we cannot see,
> > and need to be worried about) have different serial numbers and
> > therefore do not appear revoked.
>

> if Symantec produced these certificates in a sensible way

That is an *extremely* big "if".

- Matt

[Rob Stradling]

On 14/07/16 04:02, sanja...@symantec.com wrote:
> On Tuesday, July 12, Symantec erroneously produced and issued 8 SHA-1 certificates in support of one customer’s application to submit SHA-1 TBS Certificates to the CA/B Forum for a SHA-1 exception. Symantec has revoked the certificates.

Sanjay,

The final report [1] on Symantec's September 2015 "Test Certificates
Incident" noted that:
"One of these test certificates with a CN=www.google.com was an
Extended Validation (EV) test certificate and was logged to public
Certificate Transparency (CT) log servers which is standard practice
by default for EV certificates issued by CAs."

That sentence must be referring to this precertificate:
https://crt.sh/?id=9314698

So, would it be fair to also classify these 8 SHA-1 precertificates as
"test certificates" ?

The final report [1] also noted (emphasis mine) that:
"3. *We thoroughly analyzed the nature of the test certificates, and
more importantly, the nature of how/why they were issued* – that
informed us of the true risks (e.g. whether the private keys and
certificates were exposed – which they were not). This root cause
analysis crystalized our remediation steps, and guided us on what
actions were necessary to prevent this from occurring again in the
future, augmenting the extensive technical controls and procedures
already in place.
4. *We identified and implemented changes to tools, processes, and
personnel to prevent this in the future*."

Why were the changes resulting from that internal process review
insufficient to prevent these 8 SHA-1 precertificates from being issued?

> An internal process review is underway.

<snip>

How many internal process reviews will it take to *actually* "prevent
this in the future" ?


[1]
http://www.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Update.pdf

[sanja...@symantec.com]

Our online systems are blocked from issuing SHA-1 TLS certificates. These eight certificates were signed in a multi-person key ceremony on an offline system that uses externally unpredictable inputs for serial number generation. The keys were generated by a service partner of the customer. Those keys were combined with enrollment data manually entered by the customer in our managed service certificate enrollment system. That enrollment produced the SHA256 certificates. The output of the online systems was used to create the tbsCertificate structures input into the offline systems.
Symantec strongly supports the rapid deprecation of SHA-1 certificates and welcomes the end of TLS clients' support for them.

[sanja...@symantec.com]

These 8 pre-certificates are not test certificates and were produced after proper authentication and verification. Our customer first presented the 8 requests to their managed service, which produced SHA256 certificates subject to human verification and automated compliance checks that leverage our standard practices and the controls implemented after the September 2015 incident. Since the customer requested SHA-1 certificates, the intent was to first generate tbsCertificates for CABF submission and review as outlined here - https://cabforum.org/pipermail/public/attachments/20160603/0170f2c3/attachment-0001.pdf . Instead of tbsCertificates, actual certificates were generated. We will remediate the offline process that advanced further than intended, which is different from the process that led to the September 2015 incident.