Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC: A Reminder: Private Key Security - SANS Internet Storm Center SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
A Reminder: Private Key Security

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?


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

I will be teaching next: Defending Web Applications Security Essentials - SANS Security West 2019


3479 Posts
ISC Handler
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?

133 Posts
A backup writable optical disc is wasteful because of its fragility and volatility. How about printing the key in its ASCII form?

5 Posts
What about HSM (hardware security module)? It will store and process the keys for you. And won't allow to see them for anyone.

7 Posts
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.

12 Posts
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.

11 Posts
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.


11 Posts
For HSM boxes from safeNet, there is a way to generate the key, print it out and reinject it later.
3 Posts
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.


43 Posts
I keep a GnuPG encrypted backup of each private key and I have a paper copy of that GnuPG key, print formatted using
3 Posts
I took Per's challenge and tried to enter an ASCII RSA key manually -- 1675 characters, including linefeeds. I managed to do it with 5 character errors. It wasn't pleasant, and in a recovery scenario I wouldn't have the original already on the system to run diff against. Nevertheless, with standard data entry error detection & correction techniques, it's a manageable task. I highly recommend a font that clearly distinguishes between O and 0, and l and 1.

You could probably get it correctly entered in an hour or less. Not as fast as copying off a USB key, of course. But it is possible, and it might be viable for a secondary or tertiary off-site key archive. There is much to be said for the durability, both of media and technology, for a human-readable archive on paper. I can't read my old floppies, but I can read my old papers -- you might be able to future-proof by using ancient, timeless technology.

QR codes are a very interesting idea for many of the same reasons, though you will need the means to read them. For short- or intermediate-term needs, if not archiving for the ages, that wouldn't be a problem. My phone managed to read the very large QR code block for the same key, with difficulty, from my monitor, but I couldn't get it to read it off paper. Your results might be different with a different phone or printout.


50 Posts
One trick for improving the reliability of manual entry is to type in the data twice, then to diff the two files. That won't help you for read errors (where it's hard to distinguish between a O and 0, etc.), but it should help with typing errors. With that in mind, I wonder if anyone has developed a transcription scheme based on Diceware? The same reasons that make Diceware a good choice for password generation would make it a good solution for binary -> printed text -> binary conversions. With an agreed upon word list and some checksumming, that could be a viable solution.
A local pentester registered a one-person LLC (Limited Liability Company) for the express purpose of getting a state-issued corporate registration. He then used it to get his own code-signing certificates for his custom malware used in his pen tests. Game over.

Sign Up for Free or Log In to start participating in the conversation!