Izenpe test and production logs use the same key

[Graham Edgecombe]

Hi,

I'm not sure if anyone's yet realised that Izenpe's test log at
https://ct.izenpe.com/pilot shares the same key pair as Izenpe's
production log at https://ct.izenpe.com. As log IDs are derived from
public keys, the logs also have the same ID.

This can be exploited by submitting a certificate to the Izenpe test
log, which is presumably not as widely monitored as their production
log. The SCT it returns will be considered valid by clients such as
Chromium, as there's nothing to distinguish it from an SCT returned by
the production log. However, the certificate is not included in the
production log after the MMD.

I submitted a certificate to Izenpe's test log over 24 hours ago to
demonstrate this. Izenpe's test log accepts some publicly trusted roots,
and I used a certificate which chains up to a publicly trusted root
that's accepted by both the test and production logs.

Here's the SHA-256 hash of the certificate:

$ openssl x509 -in cert.pem -outform der | sha256sum -
a804a9b2770130718e86d3a63cbb468e9b1701433195ee537607c9c96b53bddd -
$

The SCT the log gave me has the following log ID:

$ tail -c +2 cert.sct | head -c 32 | base64
dGG0oJz7PUHXUVlXWy52SaRFqNJ3CbDMVkpkgrfrQaM=
$

And the following timestamp:

$ date -u -d @$(perl -e "print int 0x$(tail -c +34 cert.sct \
| head -c 8 | xxd -p) / 1000")
Tue 10 May 21:02:10 UTC 2016
$

Here's the output of verify_util.py showing a valid signature from the
key used by Izenpe's logs:

$ PYTHONPATH=. python2 ct/crypto/tools/verify_util.py verify_sct \
--sct=cert.sct --log_key=izenpe.key cert.pem
True
$

I've attached cert.pem and cert.sct (in base64 as my mail client mangled
the binary version, so you'll need to base64 -d it first) if anyone
wants to reproduce these commands. Izenpe's key can be obtained from the
Chromium inclusion bug at https://crbug.com/431700.

The certificate was included as entry #17891 in the test log. However,
it does not appear to be in the production log at the time of
writing - well over 24 hours after the timestamp in the SCT.

Perhaps the simplest way to demonstrate this is with crt.sh, which
monitors Izenpe's production log but has only seen this certificate in
Google logs so far:

https://crt.sh/?q=a804a9b2770130718e86d3a63cbb468e9b1701433195ee537607c9c96b53bddd

Of course, people running their own monitors may want to verify this
themselves instead trusting myself or crt.sh.

I've also attached the current STH from Izenpe's production log at the
time of writing - as a record of the current tree size, in case the
certificate is later submitted to it.

Graham

[Andrew Ayer]

I have independently confirmed that Izenpe is operating two separate
logs, at https://ct.izenpe.com and https://ct.izenpe.com/pilot, using
the same key pair.

It is now impossible for Izenpe to cryptographically prove that its log
is append-only. It is possible to provide two STHs, both with valid
signatures from Izenpe's production log key, and Izenpe will be
unable to produce a valid consistency proof between those two STHs.
This is, and ought to be, considered incontrovertible proof of a log's
misbehavior - allowing a log operator to rebut by saying that one of
the STHs actually came from a different log would render CT worthless.

In light of this, I believe that the Izenpe log must be presumed to
have violated its append-only property and should therefore be
disqualified from Chromium.

Regards,
Andrew

[Yuhong Bao]

It is also probably a good idea to clarify this in the log policy so this kind of mistake won't happen again.

[Matt Palmer]

On Sat, May 14, 2016 at 11:09:16PM -0700, Yuhong Bao wrote:
> It is also probably a good idea to clarify this in the log policy so this
> kind of mistake won't happen again.

This isn't an issue of "policy"; it's an intrinsic part of how CT works, as
much as the mathematics of merkle trees.

- Matt

[Rob Stradling]

FWIW, we've already clarified this in 6962-bis (as part of
https://trac.tools.ietf.org/wg/trans/trac/ticket/105):

"A log MUST NOT use the same keypair as any other log"

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

