Jump to: navigation, search

OpenPGP Web of Trust

Revision as of 01:08, 31 October 2013 by Fungi (talk | contribs) (add top level heading)

OpenPGP Web of Trust

As a distributed, online community grows it develops an increasing need for its members to be able to recognize one another electronically. The OpenPGP Standard is the mechanism preferred for this throughout most of the global free software culture. The OpenStack project relies on OpenPGP signatures for activities such as:

GNU Privacy Guard

While there are a variety of utilities and even devices available to create and manage OpenPGP keys and signatures, this document will provide examples for GNU Privacy Guard (sometimes abbreviated GnuPG or GPG) as the most popular and portable toolset. These recommendations should translate generally to most other solutions as well.

GNU Privacy Guard Installation

Use the latest available GPG 2.X version for your platform (as opposed to the less feature-rich 1.X series). On modern Debian and Red Hat based operating stystems the package name is gnupg2 but the command-line utility is invoked as gpg2.

On embedded systems or other resource-constrained platforms, a recent 1.X version can be installed instead as a lighter-weight alternative. Note that on Debian derivatives, the gnupg (1.X) packages lack HKPS support, so if you want to use them with the example configuration below you'll also need the optional gnupg-curl package.

GNU Privacy Guard Sample Configuration

# A basic ~/.gnupg/gpg.conf using stronger than default message
# digests and transport protocols. For the most part, defaults in
# modern versions are chosen for an optimal balance of security and
# interoperability, but you may wish to override them in favor of
# slightly more secure modes of operation. This example should
# evolve over time, as new cryptographic recommendations emerge and
# software defaults shift to adopt them.

# Use a strong message digest algorithm (not MD5 or SHA1) when
# signing keys.
cert-digest-algo SHA512

# Override the algorithm priority order in recipient key
# preferences. The first hash in this list is also used when
# signing without encryption.
personal-digest-preferences SHA512 SHA384 SHA256 SHA224

# Define the priority order for hashes, ciphers and compression.
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

# Receive, send and search for keys in the SKS keyservers pool using
# HKPS (OpenPGP HTTP Keyserver Protocol via TLS/SSL).
keyserver hkps://hkps.pool.sks-keyservers.net

# Set the path to the public certificate for the
# sks-keyservers.net CA used to verify connections to servers in
# the pool above.
keyserver-options ca-cert-file=sks-keyservers.netCA.pem

# Ignore keyserver URLs specified in retrieved/refreshed keys
# so they don't direct you to update from non-HKPS sources.
keyserver-options no-honor-keyserver-url

# Display key IDs in a more accurate 16-digit hexidecimal format
# and add 0x at the beginning for clarity.
keyid-format 0xlong

# Display the calculated validity of user IDs when listing keys or
# showing signatures.
list-options show-uid-validity
verify-options show-uid-validity

# If you have multiple keys (maybe you replaced an older, weaker
# one), specify the one you normally use. You can still override
# this with --local-user when needed.
#default-key 0xfedcba9876543210

The HKPS configuration above also requires a CA certificate so GPG can confirm the validity of keyservers with which it communicates. Retrieve it with:

wget -P ~/.gnupg/ https://sks-keyservers.net/sks-keyservers.netCA.pem{,.asc}

Then confirm it's legitimate by verifying the signature provided with it:

gpg2 --verify ~/.gnupg/sks-keyservers.netCA.pem{.asc,}

The output should indicate that it was made using RSA key 0x0B7F8B60E3EDFAE3.

Key Generation and Publication

