Random GPG Key Creation

Author’s note: this was originally written by me, but then optimized by Distil Networks’ excellent marketing team. However, Distil did not publish it. I am not currently affliated with Distil Networks.

GPG and Encryption

At Distil, we take security and privacy very seriously. Prior to joining Distil, I did not have a very hands on understanding of GPG keys. However, we use keys extensively to ensure that there are no breaches of confidentiality. When we send a message, we want to ensure that only the intended audience gets that data. So my goals in this article were to both dive deeper into understanding encryption, along with conveying that information to a wider audience so we can all make the technology landscape a bit safer.

What is PGP and GPG?

PGP in an acronym for Pretty Good Privacy. PGP is a combination of "hashing, data-compression, symmetric-key cryptography, and public-key cryptography." Conceptually, data is encrypted using a private key, with a recipient decrypting it using a signed key. OpenPGP follows RFC 4880 which outline the open source protocol to encrypt, decrypt, and sign data using PGP.

GPG is GnuPG, a full set of software that implements PGP. At its heart, it's a command line toolset that works well with many other systems to manage and use OpenPGP keys. It's very robust and platform agnostic, and allows for great encryption strength. Herein we'll show you how to use it to manage and create keys.

Practicality or Functionality?

Local encryption can be finicky. For example, many people view security as a trade-off between practicality and functionality. In this document, I will aim heavily toward functionality, while mitigating as much loss to practicality as possible.

Bill of Materials

We'll be using a Raspberry Pi to generate the GPG public and private keys. This is because a circuit exists within its SoC (system on a chip) that generates truly random numbers as it reads thermal noise created within various analog components.

We assume you'll be running Raspbian and that your distro is up to date. After your Raspberry Pi is running and up to date, run the following command in a terminal:

1. sudo modprobe bcm2708-rng
2. Append bcm2708-rng to /etc/modules such that this module loads on startup.

(Note: bcm2708 wasn't available on the author's Raspberry Pi because there was an update that changed the module's name. Instead, we will run sudo lsmod to learn that bcm2835 is available, and then appended –rng to its tail.)

The sudo lsmod output. Note the references to bcm2835.

You'll want to store physical print outs of QR and clear text codes for your private key in a secured physical safe. Ultimately, you'll also store your Raspberry Pi with the single master private key and revocation certificates in the same secured location. Your day-to-day key will only contain the public key and its associated signing subkeys.

Create a Secure GPG Key Pair

For now you'll be working with the Raspberry Pi, as it's going to be easier to leave the key stored internally and subsequently export the requisite generated keys.

1. Within the Pi terminal, run the command sudo cat /dev/hwrng

The sudo cat /dev/hwrng output, running while the Pi generates the desired key pair.

1. Then, in a separate terminal, run gpg2 -–gen-key.
   1. The first command, sudo cat /dev/hwrng is generating entropy for the key creation. This is the command that is pulling thermal data to generate truly random numbers.

Key pair settings.

1. Select (1) (shown above) to create an RSA and RSA key (the private and public key pair).
2. Specify a 4096 bit keysize.
3. For key expiration, it's recommended that the master key be set to expire after one year ( 1y ). If you were to lose your master key,, designating an upper limit for it will prevent subsequent misuse. (It's always easier and safer to extend dates, and only revoke keys as a last resort.)

Next, you'll set a stronger hash preference for the key—since 2005 SHA-1 has been considered insecure against a "well-funded opponent" and NIST recommends against its use. SHA-3 has not yet been introduced into the OpenPGP standard, so that leaves SHA 512 as the strongest hashing algorithm available to GPG. (More information about hashing algorithm differences is available at GnuPG)

1. Find the desired private key ID, and then enter gpg –edit-key {** KEYID **}.
2. Enter setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES TWOFISH ZLIB BZIP2 ZIP UNCOMPRESSED.

(Optional) You may want to generate an additional subkey to add another layer of physical security. For example, one might later be exported to a smart card. A good way to think of subkeys is that act very similarly to the master key, but can be revoked independently of the entire stack. So if you were to lose a physical smart card, you wouldn't have to invalidate all the keys. )

1. Enter addkey.
2. Select (4) RSA (sign only).
3. Enter 4096 bits.

Now you need to enter an expiration date, as before. Since this is to be used as a signing key on the smartcard, your choice is more subjective. A signing key can be used to encrypt and decrypt data, but can be revoked independently from the master key. This is important in cases where you might lose your physical smart card, but want to continue to use the password based subkey. For a physical key, I would recommend a similar one year (1y), but it is up to personal preference.

1. Enter your choice.
2. Save and quit.

Generating Revocation Certificates

Your public key should be available to anyone who wants to verify your identity. Since what you're protecting is your digital identity, it's only used to authenticate what data is truly yours and validates you as the original owner. It is not used to sign or encrypt data. Your public key should be easily accessible, while it is the user's responsibility to ensure your identity.

Why Do I Want My Public Key to be Accessible?

