On the Recent PGP and Truecrypt Posting

[jon@xxxxxxx]

Here is some information about the issue with PGP and Truecrypt. We cannot 
speak for the Truecrypt people, but much of the explanation applies to their 
software as well as ours.

We are disappointed that the people who developed this report released it in a 
web site and on bugtraq before contacting us at PGP Corporation. This is 
particularly disappointing because this is a false alarm, as I will explain in 
detail below.

This morning, I was contacted by M. Jacques Viau of the Information Security 
Institute of Quebec, an equivalent of CERT and other governmental security 
organizations. M. Viau told me that the research here was done by someone in 
his organization. I expressed my dismay to M. Viau that a governmental 
organization would not adhere to any standards of responsible disclosure. M. 
Viau informed me that the report had inadvertently slipped out from his 
organization. He also said that his organization has been trying to contact 
PGP, but that their calls to Symantec had proved fruitless. I told M. Viau that 
PGP Corporation and Symantec are different companies. M. Viau was surprised by 
this, and I assured him several times that while it is indeed flattering to be 
considered a part of Symantec, PGP Corporation is an independent company and 
has never been formally associated with Symantec. Nonetheless, we appreciate M. 
Viau contacting us because before he phoned, we (and some of the peopl
 e who wrote us at security@xxxxxxx) were of the opinion that this was a 
deliberate hoax.

It is indeed disappointing that this report has gone out without independent 
verification because it is a false alarm caused by misunderstanding the way 
that encryption systems work. The explanation I give below applies not only to 
PGP products but to any cryptosystem based upon key wrapping.

When a disk is encrypted, the contents of the disk itself are encrypted with a 
"disk encryption key" that is a key in a symmetric cipher such as AES, CAST, 
3DES, Blowfish, etc. Note that this corresponds to the session key of an SSL 
session or the message bulk key in an OpenPGP or S/MIME message.

That disk encryption key is then itself wrapped in other security mechanisms. 
It may be encrypted to a public key. It may be encrypted with another symmetric 
key that is derived with a passphrase. It may be encrypted to a security token. 
Note that this also corresponds to the key wrapping that occurs in other crypto 
systems from SSL to OpenPGP to S/MIME.

When the disk is opened and mounted, the software decrypts the disk encryption 
key, with public key cryptography or symmetric key cryptography or fetching it 
from the security token (which likely involves the use of cryptography) or 
whatever other mechanism it has in place. The decrypted disk encryption key is 
then used to decrypt the blocks of the disk by the disk driver. 

In the case of a self-decrypting archive, the high-level structure is the same. 
A PGP self-decrypting archive is itself nothing more than a short cryptographic 
program that prefixes an OpenPGP file, just as a self-extracting archive is a 
short program that prefixes a ZIP file. When the program is run it expands the 
data in the tail end of the file.

The process this report outlines is as follows:

1) Create an encrypted disk volume, D. Use passphrase P.
2) Make a copy of that volume, D'.
3) On D', change the passphrase to P'.
4) Using a hex editor, copy the encrypted disk encryption key (which is P) from 
D to D', overwriting P'.
5) Mount the disk D' using the passphrase P.

Let me be blunt -- this is not a bug. This is what you would expect. While it 
may appear to be a problem when described as it is, it is actually 
sleight-of-hand. 

Consider, for example, a slightly similar case:

1) Create an encrypted disk volume D.
2) Lock this disk to a security token S.
3) Back up D to a CD-ROM.
3) Replace the binding of D to S with a passphrase, P.
4) Delete D.
5) Restore D with the backup.
6) Mount the disk with the security token.

I hope it is obvious that in my case, there is nothing untoward in having a 
restored backup accessible with the token. Yet this is exactly what the report 
does, except that instead of making a backup and restoring it, the researcher 
uses a hex editor to edit the changed portions of D' to make it match D again.

Simply put, if you change the passphrase on a PGP Virtual Disk, or a Truecrypt 
volume, or anything else, it does not change the passphrase on backups of that 
data. If you restore the data from the backup, the passphrase on the restored 
file is not the passphrase on the changed one.

At this risk of beating a horse to death, let me give one last analogous 
scenario. Let us consider a unix system that has its security information in 
/etc/passwd. This works the same on a system with shadow passwords, except that 
you have to work on /etc/shadow.

1) Set the root password to "1".
2) copy /etc/passwd to /etc/old-passwd. (cp /etc/passwd /etc/old-passwd)
3) change the root password to "2".
4) using your favorite text editor, edit /etc/passwd and /etc/old-passwd
5) Copy the "root" line from old-passwd to passwd. Save the file.
6) Note that you can now log into root with "1" not "2".

The reason you can do this is that you have, using your text editor, restored 
the passwd file from its backup. This is the same thing that the report does 
with cryptographic files.

This example illustrates why we originally believed that this was a malicious 
hoax, and not a mere misunderstanding. Changing the encrypted disk encryption 
key does not re-encrypt the disk. There is, however, in PGP a "Re-Encrypt" 
button that will re-encrypt the volume. If you change the security parameters 
of a disk and wish to *revoke* old security parameters, you must re-encrypt the 
disk, which is an option available. However, please note that even 
re-encrypting does not solve the core issue, which is expecting a backup to 
change along with the live data. 

For completeness, I'll note that we are discussing whether we should add in a 
warning dialog to the passphrase change on a PGP Disk, to tell the user that an 
attacker who has learned an old passphrase, has an old disk and a hex editor 
can patch the disk so that it can be opened. On the one hand, this might be a 
good thing to do. On the other hand, merely describing the situation is 
difficult and there have been recent notable research on security software that 
pushes too much of the responsibility to a user who doesn't know what to do 
except press "OK."

There are two other situations described in this report, that patch the program 
and get access to encrypted data.

Let me re-examine the process that decrypts data. After the secured disk 
encryption key has been opened, we have to know that it is the *right* disk 
encryption key. If someone types the wrong passphrase, uses the wrong public 
key, or a different security token, then the software will get a bogus key. If 
the disk is decrypted with a bogus key, it will be random garbage and the file 
system will interpret it as a trashed disk. An SDA will unload a set of files 
that are decrypted with the wrong key and thus contain gibberish. And so on.

What this report does in its second and third steps is to patch out the check 
that verifies that the security parameters (passphrase, public key, etc.) are 
the correct ones. Then the software uses the wrong keys to decrypt the data and 
the result is as you would expect. There is no bug here.

Summing up, we are disappointed that for whatever reasons, we were not 
contacted about this research before it was put on the web and posted on 
bugtraq. Had we been contacted, we could discuss this in private rather than 
have to air the details of this misunderstanding in a public forum. I am truly 
sorry for the sake of the Information Security Institute of Quebec and its 
staff that this complex issue has turned into a public brouhaha.

        Jon

-- 
Jon Callas         
CTO, CSO           
PGP Corporation         Tel: +1 (650) 319-9016
3460 West Bayshore      Fax: +1 (650) 319-9001
Palo Alto, CA 94303     PGP: ed15 5bdf cd41 adfc 00f3
USA                          28b6 52bf 5a46 bc98 e63d