Re: [Trans] can CT defend against dual CA compromise?

[Tom Ritter <[e-mail]>]

On 24 February 2016 at 08:15, Ben Laurie <[e-mail]> wrote:

Sorry, this is complicated. I type a lot when it's complicated.



Thinking about the public key trick more... I don't think it would work.
R -> I -> L

Goal is to match a signature on L by making a new I' and then getting
a client to accept the chain. Changing the public key in I' will
invalidate the signature by R. So while I can mint a new certificate
I' that makes a valid subchain - it won't chain all the way up.




The public key of the fraudulent Intermediate should be blacklisted.
Blacklisting the Subject of the intermediate is a poor choice for the
same reason that using serial number in CRLs/OCSP is a poor choice.
The smart attacker will collide the serial/Subject with an existing
Intermediate that is nigh-unrevokable (because it breaks the
internet).

We need to use something that asserts cryptographic uniqueness for
practical purposes - but it can't be _too_ unique or an attacker uses
a trick to get around it.[0] SPKI seems like the mechanic of choice...

Do crlsets and OneCRL have the ability to blacklist on SPKI? Or do
they use serials or fingerprints?  =)




So a software update blacklists the SPKI of the fradulent
intermediate, which will block A_X and B_X.  (We only know about A_X
though, so A gets the heat while B is still unknown-compromised.)

The problem isn't that an attacker can continue to issue certs off A_X
and log them - the problem is the attacker may be able to continue to
issue *Intermediates* off of A (and B silently & simultaneously) and
log certificates off the new intermediate A_Y (of which the SCT would
be valid for B_Y also.)  The community sees A_Y and doesn't really
flinch/understand the implications w.r.t a future world where SCTs are
required for all connections.

In that world, we would need to blacklist all new SPKIs (in software)
issued by A as they pop up on the offchance they've also been minted
under B.  This seems less than ideal because the smart attacker would
issue so many intermediates that Browsers could not realistically
blacklist them all.  (And blacklisting A doesn't help.) More
engineering would be needed to accomodate all the intermediates, it
would delay the deployment... meanwhile the attacker uses B_746385 to
attack users. This is a failing of CT, in that it puts us back in the
days of "If someone is owned, we don't know."




Ben gave two ways of fixing this, I'll reword/expand:

a) Run a log that tracks everything (including a new A_Y and
A_Y-issued certs) but isn't used in browsers. I'll expand this:

Do not issue SCTs from any other log used by browsers if the
issuer_key_hash matches an intermediate issued by A. In browser
software, blacklist the SPKI of A_X at least, perhaps also A (one
would hope).

I think this would work - but it introduces a complicated new function
for log operators. They need to be able to look at an issuing_key_hash
and reject submissions if that matches a blacklist but fulfills the
root store whitelist (as opposed to currently only checking roots on a
whitelist.)

If they omit this, or fail to update the blacklist, AND an auditor
remembers this attack and implements a check for it (is anyone adding
this to any long-term storage? the Threat Analysis doc?) - we can
retroactively detect the attack again (after some users could be
attacked.)

If they implement this check the log SHOULD raise giant alarms if it
gets a submission that fulfills the root store whitelist but matches
the blacklist.


b) Continue to accept certs from A_X and A in the main logs, but don't
allow SCTs for certs chaining to either A_X (or A depending on the
investigation - but definetly A as soon as a new A_Y pops up).  Ben
said something involving timestamps - but I don't think that could
work because we have to assume the attacker can backdate anything they
want...

So in this case the certs issued by A_X and A are in the log, and can
have inclusion proofs but they were never given a SCT.  This seems
strange to me (and dkg.) But at the moment I'm not sure if an
inclusion proof is equiavlent to a SCT and would enable an attacker to
do anything. I guess it depends on how we require future validation in
client software and if we were ever to say "An inclusion proof is
acceptable in place of an SCT".  I'm not sure if we want to commit
ourselves to rejecting that equivalence for all time...



There's got to be more solutions....

c) Log signs the exact chain. Client must build this same chain and
match it. This would fix everything, but it requires strict path
building by the client, which won't happen.

d) Log signs the chain but the client uses this as a _hint_. If it
builds a path that it deems is 'wrong' based on the hint (e.g. the
hint says Federal PKI but the chain I built uses CNNIC) then reject
it. This would require complicated logic that's probably impossible to
get right more than 80% of the time.

e) The issuer_key_hash is not over the SPKI but the certificate -
including the signature by that issuer's issuer.  This would... also
break path building? Because of cross signatures?  I guess I'm still
confused about those. If R is cross-signed by another CA, C. There are
two R's right? R-self-signed and R-signed-by-C.  Or in Let's Encrypt's
case there are two intermediate certs I: I-signed-by-Lets-Encrypt and
I-signed-by-Identrust?


I guess I know there's more solutions, but isn't there another that's workable?

-tom



[0] What do I mean by this? Say you used a cert fingerprint. Using BER
tricks, you has, in the past, been able to change the fingerprint
without invalidating the signature:
https://git.openssl.org/?p=openssl.git;a=commitdiff;h=684400ce192dac51df3d3e92b61830a6ef90be3e