The Zimmermann Telegram

I encourage you to use the latest version of PGP from NAI, PGP6.0.2. That's what I use, and it's every bit as secure as any previous version of PGP, in fact the security has only improved. Peer review of the source code has shown that there have never been any back doors in PGP, and still aren't.

In particular, PGP users of version 2.6.2 should upgrade to this latest version, and generate DSS/DH keys. These new keys use the Digital Signature Standard (DSS) and the Diffie-Hellman (DH) algorithms, both open standards and the default key type in PGP. All the new features are available only for DSS/DH keys. A vast majority of PGP users have already migrated to the new format.

PGP is the best and most widely used email encryption product in the world. Through its affiliation with NAI, PGP has achieved the sales volume and mind share that it needs to maintain its leadership position. You can remain confident that the PGP development team has held on to its integrity and commitment to personal privacy.

Keep the faith.

Sincerely,

Phil Zimmermann

We apologize to our customers and the community for any problems this flaw may have caused. We plan to remedy this in future by conducting more stringent and thorough reviews of any changes to any cryptographic portion of the PGP code.

This problem has been corrected in PGP Version 6.0.2 which, when installed, searches the user's disks for PGPdisk volumes encrypted with an earlier version of PGPdisk, and offers to re-encrypt them with a new session key using a corrected implementation of CAST. Volumes created with 6.0.2 are no longer compatible with older versions of PGPdisk, but meet the high security requirements of the PGP product line.

Discovery of this issue is a reminder of why peer review of cryptographic source code is vital to the integrity of a security product. This particular issue was found in-house; however, we publish our source code for cryptographic peer review to ensure against exactly this sort of problem. Network Associates remains committed to the cryptographic integrity of PGP products and we will continue to release the full source code to PGP for public peer review.

— The PGP Development Team

A “good first step” was the nearly unanimous response to Vice President Gore's September 16th announcement on a new U.S. encryption policy. While the policy as announced does not come close to satisfying all of the industry objectives regarding export controls on cryptography, it is moving towards a workable crypto resolution. The new policy reflects input from key companies in the network security industry, including Network Associates. More importantly, the Administration has indicated clearly, both in public and private discussions, that the new policy is intended to be a floor, not a ceiling. The extent to which the Administration consulted with industry prior to the announcement reflects a positive trend that the government has indicated will continue throughout the coming year. In fact, key industry players — including Network Associates — have already been approached by the Administration for suggestions as to how to continue the momentum and move forward with further reform. Network Associates intends to keep working with government officials to broaden the new rules to encompass more of our customers and our markets.

So what does the new policy really mean for companies that wish to export strong encryption products from the U.S.? For most companies, the news is mixed.

The Administration is slowly broadening the list of organizations that are entitled to receive strong encryption from the U.S. The current list includes most banks worldwide. The new policy includes broader ranges of financial institutions, as well as insurance firms, health and medical organizations, and online merchants. However, as the list gets broader, so do the conditions and caveats associated with each designated end-user. This truly is a mixed blessing (see bad news below).

Among the most positive implications of the September announcement was the clear step away from a government-mandated and approved “key recovery” standard toward a more market-driven concept of “recoverability.” This concept was driven in part by the so-called “Private Doorbell” alliance of companies. Network Associates, together with alliance companies, proposed the use of technologies existing in products that are currently on the market. The proposal to the Commerce Department suggests the use of technologies that provide a degree of plaintext access through, for example, network administrators. The “Doorbell” companies argued — in the end persuasively — that if certain products allow network operators to obtain access under appropriate legal authority, then the products should be exportable without having to meet some government-defined key recovery standard. The upcoming regulations are expected to define “recoverable” as these type of network-layer encryption products, and also other encryption applications such as those that enable companies to create back up recovery keys, regardless of whether use of “recovery” functionality is optional or mandatory in the product.

More disturbing is the fact that the agencies involved in writing these regulations still can't agree on acceptable asymmetric key lengths. According to government insiders, the NSA wants to limit exportable asymmetric keys to “less than 1024 bits,” while Commerce wants to use the language “less than or equal to.” The latter was clearly implied in the September announcement, but the dispute is ongoing and could delay the release of the regulations. Publication of the regulation is not currently expected until the end of December.

As indicated above, the list of organizations approved for encryption exports is a mixed blessing. The regulations will carve out biotechnology and pharmaceutical companies from the definition of health and medical organizations, leaving out some of the industry's most important customers worldwide. Telcos and ISPs are omitted from the definition of “commercial firms” that can receive “recoverable” products — again carving into the benefits to the industry and its customers. Finally, the definition of online merchants is yet to be determined, and may be another interagency sticking point delaying the publication of the regulations. (It took over a year for agencies to agree on the definition of “financial institution” to implement the policy first announced in May of 1997, and just published last month.)

Finally, companies that wish to take advantage of the new regulations will find new challenges in implementation, particularly since now exports will be enforced differently with respect to destination. For example, the “recoverable” rules apply to exports to 42 countries, while the financial institution rules apply to 45 countries. These changes, while they will ultimately benefit companies like Network Associates, create bureaucratic headaches in the short run while mass-market software vendors try to educate and impose export safeguards on domestic and international channel partners. As usual, the lawyers and consultants will be the first to benefit from the new rules.

As product manager for PGP products at Network Associates, I welcome you to the second edition of the Zimmermann Telegram. This quarterly publication will keep you up to date with the latest PGP happenings and developments.

With the latest release of PGP products, PGP has truly moved into the corporate arena as the weapon of choice for communications security. The desktop applications, which have long been PGP's strength, gained some cutting-edge new features, such as Blakely-Shamir key splitting and silent install for mass corporate installation. Combined with the new features is PGPdisk 2.0, which has been integrated into the PGP Desktop Security v6.0.2 and also includes the ability to use public key encryption for corporate data recovery. To provide scalability for an enterprise installation, the PGP Certificate Server v2.0.1 is available, including dupport for TLS (Transport Layer Security) for secure communications between client and server. The PGPsdk has also been updated, now version 1.5.1, to allow companies to create specialized applications using PGP's own libraries.

Clearly, the market has begun to appreciate PGP for the flexible, scalable, managable solution that we have known it to be. In the September 27 issue of PC Week, PGP Enterprise Security garnered "A" grades in Usability, Management, and Performance in a technical review of PKI solutions. In the October 5 issue of InfoWorld magazine, PGP was deemed “a quick, easy, robust solution to global encryption and signing for corporate email and data.” Consensus is building that PGP is the easiest to use, most manageable corporate solution available today.

Also planned are new command line versions of PGP for Windows platforms (95, 98, and NT) and major Unix platforms. This new command line version will allow users to easily integrate PGP into their web scripts and automatic ftp batch processing programs. We also plan for these versions to be as compatible as possible with version 2.6.2 command line options and version 5.0 options. This command line release of PGP is planned for early to mid 1999.

Lastly, regarding one aspect of the PGP team's relationship with Network Associates: after the acquisition of PGP by NAI, there were quite a few rumors regarding the future of PGP's individual and freeware products. Consistent with Network Associates' earlier statements, I would like to reiterate that we fully intend to continue creating freeware and individual versions of PGP that provide low cost, high security solutions to users everywhere.

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.

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

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

If no match is found, the passphrase is then compared to the public key headers on the PGPdisk. For each public 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.

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 reponsible 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 the 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 filesystem 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 curently 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 sucessfully 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 seemlessly. 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 the 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 in 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 applications 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 crytographic 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 the last page of the Zimmermann Telegram.