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
Twitter