Poisoned certificates are in the OpenPGP SKS keyserver network after an unknown threat actor targeted the OpenPGP certificates of two high-profile community contributors.
The attack happened in the last week of June and exploited a defect in the OpenPGP protocol itself to poison the OpenPGP certificates of Robert J. Hansen and Daniel Kahn Gillmor, known in the community as “rjh” and “dkg.”
The immediate effect of the attack was that the poisoned certificates ended up in the SKS keyserver network and that anyone attempting to import a poisoned certificate into a vulnerable OpenPGP installation would likely break their installation.
“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 notes.
The attack, he explains, will not be mitigated by the SKS keyserver network or the OpenPGP Working Group in a reasonable time period, though some mitigations will likely be included in a future release of OpenPGP.
“The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network,” Hansen says.
The keyserver software and network were built three decades ago to facilitate the discovery and distribution of public certificates, and keyservers have a major flaw: they don’t delete information about a certificate.
This write-only design, where the keyserver network is essentially a large fileserver that anyone can write to, makes the system susceptible to a variety of attacks, Hansen says.
Although the issue has been known for decades, technical difficulties prevent further keyserver development, starting with the fact that the software itself, which is called SKS, for “Synchronizing Key Server,” was written in the OCaml language as proof-of-concept and remains unmaintained.
Because the “design goal of the keyserver network is ‘baked into’ essentially every part of the infrastructure,” changing them essentially means rebuilding everything from the ground up, Hansen, who has been involved in the PGP community since 1992, notes.
He also explains that public certificates have attestations to prove they really belong to the person in question and that the OpenPGP specification puts no limitation on the number of signatures that can be attached to a certificate.
“The keyserver network handles certificates with up to about 150,000 signatures. GnuPG, on the other hand … doesn’t. Any time GnuPG has to deal with such a spammed certificate, GnuPG grinds to a halt,” Hansen explains.
Thus, once an individual fetches a poisoned certificate from the keyserver network, the GnuPG installation breaks. Furthermore, poisoned certificates cannot be deleted and their number will increase, although it’s unclear whether the attackers would attempt to poison more certificates or what their goal is.
“Any certificate may be poisoned at any time, and is unlikely to be discovered until it breaks an OpenPGP installation,” Hansen says.
If a threat actor uploaded a poisoned vendor’s certificate to the network, it would be downloaded when a system administrator refreshed their keyring from the keyserver network, essentially making upgrades impossible by preventing the verification of a downloaded package’s authenticity.
“Even downloading the vendor’s certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network,” Hansen notes.
Those who know which certificate is poisoned are advised to attempt to delete it, as it could make their OpenPGP installation usable again, and then get a clean copy of the certificate and import it. Others should get a list of all certificate IDs, delete the keyrings completely, and rebuild from scratch using known-good copies of the public certificates.