Somebody out there has taken a big dislike to Robert J. Hansen (‘rjh’) and Daniel Kahn Gillmor (‘dkg’), two well-regarded experts in the specialised world of OpenPGP email encryption.
It’s not known who launched the attacks in late June 2019 (Hansen says he has suspects in mind), but it’s the nature of the campaign against them that has people in this corner of encryption worried – a “poisoning” attack against their personal certificate signatures held on the OpenPGP Synchronizing Key Server (SKS) network.
It sounds arcane but the effects of this on the sizeable number of people using implementations of the OpenPGP protocol – GnuPGP, SequoiaPGP, OpenPGP.js – are to varying degrees potentially very serious. Daniel Kahn Gillmor blogged last week:
My public cryptographic identity has been spammed to the point where it is unusable in standard workflows.
The most disconcerting thing about these attacks is how easy they were to launch simply by spamming large numbers of fake certificate signatures to the keyservers, effectively burying the real one belonging to the two men under thousands of bogus additions.
This sort of attack has been feared for a decade, with smaller attacks recorded a year ago fulfilling that prediction. What’s novel this time, however, is the scale and highly targeted nature of the campaign. As Hansen sums it up in his own reaction:
To have my own certificate directly spammed in this way felt surprisingly personal, as though someone was trying to attack or punish me, specifically.
And it really is a flood – comprising 55,000 fakes directed at Daniel Kahn Gillmor and twice that number at Hansen. This causes problems (see below) but what matters is that the pair now fear the attack will be used against others, expanding its scope in ways that will be very hard to counter.
“Spammed into oblivion”
Almost from the moment Phil Zimmermann invented Pretty Good Privacy (PGP) in the early 1990s, securing emails with this type of public or asymmetric key cryptography struggled with the problem that to communicate with someone, you had to have their public key.
The solution was to publish an individual’s certificates using a distributed keyserver directory that anyone could check and verify offline for themselves so they’d know that the person using it was who they said they were.
But in order to battle the possibility that governments might try to delete or falsify signatures, the SKS infrastructure was set up to be write-only. Certificates could have information added to them but neither this or the certificate itself could ever be deleted.
This required making the key server infrastructure distributed – if a certificate was deleted or removed on one server, that would be quickly noticed through a comparison with the information held by the others.
This resilience created what were then hypothetical weaknesses, including the one now being exploited in the attacks Robert J. Hansen and Daniel Kahn Gillmor, that would allow attackers to keep adding more and more data.
The OpenPGP protocol allows for up to 150,000 signatures for each user’s certificate, but popular implementations such as GnuPG can effectively be broken by fakes, notes Hansen:
Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt. It doesn’t stop, per se, but it gets wedged for so long it is for all intents and purposes completely unusable.
Fixing things
It seems that fixing this weakness isn’t going to be quick or easy, assuming it’s possible to fix it at all.
According to Hansen, the keyserver design itself is the main barrier. The algorithm used by SKS to perform reconciliation requires specialised knowledge, as does the obscure dialect of the programming language, OCaml, in which it was written by a single developer decades back.
The complicated nature of this software has resulted in it being unmaintained, which in turn has stymied the development necessary to solve larger issues such as how a deliberately federated system could even agree and implement security reforms in the first place.
Hansen’s advice is that high-risk users should stop using the keyserver network until some kind of mitigation is worked up.
That might take some time. As Daniel Kahn Gillmor puts it:
This is a mess, and it’s a mess a long time coming.