Subject: [Trans] proposed text to address Bryan's concerns

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Mar 2016 11:55:11 -0400

The following text is intended to address the concerns raised by Bryan, 
about
compromise of a CA or log.  The threat analysis already mentioned the 
possibility
of a CA or log being compromised or coerced (Section 2) but this text 
goes examines
attacks based on such compromises, especially undetected compromises, in 
more depth.

Steve
------

3.4 Undetected Compromise of CAs or Logs

Sections 3.1 and 3.2 examined attacks in the context of non-malicious 
and malicious CAs and benign and misbehaving logs. Another class of 
attacks might occur in the context of a non-malicious CA and/or a benign 
log. Specifically these CT elements might be compromised and the 
compromise might go undetected. Compromise of CAs and logs was noted in 
Section 2, as was coercion of a CA. As noted there, a compromised CA is 
essentially a malicious CA, and thus the discussions in Section 3.2 are 
applicable. The case of an undetected compromise warrants some 
additional discussion, as some relying parties may see signed objects 
only with the legitimate (non-malicious) CA, others may see signed 
objects from it’s compromised counterpart, and some may see objects from 
both.

In the case of a compromised CA or log the adversary is presumed to have 
access to the private key used by a CA to sign certificates, or used by 
a log to sign SCTs and STHs. Because the compromise is undetected, there 
will be no effort by a CA to have it’s certificate revoked or by a log 
to shut down the log.

In the case of a compromised, non-malicious CA an attacker uses the 
purloined private key to generate a bogus certificate (that the 
compromised CA would not issue). If this certificate is submitted to a 
legitimate log, then it subject to detection by a Monitor, as discussed 
in 3.1.1.1. If the bogus certificate is submitted to a misbehaving log, 
then an SCT can be generated, but there will be no entry for it, as 
discussed in 3.1.1.2. If the bogus certificate is not logged, then there 
will be no SCT, and the implications are as described in 3.1.2.

This sort of attack may be most effective if the CA that is the victim 
of the attack has issueda certificate for the targeted Subject. In this 
case the bogus certificate will then have the same certificate path as 
the legitimate certificate, which may help hide the bogus certificate. 
However, means of remedying the attack are independent of this aspect, 
i.e., revocation canbe effected irrespective of whether the targeted 
Subject received its certificate from the compromised CA.

A compromised, non-malicious CA may be able to revoke the bogus 
certificate if it is detected by a Monitor. It can do so only when the 
serial number of the bogus certificate is made known to this CA, and if 
the bogus certificate was not issued with an Authority Information 
Access (AIA) extension that enables only the malicious twin to revoke 
the certificate. (The AIA extension could be used to direct relying 
parties to a CRL or OCSP server controlled by the malicious twin. If the 
bogus certificate contains such an extension, the compromised CA cannot 
revoke it, but it will also be apparent that the bogus certificate was 
issued by the malicious twin; the AIA extension would provide a strong 
indication that the bogus certificate was not generated by the 
compromised CA itself.)

If the serial number of the bogus certificate is the same as for a 
valid, not-expired certificate issued by the CA (to the target or to 
another Subject), then revocationposes a problem. This is because 
revocation of the bogus certificate will also invalidate a legitimate 
certificate. This problem may cause the compromised CA to delay 
revocation, thus allowing the bogus certificate to remain a danger for a 
longer time.

The compromised CA may not realize that the bogus certificate was issued 
by a malicious twin; one occurrence of this sort might be regarded as an 
error, and not cause the CA to transition to a new key pair. (This 
assumes that the bogus certificate does not contain an AIA extension 
that wrests control of revocation from the compromised CA.) If the 
compromised CA does determine that its private key has been stolen, it 
may take some time to transition to a new key pair, and reissue 
certificates to all of its legitimate Subjects. Thus an attack of this 
sort may take a while to be remedied.

Also note that the malicious twin of the compromised CA may be capable 
of issuing its own CRL or OCSP responses, without changing any AIA data 
present in the targeted certificate. This revocation status data items 
will appear as valid as those of the compromised CA. If the attacker has 
the ability to control the sources of revocation status data available 
to a targeted user, then the user may not become aware of the attack.

A bogus certificate issued by the malicious CA will not match the SCT 
for the legitimate certificate, since they are not identical, e.g., at a 
minimum the private keys do not match.Thus a CT-enabled browser that 
rejects certificates without SCTs (Section 3.1.2.2) will reject a bogus 
certificate created under these circumstances if it is not logged. If 
the certificate has been logged by a compromised or malicious log, then 
an SCT will be available, but there will be no log entry (Section 
3.2.1.2). The lack of a log entry prevents detection by Monitors, and 
the presence of the SCT prevents rejection by a CT-aware browser that 
accepts SCTs from the malicious or compromised log.

In the case of a compromised, non-malicious log an attacker uses the 
purloined private key to generate SCTs for certificates that have not 
been logged by its legitimate counterpart. These SCTs will appear valid 
relative to the public key associated with the legitimate log. However, 
the STH issued by the legitimate log will not contain these SCTs. Thus 
more thorough checking of the SCTs issued by the evil twin log will note 
the discrepancy. An Auditor performing such a check might conclude that 
the log is acting maliciously, and is presenting a split view to its 
clients. In this fashion the compromised log may be shunned and forced 
to shot down. However, if an attacker targets a set of TLS clients that 
do not have access to the legitimate log, they may not be able to detect 
this inconsistency. In this case CT would need to rely on a distributed 
gossiping audit mechanism to detect the compromise (see Section 5.6).