10 year anniversary for sks-keyservers.net

December 3rd 2016 marks 10 years since sks-keyservers.net was first announced on the sks-devel mailing list. The time really has passed by too quickly, driven by a community that is a pleasure to cooperate with.

Sadly there is still a long way to go for OpenPGP to be used mainstream, but in this blog post I'll try to reminisce on a few things that have happened since Bjørn Buerger commented about *.keyserver.penguin.de being down, which lead to the need for a DNS Round Robin alternative. Having a common DNS Round Robin to use is practical for a number of reasons, mainly; (i) Its easier to communicate to users (ii) It distributes the load across multiple keyservers (iii) Non synchronizing/responding keyservers can be removed without users needing to reconfigure the systems.

After the announcement of the new service, Enigmail, the Thunderbird OpenPGP plugin, was quick to change the default preferences to point to hkp://pool.sks-keyservers.net already in December 2006, less than a week after the new service was officially announced.

The GnuPG Project started its usage of the pools when keys.gnupg.net was changed to be a CNAME to the pool in May 2012. Since then the cooperation has evolved, and in particular in the "Modern" 2.1 branch it has been completed. Since 2.1.11 the public key for the Certificate Authority used for the HKPS pool has been used by default if a user specify the use of hkps://hkps.pool.sks-keyservers.net, i.e without needing to specify the hkp-cacert, and with the release of 2.1.16 it is now the default keyserver that is used if a user has no overriding configuration. Earlier versions produced an error message of no keyserver at all in this scenario.

Some slides from my presentation of the first OpenPGP conference, in Cologne 2016, are available describing the current state of operations. And if you want to learn a bit of Norwegian you can watch the recording of the 2014 presentation, or at least read the slides that happen to be in English.

Although the growth in number of public keyblocks has been increasing as demonstrated in Figure 1, it is still a low reach with 4.5 million entries. How about we use the next 10 years to make sure it becomes mainstream?

2016-11-generate_key_chart-php
Figure 1: Number of OpenPGP public keyblocks

 

OpenPGP Certificates can not be deleted from keyservers

Due to my involvement in sks-keyservers.net I frequently get questions on whether I can remove OpenPGP certificates from the keyservers.

TL;DR; Removal of OpenPGP certificates from a keyserver is not possible.

To start off with, the OpenPGP keyserver network consists of more than 150 keyservers reconciliating their database between the peers. Even if I could delete it from some servers I operate it will be re-added on next re-synchronization with the other servers unless done in a coordinated fashion of all the keyservers in the network, i.e. virtually impossible.

The correct way to flag a key as not being used is revocation.
Revocation require access to the private key or a revocation
certificate generated while having access to the private key; gnupg 2.1 automatically generates revocation certificates when a key is generated for this purpose and places it in ${GNUPGHOME}/openpgp-revocs.d.

Data is by design never removed from keyservers, much like it stays around in a blockchain. One should never validate a public keyblock based solely on email address in UID on a keyserver; But before using a public keyblock it needs proper due diligence verifying inter alia fingerprint, creation type, key algorithm, with the perceived owner of the keyblock out of band before signing (cerifying) and using it as a trusted channel. That several certificates exists for a single email address is, from a cryptographic and security point of view irrelevant, as it is only applicable as a potential issue if people don't follow proper procedure for due diligence.

To make the story even longer;  even if it was technically possible the social protocol is missing. Speaking more generally, there might've been two (or more) people sharing the same name, and email addresses change over time, if the previous user deleted his email, it wouldn't make the certificate any less valid that someone else take over the email address, and if someone could remove the data it would require ways to verify the authentication of the request. Additionally it could make the keyserver operators viable to certain legal liability if incorrectly deleting a key allowing it to be replaced by a MITM cert.

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.