ADK flaw in recent versions of PGP

Overview

Additional Decryption Keys (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 ADK subject to the conditions list in the impact section. The attacker who modified the certificate can obtain the plaintext from this ciphertext.

PGP does not correctly detect this form of certificate modification because it fails to check if the ADK is stored in the signed (hashed) portion of the public certificate. As a result, normal methods for evaluating the legitimacy of a public certificate (fingerprint verification) are not sufficient for users of vulnerable versions of PGP.

Description

Additional Decryption Keys
A serious problem in the handling of certificates used with PGP versions 5 and 6 has recently been discovered by Ralf Senderek. A detailed description of his research into this issue and it’s conclusions can be found at:

<http://senderek.de/security/key-experiments.html&gt;
This document refers to “PGP certificates” which most users would refer to as a “PGP key”. PGP certificates are the file format used to store and exchange keys. A certificate may contain one or more keys, the creation time, signatures by other keys, and other extensions such as “additional decryption keys”.

An Additional Decryption Key (ADK) is a mechanism by which a second decryption key can be associated with a user’s primary key. All data encrypted for the primary key would also be encrypted with the second key. This configuration might be used for example in environments where data encrypted with an individual’s key also needs to be available to their employer.

The ADK feature is intended to only be enabled on those keys where the user specifically consented to having an additional key associated with theirs. However, because of an implementation flaw in PGP 5 and 6, an attacker can circumvent this consent.

Since a user’s public key certificate is often widely distributed, an attacker could make this modification to a specific copy of the certificate without the legitimate user’s knowledge. When PGP uses the modified certificate for encryption, it fails to detect that ADK is contained in the unsigned portion of the certificate. Because PGP does not report an invalid signature, senders using the modified certificate have no way to detect the modification, without complicated manual inspection.

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 employ ADKs.

The PGP Software Development Kit (PGP SDK) has this vulnerability, implying that PGP plugins and other PGP enabled applications may be vulnerable as well. We will provide additional information as it becomes available.

Impact

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 certificate.

For this vulnerability to be exploited, the following conditions must hold:

* the sender must be using a vulnerable version of PGP 
* the sender must be encrypting data with a certificate modified by the attacker 
* the sender must acknowledge a warning dialog that an ADK is associated with the certificate 
* the sender must already have the key for the bogus ADK on their local keyring 
* the bogus ADK must be a certificate signed by a CA that the sender trusts 
* the attacker must be able to obtain the ciphertext sent from the sender to the victim 

Taken together, these conditions limit the likely exploitation of this vulnerability to those situations in which the key identified as the ADK is a known valid key. These conditions might occur when the attacker is an 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 that 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 recipients 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-Hellman. The version of PGP used by the recipient has no impact on the attack.

Solution

Apply a patch
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.

Check certificates for ADKs before adding them to a keyring.
Users of PGP who want to ensure that they are not using a modified certificate should 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. Certificates which do have ADKs may be legitimate or modified and should be confirmed using an out-of-band communication.

Users of PGP 6.x for Windows 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 certificate. We are not aware of a way to identify ADKs in the UNIX command line version of PGP 5.x or 6.x.

Users of GnuPG can test for certificates with ADKs by running the command

gpg --list-packet

Certificates with legitimate ADKs will contain in the output

hashed subpkt 10 len 23 (additional recipient request)

while those missing the “hashed” keyword

subpkt 10 len 23 (additional recipient request)

appear to indicate maliciously modified certificates.

Make a reliable copy of your public certificate publicly available.
Since the recipient of messages encrypted with a modified certificate cannot prevent the plaintext from being recovered by the attacker, their best course of action is to ensure that senders are able to easily obtain legitimate copies of their public certificate.

Until this problem has been widely corrected, you may wish to make your legitimate certificate available in a location that is strongly authenticated using a different technology, or to make it available in more than one place.

For example, the CERT/CC PGP certificate does NOT contain any ADKs, and a legitimate version can be obtained from our SSL secured web site at

https://www.cert.org/pgp/cert_pgp_key.asc

You may also want to check that your public certificate has not been modified on the public certificate servers. Changes are likely to be made to the popular PGP certificate servers to detect and reject invalid certificates that attempt to exploit this vulnerability.

---

Vendor Information

747124

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

Network Associates __ Affected

Updated: October 10, 2000

Status

Affected

Vendor Statement

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 were 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 bug late Thursday evening. The MIT web site should have a new PGP 6.5.x freeware 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 bogus 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 that make PGP key server software to the problem, and expect Highware/Veridis in Belgium to have their key servers filtering keys the same way by Friday.

The fixes that we are releasing for the PGP client software filters out the offending ADK packets. We already warn the users whenever they are about to use an ADK, even in the normal case.

We will have new information as soon as it becomes available at <http://www.pgp.com>.

Philip Zimmermann
[email protected]
19:00 PDT Thursday 24 Aug 2000

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The following systems are affected by this vulnerability:

* PGP versions 5.5.x through 6.5.3, domestic and international 

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23747124 Feedback>).

GNU __ Not Affected

Updated: October 06, 2000

Status

Not Affected

Vendor Statement

GNU Privacy Guard

GNUPG does not support ADKs, and is not vulnerable to this problem.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23747124 Feedback>).

CVSS Metrics

Group	Score	Vector
Base
Temporal
Environmental

References

• <http://cryptome.org/pgp-badbug.htm&gt;
• <http://senderek.de/security/key-experiments.html&gt;
• <http://www.securityfocus.com/bid/1606&gt;
• <https://www.cert.org/pgp/cert_pgp_key.asc&gt;

Acknowledgements

The CERT Coordination Center thanks Ralf Senderek for bringing this problem to light and Network Associates for developing a solution and assisting in the preparation of this document.

This document was written by Cory Cohen, Shawn Hernan, Jeff Havrilla, and Jeffrey P. Lanza. Graphics developed by Matt DeSantis.

Other Information

CVE IDs:	CVE-2000-0678
CERT Advisory:	CA-2000-18 Severity Metric: