17.2 SECURE MESSAGING PROTOCOLS

Team-Fly

One possibility to securely transfer an e-mail message is to cryptographically protect it in a way that is useful only for the intended recipients. For example, the message can be digitally enveloped to protect its confidentiality or digitally signed to protect its authenticity and integrity:

As explained in Section 5.5, the message is digitally enveloped by encrypting it with a randomly chosen message key, encrypting the message key with the recipient's public key, and sending both—the encrypted message key—to the recipient. The recipient, in turn, can decrypt the message key with his or her private key and decrypt the message with the resulting message key. If there are multiple recipients, the message key is encrypted with the public key of each recipient.
As explained in Section 5.4, the message is digitally signed by computing a one way hash from the message and encrypting the hash value with the sender's private key.

All secure messaging schemes and protocols that are relevant today follow this approach and provide support for both digital envelopes and digital signatures [4]:

Privacy enhanced mail (PEM) and MIME object security services (MOSS);
Pretty Good Privacy (PGP) [5–7];
Secure MIME (S/MIME).

In short, PEM was an early standardization effort initiated by the IRTF Privacy and Security Research Group and later by the IETF PEM WG [8].^[3] In fact, PEM was the first serious effort to provide security services for Internet messaging. The work led to the publication of a four-part PEM specification in February 1993 [9–12]. The specification was submitted to the Internet standards track as a Proposed Standard. Unfortunately, PEM was never a recognized success in terms of commercial deployment. One of the main reasons for its lack of success was because it was limited to 7-bit encoded ASCII messages, and was incompatible with the MIME format which was developed around the same time. The other main reason for its lack of commercial success was its strict use of a hierarchy of CAs that serves as a PKI for PEM.

After the publication of the original PEM specifications in 1993, the IETF PEM WG continued to work on the development of PEM-like security services for use in conjunction with MIME messages. This work was completed in 1995 and resulted in two separate specifications which solve two parts of the MIME incompatibility problem:

RFC 1847, entitled "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted," specifies two additional MIME content types for encrypted and digitally signed messages (i.e., multipart/encrypted and multipart/signed) [13].
RFC 1848, entitled "MIME Object Security Services" (MOSS), defines a set of procedures and formats for digitally signing and encrypting MIME body parts for use in conjunction with the content types introduced in RFC 1847 [14]. When a digital signature is applied to a MIME object, the multipart/signed content type is used. When encryption is applied, the multipart/encrypted content type is used. Contrary to PEM, digital signature and encryption mechanisms can also be used independently (whereas PEM required that encrypted objects are always digitally signed).

Following the terminology introduced in RFC 1848, the entire architecture was named MOSS. It is further described in [15]. In summary, MOSS was an attempt to overcome the limitations and shortcomings of PEM (namely the incompatibility with MIME messages and the far-too-strict PKI requirements). But MOSS also had so many implementation options that it was possible and very likely for two independent software developers to come up with MOSS implementations that would not interoperate. MOSS can be thought of as a framework rather than a specification, and considerable work in implementation profiling remains to be done.^[4]

While PEM and MOSS failed to become commercially successful and have sunk into oblivion, the secure messaging schemes that are in widespread use (i.e., PGP and S/MIME) copied the good features of their predecessors while attempting to avoid the bad ones. For example, PEM introduced the use of digital envelopes and the base-64 encoding scheme, and all secure messaging schemes that were proposed afterward have retained these features.

Today, PGP and S/MIME are the way to go for secure messaging on the Internet. S/MIME is a specification, whereas PGP can be thought of as both a specification and a software package. PGP and S/MIME are very similar in nature. For example, they both use public key cryptography and digital enveloping techniques to digitally sign and cryptographically protect e-mail messages. They are overviewed and briefly discussed next. Again, more background information about secure messaging in general and PGP and S/MIME in particular is available in [4].

17.2.1 PGP

PGP is a software package that was originally developed by Philip R. Zimmermann in the early 1990s [5–7]. At that time, Zimmermann selected some of the best available cryptographic algorithms (i.e., MD5, IDEA, and RSA) as building blocks, integrated them into a platform-independent software package that was based on a small set of easy-to-use commands, and made the resulting software and its documentation, including the source code written in the C programming language, publicly and freely available on the Internet (at least for citizens from the United States and Canada). In addition, Zimmermann entered into a legal agreement with a company called Viacrypt to provide a fully compatible commercial version of PGP that was reasonably priced.^[5] The commercial version of PGP was primarily intended to satisfy the requirements of users who wanted to have a product with full professional vendor support. There were at least two legal problems related to the first versions of PGP:

