Viewable With ANY Browser

Note: My Web pages are best viewed with style sheets enabled.


PGP: Additional Decryption Key (ADK)

A boon to businesses interested in using PGP,
ADK can also cause problems.

Copyright © 2000, 2001, 2003, 2004 by David E. Ross

This page assumes that the reader has some familiarity with PGP, at least at the level provided in my Pretty Good Privacy (PGP).

Note that much (but not all) of the information here generally applies only to business use of PGP.

Why ADK?

The Problem

A business should have strong objections when employees use the company's equipment (desktop computers) to keep secrets from their employer, especially secrets at the level provided by PGP encryption. No, this is not about an employer snooping into what its employees are doing. This is about the value of the secrets to the company — as long as they are indeed shared with the employer. Reasons both businesses and individuals to use PGP for encryption are described in Why Encrypt? under my Key Encryption.

Think of how disastrous it would be to a company if such vital, confidential information were safely encrypted and then the only employee who knew the passphrase suddenly became unavailable. No, the answer is not to share the passphrase with another employee, even a manager. Sharing passwords or passphrases is not only contrary to good security practices; it is also illegal where certain government data are involved.

The Solution

Since PGP may encrypt a file or message to more than one public key, the solution is to have every employee in a company who uses PGP to encrypt to a company key as well as to any other keys. The company key and its passphrase are generally kept by a company's security office, which never encrypts with that key and only decrypts with it according to a formal policy that addresses the company's need to access data when no one with the necessary personal private key is available.

In concept, every employee of a company would always include the company's public key among those used during encryption and they would freely request outsiders sending encrypted files and messages to employees to also use the company's public key. In such an ideal world, outsiders would certainly comply with those requests. In practice, this will not happen. Employees already burdened by the need to use PGP at all, will "forget" to include the company's public key and fail to inform outsiders of the need to use that key. Positive incentives to use the company's key and negative consequences when that does not happen will not work with outsiders.

PGP Corporate Desktop and PGP Universal to the rescue!

The use of PGP freeware is restricted to non-commercial purposes only. In the past (with older versions of PGP freeware), non-commercial was defined to prohibit the use of PGP freeware by any business. After all, developing and maintaining PGP software has a cost, which the PGP Corporation wants to recover by selling non-freeware versions for commercial use.

To make commercial versions of PGP an attractive purchase for businesses, they include several features not available in PGP freeware. Appropriate to this discussion is the capability to use an additional decryption key (ADK) automatically. (Actually, it is an additional encryption key; decryption would be done by a private key. However, the terminology additional decryption key and its acronym have stuck.) An employee's public key may contain the ID of an ADK (actually the fingerprint, an extended 20-byte ID created by compressing the key) to indicate that the ADK should be used. Versions of PGP starting with 5.5 — both freeware and purchase-ware — recognize the presence of that ID as a flag that, when encrypting with the key containing it, the indicated ADK should also be used. An additional flag in the employee's public key indicates that encryption with the ADK is mandatory; without the ADK, no one can encrypt with the employee's own public key.

Using a commercial version of PGP, a company's employee will usually find that the generation of new key-pairs is disabled. To obtain a new set of keys (in case the old private key were compromised), a computer security technician generates the key-pair on a secure computer and then installs the keys on the employee's computer. The technician ensures that the new public key contains the ID of the company's current ADK. Then, the employee changes the passphrase on the new private key and uses it to sign the new public key. In the meantime, the employee's new public key has already been signed, either by the private key that goes with the ADK or with another company key. All of this signing of keys serves several purposes:

Of course the ADK has already been signed by its own associated private key and possibly also by a separate signing key that the company uses. This assures users of the ADK that the E-mail address on the ADK is authentic and that the ADK is authorized by the company. All this signing of keys might seem complicated and confusing; it is explained very well by Walter Soldierer in his Why should I sign my own public key?, which applies not only to keys used in business but also to personal keys without ADK. The overall purpose here is to authenticate a person as an employee of the company and to authenticate the use of ADK when sending that employee encrypted data.

ADK and Individual PGP Users

Of course, any company using PGP — whether or not ADKs are also used — will have some form of PGP training or orientation for its employees. The rest of us — especially we who have PGP freeware for our own personal use — need to be aware of the needs and practices of businesses when we exchange encrypted data with a company's employee.

