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

[Ben Laurie <[e-mail]>]

On 24 February 2016 at 15:35, Tom Ritter <[e-mail]> wrote:

> 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?  =)
>

https://github.com/agl/crlset-tools (answer: yes, crlsets can blacklist on
SPKI).



> 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.)
>

Surely no-one has to remember anything ... if a browser-used log logs a
cert that is for a domain that wasn't expecting that cert to be issued,
then action needs to be taken.

Eventually, presumably, everyone will get bored of taking action on every
cert issued by the compromised CA and deal with the problem in a more
fundamental way. Such as blacklisting the SPKI.



>
> 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
>