The PGP software used the RSA algorithm for authentication and key distribution. As mentioned in Chapter 5, the RSA algorithm was protected by a U.S. patent (that expired on September 20, 2000);
More important, the U.S. government held that export controls for cryptographic software were violated when the PGP software spread around the world following its publication as freeware.

The first problem was settled with the patent holders of the RSA algorithm by having the PGP software include and make use of a cryptographic subroutine library that was distributed by RSA Security, Inc.^[6] More specifically, beginning with version 2.5, the PGP software included and made use of the RSAREF cryptographic subroutine library to perform RSA public key computations. The RSAREF library, in turn, was distributed under a license that allowed noncommercial use within the United States. The commercial use of RSAREF, however, required the payment of a license fee to RSA Security, Inc. Because the commercial version of PGP was sold by Viacrypt, the use of RSAREF in this version was properly licensed.

The second problem was more severe. In fact, it led to a three-year criminal investigation by the U.S. government. Zimmermann was accused of a federal crime because the software had flowed across national borders. The investigation was carefully followed by both the trade press and the general public as further described in [7].

After the government dropped the case in early 1996, Zimmermann founded a company called Pretty Good Privacy, Inc.,^[7] which was acquired by McAfee Associates in December 1997. At the same time, Network Associates, Inc. (NAI) was formed by a merger of McAfee Associates and Network General. Today, NAI is one of the world's largest network security and management software companies with four business units and more than 2,700 employees. Zimmermann was employed by NAI until early in 2001, when he left the company to join Hush Communications.^[8]

In the United States and Canada, the PGP software is publicly and freely available for noncommercial use, but must be licensed for commercial use from NAI:

The noncommercial version of PGP is distributed by MIT.^[9]
The commercial version of PGP is distributed by NAI and its local resellers.

Outside the United States and Canada, the legal situation is less clear. Some years ago, the international PGPi scanning project was initiated and launched.^[10] The idea of the project was to export the source code of the PGP software in optical character recognition (OCR) format, and to recompile and rebuild the software entirely outside the United States and Canada. Note that the U.S. Export Administration Regulations (EAR) explicitly state:

"A printed book or other printed material setting forth encryption source code is not itself subject to the EAR ( … )"

Consequently, source code is not subject to the EAR and can be exported from the United States. If the source code is recompiled and rebuilt entirely outside the United States, a fully compatible and interoperable software package is created. The resulting versions of the PGP software (also referred to as PGPi) are publicly and freely available from the International PGP home page at http://www.pgpi.org (the site is physically located in Norway). Note that the amount of source code is huge. For example, PGP 5.0i was recompiled and rebuilt from source code that was printed in 12 books containing more than 6,000 pages, whereas PGP version 6.5.1 already came along with 40 books containing more than 20,000 pages.

In addition to the PGPi scanning project, NAI used Network Associates International B.V. in The Netherlands to market PGP products outside the United States and Canada. The corresponding Web site is available at http://www.pgpinternational.com. More specifically, the PGP products sold by Network Associates International B.V. were recompiled and rebuilt by a Swiss company called cnlab Software AG^[11] based on the C code that was legally exported from the United States (the same source code that is used for the domestic versions of the PGP software). NAI B.V. licensed the PGP software from cnlab Software AG to market it outside the United States and Canada. To comply with the EAR, NAI had to make sure that no technical assistance or support was provided from the United States to cnlab Software AG or to any international users of PGP products, and that all support for international users came from non-U.S. nationals, either from employees of NAI B.V., employees of cnlab Software AG, or anyone else.

This situation has changed and the liberalized U.S. export controls have made it possible for NAI and its PGP Security business unit to legally distribute PGP products on a worldwide scale. In fact, on January 20, 2000, PGP Security announced^[12] that its software had been successfully exported from the United States for the first time under the new export regulations. At an event launching the new PGP Security business unit of NAI, the software was exported by sending it as a binary e-mail attachment to a recipient in the United Kingdom. This simple act would have been designated a federal crime until January 14, 2000, when new export regulations were adopted by the U.S. Department of Commerce (DoC) to allow the use of U.S.-developed cryptographic technology worldwide (refer to Chapter 4 for a brief discussion of the new U.S. export regulations). It will be interesting to see how the new export regulations influence the worldwide distribution of PGP software and products. In either case, NAI still recommends buying the software from its local resellers.