The manpage for gpg2 provides wonderfully detailed usage information, but here's a few tips to get you started if you've not used it before...

  1. If you don't have a key already, use gpg2 --gen-key to create one. The Ubuntu community has a great walkthrough you can follow, but the general takeaway is that default key generation options in modern versions of GPG are sane and secure enough so you'll just be hitting the enter key from there on mostly.
  2. If you just created your key, or even if you already have a key and you generated it within the last few years (it's probably good enough) there's a great set of recommendations you can use to make your workflow even more secure.
  3. If you have a key which is... older... (you know who you are), that dusty old 1024-bit relic with signatures from people you met at conferences a decade ago is not a badge of honor--instead, the cool kids are laughing at you from high atop their shiny new keys. Generate and transition to something slightly less stale and musty. You'll be glad you did.
  4. Some people might feel obligated to choose a 4096-bit key size for extreme future-proofing, but honestly the 2048-bit default should be fine for a while.
  5. When it prompts for a real name, you want to make sure you enter one which matches as much as possible what you use on official identification (government-issued photo identification for example).
  6. It's best to leave the comment field of the user ID blank unless you need it to clarify your official name in some unusual way.
  7. Make sure to publish your key! gpg2 --send-key 0xfedcba9876543210 (or whatever your key ID is) should be all you really need if you followed the configuration recommendations earlier.
  8. If you don't know your key ID, gpg2 --list-keys you@example.com (substituting an E-mail address you associated with that key) will show you. It's the line which starts out pub followed by the keysize and a letter indicating the key type (it'll be something like 2048R). The hexidecimal number following the slash (/) on that line is your key ID.

Key Signing Process

Using a signature to attest to the validity of another key, key signing, is what forms the web of trust. It enables you to determine the relative authenticity of a signature from someone you've never met, based purely on transitive signatures from other people you have met. At some point the OpenStack community will begin to hold regular key signing parties, and this section should go into detail on our practices for them. Something along the lines of this keysigning party howto.

Ad-hoc key signing is also highly encouraged--summits and local user group meetings are great places for this too--here are a few suggestions to make this easier...

  1. Keep official photo identification with you, appropriate to the setting. If it's an OSUG meet-up, then your local government ID (perhaps a driving license) or even university ID might be fine. If at a large conference with international attendees then a full passport book would be better. The goal is to provide some reassurance to those signing your key that you are who you say you are, so it's best if you have identification with a photo which looks like you, is not trivially falsified/counterfitted, and which is fairly clearly provided by an authority known to the signer so they can hope to confirm its legitimacy. Bringing more than one form of identication can also help.
  2. Carry slips of paper or maybe business cards with your name as it appears on your photo identification and OpenPGP key, along with the associated key ID and preferably also its fingerprint (which can be obtained by running gpg2 --fingerprint 0xfedcba9876543210 substituting your real key ID in the command).
  3. When signing someone's key, look at their photo identification. Check that the picture on it looks like the person providing it. Check that it at least seems legitimate and comes from an authority known to you in some way (for example, a work badge provided by their employer is unlikely to be a great choice unless you work at the same place, since you probably haven't seen one before and don't know the circumstances under which they're issued). If you're not comfortable with the ID provided ask for an alternate form of identification instead, and feel free to choose not to engage in a key signing unless you're fairly certain of its authenticity. Make a note of the name on the photo ID and get their key fingerprint (this is easy if they brought them already printed out for you), for use later when you will actually sign their key.
  4. At some point after the exchange of information and ID verification (could be minutes or months), retrieve their key from a keyserver into your local keyring. This can be accomplished with gpg2 --recv-keys 0xfedcba9876543210 (or whatever their key ID is). Use the command mentioned earlier to see the fingerprint and real name on their key and compare it to the notes you made. Make note of the addresses in each uid line as well and send an encrypted+signed E-mail message to each one containing different, unique, long random strings and asking them to send you an encrypted+signed reply containing the same random string (learning to send and receive OpenPGP E-mails is left as an exercise for the reader). This is easier if you keep a list of what random strings you sent to which addresses for various people. If the replies comes back from all addresses on their key and the strings match, then feel free to sign their key with gpg2 --sign-key 0xfedcba9876543210 (substituting their actual key ID of course).
  5. If you find you're doing this a lot, you may want to settle on and publish your own signing policy detailing your personal choices.