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.
Richard Pennington
A possible mitigation would be to throttle the bandwidth available to the spammers – e.g. to require that no new signature could be added for 24 hours after another new signature for the same certificate. It would then take about 410 years to fill up the signature space on a certificate, which is long enough to deal with the attack.
Allureana
If we’re not using OpenPGP in any way, does this have any effect on us?
Paul Ducklin
AFAIK, you need to be using some product that uses OpenPGP keys (for example, GnuPG) and to be using public keys fetched from
a particular database of public keys, namely a keyserver known as SKS.
As the blog post linked to above explains, if you fetch the author’s public key from the SKS keyserver (many PGP-style products have an option to do this automatically) instead of getting it from a better-curated server, or from his own website directly, you get a version of his keyfile that, while crytographically valid, takes over two minutes to process instead of one second.
So if you don’t use OpenPGP and its PGP/GPG/GnuPG cousins this is irrelevant to you because you’ll never need to load/parse/use an OpenPGP public key so this “time-wasting” problem can’t be triggered.
And, apparently, if you avoid public keys from the SKS server, you should similarly avoid any problems.
Anonymous
Could it be an attempt to exfiltrate information? If you use the wrong key, is the email going to go to unknown recipients?
Paul Ducklin
In this case the key is correct (it’s not a new key with a similar name and email address), but contains so much additional data that it is slow to load and use.
Darren L.
This was a poor design from the beginning. LetsEncrypt has normalized ‘disposal’ certificates for websites. We should follow their lead with OpenPGP. Sigs should not exist forever in sks. I expire all my certs after a year, and I regret those from years back on different email addresses that I did not expire, and which now exist forever. The days of an email and openpgp cert as an identity are obsolete. Certificates should serve their function and change frequently.