As mentioned, the first versions of PGP were implemented by Zimmermann. Major parts of later versions of PGP, however, were implemented by an international collaborative effort involving a large number of contributors. Here, we use the term PGP to refer to software developed by NAI (or its PGP Security business unit respectively) or any other software that implements and conforms to the PGP or OpenPGP specifications. There are many versions of PGP in use today:

PGP 2.6.x was the first version that was widely used and internationally deployed. This version of PGP is specified in the informational RFC 1991 [7]. It requires the use of MD5, IDEA, and RSA.
PGP 5.x was introduced to define new message formats and correct a number of problems in the PGP 2.6.x design. PGP 5.x is also known as PGP 3.
After the release of PGP 5.x, an IETF OpenPGP WG was formed in the IETF Security Area. The aim of the WG was to use PGP 5.x as a basis and to come up with a new OpenPGP specification. More recently, OpenPGP was specified in RFC 2440 [8] and submitted to the Internet standards track.^[13]
Based on PGP 5.x and the OpenPGP specifications, NAI came up with PGP 6.x that introduced some new features that go beyond a tool for secure messaging. Two of these features include PGPnet, which is basically a "bump-in-the-stack" implementation of the IP security (IPsec) protocol suite (as explained in Chapter 14), and PGPdisk, which allows a user to transparently encrypt and decrypt partitions on local hard disks. The latest and most widely deployed version of PGP 6.x is PGP 6.5.3.
In September 2000, NAI publicly released PGP Desktop Security 7.0. In addition to the functionality of PGP 6.5.3, PGP Desktop Security 7.0 provides a personal firewall and a personal intrusion detection system (IDS). The reason for this is that any computer system that uses PGPnet to interconnect to an intranet represents a network access point and must be protected accordingly (e.g., using a personal firewall and/or IDS). Furthermore, PGP Desktop Security 7.0 fully integrates with X.509-based PKIs and provides a single sign-on (SSO) mechanism for the Windows 2000 operating system. Finally, PGP Desktop Security 7.0 comes with an optional passphrase recovery mechanism.^[14] Support for smartcards (primarily for the European market) and USB tokens (primarily for the U.S. market) was stated to become available in PGP 7.1.

In addition, there are several PGP versions that are marked with special characters. For example, we mentioned in footnote 10 that a PGP version number with an appended character "i" (e.g., PGP version 6.0.2i) refers to an international version that is made available as part of the PGPi scanning project, meaning that the software has been recompiled and rebuilt entirely outside the United States and Canada.

Contrary to MOSS and S/MIME, PGP must not be integrated into the user agent software. A user can create a message with his or her favorite word-processing program (e.g., a "normal" text editor or Microsoft Word), digitally sign or encrypt the file with PGP, optionally encode it for transport with PGP's radix-64 encoding function or any other encoding utility, and finally use a commercial off-the-shelf (COTS) user agent of his or her choice to send the resulting message to the recipient. The point to make and to remember is that PGP must not be part of the user agent that is finally used to send out the message, and that PGP can reside entirely outside the user agent. However, from a user's point of view it is more convenient to have PGP incorporated into and become part of the user agent software. In the simplest case, the user has two buttons, one for signaling the use of digital signatures (to protect the authenticity and integrity of a message) and one for signaling the use of digital envelopes (to protect the confidentiality of a message).

If a user agent is MIME compliant, it may even be possible to combine PGP's functionality with the functionality of MIME. In fact, the approach to combine PGP and MIME is called PGP/MIME and the approach to combine OpenPGP and MIME is called OpenPGP/MIME:

PGP/MIME is based on the message formats defined in RFC 1991 [16] and further specified in RFC 2015 [17].
OpenPGP/MIME is based on the message formats defined in RFC 2440 [18] and further specified in a pair of Internet-Drafts^[15] that are developed by the participants of the IETF OpenPGP WG. By the time you read this book, these Internet-Drafts will probably have become standard track RFC documents.

