Date: 26 May 2006 21:36:48 -0000
From: jon@....com
To: bugtraq@...urityfocus.com
Subject: On the Recent PGP and Truecrypt Posting


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 people who wrote us at security@....com) 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

Powered by blists - more mailing lists