Date: Fri, 29 Mar 2024 06:01:55 -0400 (EDT) Message-ID: <1682132648.9.1711706515214@windcrest.sei.cmu.edu> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8_1723672852.1711706515213" ------=_Part_8_1723672852.1711706515213 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A complete revision history is at the end of this file.
Additional Decryption Ke= ys (ADKs) is a feature introduced into PGP (Pretty Good Privacy) versions 5= .5.x through 6.5.3 that allows authorized extra decryption keys to be added= to a user's public key certificate. However, an implementation flaw in PGP= allows unsigned ADKs which have been maliciously added to a certificate to= be used for encryption.
Data encrypted with PGP 5.5.x through 6.5.3 = using a modified certificate will generate ciphertext encrypted with the AD= K subject to the conditions list in the impact section. The attacker who mo= dified the certificate can obtain the plaintext from this ciphertext.
= a>PGP does not correctly detect this form of certific= ate modification because it fails to check if the ADK is stored in the sign= ed (hashed) portion of the public certificate. As a result, normal methods = for evaluating the legitimacy of a public certificate (fingerprint verifica= tion) are not sufficient for users of vulnerable versions of PGP.
A serious problem in the handling of certificates when encrypting with = PGP versions 5.5.x through 6.5.3 has recently been discovered by Ralf Sende= rek. A detailed description of his research and conclusions can be found at=
This advisory refers to "PGP certificates", which most users would refer= to as a "PGP keys". PGP certificates are the files used to store and excha= nge keys. A certificate contains one or more keys, as well as other informa= tion such as the creation time, signatures by other keys, and "additional d= ecryption keys".
An Additional Decryption Key (ADK) is a mechanism by which a second decr= yption key can be associated with a user's primary key in a certificate. Al= l data encrypted for the primary key would also be encrypted with the secon= d key. This configuration might be used, for example, in environments where= data encrypted with an individual's key also needs to be available to thei= r employer.
The ADK feature is intended to only be available on those certificates w= here the user specifically consented to having an additional key associated= with theirs. However, because of an implementation flaw in some versions o= f PGP, ADKs added to a victim's certificate by an attacker may be used for = encryption in addition to the victim's key without their consent.
Since a user's public key certificate is often widely distributed, an at= tacker could make this modification to a specific copy of the certificate w= ithout the legitimate user's knowledge. When a vulnerable version of PGP us= es the modified certificate for encryption, it fails to detect that the ADK= is contained in the unsigned portion of the certificate. Because PGP does = not report an invalid signature, senders using the modified certificate hav= e no way to detect the modification without complicated manual inspection.<= /p>
No legitimately produced PGP certificate will exhibit this vulnerability= , nor is this an inherent weakness in the ADK functionality. Your exposure = to this vulnerability is independent of whether or not you legitimately emp= loy ADKs.
The PGP Software Development Kit (PGP SDK) has this vulnerability, imply= ing that PGP plugins and other PGP enabled applications may be vulnerable a= s well. We will provide additional information as it becomes available.
Attackers = who are able to modify a victim's public certificate may be able to recover= the plaintext of any ciphertext sent to the victim using the modified cert= ificate.
For this vulnerability to be exploited, the following condit= ions must hold:
Taken together, these conditions limit the likely exploitation of t= his vulnerability to those situations in which the key identified as the AD= K is a known valid key. These conditions might occur when the attacker is a= n insider known to the victim, but are unlikely to occur if the attacker is= a completely unrelated third party.
Viewing the keys in a GUI interface clearly shows tha= t an ADK is associated with a given recipient, as shown in this image.
Since the key associated with the ADK is clearly listed as one of the re= cipients of the ciphertext, it is likely that the sender might notice this = and be able to identify the attacker.
The recipient may use any type of PGP key, including RSA and Diffie-Hell= man. The version of PGP used by the recipient has no impact on the attack. =
Network Associates has produced a new version of PGP 6.5= which corrects this vulnerability by requiring that the ADK be included in= the signed portion of the certificate.
Appendix A contains informati= on provided by vendors for this advisory. We will update the appendix as we= receive more information. If you do not see your vendor's name, the CERT/C= C did not hear from that vendor. Please contact your vendor directly.
Users= of PGP who want to ensure that they are not using a modified certificate s= hould check for the existence of ADKs when adding new keys to their keyring= . Certificates that do not have ADKs are not vulnerable to this problem. Ce= rtificates which do have ADKs may be legitimate or modified and should be c= onfirmed using an out-of-band communication.
Users of PGP 6.x for Win= dows and MacOS can test for the presence of ADKs in a certificate by right = clicking on the certificate and selecting "Key Properties". If the ADK tab = is present, the key has one or more ADKs and might be a malicious certifica= te. We are not aware of a way to identify ADKs in the UNIX command line ver= sion of PGP 5.x or 6.x.
Users of GnuPG can test for certificates with= ADKs by running the command
Certificates with legitimate ADKs will contain in the output
Since the r= ecipient of messages encrypted with a modified certificate cannot prevent t= he plaintext from being recovered by the attacker, their best course of act= ion is to ensure that senders are able to easily obtain legitimate copies o= f their public certificate.
Until this problem has been widely correc= ted, you may wish to make your legitimate certificate available in a locati= on that is strongly authenticated using a different technology, or to make = it available in more than one place.
For example, the CERT/CC PGP cer= tificate does NOT contain any ADKs, and a legitimate version can be = obtained from our SSL secured web site at
You may also want to check that your public certificate has not been mod= ified on the public certificate servers. Changes are likely to be made to t= he popular PGP certificate servers to detect and reject invalid certificate= s that attempt to exploit this vulnerability.
GNUPG does not support ADKs, and is not vulnerable to th= is problem.
We= at NAI/PGP Security regret this important bug in the ADK feature that has = been described on various Internet postings today (Thursday 24 Aug). We wer= e made aware of this bug in PGP early this morning.
We are responding= as fast as we can, and expect to have new 6.5.x releases out to fix this b= ug late Thursday evening. The MIT web site should have a new PGP 6.5.x free= ware release early Friday, and the NAI/PGP web site should have patches out= for the commercial releases at about the same time. As of this afternoon (= Thursday), the PGP key server at PGP already filters out keys with the bogu= s ADK packets. We expect to have fixes available for the other key servers = that run our software by tomorrow. We have also alerted the other vendors t= hat make PGP key server software to the problem, and expect Highware/Veridi= s in Belgium to have their key servers filtering keys the same way by Frida= y.
The fixes that we are releasing for the PGP client software filter= s out the offending ADK packets. We already warn the users whenever they ar= e about to use an ADK, even in the normal case.
We will have new info= rmation as soon as it becomes available at http://www.pgp.com.
Philip=
Zimmermann
prz@pgp.com
19:00 PDT Thursday 24 Aug 2000
A signed version of this statemen= t is available at
The CERT Coordination Center thanks Ralf Senderek for bringing this prob= lem to light and Network Associates for developing a solution and assisting= in the preparation of this advisory.
Authors: Cory Cohen, Shawn Hernan, Jeff Havrilla, and Jeffrey P. Lanza. = Graphics developed by Matt DeSantis. Feedback on this advisory is app= reciated.
Copyright 2000 Carnegie Mellon University.
Revision History
August 24, 2000: Initial release August 25, 2000: Fixed some typographical and semantic errors in the Impac= t section. August 29, 2000: Added information about the GNU Privacy Guard, GPG September 28, 2000: Corrected misspelled name in author section