Why Not ADK?

When I originally wrote this, Network Associates, Incorporated, (NAI) owned the PGP product, having bought it from Philip Zimmermann's PGP, Inc. After I wrote this, NAI sold the product to the PGP Corporation (a new company, not a resurection of Zimmermann's old company).

A Security "Hole"

On 24 August 2000, Ralf Senderek (a computer cryptography researcher in Germany) reported a security vulnerability in the processing of ADKs. Senderek's report quickly resulted in an advisory by the CERT Coordination Center.

This "hole" means that PGP will use an ADK even if the ADK ID was added to a public key after the key's owner signed it with his private key. Thus, a personal, non-business key could request or even require an unauthorized ADK. An fraudulent alteration to your public key — possibly distributed via public key servers — could cause an encrypted message sent to you also be sent to an interloper who could then decrypt it.

This entirely defeats the purpose of PGP and encryption!

The head of NAI's PGP Security asserted

exploitation of this bug can be characterized as an academic exercise, with little or no practical use as an exploit in real-world environments … .
The CERT advisory describes six conditions that must all exist for this security vulnerability to be realized, a combination that CERT thinks to be unlikely. Rather than go over CERT's technical detail, I present a less technical scenario involving Tom (the attacker), Dick (the victim), and Harry (a naïve user of PGP). This scenario is not so unlikely after all.

In the above scenario, the unquestioning acceptance by Harry of a request for an ADK when sending a message to Dick may be the weakest point in the use of PGP to exchange encrypted messages. Dick remains completely unaware of the threat until his bank calls him about the charges to his Visa account. There is little Dick could do to protect himself from Harry's na´vetÚ. Of course, Dick must now revoke his key and send the revocation to the key servers; he will then have to generate a new key.

Corrective Actions by NAI

Within two days of the CERT alert, NAI took several actions to address this problem:

Some of the corrective actions, however, seemed hasty and poorly designed. For example, the upgrades to PGP itself ignore non-authenticated ADK IDs; but the user is not informed that someone might have tampered with a key on her public keyring. While two large public key servers have been examined, not all server networks include those two; and there are some significant key servers that are not part of server networks. Debates about these issues continue.

Preventive Actions for Individuals

As seen in the scenario above, you can do little to protect yourself against being a victim of the ADK security "hole". The most important thing you can do is download your public key from a key server and check it for an indication of an ADK. To do this, you must first temporarily remove your public key that already exists on your keyring. However, newer versions of PGP (at least by 6.5) allow you to examine keys on a key server without installing them on your keyring. If you find that someone has tampered with your public key, your best recourse is to revoke the key and generate a new key-pair.

On the other hand, you can do several things to protect yourself against falling into the role of Harry in the scenario:

PGP 2.6.x and RSA Keys

If you are a purist who insists on using only PGP 2.6.x, no preventive measures are required to keep you from unknowingly helping an attack. Your version of PGP lacks any ADK capability. Furthermore, the RSA keys you generate are v.3, the format of which has no place where an attacker can place an ADK ID. Only PGP 7.x and later versions generate RSA v.4 keys that are vulnerable to an ADK attack. DSS/DH keys are all v.4 and vulnerable, even those generated by PGP 5.x. PGP 2.6.x does not have a DSS/DH capability; it can generate and use only RSA keys.

According to Senderek, someone can tamper with an RSA v.3 key as easily as with a DSS/DH key. This involves changing the key from v.3 to v.4. However, that alteration invalidates the self-signature that had been applied to the v.3 key. For an attacker to then add an ADK ID, you must first sign your altered key again.

Preventive actions in this case are obvious:

While PGP 2.6.x and its RSA v.3 keys protect you both from being a victim of the ADK "hole" and also from abetting an ADK attack, vigilance is still required.

My Thoughts and Analyses

Despite expressions of anguish and platitudes of optimism, the ADK security "hole" is not a black and white issue. You see both positives and negatives in my discussions below.

ADK Links

See also the list of links on my main PGP page.

No, I am not employed by the PGP Corporation; and I have no investment in that company.

Last updated 13 September 2004

Link to my main PGP Web page
Main PGP page
Link to David Ross's home page
David Ross home
Link to David Ross's public PGP keys
My PGP keys

Valid HTML 4.01