logo~stef/blog/

PGP key generation

2012-10-02

With the usage of PGP in everyday life our communication is mostly state of the art, and quite expensive to compromise. The weakest links are nowadays the systems where the communication terminates and is decrypted to plaintext. Not only are the messages available unencrypted, but also the encryption keys. Proper key management becomes essential, however diligent key management is something that not even the German Wehrmacht was always able to do properly. :) To reduce the probability of errors, there's a script at the end that automatizes most steps.

One essential aspect of key life-cycle management is key generation.

Note: most of the procedure below can be substituted by using an OpenPGP smartcards which allow to generate keys, that cannot be extracted easily, all signing and decryption happens in the smartcard itself. Such smartcards however usually have certain storage limits. Current technology allows usually 3 keys with 3072 bits, some newer models also 4096.

Generating a new key

Needed things:

  • a secure offline environment for key generation,
  • secure offline location to store the signing key,
  • Another secure offline location to store a backup of the signing key,
  • A third secure offline location to store a revocation certificate,
  • A pristine offline system for generation and handling of the key,
  • 3 distinct and strong passphrases

Offline system for key management

The biggest threat to key generation is a trojan/malware compromised system that leaks not only the keys but also captures the keystrokes of the passwords. To counter this threat it is strongly advised to use a pristine live CD to boot into an offline environment (yes, disconnecting the network cable is a good idea anyway). I like Tails for such a live system, but Privatix or Liberté Linux might be similarly useful.

Most PGP keys consist usually per default of a signing and an encryption key. The web of trust is woven by signing other peoples signing key. However there's a trade-off, either the key has a limited lifetime, and we have to ask our peers to re-sign the new key from time to time. Alternatively you create an unlimited signing key, but then handling becomes difficult as you want to protect this key with increased diligence. Multiple sources online suggest creating a master signing key, which is only used (again offline - see a pattern here?) for signing other keys and at least two subkeys, one for signing anything else and one for encryption. This allows you to regularly update your sub-keys without the need to re-sign them with your peers, only your master key needs to sign the new sub-keys. Regenerating your sub-keys regularly also reduces the lack of perfect forward secrecy in PGP.

All three keys should be protected by strong passphrases. As signing and encryption are not necessarily happening with the same frequency and applications, so it makes sense to set different passphrases for both. That means 3 passphrases in total, sounds hard to remember. Instead of using a long random password, rather use a passphrase consisting of at least 5 words. Now instead of 14 random letters you have to remember only five words, that should be manageable - especially if you make up a small story out of the words. One way to generate such passphrases is the Diceware method, another way is this simple script which replaces dices with openssls rand and the word list can be any size that fits in memory - this can be seeded with any kind of word list that you trust.

When you generate a key, it is good practice to also generate a key revocation certificate for the case your key gets compromised. In cases where you might not have the key available anymore to generate such a certificate having one ready up-front can prove useful. For cases when you lose or destroy the encrypted container containing the private keys it is also useful to have a backup ready - after all it took a lot of entropy to generate the key, don't waste it ;).

Both the revocation certificate and the backup are hopefully very rarely needed, but should be well protected. You can choose to use passphrases and encrypted containers, or you can encrypt the cert/backup with a 128 byte cryptographically strong random key and use Shamirs Secret Sharing Scheme to split up the encryption key into multiple parts and distribute them geographically and perhaps to trusted persons. Only when a preset amount of shares is presented, can the backup/cert be accessed. You could also generate a third set of shares for your backup, in case something happens to you and you want your family, friends or lawyers be able to read encrypted data belonging to a certain private key...

As you should very rarely need to generate such a full key and it is quite a complex procedure, there's a script that tries to automatize all the steps above. It depends on gpg, gpgsplit, srm, openssl and ssss, of which i think ssss might be necessary to install manually on tails. The script generates all interim material into /run/shm so that no trace on storage media is left, you have to move the various pieces yourself to their final location, like importing the subkeys into your keyring, distributing the shares for the backup and the revocation cert and the master signing key and it's backup copy. I will try to cover the storage of keys on dedicated USB sticks in a later post. I hope you enjoy your new pimped keys (oh and by the way nothing prevents you from having more than only two subkeys).

Comments and improvements are welcome.

permalink


next posts >
< prev post

CC BY-SA RSS Export
Proudly powered by Utterson