This blog post was inspired by two op-eds on arstechnica. One arguing that PGP’s1 weak link is the difficulty to ensure the security of the secret key over its lifetime. A compromised secret key is a catastrophic event, making all prior encrypted messages accessible. Additionally, there are disqualifying UX issues. PGP is difficult to use, creating opportunities for mistakes to creep in. The author suggests alternatives for secure messaging, for example Signal or OTR.
A second op-ed shortly after takes the opposite position, pointing out that PGP has unique capabilities, that are not addressable with alternatives. Go read both of those articles, they are worth your time.
I stand strongly on both sides. Like many things the matter isn’t just black and white, but contains shades of gray. More so, since GnuPG, the free implementation of the OpenPGP standard is in constant development, acknowledging and addressing some of the issues raised. Considering that PGP was developed in 1991, it is reassuring that despite the large amount of effort poured into trying to break it, PGP is still regarded as secure against direct attacks of the underlying cryptography. With that in mind I decided to start using it for the sake of understanding how it works, and to experience its advantages and shortcomings in daily use first hand. This blog post will address the points made in the op-ed that I have gained personal experience with, specifically the interaction of email with OpenPGP, the UX issues that come with that as well as what I have done to simplify the long time security management of my private OpenPGP key.
OpenPGP encrypted email is not widely used. For one, if you want to exploit all the bells and whistles of what OpenPGP offers to encrypt email it does get complicated. And since few use it to securely send emails, we are left with the classical chicken and egg dilemma. But the landscape is changing. More and more email providers support OpenPGP encryption out of the box (ProtonMail, Hushmail are two examples), making it possible to send and receive encrypted emails without spending a lot of time learning all the ins and outs. My email provider of choice (countermail) goes one step further, also encrypting emails that come in without encryption. The encryption key can even be a self-generated public key, making it impossible to decrypt emails without the corresponding private key stored on a personal computer (or stored on a Yubikey as we’ll explore later in this blog post).
The upshot is that everyone can take advantage of encrypted email. Simply sign up with an email provider that takes privacy serious and supports encryption (here is a list). Use this as a first step to get comfortable, then start exploring the more advanced features of OpenPGP.
That being said, in a world dominated by email providers that forego cash in favor of knowledge about their users’ private data, and users that are more than willing to engage in that trade, I don’t have much hope that email encryption will become mainstream anytime soon. But that doesn’t stop us from having some fun and go all out, taking advantage of OpenPGP’s gpg-agent to disguise as the ssh-agent, and top it off with storing the private keys on the Yubikey.
I wrote about the YubiKey (made by Yubico) and it’s use as a two factor authentication token before (see my Yubikey blog post). Two factor authentication is only one of the cryptographic functionalities the Yubikey provides. A Yubikey also supports the CCID smart card protocol and can act as an OpenPGP smart card to store keys that are compatible with the OpenPGP standard.
Storing keys on a smart card is a big step up in security as the keys can’t be extracted from the smart card. Stealing the keys means stealing (and keeping) the smart card. That is something you are more likely to notice than if someone made a copy of your keys stored on a hard drive. It is also something that requires physical access by virtue of the smart card design.
Interoperability with a smart card is one of the features that differentiates PGP from alternatives like Signal and OTR and minimizes the ability for a third party to circumvent the encryption, as pointed out in the aforementioned arstechnica op-ed. It also diminishes the main point made against PGP, as smart card storage of the private key strengthens the ability to keep the private key secure over its lifetime.
A smart card is also easy to transport, limiting the proliferation of secret keys to every device where you want to perform functions that require access to the private keys.
There are many tutorials freely available that can walk you through generating OpenPGP keys and storing them on a smart card. This link points to the best tutorial that I found. If you follow the instructions, you will end up with three private keys stored on the Yubikey; a signature key, an encryption key and an authentication key. I mostly use the authentication key to log on to remote servers via ssh and the encryption key to read my encrypted email.
On my mac the installed gpg tools are smart enough to realize that the Yubikey with the encryption key is plugged in. My email client mailmate will then automatically decrypt any incoming encrypted email. Without the Yubikey, a message states the email could not be decrypted as the corresponding private key was not found. That is exactly the behavior we want.
As I said before, hardly anyone sends OpenPGP encrypted emails. So let’s focus on the authentication key, which is useful on its own right.
Interactive remote access to computers is typically done via secure shell (ssh), which creates an encrypted channel through which all data is tunnelled. The encryption is strong enough that the weakest link remaining is the authentication process. If a password is used for authentication, the usual password related issues arise. A short and easy to type passord is weak and gives an attacker the chance to get access by brute force. A long and cryptic password is inconvenient, and few people will accept that inconvenience if ssh connections have to be created frequently.
As an alternative ssh provides authentication through public keys. A public key is placed on the remote computer, while the private key remains on the computer from which the connection originates. A nice tutorial to set up public key authentication for ssh can be found on the ubuntu wiki. Beyond what the tutorial spells out, I usually turn off root login, password authentication and challenge response authentication (see here for why) in the config file for the ssh daemon. In the end this leaves access to the remote computer restricted to public key authentication.
ssh connections authenticated via public key encryption are secure and convenient. The latter due to the ssh-agent, which eliminates repeated password entries during a login session. However, that means the private key has to be stored on every computer from which a connection to the remote computer originates. That is inconvenient at best, a security risk if one does not have full control over those computers.
The gpg-agent offers a way out. It can be configured to work as a drop-in replacement for the ssh-agent, which means it will work with the majority of ssh clients. Different than the ssh-agent, the gpg-agent does know how to interact with a smart card. In practical terms that means that the private key used to authenticate when establishing a ssh-connection can reside securely on the Yubikey. All that is required is to plug the Yubikey into a USB slot. Since the gpg-agent understands about an OpenPGP smart card, a ssh client requesting the private key will prompt the gpg-agent, which in turn looks for an authentication key on the Yubikey. If found, that key will be used by the ssh client to authenticate with the remote machine.
You still will have to visit each machine once to set up the gpg-agent, but instead of installing ssh keys you will enable the gpg-agent so that the authentication key, safely stored on your Yubikey is accessed for ssh authentication.