Generating More Secure GPG Keys: Rationale

This is part of a series on GNU Privacy Guard:

1. Getting Started with GNU Privacy Guard
2. Generating More Secure GPG Keys: Rationale (this post)
3. Generating More Secure GPG Keys: A Step-by-Step Guide
4. Using an OpenPGP Smartcard with GnuPG

In my last post on getting started with GNU Privacy Guard, I mentioned that I’d like to go into more depth about how to use GnuPG more securely. In this post, I’ll show how I recently set up my new OpenPGP key and smart card.

Risks of Naive GPG

First, let’s talk about some of the risks of using GPG in the naive way I demonstrated in my last post.

Endpoint Security

Once we start using GnuPG to encrypt and sign our data, one of the largest remaining risks is “endpoint security” — namely that our laptop might be compromised and our secret key exposed to an attacker. We generated our key on the laptop we use for a variety of purposes on a daily basis.

General Purpose Computing -> Large Attack Surface

I won’t get into exactly how we might be vulnerable here, but if we start to think about the variety of things we use our computers for on a daily basis — how many different applications we run and networks we connect to — we can start to develop a sense for how vulnerable our laptops and workstations might be.

Trusting Complex Systems

We often take our computers for granted. Modern personal computers are extremely complex systems consisting of many layers and components. If we’re concerned about the security of these systems, there are lot of entities we have to trust. Application developers, Operating System developers, Hardware vendors, and vendors of vendors of vendors (ad absurdum) for both hardware and software.

“That’s probably the most frustrating thing. We have no choice but to mistrust everything.” – Bruce Schneier

Even your hard drive might be hackable.

Worst Case Scenario

In the case of our use of GPG, the worst case scenario is that our secret key is stolen, allowing an attacker to decrypt any messages encrypted using our public key, impersonate us by applying our digital signature to communications or even code and software they’ve tampered with. They might also be using our key to gain access to services we’ve authenticated with. This could mean the equivalent of having every one of our passwords stolen.

Mitigation

What can be done to mitigate these risks? I’d like to walk through a few measure that I’ve taken to make my own GPG configuration more secure. These measures might be overkill for some or insufficient for others.

You should consider what resources potential attackers would be willing to expend in order to compromise your security measures and what risks and liabilities you stand to incur if they do. For a more formal approach, you might look at the ISO/IEC 27000-series of standard best practices for information security management.

In my case, while I don’t consider myself a particularly high-value target, I’ve enjoyed learning more about how to keep my data secure, and I can sleep better at night knowing that I’ve taken a few tangible steps to improve my personal information security.

1. Remove Secret Part of Primary Key & Keep it Offline

One way to increase the security of our GPG setup is to use short-lived subkeys for day-to-day use while keeping our primary offline and protected.

Doing this allows us to build trust in our primary key that we can transitively transfer to subkeys without risking the loss of all of the trust (i.e. signatures) we’ve built up in the primary key.

Expiring and rotating our subkeys on a regular basis allows us to lessen the impact of a potential compromise of these keys. If an attacker were to gain access to our current set of subkeys, they would only potentially be able to decrypt messages sent to us since those keys were created and before they expire rather than all of the encrypted messages we’ve ever received.

We can also revoke just these compromised subkeys without needing to revoke our entire key.

2. Keep Subkeys on a HSM

Another way we can increase the security of our cryptographic keys is to use a Hardware Security Module (HSM) that keeps the private key material entirely inaccessible while allowing us to use the keys for signing, decrypting, etc. via commands sent to the device.

There are many different types of HSMs with a variety of features. The solution I settled on is somewhere between a “SmartCard” and a security “token.” In fact, it’s a (mini-)SIM-sized SmartCard, plus a small USB card reader that together function effectively as a USB token. Specifically, I purchased the OpenPGP SmartCard V2 and Gemalto USB Shell Token V2 from kernel concepts.

An open specification for the OpenPGP SmartCard v2.0 is available from g10code, a consulting company founded by the principal author of GnuPG, Werner Koch.

After setting up this new system, I’ve found it to be a surprisingly convenient way to increase the security of my GPG keys. Next I’ll walk through how I generated a new key and how I’ve set up the SmartCard for daily use.

Read the rest of this series on GNU Privacy Guard:

1. Getting Started with GNU Privacy Guard
2. Generating More Secure GPG Keys: Rationale (this post)
3. Generating More Secure GPG Keys: A Step-by-Step Guide
4. Using an OpenPGP Smartcard with GnuPG