[Cryptography] Protecting Private Keys

[Jerry Leichter]

On Sep 7, 2013, at 10:20 AM, Jeffrey I. Schiller wrote:
> One of the most obvious ways to compromise a cryptographic system is
> to get the keys. This is a particular risk in TLS/SSL when PFS is not
> used. Consider a large scale site (read: Google, Facebook, etc.) that
> uses SSL. The private keys of the relevant certificates needs to be
> literally on hundreds if not thousands of systems. Chances are they
> are not encrypted on those systems so those systems can auto-restart
> without human intervention. Those systems also break
> periodically. What happens to the broken pieces, say a broken hard
> drive?
I can tell you, in broad terms, what happens at Google:  The disks are physically destroyed, on site.  Every disk is tracked from cradle to grave - checked into the datacenter, where it receives a unique ID; checked in and out of the machine, carts that are used to move devices around datacenters (otherwise a great way to lose track of something), various secure storage facilities (on site), and on to eventual destruction.  No drive that was ever plugged into a live machine ever leaves its data center in a condition that the data on it is recoverable.  (This despite the fact that in many cases the data on the disk is already encrypted.)

Actual long-term key storage is done in a relatively small of locations.  And there are various other tricks to make it hard to get information out of a machine should you somehow get it out of the facility, and to make it hard to sneak a machine of your own *into* the facility.

While Google's particular approaches are unique, other large-scale providers who are concerned about security do the same general kind of thing.  I seem to recall seeing a description of how Facebook similarly tracks and manages disk drives, for example.

It would be nice if there were some published standards for such things and a third-party auditing mechanism.
                                                        -- Jerry