Key signing party for small teams
To make key signings as efficient as possible it’s important that all participants comes prepared. We avoid using Key Servers, since they are flakey, slow and might publish more information than you want. Before the event all users should have received a list of keys that will be signed, and imported them into their own keyring.
Most people don’t carry around their master key, or prefer to keep it air-gapped. These people will provide their signature later. During the signing party everyone will take a secure note of KeyID and fingerprints that they have checked. In order to speed things up and help for those with offline keys a list of KeyID and fingerprints can be prepared as a hardcopy, where the participants can take notes.
The benefit of GPG in the workplace
Most companies do a decent job with background checks and general vetting of people before hiring them. And physical security in buildings is often more than good enough, someone will notice if you go around pretending to be me at the office. On the Internet however that is a lot harder, so you need to have some kind of digital proof, something that cannot be copied or easily stolen.
You also get the added benefit of a second vetting. Security works best in layers, it’s best to not assume anything. If the user loses their key or doesn’t have it you just have to do another Key Signing. At least if you want to do anything online for this user.
And that’s GPG, when used in combination security tokens, like YubiKey. Users store the private keys (or signing keys) on security tokens, which cannot be copied, and when lost, is easily noticed. The token is protected by a PIN-number, and the private key stored on the devices cannot be extracted or otherwise removed from the device. The owner of the key can configure how many PIN attempts to allow before the key is locked. On keys like YubiKey you can also set an admin PIN which lets you reset PIN attempts. Signature counters (including number of bad PIN entries) can only be reset by factory resetting the device, which also removes key material.
A very typical scenario is that someone needs to reset or unlink an MFA device from their account. Since it’s easy to impersonate someone over the Internet you need a way to provide proof that the user is who they say they are. This can be done using asymmetric encryption. The idea is that all users exchange public keys in a secure manner, like in person or using Web Key Directory, and that all requests are signed using their private key. This way everyone can verify (to some extent) that the person are who they say they are. We can also encrypt messages using the recipients public key, you sign the message or file to prove who you are and you encrypt the message to ensure that only the recipient can read it.
Lets do the Key Signing Dance
To check that the key holder is who they say they are, we meet up face-to-face, and do the key signing dance:
- The other participants import the key holders public key into their local keyring, using either of these alternatives:
gpg --import foobar.gpg
gpg --locate-keys firstname.lastname@example.org
gpg [--keyserver <pgp.mit.edu|pool.sks-keyservers.net>] --recv-keys email@example.com
curl https://github.com/foobar.gpg | gpg --import
- The key holder confirms their KeyID and fingerprint by reading it out loud
- The other participants verify the key holders valid ID, like a drivers license or passport
- The other participants takes a note that they’ve verified this key
When all keys are verified the participants either sign and export the signature at the venue and hand them over to the key holder, or wait until they have access to their master key and do it then. Out of curtesy it’s common to not publish key signatures to public key servers, but rather export the signature and send it via email to the key holder. Then they can import the signatures and publish it key servers and web key directory at their own will.
- Sign the key holders public key, using the
gpg --sign-key KeyID
- Encrypt the key and send to key holder via email
gpg --export --armor <UID|KeyID> > <UID|KeyID>.key
gpg --encrypt --recipient <UID|KeyID> <UID|KeyID>.key(creates KeyID.key.gpg)
gpg --export --armor <UID|KeyID> | gpg --encrypt --recipient <UID|KeyID> -o <UID|KeyID>.key.gpg
- Listing keys and fingerprint
gpg --list-keys [UID|KeyID]
gpg --list-keys --fingerprint [UID|KeyID]
- Exporting keys
gpg --export --armor <UID|KeyID>
gpg --export --armor SUBKEYID! [SUBKEYID! ..]
- Listing and importing key signatures
gpg --list-sig <UID|KeyID>
gpg --import --import-options merge-only foobar.gpg
gpg --decrypt foobar.key.gpg | gpg --import --import-options merge-only
- Signing and encrypting a file, where UID|KeyID is recipient of file
gpg -se -r <UID|KeyID> [file]
- Creating a clearsign; a message that contains both message and signature
gpg --clear-sign [file](write message and finish with ^D)
Replacing a YubiKey (HSMs)
If you’re using multiple YubiKeys with the same key material on them you need to tell gpg-agent about the serial number of the key you want to use, since they are tied together. The easiest way is to just tell the agent to relearn the new serial numbers.
- Replacing YubiKey using gpg-agent-connect to relearn
- Plug in spare / replacement YubiKey
gpg-connect-agent "scd serialno" "learn --force" /bye
- Replacing YubiKey by removing key stubs
- Find keygrip
gpg --with-keygrip --list-secret-keys KeyIDfor all keys
- Locate stubs in
~/.gnupg/private-keys-v1.d/and delete them
- Insert new YubiKey
- Find keygrip
Why shouldn’t you publish signatures to Key Servers on other users behalf?
I was a little puzzled by this myself, as it seems strange that key servers allow a usage pattern that is not recommended. Apparently there are two primary reasons, most notably that you’ve likely only verified their name and identity, not the ownership of the e-mail account used as their UID. When you send the signature to the key holder via e-mail only the holder of that e-mail account would be able to publish the signature, proving that they own that account. And last but not least, there is a privacy concern. The Key Holder might not want the world to know that you two know each other. So we make it up to them to decide.Published: 08 August, 2019