Encryption keys are considered the key to the kingdom, both from a server-, service- and user-oriented approach. One of the most popular solutions for encryption keys is GnuPG, an implementation of the OpenPGP standard for encrypting and signing data and communication. GPG uses public-private keys, wherein you distribute your public key and protect your private key by all possible means.

You do not want to store your private key on your workhorse, and definitely not together with the data it has to protect. Ideally, you store it offline. Know what works best? Paper! Print the key and store it in a safe vault. But if you do kick it new school, use a removable USB drive.

You can use the armored option from GPG or a tool like paperkey.

$ gpg --export-secret-key --armor

Sub-Keys Instead of Private Keys

When the private key isn't available on your system, how do you sign or encrypt data? By creating sub-keys with an expiration date. As with a normal private key, you should store these keys safely but accessible to you — in an encrypted container or a keychain, for example.

One of the basic security precautions when using GPG (or any other key-based system) is setting a strong passphrase before you can use the secret key. Remember, the algorithms for encrypting data usually suffice. The security comes from the encryption keys and how they are protected.

gpg --edit-key

gpg>

gpg> save

How do you share these keys with team members? If you set a strong passphrase for the secret key, you can:

• Send it via e-mail.
• Use a secure upload mechanism (sftp) to a protected storage.

For additional security, encrypt the e-mail or the uploaded file with the public key of the recipient.

Sharing the passphrase for the shared key via the same communication you used to transmit the key is not a good idea. It should rather happen out-of-bands. Choose a communication channel that's secure, one-on-one and where you can verify the recipient.

A simple solution? Pick up the phone, verify you're talking to the intended recipient and share the password via voice-communication. An added benefit is that you get to know the person who will be using your keys. It doesn't scale well to large teams, but it works with most environments.

Managing Keys with KMIP

What do you do if you have to integrate multiple systems from different vendors? Manually exchanging keys becomes very cumbersome. This is where Key Management Interoperability Protocol (KMIP) comes in. This protocol is governed by the OASIS standards body for the storage and maintenance of key, certificate, and secret objects.

Keep in mind there is a Python implementation at GitHub, called PyKMIP, that allows you to set up a client/server model. Get it via:

$ git clone https://github.com/OpenKMIP/PyKMIP.git

Revoking Keys

Something that is often overlooked is having a procedure for revoking keys. Keys can get compromised. Keyholders can leave your organization. You want to be prepared when this stuff happens. For starters, an authorized staff member should be able to issue revocation certificates. Ideally these are already generated when creating the key and then stored somewhere safe. After revocation, however, the authorized user should access the private key and generate new sub-keys.

Generating GPG revocation certificates is easy:

$ gpg --output revoke.asc --gen-revoke

Backup Your Private Keys

You probably take good care of your data with test backup procedures. The same goes for the private keys. It stinks when sub-keys go missing, but you can revoke them and generate new ones. To do so you'd still need the private key, so make sure your backup is also extended to these keys. Be sure to test this procedure before an incident occurs.

Accountability

Logging service requests is essential. Likewise, you need to have an audit trail of who used which key, where and why.