Can Private Keys Grow Legs?

January 29th, 2010   -   Posted by: Jeff Allen

In the latest installment of our “Simon the IT Dummy” video series, Simon Christopher encounters copies of PFX files on a compact flash card that had been left behind by a fired co-worker (PFX files are encrypted security files that contain private keys). The device also had several spreadsheets on it, which (based on the file names that are legible in the 720p version of the video on YouTube) almost certainly contain regulated data. Simon instantly recognizes  that this was a data breach, as this type of data would never be stored or transported on a digital camera memory card for any official purpose.

As always with the Simon videos, this scenario is admittedly a little over the top, but let’s back up a few steps and talk about why private key security would be an issue. In a public key cryptography scheme, two asymmetric cryptographic keys are used – a public key and a private key. The public keys are used for encryption and are distributed freely to parties who need to send encrypted data. The private keys are used by the receiving party for decryption and therefore must be stored securely to ensure against unauthorized decryption and data access.

I once heard someone describe this scheme using the analogy of a public mailbox on a street corner. Letters can be put into the mailbox by anybody, and they are kept secure and private inside the mailbox. Only the mail carrier has the key to unlock the box and access the letters. Of course, this analogy has its imperfections, but I find it helpful in illustrating the role of the private keys in a PKI scheme, and there are a surprising number of parallels to our encryption world.

mailbox_orange

First, these keys clearly must be safe-guarded. They are the proverbial keys to the kingdom – whoever has access to the keys can access the data.

Next, I suspect just like in PKI implementations, the same lock is often used on a number of different mailboxes, and multiple copies of the same key are distributed to mail carriers to simplify the process of distributing and managing who gets keys and who can open the mailboxes. From a management standpoint, it would be simplest if there was just one key and lock pair. Then each mail carrier could be issued a key that would open any box they needed to access. Later, if routes or responsibilities changed, nobody would have to sort through and decide which keys to revoke and which to issue. Mail carriers would always have the key they need to do their job. Of course the security challenges to such an approach are obvious, and therefore such a practice would never be allowed in the IT world. Or would it?

Unfortunately, what happens in the IT world is often very much like the process described above. Administrators who setup hundreds and even thousands of systems regularly share keystore passwords (keystores are generally software stores where cryptographic keys are stored). In fact, within IT groups (UNIX sys admin, etc.) keystore, SSH and other system passwords are often shared across a number of systems, devices and applications. In an interesting parallel with the mailbox system, most software-based keystores don’t have the concept of a user account, so any entity that presents the right password is in, and there is no way to tell whether it was a good guy or a bad guy. The mailbox works the same way – anyone with a key is in. You don’t have to be a mail carrier – you just have to get his key (but that’s a topic for another blog).

Finally, there is a big difference between what you need (access, expertise, keys, etc.) to exploit bad private key security and what you need to exploit the mailbox system. In order to exploit either system, you need a key. Once you get the key, however, then you need a mailbox or some data. Getting a mailbox, especially one located in a public place is kind of difficult. But in the IT world, data can be discretely collected and removed from an organization fairly easily—especially if it’s encrypted when it goes out. Perhaps nobody will remove data on a compact flash card, but it’s probably not as far-fetched as it seems.

Now if only there was a software company that could help manage this stuff…





Leave a Reply