Category: Security

OpenPGP Key Signing Parties

After posing Monkeysphere: Easing key management and improving HTTPS security I received some constructive feedback from an acquaintance. The message was clear enough; I need to make an effort in getting more signatures for my key so that it is possible to validate it based on the Web of Trust.

 

There are several ways to get the key better connected, but a popular method is to set up, or simply participating in, key signing parties (KSP). The Keysigning Party HOWTO is a good read, so I won't go into the descriptives too much, except to say that I'm a fan of the List Based Method Party described in the howto. This require a bit more organization ahead of the key signing party, but overall the experience should be a smoother one. The basic idea with this approach is that you have one, or several, organizers that collects the public keys of the participants ahead of time and prepare a list of keys for the participants. Normally there will be a set of requirements for these keys e.g. that they are available on public keyservers such as the sks-keyservers.net pools.

Those wanting to participate then send a copy of the key itself or the keyid or fingerprint for such a key so that it can be retrieved from the keyservers. From an organizer perspective the steps are then to start building up a database of participants, e.g. in a GnuPG keyring, which is what I'll use.

 

Step 1: Create a directory for information about the key signing party

mkdir -p $HOME/Tmp/KeySigningPartyRing

Step 2: For each of the participants, download the keys into a gpg keyring in this home dir

I'm starting with my own keys

gpg2 --homedir $HOME/Tmp/KeySigningPartyRing --keyserver eu.pool.sks-keyservers.net --recv-key 0x0B7F8B60E3EDFAE3

gpg2 --homedir $HOME/Tmp/KeySigningPartyRing --keyserver eu.pool.sks-keyservers.net --recv-key 0x43FE956C542CA00B

These keys are then stored in pubring.gpg in the homedir specified.

 

Step 3: Creating the participant list

To create a list of participants based on the information found in the keyring I personally use a PHP Script that is available at https://bitbucket.org/kristianf/keysigningpartylist

This script take the homedir as an argument, so I run it as

php -f /path/to/keysigningPartyList.php $HOME/Tmp/KeySigningPartyRing

The script can be configured by a file called ksp_conf in the same homedir,  I set the variables as

title: My KSP
date: 2013-12-31

Step 4: Digitally sign the participant list

In order to ensure that the list has not been modified after it is uploaded to a http/ftp location that the participants have access to I then sign the two files generated from the script, which unless otherwise configured in ksp_conf is key_party_list.html and fpr.txt I also sign these files using gpg. To do this, while having the homedir as my working directory,  I run

for f in key_party_list.html fpr.txt; do gpg2 --armor --detach-sign $f; done

 

Step 5: Upload the participant list

I can then upload the participant list, the fingerprint list (this is a convenience file, more on that later) and the relevant digital signatures.

for f in key_party_list.html* fpr.txt*; do scp "$f" "server:/path/to/openpgp_key_signing_party_example/"; done

The result can be seen at http://dev.kfwebs.net/openpgp_key_signing_party_example/ . Each participant will then print the participant list, or the organizer print them and bring along to the key signing party.

Step 6: Holding the KSP

During the KSP each participant then bring a copy of their own fingerprint and key data that can be used to match against the list and verify the ID documents to make sure they match the UID.

 

Step 7: Signing the keys and uploading this for others to see

After the KSP is done, and all keys have been verified, it is time to sign the other's keys. This is where the convenience-file fpr.txt comes in, as this can readily be passed on to tools such as caff and monkeysign or it can just be used to retrieve all the keys from a keyserver.

Monkeysphere: Easing key management and improving HTTPS security

Update 2014-05-24

To make it easier to add the overlay it is now included in Layman (make sure layman is compiled with the mercurial use flag). It can then be added using layman -a k_f

End of Update

Lately I've been paying some more attention to Monkeysphere. Since it has been some time since my last blog post, I figured this was a good opportunity to share some new ideas.

I've already been using parts of the framework for some of my websites, including sks-keyservers.net for quite some time. The reason for this is to offer an alternative to the traditional way of validating the authenticity of HTTPS server certificates, by utilizing the more decentralized approach of OpenPGP's Web of Trust (WoT). In particular with the recent Snowden/NSA/GCHQ revelations, an alternative to the Root CA (Certificate Authority)  structure being used today is interesting to investigate further.