A good way to visualize your public key is that it's like a digital driver's license. It is used to verify the owner. But like you would use a key to unlock a car, you would use a signing key or master key to encrypt or decrypt data. You want your public key to be known, as it's validation that you own that data. And if you have many correspondents that need access to your public key, it may be wise to upload your key to a public keyring. If you have uploaded your public key to a public key server, it'll be replicated among various other key servers—there isn’t a centralized location where you can simply delete your key. Nor is there a "central authority" to invalidate your keys. More information regarding public key servers can be found at the GNUPG website.

Importance of Revocation Certificates

The case for keeping revocation certificates becomes very strong if you lose your master key or signing subkeys. If you upload a public key that somebody else can now use, they would be able to impersonate you using your key identity, allowing the attacker to send data that is assumed to be yours. To prevent this, you would need to upload the public key revocation certificate to the public keyring to invalidate that key pair. .

Similarly to the car analogy, revoking a public key would be like voiding a driver's license, while revoking a private key would be like disabling the lock on that specific car. If you lose your private key, you will need to make sure you upload the private key revocation file to wherever the private key exists.

Creating Revocations Certificates

1. Run gpg –armor –output {DESIREDNAME}.asc –gen-revoke {KEYID}.
2. Print a physical copy of the output.
3. Repeat steps 1 – 2 for each key on the keyring, replacing each {** VARIABLE **} as appropriate.

NOTE: There should be at least three: the master key, the signing key, and the public key.

1. Store the hardcopies in a secure location (e.g., the safe).

Export the Key Pair

Now you'll export the actual public and private key pair—the files that become your master public and private keys—from the Raspberry Pi (do not keep them on the computer you use every day). Exporting the private key is a good idea in case one of the keys becomes corrupted. These will be securely stored along with the Raspberry Pi (i.e., in a safe).

1. Run gpg –armor –export {KEYID} > {DESIREDPUBLICNAME}.asc
2. Run gpg –armor –export-secret-keys {KEYID} > {DESIREDPRIVATENAME}.asc

---

We also recommend printing a QR code that translates to text; this facilitates retyping the keys in later if you lose digital access to the file keys. This is a very simple process; and there are several online applications that convert text to QR codes (which you use at your own risk). If you do not wish to use a web based program for this, there are also UNIX programs that can perform the conversion within the terminal, as described in Linux Magazine.

All told, you'll end up with eight hardcopy printouts: a master key, public key, two signing keys, and revocation keys for each of the former. Add to this total the sixteen additional QR codes (one for each text printout).

The Daily Key

To get a usable key for daily use:

• Run gpg –armor –export-secret-subkeys {** KEYID *} > {* DESIREDSUBKEYNAME **}.asc.

This writes the secondary signing keys (generated earlier) to a file named {** DESIREDSUBKEYNAME **}.asc.

Now you can copy {** DESIREDPUBLICNAME **}.asc and {** DESIREDSUBKEYNAME **}.asc to your daily computer and further distribute the keys from there. To import the keys onto your daily computer:

1. Run gpg –allow-secret-key-import –import {** DESIREDSUBKEYNAME **}.asc.
2. Run gpg –import {** DESIREDPUBLICNAME **}.asc.

To verify that each key was correctly imported:

1. (Public keys) Run gpg –list-keys.
2. (Private keys) Run gpg –list-secret-keys.

NOTE: Under the imported key, "sec#" (as opposed to "sec") means that your master key is missing on that key pair.

You have effectively created a fully-functional key pair (that doesn't contain the private master key) by joining together the created subkeys with the public key.

Public keys shown on the Raspberry Pi. To view private keys, enter gpg –list-secret-keys.

Key trusts on a per-host basis, meaning that if you import a key, it will assume there is no trust inherently. Since you created the key, that means it's fair to assume that you fully trust that the key belongs to you. On the host computer (not the Raspberry Pi, which you have securely stored at this point):

1. Enter gpg –edit-key {** KEYID **}.
2. In the shell, type trust and then save.

Ultimately, it's fair to select that you fully trust the key. (A key trust is the process of validating on a host-by-host basis that you recognize that you own the key.)

Conclusion

You've now seen how to create a secure key pair and properly remove the master key from day to day usage. Once your secondary key pair is validated as working, relocate the Raspberry Pi and the hardcopies of the QR/plaintext codes to the designated secure location (e.g., a safe). Additionally, you may want to create a master key backup, placing it in another trusted physical location that offers availability as needed.

About the Author

Citing his thrill and privilege to be able to work with its fantastic crew of passionate, security-focused people, Colin Murray is a new member of Distil Network's Professional Services Team. The Professional Services Team is responsible for sorting through big data, informing customers about Distil's service functionalities, and making sure a customer's network is not being exploited by constantly monitoring it for anomalies. Colin enjoys explaining security and writing reports. Saying, "I want to empower our users to do their business while we fight the bad guys," his dream is that we can all use our computers as informed users without the perpetual fear of being hacked.