The Zimmermann Telegram
IN THIS ISSUE
An Open Letter to PGP Users
(cz)
An Important Announcement for PGPdisk for
Windows Users
(cz)
New U.S. Government Crypto Rules Bring Good
News and Bad News
(cz)
A Word from the Product Manager
(cz)
Technical Details of PGPDisk
(cz)
Last page
(cz)
Technical Details of PGPdisk
Nick Ryan
Software Engineer
PGP is perhaps best known for its powerful email encryption utilities. While public key encryption was at first a difficult concept for many to understand, it's not uncommon these days to see PGP key fingerprints on business cards. Using PGP, it is now possible to transmit virtually any form of information over any kind of network with complete security.
Communications privacy is only
part of the picture, however. It makes little sense to encrypt your email
while at the same time leaving your confidential files unprotected on your
computer. Although PGP itself can be used to protect individual files,
it's inconvenient to manually encrypt and decrypt documents you use frequently.
PGPdisk, included in PGP versions 6.0 and later, provides an easy way to
secure your data.
How PGPdisk Works
Like 'traditional' PGP, the concept of PGPdisk can be difficult at first to grasp. PGPdisk creates a virtual encrypted volume of any fixed size in which you can store any number of files. Most people are aware that the files on their computer are stored on hard disks. However, the computer's operating system isn't restricted to seeing each hard disk as a single container.
It views a hard disk as one or more volumes, each of which is a logically separate entity. A volume is simply a name for a piece of storage that can be used to hold files, and a single hard disk can contain more than one volume. On a Microsoft Windows machine, volumes are assigned drive letters from 'A' to 'Z', while on the Macintosh volumes can be given any name. Some types of volumes, such as ZIP disks, can be made to appear and disappear from the machine, a process which is called 'mounting' and 'unmounting' a volume.
A user can mount or unmount PGPdisk volumes, or 'PGPdisks' at will, simply by entering a passphrase. The unique aspect is that a PGPdisk volume is not really a container full of files, but a single file stored on another volume. This is possible because volumes are merely abstractions that can be implemented however the software sees fit. The actual implementation is transparent to both the OS and the user, thus making a PGPdisk seem like any other volume and thus very easy to use. If a user wants to create a 100-MB encrypted volume, PGPdisk will create a 100-MB PGPdisk file. To use the file, the user asks PGPdisk to mount it, enters the password, and the volume appears on his computer just as if it were another drive, like the C: drive. The encryption and decryption happens transparently in the background.
PGPdisks are very secure. Data in a PGPdisk file is always stored in encrypted form, even while the volume is mounted. The data is secure even if the computer is turned off or crashes. In fact, this is the most important feature of using PGPdisk: the data is encrypted unless it is in use.
The PGPdisk program itself has
no knowledge of any of the data stored on any PGPdisk volume. The filesystem,
which is controlled by the operating system, is responsible for handling
all file and directory requests directed at the volume. It translates these
operations into reads and writes of individual blocks û or 'sectors' û
of data, which it then forwards to the volume. A PGPdisk, therefore, is
not a filesystem û it is a volume. When a user creates a PGPdisk volume,
he or she is given the opportunity to format it using any available filesystem.
Although this makes it impossible to use PGPdisks across multiple platforms,
it provides for maximum compatibility with a large number of applications.
The PGPdisk Internals
A PGPdisk file is treated as a collection of 512-byte- sized blocks, which comprises the volume. Blocks at the beginning and the end of the file are used to store administrative data such as the file allocation table, while the center portion of the file û the data area û holds an encrypted image of the PGPdisk volume itself. PGPdisk satisfies read and write requests from the operating system by mapping them to reads and writes from the data area, performing on-the-fly encryption and decryption as needed. As described above, PGPdisk is unaware of the files stored on an unmounted PGPdisk. This is so one can use any filesystem to format a PGPdisk volume. PGPdisk does not need to know how the filesystem has chosen to store data on the volume.
The reserved blocks at the beginning
and end of the PGPdisk file are used to store a linked list of header structures,
whose primary function is to store cryptographic data. PGPdisk uses a 128-bit
version of the symmetric CAST algorithm for encryption and decryption.
When a PGPdisk volume is first created, it gathers random data from the
user and uses this data to create a unique 128-bit CAST session key, as
well as 64- bits of 'salt.' Salting refers to the process of combining
an arbitrary number with the passphrase during the session key creation
process, to make dictionary-based attacks on the passphrase infeasible.
The user enters a passphrase, which will become the 'master passphrase'
for the PGPdisk. (A single PGPdisk has one master passphrase and can have
up to seven alternate passphrases, as well as an unlimited number of
PGP public keys.) PGPdisk then creates the new volume, and
the data area is zeroed and encrypted with the session key.
PGPdisk Passphrases
Normally, encryption keys can have only one passphrase. However,
PGPdisk allows multiple passphrases to access the same CAST session key.
This is accomplished by storing a separate, encrypted copy of the session
key for each passphrase. To add a passphrase, the user must first enter
the master passphrase for the PGPdisk. This passphrase is used to retrieve
the PGPdisk session key, after which the user is given the opportunity
to add an additional passphrase. PGPdisk then performs a SHA-1 hash and
salts the new passphrase and uses the result as a CAST key, which is used
to encrypt the master CAST session key. The encrypted CAST session key
is then also stored in the header.
In the case of a public key passphrase,
the user is asked to specify a public key that he wishes to attach to the
PGPdisk. Using the PGPsdk (the encryption libraries used in all PGP products),
PGPdisk then encrypts the session key using the specified public key and
stores the result in a new header, along with the key ID of the specified
public key. This is similar to the way in which an email message is encrypted
with PGP.
How a PGPdisk is Mounted
To mount a PGPdisk, the user enters a passphrase. The passphrase is first checked against the master passphrase and any alternate passphrases. If a match is found, the key is used to decrypt the encrypted session key stored in the associated passphrase structure, and the PGPdisk is mounted.
If no match is found, the passphrase is then compared to the public key headers on the PGPdisk. For each public key header, PGPdisk uses the PGPsdk to determine if the entered passphrase unlocks the private key that corresponds to the public key whose ID is stored in the header. (If the public/private key pair is not on the current keyring, this process fails, and the user is warned). The encrypted session key is then decrypted using this private key.
In the PGPdisk file, all master and alternate passphrase key information is stored in a single structure called the primary PGPdisk file header. This structure contains version information, some salt data, and other administrative data. It also contains the aforementioned passphrase key structures, one each for the master passphrase and up to seven alternate passphrases. This primary file header is stored in the first block of the file, and a backup copy called the alternate header is stored in the last block of the file. Additionally, public key passphrases are stored in separate headers called PGPdisk public key headers. Each is one or more blocks in size, depending on the size of the encrypted data (which varies with the public key size). These headers are stored in a linked list beginning after the primary file header. Depending on the number of reserved blocks at the beginning of the PGPdisk file, additional public key headers can be stored at the end of the file if space runs out at the beginning.
The PGPdisk header format is flexible enough to allow for use of 128-bit symmetric algorithms other than CAST, but no such expanded functionality is currently supported by the code.
PGPdisk also takes great care
to make sure that all sensitive key and passphrase data are stored in secure
memory buffers. These buffers are locked in memory to prevent them from
being swapped to the page file, and they are cleared before being freed.
In addition, all text entry boxes in all passphrase dialogs are implemented
such that no copy of the passphrase is stored in the clear anywhere in
memory û even during entry. Although a keystroke monitoring program can
still be used to capture a passphrase while it is being typed, this is
a potential problem with any security product on any platform. It is virtually
impossible to provide 100% protection against such programs, since
a monitor can be written to hook into the operating system at any one of
many layers.
PGPdisk and Microsoft Windows
The heart of PGPdisk lies in the PGPdisk driver. A driver is a piece of software that is executed at a higher privilege level than ordinary code, such as an application. To perform such operations as mounting and unmounting volumes under Windows, one must write a driver.
In both Windows 98 and NT there is a distinction between user-mode and kernel-mode code. User-mode refers to executables that use the Win32 API, such as the PGPdisk application and the PGPdisk shell extension DLL. These components can run unchanged under either operating system. Kernel-mode refers to drivers that are allowed to perform tasks such as interfacing with hardware and implementing filesystems. Windows 98 and NT have completely different driver APIs, which required us to write two versions of the PGPdisk, one for each OS. Here I will focus on the NT driver, which is more advanced in concept and practice. The primary task of the PGPdisk driver is to present a view of the PGPdisk volume to the operating system. This encompasses creating and deleting drive letters and processing I/O requests. The driver also performs several secondary tasks, such as locking memory buffers and hooking mouse and keyboard activity.
When a user wishes to mount a PGPdisk, the PGPdisk application is responsible for requesting a passphrase and decrypting the session key. It then communicates to the PGPdisk driver the session key, the path of the PGPdisk file, and the user's preferred drive letter. The driver then calls system services to create a new volume object and to associate it with a drive letter. The volume is not yet available for access, however. First, a filesystem must be attached to the volume. This is accomplished by the OS, which asks each installed filesystem driver if it recognizes the new PGPdisk volume. Each driver reads the first sector of the PGPdisk, which contains a signature identifying the 6lesystem used to format the volume. If the driver recognizes the signature, it 'claims' the PGPdisk volume as its own and presents a file/directory view to the system. To unmount a PGPdisk, the PGPdisk driver first ensures that none of the files on the volume are currently in use. It attempts to lock the volume for exclusive access, and if the lock attempt fails, PGPdisk asks the user to close any open applications that may be using the volume. Once the volume is successfully locked, the driver tells the system to sever the link between the PGPdisk volume and its drive letter.
The driver does much more than simply mount and unmount PGPdisks, however. It also processes all I/O requests for its volumes using separate kernel-mode threads, one for each mounted PGPdisk. When a request is received, it is queued to the associated PGPdisk thread for processing. In the case of a read or a write, the thread reads or writes the associated data from the PGPdisk file itself and performs on-the-fly encryption or decryption as needed.
It's a little known fact that drivers under both Windows 98 and NT can open files just as applications can. Due to the unique nature of the kernel-mode environment, one must take care to prevent deadlocks. As long as all the rules are followed and the appropriate synchronization mechanisms are put in place, the process works nearly seamlessly. Microsoft probably never anticipated that volumes and files would be used in this manner, but did not explicitly prohibit such use.
It is generally a good idea to execute as little code as possible within kernel-mode. The reason is that when a problem or a crash happens in kernel-mode, it is highly likely to bring down the system with a hang or a blue- screen, while a crash is user-mode results in at most the loss of the current application. For this reason, non- essential functions such as PGPdisk header verification are best left to the application, not the driver. The easiest way to enforce this is to ensure that as little functional code as possible is shared between the driver and the application. One can then be free to put as many bells and whistles into the user-mode code as one wishes, while keeping the kernel-mode code as lean as possible.
The driver also performs two other very useful functions. Earlier I mentioned that PGPdisk is careful to hold sensitive key and passphrase data in locked memory buffers. Ordinarily, a Win32 application cannot tell the system to allocate locked memory for it. A driver can lock any range of pages in memory, however. The PGPdisk application calls into the driver quite frequently to lock down its secure buffers, and to unlock them before they are freed.
The driver also hooks mouse and keyboard input. This is necessary to support PGPdisk's inactivity timeout feature, which can automatically unmount all PGPdisks after the computer has been idle for a specified period of time. There is unfortunately no support for such functionality in Win32, so the task must be left up to the driver. The hooks are very simple, since they just have to reset an idle-timeout counter every time a key or a mouse button is pressed. Rest assured that no record is kept of anything the user types or does. Remember my comments above about how easy it is for keystroke monitors to hide in a computer? This demonstrates how easy it is to hook into the system at a very low level.
As you can see, PGPdisk is a very complex application, yet it provides strong security in a simple, easy-to-use, and convenient format. If you are interested in reviewing PGPdisk more closely, we encourage you to take a look at the source code, which we print for cryptographic peer review. The PGPdisk source code is included with the source code for PGP 6.0 and later. Details on how to obtain the source code books are included on that last page of the Zimmermann Telegram.
á
á