The Monkeysphere project's goal is to extend OpenPGP's web of trust to new areas of the Internet to help us securely identify servers we connect to, as well as each other while we work online. The suite of Monkeysphere utilities provides a framework to transparently leverage the web of trust for authentication of TLS/SSL communications through the normal use of tools you are familiar with, such as your web browser0 or secure shell.

For this part, Monkeysphere imports the cryptographic details from my usual X.509 SSL Certificate used to identify the https connection and generate an OpenPGP certificate containing the same data, after which I've signed the OpenPGP key using my personal key and uploaded the certificate to the usual keyservers. This way, anyone that has validated my own OpenPGP key (if you don't have one on your own yet, you should create one) can find a trust path and compare the key data of the OpenPGP key to the X.509 certificate provided during SSL/TLS negotiation. When a match is found, we know that this is the intended key and can continue to browse safely.

Although it is possible to validate this manually, that can obviously be cumbersome, so I'm using the components msva-perl and the Firefox extension for Monkeysphere, titled xul-ext-monkeysphere, that automates the process. For information on how to set this up for yourself, see the documentation on Identifying secure web servers through the Web of Trust.

Somewhat more hidden to the everyday user, is however one of Monkeysphere's greatest advantages; using OpenPGP to ease key management for the Secure Shell Protocol (SSH). As my key has an authentication subkey that I use to log into my servers, it helps me automate how I access my servers. It is prudent to utilize Public Key Infrastructure and deny any password-based authentication to get into the server, to make it more difficult for an adversary to brute-force their way into the server, or simply to reduce the resources needed on the server to handle such attempts by automated robots. By specifying a trusted introducer on each server I can specify the OpenPGP User IDs that are permitted access for a given user. This also enable me to easily add new users without requesting that they provide me with their SSH keys, and managing the updating of such keys whenever they change across a number of servers. More importantly, if a user detect that their key is compromised and revoke it, it is automatically handled across all my servers as well, limiting the security impact. And the best part, it is rather  easy to set up. 

Monkeysphere also works for authenticating the server itself based on the Host key for SSH so that I don't have to remember the fingerprint of the host key whenever I clear out my known_hosts file.
If you haven't already, I recommend looking into this approach. If you're using Gentoo, as I am on most of my servers, I've created a repository for a Portage Overlay available at https://bitbucket.org/kristianf/portage-overlay/

In order to use this, you'll want to pull the repository into some location using

hg clone https://bitbucket.org/kristianf/portage-overlay/

You can then create a symlink to e.g. /usr/local/portage and include this in your /etc/portage/make.conf file using

PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"

you should then be able to emerge the packages using e.g.

emerge monkeysphere

Note that for now I've masked the packages with the ~arch attribute, so you'll need to unmask them as per instructions provided by portage, or by adding the following to your /etc/portage/package.accept_keywords in order to unmask all packages in this overlay for your ~arch:

*/*::kristian_general_overlay

In order to update the repository and get updates you'll want to run

hg pull && hg up

in your local repository directory from time to time before wanting to updated your installed packages.

 

 

New OpenPGP key generated utilizing Elliptic Curves

I have generated a new OpenPGP key that I will start migrate over to immediately, however, I do not really expect to revoke my current keys within the next few years for reasons found below. But before getting into that - the new key info. As per my usual setup the encryption subkey has a one year expiry. (I've also updated the keys 0x16E0CF8D6B0B9508 and 0x0B7F8B60E3EDFAE3 with new encryption subkeys for next year)

pub 521E/43FE956C542CA00B created: 2012-10-07 expires: never usage: SC
sub 521e/063FC02F1BFDEAA8 created: 2012-10-07 expires: 2013-12-30 usage: E

Why do I expect such a long migration path?

This key is an Elliptic Curve Public key following RFC6637. It is using a NIST curve of an ECC strength that is 521 bits, which relative to an RSA key should be about 15,360 bits. My RSA key that is this length apparently isn't supported in newer versions of GnuPG (version 2.1, that is using GPG Agent for storing the secret keys)

Currently the only implementation I'm familiar with that accept ECC keys is GnuPG 2.1, which is still in Beta. The SKS keyservers handle this type of key since version 1.1.4 and the sub-pool hkp://subset.pool.sks-keyservers.net require servers to be at this version, and is as such ECC safe .

The new key might also turn out to be replaced if we get an OpenPGP standard of versions 5 within a reasonable timeframe. Until then, contact me using whichever key you want - as long as you consider the value of your own privacy and is using one of them.