We conclude our look at using public-key cryptography to secure your mail and text by delving into managing your GnuPG keys — the foundation of its security.
Over the past few editions of Networking Notes, we’ve covered the installation and configuration of GnuPG, a Free Software implementation of Pretty Good Privacy, a public-key cryptography protocol you can use to secure your mail and text.
This week, we’re going to delve into managing your GnuPG keys … the foundation of its security. You’ll need a few things installed to follow along. First, you’ll want to install MacGPG from the MacGPG site, including the files labeled “GNU Privacy Guard” and “GPG Keychain Access.”
You’ll also want to go ahead and install GPGMail, a plugin that works with Apple’s Mail.app and provides a means to sign and encrypt e-mail messages.
If you need a refresher on GnuPG, or want more detailed guides on installation, part one of these columns covered what public-key cryptography is and how to get MacGPG. Part two spent time installing and configuring GPGMail.
We’re going to start from the assumption that you’ve installed all the software and have generated a GnuPG key.
Sharing and Managing Keys
At the core of GnuPG’s capability to secure your messages and files or verify the integrity of messages you sign with it is the concept of public and secret keys. Whenever you generate a GnuPG keypair, you’re creating one of each:
- The secret key needs to be closely held. When you generate it, you can give it a password and that password should be a strong one. The Mac Password Generator can help you with that. No matter how strong the password, you should also take care to avoid making the key publicly available. Some people keep theirs stored on a portable USB drive. You don’t need to go that far, but it’s not something you should put in a publicly shared place, either.
- The public key isn’t supposed to be a secret. In fact, to use GnuPG encryption successfully, anybody you’re going to be sharing encrypted mail with has to have a copy of that key.
Managing your keys is a job for the GPG Keychain Access app. With it you can create keys, collect public keys from your correspondents, and search public key servers to add to your collection of public keys from others. Your collection of keys, including the public keys of others and your own secret keys, is called a keychain. You can also use GPG Keychain Access to export your public key into a format others can use to add it to their own GnuPG keychain. Finally, GPG Keychain Access offers a way to find keys over the Internet using public keyservers.
Distributing keys can be a challenge. A public key in ASCII format takes up over a thousand random characters, so it’s not something you want to type in by hand or repeat back to a colleague over the phone. You can also post a public key to your Web site, but that presupposes that you have a Web site and that it is completely secure.
So that’s where public keyservers come in. They provide a place to store a public key in such a way that others can easily retrieve it and add it to their keychains. GPG Keychain Access provides a way to automate uploading your key to a keyserver.
To upload a key you’ve already generated, open GPG Keychain Access, click on the “Secret” tab, and click on the key you’d like to upload. Click the “Key” item in the menu bar and select “Send to Keyserver.” Since GPG Keychain Access is just a graphical front-end to command line tools, a terminal window will open up and you’ll see something like this:
gpg --send-key F4F1BA89F8E0631DD077906C876A9CF2C03D4D7D You have mail. caladan:~ mph$ gpg --send-key F4F1BA89F8E0613DD078906C876B9CF2C03D4D7D gpg: sending key C03D4D7D to hkp server wwwkeys.us.pgp.net
That’s all there is to it. Your key is now residing on a public server.
You can also search for and download keys from a public keyserver and import them into your keychain. Let’s say, for instance, that I wanted to find a public key for one of my coworkers. I could ask them for it, but if they’ve already uploaded it to a keyserver, I can retrieve it there.
Click the “Key” item in the menu bar and select “Search for Key.” A text entry box will pop up asking for search terms. If you know the e-mail address of the person whose key you want to retrieve, you can type that in. You can also search on a fragment of an e-mail address or a name.
For the sake of example, since I know the domain of the person whose key I want to import, I’ll search on that: jupitermedia.com.
As with uploading a key, a terminal window will open and execute a shell command. This time, here’s the output I might get:
caladan:~ mph$ gpg --search-keys @jupitermedia.com gpg: searching for "@jupitermedia.com" from hkp server wwwkeys.us.pgp.net (1) Michael Hall (Managing editor with Jupitermedia) <email@example.com 1024 bit DSA key C03D4D7D, created: 2008-01-16 (2) Steve Smith <firstname.lastname@example.org> 2048 bit RSA key 6CEBA8D5, created: 2004-05-27 (3) Peter Rabbit <email@example.com> 1024 bit DSA key 5E3E1D21, created: 2003-01-07 Keys 1-6 of 6 for "@jupitermedia.com". Enter number(s), N)ext, or Q)uit >
We’ll assume I wanted to import Steve Smith’s key. If I type “2” (the number next to his name) and return, I see:
gpg: requesting key 6CEBA8D5 from hkp server wwwkeys.us.pgp.net
It can take a little while, but eventually I’ll get this output:
gpg: key 5244496A: public key "Steve Smith <firstname.lastname@example.org>" imported gpg: Total number processed: 1 gpg: imported: 1 </email@example.com>
Checking under the “Public” tab of GPG Keychain Access, I see an entry for my newly imported key.
A Matter of Trust
And all this brings us to a core issue with any kind of public-key encryption: How do we know that a public key is legitimate? When you import a public key into your keychain, all you’ve done is guaranteed that data encrypted using that key can be decrypted by the person who controls its secret counterpart. A sophisticated attacker could, conceivably, figure out a way to substitute his phony public key for an intended recipient’s legitimate one. While the keyservers are convenient, they do nothing to validate the identity of the people submitting keys to them. If you need absolute trust that the public key you have in your keychain belongs to someone, you have to take steps to verify that.
Fortunately, GnuPG makes this somewhat easy. Each key it generates has a fingerprint. Before using someone’s public key to encrypt sensitive data, you should confirm the key’s fingerprint with them.
In GPG Keychain Access, you can see any key’s fingerprint by adding the “Fingerprint” column to the list of items displayed in the public and secret key lists. Click the down arrow at the right end of the headings in either the public or secret panes and make sure “fingerprint” is selected. You can then read that fingerprint back to your correspondent, who can verify it for you.
Another way people can verify the authenticity of keys is through key signing.
When you sign a GnuPG key, you’re certifying that the key belongs to the person it claims it does. You can then upload the signed public key to a keyserver. The more certifying signatures a public key has, the more it can be said to be trustworthy, provided you trust the people who have signed it.
You can sign any key you’ve verified using the fingerprint method. You can also go to “keysigning parties,” which are events where GnuPG and other PGP users gather to confirm the authenticity of each others’ keys. Keysigning parties are common enough occurrences at developer conferences, and you can find people interested in keysigning via sites like Meetup, which has a listing for OpenPGP Meetups by city. You can learn more about keysigning parties by reading the GnuPG Keysigning Party HOWTO, which includes a much more detailed explanation of the web of trust that underlies keysigning, as well as information about what you’ll need to bring along.
Michael Hall has been using, maintaining and writing about networks for nearly 15 years. He’s the managing editor of Enterprise Networking Planet and he blogs about Internet privacy and security at Open Networks Today.