A Reminder: Private Key Security

Published: 2012-03-20
Last Updated: 2012-03-20 01:03:08 UTC
by Johannes Ullrich (Version: 1)
13 comment(s)

One of the special features of Stuxnet was the use of a stolen private key to sign drivers. This made it harder to detect the injected files as malicious. Since (and before) Stuxnet, we have seen stolen keys used a few times. Most recently, Kaspersky is reporting about malware which employs a key stolen from Swiss company Conpavi AG [1].

Time to re-visit some of the best practices to secure the private key. These rules are written with SSL keys in mind, but apply to other private keys as well (ssh, PGP, code signing...)

First of all, limit the machines that the private key "touches". Ideally, you have an isolated system that is used to create the key and to back it up. Then, a dedicated USB key, a CD or another non-network medium is used to move the key to the server. At least one certificate authority I am aware of offers to create the private key for you. DONT. The certificate authority only needs the public key which is included in the certificate signing request. It does not need the private key and should never ask for it.

It is possible to encrypt the private key. It very much depends on the use case if this is appropriate or not. For a server SSL key, this would imply that you will need to enter the passphrase whenever you restart the service. On the other hand, the key should only be readable by "root". In this case, if an attacker already has root, the attacker may be able to read the encrypted key directly from memory. However, for keys used for code signing or e-mail signatures or encryption, entering the pass phrase is more feasible.

In some cases, the private key can be stored on a smart card and secured with a PIN. This is preferred for interactive applications if the key is used to log in to a system. For ssh, it is frequently required to use the key for automatic cron/batch processes. In this case, a specific key can be generated and its permissions can be limited (this is a topic for a follow up diary on securing ssh).

Before generating a key pair, think about how it is used and what parameters should be selected. Here are some of the options:

- Key Strength: For RSA, a 2048 bit key is said to be equal in strength to a 112 bit symmetric cipher key. This is sufficient for most applications, but 4096 bits is typically preferred as it is still feasible and doesn't "break the bank" for CPU cycles on a modern server.

- Algorithm: RSA is usually providing the best tradeoff with respect to speed and security, but for some applications, DSA may be more appropriate. Read up on the particular application and find out what algorithm works best.

- Entropy: good keys need good random numbers. It can be hard to create good random numbers on a system that is used exclusively to create keys. Sometimes, I prefer to create the key on the target server and then move it to a USB stick for backup. I haven't tried it yet, but I assume that a simple game like Solitair may be useful ;-) (you do want to install something that is part of the core OS install in order to avoid additional untrusted software).

- key transfer: if you don't create the key on the target server, you have to move it somehow to the target server. Even if you create it on the target server, a backup may be necessary. The key should only be moved over an encrypted connection or "in hardware" (= USB token). I would try and avoid having all keys on one USB token (imagine plugging it into an infected server!). The keys should be encrypted "at rest" . A backup to DVD or CD may sound wastefull (couple KB of keys on a GB of DVD), but its < $1 per key, hopefully less money then you made reading this article. CDs and DVDs are easily archived and accounted for. However, not all servers have DVD/CD drives. 

There are a number of harware solutions to store keys that are more appropriate for servers. They tend to be a bit more pricey (I have seen them for $500) and may not work in all cases.They are typically referred to as hardware security modules (HSM) and they may include random number generators.

Any other ideas? Anything I missed?

 [1] http://www.securelist.com/en/blog/682/Mediyes_the_dropper_with_a_valid_signature

Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: private key ssl
13 comment(s)


I will gladly archive your keys for you. Of course, I may put them to my use...
I haven't looked into it yet, but does IronKey offer any advantages here?
A backup writable optical disc is wasteful because of its fragility and volatility. How about printing the key in its ASCII form?
What about HSM (hardware security module)? It will store and process the keys for you. And won't allow to see them for anyone.
I agree with Irosa, writable discs are more likely to fail than other options so I would avoid them. Printing and using OCR for recovery is a tantalizing idea, but one that I'd want to thoroughly test before relying on.
Manually entering an ASCII key printed on papir is close to impossible to get right. A long time ago I had to service a server (Windows 2000) in a datacenter where both the administrator username and password were a random 64 character ASCII string... It took forever to get both right.
If you're going to put it on a disk a CD rather than a DVD seems to be a lot more reliable, especially when moving between machines; but do put other stuff on the CD, (and save multiple copies) some drives get confused by very short tracks and a CD's recording surface can be physically damaged. DVDs seem to delaminate a lot sooner than a CD so you lose the disk sooner rather than getting read errors.

If you're going to print out the key you should probably use something like QR Codes. (Or another high density barcode)

Failing that it's possible to make it easier to enter a long random code by encoding it in dictionary of (say 4096) English words, of course you have to store the dictionary somewhere.

For HSM boxes from safeNet, there is a way to generate the key, print it out and reinject it later.
I was always partial to the RSA smartcards and/or tokens myself, but they clearly aren't for everyone. The idea is that the card itself has the engine to create the keypair, and the card lets you download the public key but never the private key. Or at least the ones I have used are like that.

Some people claim that with some models you can start to cut the thing apart and put it under an electron microscope to dig out the private key - I don't remember the details for that however, so I don't know if that is true or an urban legend.

I keep a GnuPG encrypted backup of each private key and I have a paper copy of that GnuPG key, print formatted using http://www.jabberwocky.com/software/paperkey/

Diary Archives