[Iñigo Barreira]

All,

Let´s try to summarize:

1.- Both logs share the same keys but have different certificates

2.- To use the Izenpe CT log, there´s a contract and only admitted roots are included

3.- The creation od this "pilot" was because some customers were unable to log any precert/cert in the Izenpe CT as they do with the Google one for testing. That was probably due to restrict TLS connection, use of crypto suites, etc.

4.- The intention of this test log was only for development CA roots, not for production.

5.- The roots included in the ct pilot are:

CN	O	CERTIFICADOS	PRECERTIFICADOS
Izenpe.com - DESARROLLO		1	77
Demo Root	Safelayer Secure Communications S.A	2	5
Izenpe.com - SAFELAYER	IZENPE S.A.
SwissSign EV Gold CA 2014 - G22 (No root)	SwissSign AG
SwissSign Gold CA - G2	SwissSign AG	17020
SwissSign Gold Root CA - G3 INT	SwissSign AG
Entrust QA Certification Authority - L1M	Entrust, Inc.	3	774
Entrust Certification Authority - L1E	Entrust, Inc.
Entrust QA Certification Authority - L1J	Entrust, Inc.
Entrust QA Class 3 Client CA - SHA256	Entrust, Inc.
Actalis Authentication Root CA	Actalis S.p.A./03358520967	1	1
TWCA Root Certification Authority	TAIWAN-CA	0	0
TAIWAN-CA	TAIWAN-CA
D-TRUST Root Class 3 Test CA 2 EV 2009	D-Trust GmbH		22
neXus CT Test Root	neXus

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20160515064815.GK5275%40hezmatt.org.

[Iñigo Barreira]

Sorry,

clicked the send button before finishing and rechecking the email before sending it. Continuing:

1.- correction: Both logs use the same key but different databases

5.- The green ones are development roots, the red ones are "production" roots to make them easy to deploy in the real world as requested by our customers. You can see that there are a few ones in total and less than the ones in the production one

6.- As said, this pilot is for internal use and yes, we were wrong using the same keys.

Anyway, the action we made this saturday was:

1.- Stop the service of the CT log called pilot. None can access now

Regards

[Matt Palmer]

On Mon, May 16, 2016 at 12:16:00PM +0200, Iñigo Barreira wrote:
> Anyway, the action we made this saturday was:
>
> 1.- Stop the service of the CT log called pilot. None can access now

However, there are still valid SCTs in existence for certificates which do
not appear in the log within the required MMD. What do you plan to do about
those?

- Matt

[Iñigo Barreira]

Matt,

the main issue is with the precertificates for those in the red color. Then, only the Entrust and Actalis are affected. The Entrust ones are not the production ones, so not trusted by any browsers, just for testing according to what stated in Mozilla Salesforce. The Actalis one is indeed a production one, according to Mozilla salesforce, and this is the only one problematic.

So, in summary, only one precertificate is affected. And this is:

www-test08032016.actalis.it which DNS can´t be resolved

Regards

- Matt

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20160517000102.GW5275%40hezmatt.org.

[Ryan Sleevi]

Thanks for alerting us and the community to this, Graham.

I agree that this is a violation of the policy, as discussed on this thread, and have announced that the current Izenpe Log will be removed on 30 May 2016.

Izenpe is welcome to reapply with a new log key and new log URL, and this new log will undergo the same qualification process as all other logs that apply.

[Matt Palmer]

On Wed, May 18, 2016 at 12:11:27PM +0200, Iñigo Barreira wrote:
> the main issue is with the precertificates for those in the red color.

No, the main issue is that your log is not complying with the basic
requirements of a CT log -- that every SCT issued corresponds with an entry
available in the log within a certain time period of SCT issuance.

- Matt

[David Fernandez]

Hi,

this post wants to inform that the CT log server "ct.izenpe.com" has been shutdown today. We have kept it powered on just for testing purpose since it was disqualified last May. Last week the ssl certificate expired so it makes no sense to keep it running.

- Matt

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.

To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/20160518234816.GH5275%40hezmatt.org.