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