Note that RFC 1991 requires the use of patented cryptographic algorithms (RSA and IDEA), and that it cannot be submitted to the Internet standards track accordingly (it has been published as an informational RFC document). Because RFC 2015 relies on RFC 1991, it cannot be submitted to the Internet standards track, either. Consequently, PGP/MIME is not going to become an Internet standard. Contrary to that, it is likely and very possible that OpenPGP/MIME as specified in RFC 2440 will be submitted to the Internet standards track and that PGP/MIME implementations will be replaced by OpenPGP/MIME implementations in the future. In the meantime, not all user agents implement the PGP/MIME and OpenPGP/MIME specifications. For example, Qualcomm Eudora version 4.3 implements only PGP/MIME, whereas Microsoft Outlook Express version 5 implements neither of the two specifications.

Finally, note that an interesting alternative to NAI products is being developed in Germany. More specifically, the German Federal Ministry of Economics and Technology issued a DM 250,000 grant to the GNU Privacy Guard (GPG) project on November 19, 1999. The aim of the project is to further develop the GnuPG software, a free and open source implementation of the OpenPGP specification. Because GnuPG does not use IDEA or RSA, it can be used without any legal restriction. The software is currently available only as a command line program (a GUI version is planned for the future). Further information about the GPG project in general, and the GnuPG software in particular, is available at http://www.gnupg.org.

It is commonly agreed that the (cryptographic) strength of PGP, OpenPGP, and GPG is comparably good. In fact, there have been published only two vulnerabilities so far:

A vulnerability was found in the additional decryption key (ADK) feature of PGP in August 2000. In fact, it was possible to add an ADK to a PGP certificate in order to have a specific message key be additionally encrypted with this ADK. Anybody who knows the ADK is able to decrypt the message key and the message accordingly. The vulnerability is further described in CERT Advisory^[16] CA-2000–18 entitled "PGP May Encrypt Data with Unauthorized ADKs."
Two Czech cryptologists, Vlastimil Klima and Tomas Rosa, publicly announced the discovery of a flaw in the OpenPGP format in March 2001. The flaw was reported in The New York Times and refers to the way in which a user's private key is stored in an OpenPGP key ring. More specifically, the integrity of the key is not entirely protected. This allows an attacker (who has physical access to the private key ring) to modify the key and to invoke the use of this key for the generation of future signatures. Equipped with a legitimate signature and a signature that uses the modified key, the attacker can cryptanalyze the user's private key. The flaw is severe. Nevertheless, keep in mind that exploiting the flaw requires physical access to the private key ring, and that by having this kind of access, it is much simpler for the attacker to simply grab the encrypted key ring and use a keylogger to eavesdrop on the passphrase that is required to decrypt the private key.

Unfortunately, it is not clear whether—and if so what—other vulnerabilities have been found in PGP, OpenPGP, and GPG software packages so far.

17.2.2 S/MIME

Earlier in this chapter, we mentioned that PEM was an early IETF-initiated Internet standardization effort for secure messaging that suffered from two major limitations and shortcomings (namely, the incompatibility with the MIME message formats and the far-too-restrictive PKI requirements), and that MOSS was an attempt to overcome them. In parallel with the development of MOSS in the mid-1990s, however, an industry working group led by RSA Security, Inc., started to develop another specification for conveying digitally signed and/or encrypted and digitally enveloped data in accordance to the MIME message formats and some of the earlier specified public key cryptography standards (PKCSs).^[17]

The approach and protocol specifications that were developed by the industry working group were named Secure Multipurpose Internet Mail Extensions (S/MIME). Similar to PEM and MOSS, S/MIME also was designed to add security to e-mail messages that make use of the MIME message formats. Consequently, S/MIME cannot be used with user agents that do not provide support for MIME (contrary to PGP). Unlike PEM and MOSS, however, S/MIME has been successfully deployed in the marketplace.

While the goals of MOSS and S/MIME were largely the same, the final solutions ended up being quite different. This is primarily because S/MIME is built on top of some PKCS specifications (and as such makes heavy use of ASN.1 specifications), whereas PEM, MOSS, and PGP use character-encoding style of protocols. Note, however, that this is not a fundamental difference, but rather an implementation issue. Also note that using established encoding schemes is certainly good practice, as any security analysis does not have to start from scratch.

As of this writing, there are three versions of S/MIME, of which only versions 2 and 3 are used in practice:

