Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My question is a bit of weird one and doesn't apply to me so much as I'm just curious.

My question is:

If a large company (say, Google, Facebook, or a bank) were to have its private key stolen, how long would it take to re-secure communications? How long does it generally take to detect an intrusion like that, and once it's detected, how long does it take/difficult is it to change the key? How many communications could be exposed between the time a hacker stole the key and the company is able to re-secure itself.

Any articles you could direct me to explaining this would be much appreciated. Thanks in advance.

share|improve this question

closed as primarily opinion-based by Adi, Iszi, TildalWave, Xander, NULLZ Nov 2 '13 at 2:32

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

It's impossible to answer this question. Actually, it's not even a question (by our standards). It all depends on the company's activities, the usage of the key (Is it a private key for SSL communication for a public HTTPS service? Is it a private key used to sign certificates? Is it a public key used to sign messages?), the cipher suite used (EDH or DH), intercepted previous communications, the intrusion detection systems used, the frequency of audits, the type of attack, etc. There are, literally, hundreds of factors here. – Adi Nov 1 '13 at 17:11
up vote 3 down vote accepted

Actually, your larger companies like Google or Facebook do, in fact, have a certificate. This is a CA-level certificate (able to sign other certificates and thus vouch for those holders' identity) which is either issued by an external CA, or whose public counterpart is registered as being implicitly trusted by OSes, web browsers, etc. Call it the Golden Key.

From this certificate, the company will generate additional "intermediate" certificates. These are also CA-level certificates, which are then used to generate end-level certificates that identify individual servers, endpoints and even internal workstations within the company's "private key infrastructure". Such an infrastructure allows the sysadmin to drastically reduce the amount of his network that has to be "trusted" (in reality such internal communications are only "trusted" because it's considered infeasible to secure them).

If an intermediate certificate is stolen, it's disruptive but usually not the end of the world. An attacker can do a lot with any CA certificate that has an unbroken "trust chain" up to a globally-trusted root. However, as soon as reports of a certificate for Google, signed by one of an unrelated company's intermediate CAs, becomes known, the jig is up; the company will issue a "revocation" of the signed certificate, and if it's believed that the CA has been fully compromised, will revoke the intermediate CA itself. A revocation is kind of an anti-certificate; it's signed in much the same way as a normal certificate, but tells any computer to which it is distributed not to trust certificates with a given signature, or that have been signed with a particular CA certificate. Now, this will revoke trust in all the legitimate certificates as well, which as I said is disruptive, but the company can recover, typically by re-issuing new certificates to all known legitimate certificate owners.

This happens from time to time. Notably, it happened to Comodo, a company whose primary business is issuing certificates to other companies. One of its CA certs was compromised and used to generate fake certificates for Google and other major sites for phishing and other nefarious purposes. As soon as it was clear that only one CA was affected, Comodo revoked that CA, transitioned legitimate certificate holders to new certificates signed by other non-compromised CA keys, then generated a new intermediate CA from its Golden Key to replace the revoked one, and it was back to business as usual.

If the Root Certificate, the Golden Key, of a company is stolen, that's the end of the world, for the company holding it at least. Root CA certificates are among the most valuable things in the hacker underworld. As such, there is usually an extreme level of security inherent in the storage of any device which holds the Golden Key (typically a Hardware Security Module). You can watch this video, showing just some of the rigamarole behind the generation and storage of the Root CA certificate for the DnsSec extensions to DNS, which add proof of origin and denial of existence capabilities to the standard DNS framework. If a Golden Certificate is believed to be compromised, everything underneath it in the hierarchy is suspect; there's no way to prove or disprove the legitimacy of any certificate signed by it. Therefore, the only thing you can do is revoke trust in that root certificate completely and deal with the fallout.

This is much rarer, but it has happened. DigiNotar, a Dutch root CA company similar to Comodo, was the victim of multiple attacks that compromised the company's trusted root certificate; the private key was then used to generate fake certificates for a number of major websites. DigiNotar could not reliably identify all the fakes, could not therefore guarantee they had all been revoked, and could not even guarantee that its root private key had not been copied offsite. As a result, the major OS and browser writers responded by simply revoking trust in DigiNotar's root certificate altogether. Hilarity ensued, as DigiNotar was the root CA for several Dutch Government websites, including the counterpart to the U.S. IRS. Imagine going to and being told by your browser that the site may be fraudulent; that's exactly what happened to visitors of the Dutch Tax and Customs Administration website. The Dutch government quickly assumed control of DigiNotar's intermediate CAs, and transitioned all their sites to other certificate authorities. DigiNotar had filed for bankruptcy by the end of the same month.

share|improve this answer

When a private key is stolen, the balance is between restoring security, and maintaining business. For instance, for a SSL server, if the private key is stolen, then the attacker can impersonate the server and run Man-in-the-Middle attacks; if the SSL server does not use the "DHE" cipher suites, then the key thief can also decrypt connections that he passively eavesdrops on.

In real practice, there is about nothing the server owner can do about it. Well, he can configure his SSL server to use DHE, and/or generate a new private key and obtain a new certificate. And he will inform the CA so that the CA revokes the bad certificate. However:

  • Certificate revocation is asynchronous, so there is still a time frame (typically a few days) during which the bad certificate will still appear as "correct" to clients.

  • Most Web browsers don't verify revocation status anyway, so in fact the attacker can use the stolen private key for server impersonation until the certificate expires, which can take several years.

For really serious cases, the following may happen:

  • The browser and/or OS vendors can push an explicit patch to untrust any certificate using the stolen keys. Microsoft has done that for the DigiNotar blunder.

  • Non-technical countermeasures can still apply; for instance, calling the Police/FBI/Mafia and let them find out about the thief, and reprimand/jail/dispatch him.

(Most of this movie is about trying to plug an information leak through classic police techniques.)

share|improve this answer

Well, just speaking generally, big companies rarely have "a" private key. They will have lots of keys, and some will be for this thing and some for that thing, and that makes it much more manageable. Single points of failure are to be avoided.

SSL certificates for big sites are unique, but they're much easier to switch out than a private key system due to the centralized infrastructure.

As far as knowing your key has been compromised, there really isn't any way to know unless you catch someone using it against you. Best practice is to change the key if it might have been compromised, but if it's silently compromised and used to steal information in such a way that it doesn't raise suspicion, it can go on until they change the key as part of a normal key rotation.

share|improve this answer

Detecting intrusion can take milliseconds, or it can take years. Or anywhere in between.

Changing private keys is as simple as getting a new certificate. That could take seconds, or it could take weeks.

The number of communications compromised is therefore a function of the communication rate versus the individual response time, which be anywhere from zero to billions of connections.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.