7

What if someone could steal a Certificate authority's private key? I know this will (probably) never happen, but what would happen to the certificates that were already signed with this private key?

The person could start signing certificate as if he was the CA, but would it cause any harm to the certificates that were already signed with that key?

(Because question was identified as a possible duplicate: the focus of my question is on the fact if this breach would cause harm to the already signed certificates)

Sam Hendrickx
  • 81
  • 1
  • 5

3 Answers3

10

If someone steals a CA's certificate signing key, the already signed certificates remain valid. But that doesn't mean they are not harmed. The whole point of certificates is that only a trusted party can produce them, so that when you see a certificate, you can be confident that it is valid and that you're talking to the entity you intended to talk to. If an untrusted party can produce a mathematically valid certificate, then the certificate is not worth the electrons it's written on. This means that all websites (not just the ones who used the CA's legitimate service!) are vulnerable to a man-in-the-middle attack carried out by the attacker (barring partial countermeasures such as certificate pinning). See What are the risks of a Certificate Authority hack for 'the average user'? for more explanations of the consequences of a stolen CA certificate signing key. Basically, not just the certificates emitted by this CA but all certificates are harmed.

To counter this harm, it is necessary to revoke the trust in the compromised key. This means that verifiers — browsers and other TLS clients (and servers, for client certificates) — must stop trusting the compromised key; until this is done no certificate from that CA can be trusted.

Normally, a CA has another key which they can use to revoke certificates. The revocation key should be kept with stringent security measures: unlike the signing key, which is used daily to sign certificates and thus has to be relatively accessible, the revocation key is hardly ever used (only to certify a new signing key or to revoke an existing one), so it can be made hard to access (typically requiring multiple officers of the CA to enter key fragments manually in an offline, physically secure environment). Once the compromised key is revoked and, a one is deployed, and the old certificates are re-signed, the harm is undone. As you can imagine, doing all of this, especially propagating the information to all browsers out there, would take a while, and given that it's an uncommon event, there would undoubtedly be platforms that keep thinking the old CA signing key is valid.

Another more drastic way is to update verifiers to remove the compromised CA from the list of trusted CAs. This solves the problem for certificates that aren't emitted by the compromised CA, but leaves the customers of the compromised CA in a lurch: they need to get another CA to sign a new certificate.

By the way, it has happened before.

Community
  • 1
Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • So basically, it screws over the entire web's security. (So much for TLS being pushed as a silver bullet) – user253751 May 27 '15 at 22:22
  • 2
    @immibis TLS is not "pushed as a silver bullet," at least not by anyone who understands that given enough time, *all* security is breakable. It's so ubiquitous because it is pretty darn strong and (due to all the existing infrastructure) relatively easy/cost-effective to use. This makes it pretty much *the best we have* in terms of securing our electronic communications and far, far better than nothing. That's why everyone advocates using it. – jpmc26 May 27 '15 at 22:29
  • @jpmc26 I mean that it seems to be pushed in a way that will lead server owners (particularly ones who don't care about security) to think of it as a silver bullet. – user253751 May 28 '15 at 00:36
  • 3
    @immibis Anyone who thinks there is such a thing as a silver bullet in anything related to software is either inexperienced or incompetent. Even so, getting someone to use TLS at all is still a good thing; it *is* one of the few things you can blindly do in software that 99.9999% of the time results in a real improvement (over doing nothing). I'd much rather the inexperienced and incompetent err on the side of using it than erroneously think it's worthless; wouldn't you? – jpmc26 May 28 '15 at 00:40
6

A normal CA has a procedure in place for this. It starts with invalidating ALL certificates signed with the key, Then have the CA make a new Root Key and Certificate, then do all the steps involving the setup of a new CA. After that is done, reissuing all certificates that were affected and still valid.

A problem if this is not mitigated soon after the key is stolen is that the lost reputation of a malicious certificate causes a CA to go out of business. Like diginotar did.

Ismail Marmoush
  • 101
  • 3
LvB
  • 8,217
  • 1
  • 26
  • 43
  • From what I understood DigiNotar had quite a few dubious practices. Initially they just seem to sign any requestion, but later it was discovered they could not tell how much they had been compromised. Once those came to light there was no saving them. They could have mitigated to the moon and back at the time of discovery and they would still not have escaped bankruptcy :| – Maarten Bodewes May 27 '15 at 19:50
  • yes I did not explain why diginotar went under. just that it did after a 'leak'. – LvB May 27 '15 at 19:52
2

You are correct that it would not cause any harm to the certificates that were already issued, but it does call into question which certificates are still trustworthy, and which are not. It's safer and easier to just treat all certs issues by that signing key as "compromised" and re-issue them.

In this case the CA's signing certificate would be revoked with "Key Compromise" as the revocation reason, and any certificates it signed would fail to validate. If you are confident that you know the date of the key compromise, most CA software (but I can't speak for all CA software) will allow you to specify both a Revocation Date, and a Compromise Date, with the assumption that certs issued before the Compromise Date are still trustworthy.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 1
    Except that the dates in the certificate are authenticated by ... the CA's signing key, which is now compromised. The people who got hold of the key can issue certificates that claim they were issued before the compromise. – cjm May 27 '15 at 21:39
  • @cjm If it's a self-signed root CA, then yes, you have to revoke and re-issue all certs. If it is a subordinate CA, then your revocation info is signed by your superior, and there's no issue. This is why most self-respecting production CAs use an offline root CA. The idea is that the root signs a cert for the publicly-visible CA, and then gets unplugged and stored in a vault. This way, the CA that the public interacts with is not self-signed and you don't have these issues. – Mike Ounsworth May 27 '15 at 22:31