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).
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
