Note: My Web pages are best viewed with style sheets enabled.
|
Unrated |
PGP: Additional Decryption Key (ADK)
A boon to businesses interested in using PGP,
ADK can also cause problems.
Copyright © 2000, 2001, 2003, 2004, 2022 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:
- It is strongly recommended that the owner of a key-pair use her private key to sign her own public key. This self-signing proves to others who might use the public key to encrypt and send a file to the owner that the E-mail address appearing in the key is authorized by the owner. (This does not prove, however, that the owner is who she claims to be.)
- By signing the new public key after the ID of the ADK is added, the employee verifies that the ADK does indeed go with his public key, that he knows that any file or message encrypted for him will also be encrypted for the ADK. Without such a signature, the association of the employee's public key with the ADK is suspect. (See below.)
- The presence of the signature from the company's key validates the employee's key as being authorized by the company.
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.
- A company may request the use of an ADK on any encrypted message sent to its employees. This is not snooping; this is merely ensuring that business correspondence and data remain available to the company even after the employee departs. Even if an ADK is not flagged as mandatory, you should indeed comply. If an ADK is mandatory, you will be unable to encrypt messages to the company's employees unless you obtain the ADK (usually from a public key server) and allow its use.
- You must realize that, when a company uses ADKs, the management can decrypt and read not only any message you send to an employee but also any message that an employee sends to you. If you object to this, you should avoid using the company's Internet connection and company-owned computers when exchanging non-business messages with employees when they are being paid by the company to work.
- If you think you are indeed encrypting and exchanging personal communications but PGP indicates the use of an ADK, STOP!! Only commercial, purchase-ware versions of PGP can impose ADKs. The freeware versions of PGP can support requests or mandates to use ADK but cannot setup a public key to require an ADK. Therefore, the presence of an ADK ID clearly means you are about to send a message to someone through her company's PGP capability. Contact your intended recipient by some other means and ask her about the presence of an ADK ID on her public key.
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.
- Tom obtains a copy of Dick's public key from a key server. He uses a binary or hexadecimal file editor to add the fingerprint of his own key as an ADK ID to Dick's key and also set the flag to make ADK mandatory. Then he uploads the tampered key back to a key server. The uploaded key updates Dick's existing public key (as per the intentional design of key servers). Tom's public key was already on the same key server, which is part of a network of key servers.
- Dick wants to buy a very expensive stereo system from Harry's store. Dick sends Harry an encrypted E-mail message containing his Visa card number and asking for the total charge that will be placed on his account.
- Harry, having never before exchanged encrypted messages with Dick, does not have Dick's public key. Thus, Harry downloads Dick's key from a key server in the same network where Tom uploaded the tampered key.
- Harry attempts to send Dick an acknowledgement of Dick's message, complete with the amount charged to Harry's Visa card and the card number to which that amount was charged. However, Harry is alerted by PGP of the need for an ADK that is not on his keyring. Since he is a business user of PGP, Harry is somewhat familiar with ADKs. Thinking that Dick is sending E-mail from his workplace, Harry uses PGP to locate and download the missing ADK, after which he successfully sends the encrypted message to Dick. In the process, a copy of the message is also encrypted to Tom's public key.
- Having been monitoring E-mail traffic to and from Dick, Tom readily intercepts Harry's E-mail. The message is allowed to continue on to Dick; but Tom captures a copy. This is the hardest part of the whole scheme, but this kind of hacking does indeed occur. Notice that it does not involve PGP at all.
- Tom decrypts Harry's message to Dick using his own private key. Tom has a great weekend, charging meals, entertainment, and all kinds of purchases to Dick's Visa card.
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:
- PGP 6.5.8 was issued in both free-ware and purchase-ware versions. The latter was free to those who had already bought prior versions of PGP (including PGP Desktop Security). These new versions ignore any ADK ID whose presence on a public key has not been authenticated with the key owner's signature. (In the scenario above, if Harry installs a new version of PGP, his role is eliminated. Thus, the "hole" is nearly closed.)
- A freeware tool — PGPrepair — was released for use with Windows, UNIX, and Linux (but not Macs). This tool scans a user's keyring for keys that have ADK IDs that are not authenticated with the key owner's signature. Optionally, PGPrepair will strip those bogus ADK IDs from the affected public keys. (Harry should install this tool and check his keyring whenever he downloads a new or updated public key. Unfortunately, with the sale of PGP by NAI, I no longer have a link for downloading PGPrepair. If Harry requests, I can send him the actual installation file.)
- Patches were developed for public key servers that will strip bogus ADKs from keys being uploaded or updated. These patches are still in beta testing and have not yet been released for installation to all key servers. When they become available and are installed in the key servers, these patches would block Tom's ability to upload a tampered public key. (This part of the "hole" still gapes open.)
- NAI examined the world's largest key server (largest in terms of the number of keys held, almost 1,200,000) and sponsored the examination of the largest key server in Europe (over 1,100,000 keys) to determine the extent of the problem. Not one tampered key was found. (Okay, Tom has not yet started his criminal activity.)
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:
- Examine every new key you add to your keyring and every existing key that you update. If any request or require an ADK, scan your keyring with NAI's PGPrepair.
- When encrypting a file or E-mail message to someone else, be suspicious of the presence of an additional encryption to an ADK. If necessary, phone the other person and ask about the ADK. If you E-mail that person, request that she digitally sign her response. Then you will be able to verify that the response did not come from an attacker. (The security "hole" does not affect digital signatures.)
- Upgrade your version of PGP to 6.5.8 or a later version.
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:
- If you must use RSA keys, use only RSA v.3 keys. Avoid PGP 7.x or later versions when generating RSA key-pairs. The later versions have an option for RSA v.3, but it is possible to forget to use that option. For safety, use a PGP that simply cannot generate RSA v.4 keys (e.g., PGP 2.6.x).
- When you generate a new RSA v.3 key-pair, self-sign it immediately. This creates a baseline state against which you can later check your key for alteration into a RSA v.4 key. Of course, as described by Soldierer, you should always self-sign any key you generate — RSA or DSS/DH, PGP 2.6.1 or PGP 8.0.3 — even if the ADK "hole" is not a concern. (Starting with PGP 5.0, newly generated DSS/DH keys are automatically self-signed; but it does no harm to verify that this occurs.)
- If you find a copy of your public RSA key without your signature, immediately suspect that it has been altered from v.3 to v.4. Contact the source of that copy and alert her. Do not sign this unsigned key!
- When you add or update someone else's public RSA key on your keyring, use
PGPrepair to check for ADK alterations. (No, PGPrepair will not tell you the version of the key formats.) Even with PGP 2.6.x, which ignores ADK alterations, you should do this; then, if you find a tampered public key, you can notify the key's owner.
- When someone signs your public key and presents the results to you, do not self-sign it again. Once is enough. But do check to see if your signature is still there. If your signature is missing, notify the person who just signed your key about this attempted alteration. Check the public key servers. If the tampered key appears on the servers, you may have to revoke it and generate a new key-pair. Otherwise, whoever signed your tampered public key should delete that copy from his keyring and re-import the key from a key server.
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.
- Given the very sensitive nature of data that are encrypted — given the purpose of PGP — any security vulnerability is serious. Despite the assertion by NAI's head of PGP Security that any actual breach is unlikely and CERT's downplaying of the seriousness of the "hole", I do believe that an attack scenario as I described would not be truly difficult. If the attacker were a government, it would be especially easy. This "hole" is indeed the much-feared "backdoor".
- A little caution goes a very long way. You can easily avoid helping an attacker. If you have data so sensitive that you encrypt it before sending it to someone else, you should worry that an unintended third recipient might be decrypting it. Because of that worry, you should take all the preventive measures that keep you out of Harry's role.
- PGP is not dead! Senderek reported a software discrepancy in the implementation of a utility function of PGP. There is no discrepancy in the PGP algorithms or concept.
- Some users of PGP are very unhappy that the new versions fail to block any encryption to a tampered key. Yes, I would like a warning if I use a tampered key. But an outright refusal by PGP to use a tampered key could result in a denial of service attack against the key owner. If an attacker cannot capture copies of E-mail sent to his intended victim, he could still stop encryption of such E-mail. All that would be necessary would be to plant tampered public keys on key servers. This would force the sending of sensitive data as cleartext (without encryption).
- Some users are even more unhappy that the ADK capability was ever implemented. Long before Senderek's discovery, they decried ADK as a security breach. Rumors circulated that ADK was the dreaded "backdoor" that would allow the government to snoop into our encrypted data. While that might indeed be the result of the software discrepancy (especially if government agents succeed in convincing some key server operators not to install the corrective patches when they become available), the ADK capability is a valid concept. It avoids the need for businesses to adopt key escrow practices (which would give managers our passphrases and not merely our private keys). More important, it promotes the further spread of PGP, increasing our opportunities to use it and enhancing general attitudes towards keeping some messages and data secret. (The goal should be to eliminate the question: "Why do you think it's necessary to hide things?")
- I was concerned about the delay by NAI in allowing public inspection of the code for the patches and upgrades. Such inspections served to ensure vulnerabilities did not exist. No, those inspections are not perfect; they did allow this particular vulnerability to slip by for quite some time. However, without such inspections, Senderek could not have made his discovery. Fortunately, the PGP Corporation resumed the practice of allowing public inspections of its code.
- NAI failed to provide a proper explanation of the Trust Model option "Warn when encrypting to keys with an ADK" (Advanced tab on the Options window). Enabling this option does not always warn you when you encrypt to a public key that contains an ADK ID. According to various reports, this option provides a warning only if the requested ADK is not present on your keyring; some reports indicate the warning appears only if the missing ADK is mandatory. With PGP 6.5.8, NAI provided both a new PGP User's Guide and a new Help file. Neither documents clarified the simple statement of the check box. Indeed, the PGP User's Guide explicitly declares: "Use this checkbox to specify whether to issue a warning whenever an encrypt-to key has an associated Additional Decryption Key." Wrong!! In the conditions listed in the CERT advisory, use of the check box would provide no warning at all!
The exact same description for the checkbox appears in the PGP User's Guide issued by the PGP Corporation for PGP 8.0.3. However, the code was changed to reflect that description. That is, if you have both a public key with an ADK flag and the related ADK on your keyring, you will indeed get a warning before encrypting. (For PGP 8.0.3 freeware, the checkbox is always checked; the ability to uncheck it is disabled.)
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 29 January 2022
