Robert J. Hansen, a maintainer of the GnuPG FAQ, revealed about a certificate spamming attack against him and Daniel Kahn Gillmor, two high-profile contributors in the OpenPGP community, in the last week of June 2019.
The attack exploited a defect in the OpenPGP protocol to “poison” both Hansen’s and Gillmor’s OpenPGP certificates. “Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways”, Hansen wrote on his GitHub blog post.
Gillmor said his OpenPGP certificate was flooded with bogus certifications which were uploaded to the SKS keyserver network. The main use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. This attack has the following consequences:
- If you fetch a poisoned certificate from the keyserver network, you will break your GnuPG installation.
- Poisoned certificates cannot be deleted from the keyserver network.
- The number of deliberately poisoned certificates, currently at only a few, will only rise over time.
- The attackers may have an intent on poisoning other certificates and the scope of the damage is still unknown
A year ago, OpenPGP experienced similar certificate flooding, one, a spam on Werner Koch’s key and second, abuse tools made available years ago under the name “trollwot”. There’s a keyserver-backed filesystem proposed as a proof of concept to point out the abuse.
“Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned”, Hansen further added.
He also said that the mitigation to this attack cannot be carried out “in any reasonable time period” and that the future releases of OpenPGP software may have mitigation. However, he said he is unsure of the time frame.
The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network, Hansen says.
The “keyserver software” was written to facilitate the discovery and distribution of public certificates. Users can search the keyserver by a variety of different criteria to discover public certificates which claim to belong to the desired user. The keyserver network, however, does not attest to the accuracy of the information. This was left for each user to ascertain according to their own criteria.
According to the Keyserver design goals, “Keyservers could add information to existing certificates but could never, ever, ever, delete either a certificate or information about a certificate”, Hansen said as he was involved in the PGP community since 1992 and was present for these discussions. “In the early 1990s this design seemed sound. It is not sound in 2019. We’ve known it has problems for well over a decade”, Hansen adds.
This shows that Keyservers are vulnerable and susceptible to attacks and how the data can be easily misused.
Why SKS Keyserver Network can never be fixed
Hansen has also given some reasons why the software was not fixed or updated for security to date.
A difficult to understand algorithm
The SKS or standard keyserver software was written by Yaron Minsky. It became the keystone of his Ph.D. thesis, and he wrote SKS originally as a proof of concept of his idea. The algorithm is written in an unusual programming language called OCaml, which Hansen says has an idiosyncratic dialect. “ Not only do we need to be bright enough to understand an algorithm that’s literally someone’s Ph.D. thesis, but we need expertise in obscure programming languages and strange programming customs”, Hansen says.
Change in design goal may result in changes from scratch
Due to a difficult programming language it is written in, there are hardly any programmers who are qualified to do such a major overhaul, Hansen says. Also, the design goal of the keyserver network is “baked into” essentially every part of the infrastructure and changing it may lead to huge changes in the entire software.
Lack of a centralized authority
The lack of centralized authority was a feature, not a bug. This means there is no single point of failure for a government to go after. This makes it even harder to change the design goals as the network works as a confederated system.
Keyserver network is a Write-only file system
The Keyserver network is based on a write-only, which makes it susceptible to a lot of attacks as one can only write into it and have a tough time deleting files. The keyserver network can be thought of as an extremely large, extremely reliable, extremely censorship-resistant distributed file system which anyone can write to. Attackers can easily add any malicious or censored content files or media, which no one can delete.
Mitigations for using the Synchronization Key server
Hansen says high-risk users should stop using the keyserver network immediately.
For those confident with editing their GnuPG configuration files, the following process is recommended:
- Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it.
- Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it.
keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It has some limitations like its search functionality is sharply constrained. However, once changes are made users will be able to run gpg –refresh-keys with confidence.
Daniel Kahn Gillmor, in his blogpost, says, “This is a mess, and it’s a mess a long time coming. The parts of the OpenPGP ecosystem that rely on the naive assumptions of the SKS keyserver can no longer be relied on because people are deliberately abusing those keyservers. We need significantly more defensive programming and a better set of protocols for thinking about how and when to retrieve OpenPGP certificates”.
Public reaction to this attack is quite speculative. People shared their opinions on Twitter. Some have also suggested migrating the SKS server towards the new OpenPGP key server called Hagrid.
There’s been a debate in the crypto community about whether the OpenPGP infrastructure is worth carrying on or whether it should be thrown out and replaced. This attack is obviously a very powerful argument for the latter. But it’s also a crappy thing to do to people.
— Matthew Green (@matthew_d_green) June 29, 2019
This is starting well, trying to migrate a SKS server towards the new OpenPGP key server called hagrid https://t.co/BOv9fPwbFc but to build it: You need the nightly build of the Rust compiler (not the stable one.). There is huge list of dependencies and compilation fails.
— Alexandre Dulaunoy (@adulau) June 29, 2019
To know more about this in detail, head over to Robert J. Hansen’s GitHub post.