S/MIME version 1 was specified and officially published in 1995 by RSA Security, Inc. [19].
S/MIME version 2 was specified in a pair of informational RFC documents—RFC 2311 [20] and RFC 2312 [21]—in March 1998.^[18]
The work was continued in the IETF S/MIME Mail Security (SMIME) WG and resulted in S/MIME version 3 in June 1999. S/MIME version 3, in turn, was specified in a set of five related RFC documents (RFC documents 2630 to 2634 [22–26]) and has been submitted to the Internet standards track.^[19] The changes between version 2 and version 3 are not fundamental, and it is generally recommended that S/MIME version 3 implementations should attempt to have the greatest interoperability possible with S/MIME version 2 implementations. The S/MIME version 3 enhanced security services as specified in [26] are taken rather directly from the Message Security Protocol (MSP) that was developed for the Defense Message System during the late 1980s, before the S/MIME work.

Since the very beginning of the standardization effort, many vendors of Internet messaging products (including, for example, Microsoft and Netscape Communications) have actively supported S/MIME. In fact, S/MIME is an integral part of most user agent software packages that are available today. This commitment and strong vendor support have not changed so far and are likely to continue in the future.

In the past, S/MIME has had some difficulties receiving consideration as an Internet standards track protocol because of its use of patented technologies and algorithms. Historically, all standards approved by the IETF must use only public domain technologies and algorithms, so anyone can implement them without paying royalties to patent holders. Unfortunately, this is not the case with some public key algorithms. For example, we mentioned in Chapter 5 that the RSA public key algorithm was protected by U.S. Patent No. 4,405,829, "Cryptographic Communications System and Method," granted to MIT in September 1983. Also, other public key algorithms are protected by patents.^[20] As mentioned, S/MIME makes use of PKCS #1, PKCS #7, and PKCS #10. Although the PKCS specifications are freely available, any developer who wants to use the algorithms described therein (e.g., the RSA algorithm), whether he or she uses RSA Security's own toolkits or not, is required to pay RSA Security, Inc., royalties, at least for products created and distributed in the United States.^[21] Because of this situation, Internet standardization for S/MIME version 2 has been blocked and the pair of informational RFC documents is historical material being published for the public record. Meanwhile, the situation has improved mainly for two reasons:

S/MIME version 3 provides more flexibility with regard to the cryptographic algorithms that must be supported.
Most public key patents have expired (e.g., the patent for the Diffie-Hellman key exchange and the RSA algorithms).

Consequently, it is possible and very likely that the situation is going to improve and that Internet standardization for S/MIME version 3 will speed up considerably.

Finally, because S/MIME version 3 has been submitted for possible consideration as an Internet standards track protocol, interoperability has become a major issue. Vendors participate in S/MIME compliance and interoperability testing programs conducted over the Internet. As such, they put their application programs through S/MIME test suites that include on-line certification, digitally signed and digitally enveloped message creation, and verification and decryption of received messages. For example, RSA Security, Inc., runs an S/MIME interoperability center that may serve as a reference.

^[3]Both groups no longer exist.

^[4]This has not changed so far.

^[5]The company no longer exists and the URL http://www.viacrypt.com leads to the home page of Network Associates, Inc. (NAI).

^[6]At that time, RSA Security, Inc., was named RSA Data Security, Inc.

^[7]http://www.pgp.com

^[8]http://www.hush.com

^[9]http://web.mit.edu/network/pgp.html

^[10]The letter "i" stands for "international version." Further information about the PGPi scanning project is available at http://www.pgpi.org/pgpi/project/scanning/.

^[11]http://www.cnlab.ch

^[12]The announcement was made during the RSA Data Security Conference that was held on January 16–20, 2000, in San José, California.

^[13]As of this writing, the OpenPGP specification is a Proposed Standard.

^[14]The mechanism uses five personal questions and answers that are provided by the uses during the PGP initialization and configuration process.

^[15]draft-ietf-openpgp-mime–*.txt and draft-ietf-openpgp-multsig–*.txt

^[16]http://www.cert.org/advisories/CA-2000-18.html

^[17]The PKCS specifications are developed by another industry working group also led by RSA Security, Inc. Consequently, RSA Security, Inc., had a vital interest promoting the PKCS specifications and applying them in the field of secure messaging.

^[18]The pair was complemented by three informational RFC documents that specify PKCS #1 (RFC 2313), PKCS #7 (RFC 2314), and PKCS #10 (RFC 2315).

^[19]As of this writing, S/MIME version 3 is a Proposed Standard.

^[20]Most public key algorithms are protected by U.S. patents (and not international patents as, for example, some of the earlier secret key algorithms).

^[21]Outside the United States, the development and marketing of public key cryptography are not restricted.

Team-Fly