Category: Security

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: Duplicate keyids - short vs long

Lately there seems to be a lot of discussion around regarding the use of short keyids as a large number of duplicates/collisions were uploaded to the keyserver network as seen in the chart below:

generate_key_bar_chart.php

The problem with most of these posts are they are plain wrong. But lets look at it from a few different viewpoints, one of which is the timing of the articles. For OpenPGP V4 keys the short keyid are the lowest 32 bits of the fingerprint. The specific keys that were published, some 20,000 keys that duplicate the strong set keys, were generated by evil32 in 2014, so nothing is actually new here (except it being published on the keyservers), and adding to that the triviality of short keyid collisions has been known from the start, which is ok, since it is just a short, convenient identifier.

What was interesting with the evil32 keyring however was demonstrating doing this on a large scale, by cloning the full strong set of the common Web of Trust (WoT). A strong set can be described as "the largest set of keys such that for any two keys in the set, there is a path from one to the other".

So what have we learned so far - when discussing keys there is such a thing as a path between keys existing in a strong set (that requires the path to be complete in both directions), the path we're talking about is a signature path, whereby Alice and Bob meet up at a conference and exchange data and check IDs after which they sign each others keys, then a path exists.

So where does duplicate short keyids make things diffused from a security perspective? Absolutely nowhere! The issue arise when people start using OpenPGP without understanding any concept of operational security or key management, and start using encryption and digital signatures "because it is cool" without actually verifying any of the recipients' keys. They go looking for a key on the keyservers, gets two results and are confused, making a large fuss about it.

In many ways we should be thankful that the duplicate keys are on the keyservers and starts confusing people, maybe they will start doing some key verification now? Not likely, when even Computer Emergency Response Teams (CERT) such as the dutch don't understand basic concepts of security and starts wanting to prove the negative and detecting duplicate keyids. In an intentional attack, all the keys found might very likely be an attacker, you should verify positively with the person you want to communicate with, or through your network of trusted peers (that you assign a trust level to when calculating the WoT), never, ever, try to guess what is wrong by proving something is false.

The most common suggestion over the past few days seems to evolve around "Use the long keyid", whereby the short keyid is a 32 bit identifier, the long keyid increases the size to 64 bits, and for GnuPG this can be achieved using "keyid-format 0xlong" in gpg.conf. And sadly, the suggestion is based on the same misconception. For one thing, generating colliding 64 bit keyids is also possible, but the really scary thing is it still assumes users are not properly verifying the keys they are using with the full fingerprint in place, normally along with the algorithm type and creation date, for which purpose I carry around the following slip of paper:

Screenshot from 2016-08-17 18-26-59

The moral? If you actually do your job and validate the keys of your correspondents either directly or through trusted peers (including Certificate Authorities) that have signed the key, whether you're using the short keyid or the long keyid as reference is mostly without importance as the selection of keys you look at are already verified, and the likelihood of having collission on that set of keys is slim.

The one thing that is very sure is that the existence of duplicate/colliding short keyids on the keyserver networks does not impact security if OpenPGP is used properly (if anything it improves it if people start using their brain)

Norwegian government propose access to extended surveillance methods

The Norwegian Government proposed Proposition 68 L (2015-2016) today extending and introducing a wide range of methods for the police to cross the privacy boundry with increased surveillance, including what the Minister of Justice, Progress Party (FrP)'s Anundsen, calls "surveillance closer to the soul".

The possibility to perform telecommunications control in Norway has history back to 1915, however was limited to cases involving national security until 1976. Starting in 1915 the surveillance was restricted to post and telegraph but telephone surveillance was added in December 1950. Now in 2016 the government wants to extend the scope to:

  • "Data reading" is introduced as a term giving the police access to hacking into computers, including adding keyloggers (physical or virtual)
  • Possibility to send silent SMSes to generate telephone traffic. The Norwegian police has already been wildly criticized for illegally using IMSI catchers across, in particular, Oslo in violation with court order and registration requirements. A silent SMS is a message that is not displayed by the phone, but the generated traffic will increase the verbosity information that can be apprehended by the police when the phone company is compelled to turn over data.
  • Take control over email accounts without a court order to ease access to information early in an investigation
  • Physically bug (microphone) private rooms without an actual crime having been committed as a preventive measure.

"Closer to the soul", indeed; if you don't already see the resemblance to Minority Report (2002) you likely want to make it your weekend movie pick. IMDB summarize the Spielberg movie as "In a future where a special police unit is able to arrest murderers before they commit their crimes, an officer from that unit is himself accused of a future murder"

Anundsen argues that you don't get any more access to an individual's thoughts from monitoring what is typed on a computer and potentially never sent, than you get by physically taking control over the person's diaries. Without going into how wrong that argument sounds to begin with, there is of course a difference of awareness of the police physically getting access to a person's diaries or just silently monitoring in the background while the person were to be writing in the diary without knowledge of the police presence.

This adds to a long line of police requests for increased access to information across the globe. Senators in USA wants a new bill to impose fines if operators don't willingly help attacking their own products and Obama is ever reducing security, this time by increasing the scope of use of data collected.

So what can you do to protect yourself in a society where everyone around you is increasingly becoming your enemy? Arstechnica had an interesting post recently titled "Most software already has a 'golden key' backdoor: the system update". If you can't trust the operative system and hardware providers you're lost to begin with. Bill Gates expresses his view on personal information access as “It is no different than [the question of] should anybody ever have been able to tell the phone company to get information, should anybody be able to get at bank records,” Gates said. “There’s no difference between information.” He offered this analogy: “Let’s say the bank had tied a ribbon round the disk drive and said, ‘Don’t make me cut this ribbon because you’ll make me cut it many times.’”

So you need a software stack that you can trust, and likely want to audit the source code of, or if using binary builds at least a system that use reproducible builds.

With a relatively trusted software stack, and monitoring any update activity, while making sure that you do update for security issues immediately, of course, the added complexity of encrypted and digitally signed emails comes into question. Personally I quite prefer OpenPGP using the GnuPG implementation, and with the way the world continues to develop I'm tempted to refuse to answer emails from people that sends me emails that aren't following proper email etiquette and are properly signed and encrypted. Phone calls and SMS messages I prefer not to get or take to begin with (we haven't even discussed SS7 in this post). Naturally private keys should only be stored on smart cards and data expected to be sensitive only read on airgapped systems.

It is also curious that Norway is following China in its privacy activity by this act.