Page 167

5 Escrowed Encryption and Related Issues

This chapter describes a tool—escrowed encryption—that responds to the needs described in Chapter 3 for exceptional access to encrypted information. Escrowed encryption is the basis for a number of Administration proposals that seek to reconcile needs for information security against the needs of law enforcement and to a lesser extent national security. As in the case of export controls, escrowed encryption generates considerable controversy.

5.1 WHAT IS ESCROWED ENCRYPTION?

The term "escrow," as used conventionally, implies that some item of value (e.g., a trust deed, money, real property, other physical object) is delivered to an independent trusted party that might be a person or an organization (i.e., an escrow agent) for safekeeping, and is accompanied by a set of rules provided by the parties involved in the transaction governing the actions of the escrow agent. Such rules typically specify what is to be done with the item, the schedule to be followed, and the list of other events that have to occur. The underlying notion is that the escrow agent is a secure haven for temporary ownership or possession of the item, is legally bound to comply with the set of rules for its disposition, functions as a disinterested extratransaction party, and bears legal liability for malfeasance or mistakes.

Usually, the rules stipulate that when all conditions set forth in the escrow rules have been fulfilled, the item will eventually be delivered to a



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 167
Page 167 5 Escrowed Encryption and Related Issues This chapter describes a tool—escrowed encryption—that responds to the needs described in Chapter 3 for exceptional access to encrypted information. Escrowed encryption is the basis for a number of Administration proposals that seek to reconcile needs for information security against the needs of law enforcement and to a lesser extent national security. As in the case of export controls, escrowed encryption generates considerable controversy. 5.1 WHAT IS ESCROWED ENCRYPTION? The term "escrow," as used conventionally, implies that some item of value (e.g., a trust deed, money, real property, other physical object) is delivered to an independent trusted party that might be a person or an organization (i.e., an escrow agent) for safekeeping, and is accompanied by a set of rules provided by the parties involved in the transaction governing the actions of the escrow agent. Such rules typically specify what is to be done with the item, the schedule to be followed, and the list of other events that have to occur. The underlying notion is that the escrow agent is a secure haven for temporary ownership or possession of the item, is legally bound to comply with the set of rules for its disposition, functions as a disinterested extratransaction party, and bears legal liability for malfeasance or mistakes. Usually, the rules stipulate that when all conditions set forth in the escrow rules have been fulfilled, the item will eventually be delivered to a

OCR for page 167
Page 168 specified party (e.g., possibly the original depositing party, an estate, a judicial officer for custody, one or more individuals or organizations). In any event, the salient point is that all terms and conditions and functioning of an escrow process are, or can be, visible to the parties involved; moreover, the behavior and performance of formal escrow agents are governed by legally established obligations. As it applies to cryptography, the term "escrow" was introduced by the U.S. government's April 1993 Clipper initiative in the context of encryption keys. Prior to this time, the term "escrow" had not been widely associated with cryptography, although the underlying concepts had been known for some time (as described below). The Clipper initiative promoting escrowed encryption was intended ''to improve the security and privacy of telephone communications while meeting the legitimate needs of law enforcement."' In this original context, the term "escrowed encryption" had a very specific and narrow meaning: escrowed encryption was a mechanism that would assure law enforcement access to the voice communications underlying encrypted intercepts from wiretaps. However, during 3 years of public debate and dialogue, "escrow," "key escrow," and "escrowed encryption" have become terms with a much broader meaning. Indeed, many different schemes for "escrowed encryption" are quite different from "escrowed encryption" as the term was used in the Clipper initiative. As is so often the case in computer-related matters, terminology for escrowed systems is today not clearly established and can be confusing or misleading. While new terminology could be introduced in an effort to clarify meaning, the fact is that the present policy and public and technical dialogues all use "escrow" and "escrowed encryption" in a very generic and broad sense. It is no longer the very precise restricted concept embodied in the Clipper initiative and described in Section 5.2.1. Escrow as a concept now applies not only to the initial purpose of assuring law enforcement access to encrypted materials, but also to possible end-user or organizational requirements for a mechanism to protect against lost, corrupted, or unavailable keys. It can also mean that some process such as authority to decrypt a header containing a session key is escrowed with a trusted party, or it can mean that a corporation is ready to cooperate with law enforcement to access encrypted materials. 1 See "Statement by the Press Secretary, The White House, April 16, 1993," reprinted in David Banisar (ed.), 1994 Cryptography and Privacy Sourcebook, Part II, Electronic Privacy Information Center, Diane Publishing, Upland, Pa., 1994. The name "Clipper" initially selected as the name of this effort proved later to be a trademark whose holder relinquished it to public use.

OCR for page 167
Page 169 This report conforms to current usage, considering escrowed encryption as a broad concept that can be implemented in many ways; Section 5.3 addresses forms of escrowed encryption other than that described in the Clipper initiative. Also, escrowed encryption is only one of several approaches to providing exceptional access to encrypted information; nonescrow approaches to providing exceptional access are discussed in Chapter 7.2 Finally, the relationship between "strong encryption" and "escrowed encryption" should be noted. As stated above, escrowed encryption refers to an approach to encryption that enables exceptional access to plaintext without requiring a third party (e.g., government acting with legal authorization, a corporation acting in accordance with its contractual rights vis-à-vis its employees, an individual who has lost an encryption key) to perform a cryptanalytic attack. At the same time, escrowed encryption can involve cryptographic algorithms that are strong or weak and keys that are long or short. Some participants in the public debate appear to believe that escrowed encryption is necessarily equivalent to weak encryption, because it does not prevent third parties from having access to the relevant plaintext. But this is a mischaracterization of the intent behind escrowed encryption, since all escrowed encryption schemes proposed to date are intended to provide very strong cryptographic confidentiality (strong algorithms, relatively long keys) for users against unauthorized third parties, but no confidentiality at all against third parties who have authorized exceptional access. 5.2 ADMINISTRATION INITIATIVES SUPPORTING ESCROWED ENCRYPTION Since inheriting the problem of providing law enforcement access to encrypted telephony from the outgoing Bush Administration in late 1992, 2 In the more general meaning of escrowed encryption, exceptional access refers to access to plaintext by a party other than the originator and the recipient of encrypted communications. For the case of stored information, exceptional access may refer to access to the plaintext of an encrypted file by someone not designated by the original encryptor of the file to decrypt it or even by persons so designated who have forgotten how to do so. See also Chapter 3. Contrast the meaning of third-party access in the original Clipper context, in which third-party access refers to assured access, under proper court authorization, by law enforcement to the plaintext of an encrypted voice conversation. The Clipper initiative was intended to support a system that provided a technically convenient means to assure fulfillment of such a requirement. Note that this meaning is much narrower than the use of the more general term "exceptional access" described in the previous paragraph.

OCR for page 167
Page 170 Clinton Administration officials have said that as they considered the notso-distant future of information technology and information security along with the stated needs of law enforcement and national security for access to information, they saw three alternatives:3 • To do nothing, resulting in the possible proliferation of products with encryption capabilities that would seriously weaken, if not wholly negate, the authority to wiretap embodied in the Wiretap Act of 1968 (Title III) and damage intelligence collection for national security and foreign policy reasons; • To support an approach based on weak encryption, likely resulting in poor security and cryptographic confidentiality for important personal and business information; and • To support an approach based on strong but escrowed encryption. If widely adopted and properly implemented, escrowed encryption could provide legitimate users with high degrees of assurance that their sensitive information would remain secure but nevertheless enable law enforcement and national security authorities to obtain access to escrow-encrypted  data in specific instances when authorized  under law. Moreover, the Administration hoped that by meeting legitimate demands for better information security, escrowed encryption would dampen the market for unescrowed encryption products that would deny access to law enforcement and national security authorities even when they sought access for legitimate and lawfully authorized purposes. The Administration chose the last, and since April 1993, the U.S. government has advanced a number of initiatives to support the insertion of key escrow features into products with encryption capabilities that will become available in the future. These include the Clipper initiative and the Escrowed Encryption Standard, the Capstone/Fortezza initiative, and the proposal to liberalize export controls on products using escrowed encryption. These initiatives raise a number of important issues that are the focus of Sections 5.3 to 5.13. 5.2.1 The Clipper Initiative and the Escrowed Encryption Standard As noted above, the Clipper initiative was conceived as a way for providing legal access by law enforcement authorities to encrypted tele- 3 See, for example, statement of Raymond Kammer, Deputy Director, National Institute of Standards and Technology, before the Committee on the Judiciary, U.S. Senate, May 3, 1994. Available on-line at http:// www.nist.gov/item/testimony/may94/encrp.html.

OCR for page 167
Page 171 BOX 5.1 Key Technical Attributes of the Clipper Initiative 1. A chip-unique secret key—the "unit key" or "device key" or ''master key"— would be embedded in the chip at the time of fabrication and could be obtained by law enforcement officials legally authorized to do so under Title III. 2. Each chip-unique device key would be split into two components. 3. The component parts would be deposited with and held under high security by two trusted third-party escrow agents proposed to be agencies of the U.S. government. Note: "Third-party" is used here to indicate parties other than those participating in the communication. 4. A law enforcement access field (LEAF) would be a required part of every transmission. The LEAF would contain (a) the current session key, encrypted with a combination of the device-unique master key and a different but secret "family key" also permanently embedded in the chip, and (b) the chip serial number, also protected by encryption with the family key. 5. Law enforcement could use the information in the LEAF to identify the particular device of interest, solicit its master-key components from the two escrow agents, combine them, recover the session key, and eventually decrypt the encrypted traffic. 6. The encryption algorithm on the chip would be secret. 7. The chip would be protected against reverse engineering and other attempts to access its technical details. SOURCE: Dorothy Denning and Miles Smid, "Key Escrowing Today," IEEE Communications, Volume 32(9), September 1994, pp. 58-68. Available online at http://www.cosc.georgetown.edu/~denning/ crypto/Key-Escrowing-Today.txt. phony.4 The Escrowed Encryption Standard (EES; a Federal Information Processing Standard, FIPS-185) was promulgated in February 1994 as the key technological component of the Clipper initiative (Box 5.1). Specifically, the EES called for the integration of special microelectronic integrated circuit chips (called "Clipper chips") into devices used for voice communications; these chips, as one part of an overall system, provide voice confidentiality for the user and exceptional access to law enforcement authorities. To provide these functions, the Clipper chip was designed with a number of essential characteristics: • Confidentiality would be provided by a classified algorithm known as Skipjack. Using an 80-bit key, the Skipjack algorithm would offer 4 Dorothy Denning and Miles Smid, "Key Escrowing Today," IEEE Communications, Volume 32(9), September 1994, pp. 58-68.   Available on-line at http://www.cosc. georgetown.edu/~denning/crypto/Key-Escrowing-Today.txt.

OCR for page 167
Page 172 considerably more protection against brute-force attacks than the 56-bit DES algorithm  (FIPS 46-1). The Skipjack algorithm  was reviewed by several independent experts, all with the necessary security clearances. In the course of an investigation limited by time and resources, they reported that they did not find shortcuts that would significantly reduce the time to perform a cryptanalytic attack below what would be required by brute force.5 • The chip would be protected against reverse engineering and other attempts to access its technical details. • The chip would be factory-programmed with a chip-unique secret key, the "unit key" or "device key,"6 at the time of fabrication. Possession of this key would enable one to decrypt all communications sent to and from the telephone unit in which the chip was integrated. • A law enforcement access field (LEAF) would be a required part of every transmission and would be generated by the chip. The LEAF would contain two items: (a) the current session key,7 encrypted with a combination of the device-unique unit key, and (b) the chip serial number. The entire LEAF would itself be encrypted by a different but secret "family key" also permanently embedded in the chip. The family key would be the same in all Clipper chips produced by a given manufacturer; in practice, all Clipper chips regardless of manufacturer are programmed today by the Mykotronx Corporation with the same family key. To manage the use of the LEAF, the U.S. government would undertake a number of actions: 5 See Ernest Brickell et al., SKIPJACK Review: Interim Report, July 28, 1993. Posted to the "sci.crypt" newsgroup on August 1, 1993, by Dorothy Denning and available on-line at http://www.cosc.georgetown.edu/~denning/SKIPJACK.txt.   Reprinted in Lance J. Hoffman (ed.), Building in Big Brother: The Cryptographic Policy Debate, Springer-Verlag, New York, 1995, pp. 119-130. 6 The device key or unit key is used to open the encryption that protects a session key. Hence, possession of the unit key allows the decryption of all messages or files encrypted with that unit or device. "Session key" is defined in footnote 7. 7 "Session," as in computer science, denotes a period of time during which one or more computer-based processes are operational and performing some function; typically two or more of systems, end users, or software processes are involved in a session. It is analogous to a meeting among these things. For cryptography, a session is the plaintext data stream on which the cryptographic process operates. The session key is the actual key that is needed to decrypt the resulting ciphertext. In the context of an encrypted data transmission or telephone call, the session key is the key needed to decrypt the communications stream. For encrypted data storage, it is the key needed to decrypt the file. Note that in the case of symmetric encryption (discussed in Chapter 2), the decryption key is identical to the encryption key. Since asymmetric encryption for confidentiality is efficient only for short messages or files, symmetric encryption is used for session encryption of telephony, data transmissions, and data storage.

OCR for page 167
Page 173 • The unit key, known at the time of manufacture and unchangeable for the life of the chip, would be divided into two components, each of which would be deposited with and held under high security by two trusted government escrow agents located within the Departments of Commerce and Treasury. • These escrow agents would serve as repositories for all such materials, releasing the relevant information to law enforcement authorities upon presentation of the unit identification and lawfully obtained court orders. When law enforcement officials encountered a Clipper-encrypted conversation on a wiretap, they would use the LEAF to obtain the serial number of the Clipper chip performing the encryption and the encrypted session key.8 Upon presentation of the serial number and court authorization for the wiretap to the escrow agents, law enforcement officials could then obtain the proper unit-key components, combine them, recover the session key, and eventually decrypt the encrypted voice communications.9 Only one key would be required in order to obtain access to both sides of the Clipper-encrypted conversation. The authority for law enforcement to approach escrow agents and request unit-key components was considered to be that granted by Title III and the Foreign Intelligence Surveillance Act (FISA).10 As a FIPS, the EES is intended for use by the federal government and has no legal standing outside the federal government. Indeed, its use is 8 Because the family key would be known to law enforcement officials, obtaining the unencrypted LEAF would present no problems. 9 Questions have arisen about NSA access to escrowed keys. NSA has stated for the record to the committee that "key escrow does not affect either the authorities or restrictions applicable to NSA's signals intelligence activities. NSA's access to escrowed keys will be tied to collection against legitimate foreign intelligence targets. The key holder must have some assurance that NSA is involved in an authorized intelligence collection activity and that the collection activity will be conducted in accordance with the appropriate restrictions." For a description of these restrictions, see Appendix D of this report. 10 Dorothy Denning and Miles Smid, "Key Escrowing Today," IEEE Communications, Volume 32(9), 1994, pp. 58-68. Available on-line at http://www.cosc.georgetown.edu/ -denning/crypto/Key-Escrowing-Today.txt. Given its initial intent to preserve law enforcement's ability to conduct wire taps, it follows that Clipper key escrow would be conducted without the knowledge of parties whose keys had been escrowed, and would be conducted according to a set of rules that would be publicly known but not changeable by the affected parties. Under the requirements of Title III, the affected parties would be notified of the tapping activity at its conclusion, unless the information were to become the basis for a criminal indictment or an ongoing investigation. In the latter case, the accused would learn of the wiretaps, and hence the law enforcement use of escrowed keys, through court procedures.

OCR for page 167
Page 174 optional even by federal agencies. In other words, federal agencies with a requirement for secure voice communications have a choice about whether or not to adopt the EES for their own purposes. More importantly, the use of EES-compliant devices by private parties cannot in general be compelled by executive action alone; private consumers are free to decide whether or not to use EES-compliant devices to safeguard communications and are free to use other approaches to communications security should they so desire.11 However, if consumers choose to use EES-compliant devices, they must accept key escrow as outlined in procedures promulgated by the government. This characteristic—that interoperability requires acceptance of key escrow—is a design choice; a different specification could permit the interoperability of devices with or without features for key escrow. The EES was developed by communications security experts from the NSA, but the escrow features of the EES are intended to meet the needs of law enforcement—i.e., its needs for clandestine surveillance of electronic and wire communications as described in Chapter 3. NSA played this development role because of its technical expertise. EES-compliant devices are also approved for communicating classified information up to and including SECRET. In speaking with the committee, Administration officials described the Clipper initiative as more or less irrelevant to the needs of signals intelligence (SIGINT) (Box 5.2). As of early 1996, AT&T had sold 10,000 to 15,000 units of the Surity Telephone Device 3600. These include four configurations: Model C, containing only the Clipper chip, which has been purchased primarily by U.S. government customers; Model F, containing only an AT&T-proprietary algorithm that is exportable; Model P, containing an AT&T-proprietary nonexportable algorithm in addition to the exportable algorithm; and Model S, with all three of the above. Only units with the Clipper chip have a key-escrow feature. All the telephones are interoperable—they negotiate with each other to settle on a mutually available algorithm at the beginning of a call.12 In addition, AT&T and Cycomm International have agreed to jointly develop and market Clipper-compatible digital voice encryption attachments for Motorola's Micro-Tac series of handheld 11 For example, an opinion issued by the Congressional Research Service argues that legislation would be required to mandate the use of the Clipper chip beyond federal computer systems. Memorandum from the American Law Division, Congressional Research Service, "Current Legal Authority to Mandate Adoption of 'Clipper Chip' Standards by Private Parties," Library of Congress, Washington, D.C., October 4, 1994. 12 AT&T Secure Communications product literature, available on-line at http://www. att.com/press/0694/940613.pdb.html, and personal communication with Bruce Bailey, AT&T Secure Communications Systems, Greensboro, N.C., March 29, 1996.

OCR for page 167
Page 175 BOX 5.2 The Relationship of Escrowed Encryption to Signals Intelligence Escrowed encryption—especially the Escrowed Encryption Standard (EES) and the Clipper initiative—is a tool of law enforcement more than of signals intelligence (SIGINT). The EES was intended primarily for domestic use, although exports of EES-compliant devices have not been particularly discouraged. Given that the exceptional access feature of escrowed encryption has been openly announced, purchase by foreign governments for secure communications is highly unlikely. On the other hand, the U.S. government has classified the Skipjack algorithm to keep foreign adversaries from learning more about good cryptography. In addition, wide deployment and use of escrowed encryption would complicate the task of signals intelligence, simply because individual keys would have to be obtained one by one for communications that might or might not be useful. (Still, EES devices would be better for SIGINT than unescrowed secure telephones, in the sense that widely deployed secure telephones without features for exceptional access would be much harder to penetrate.) Finally, the impact of escrowed encryption on intelligence collection abroad depends on the specific terms of escrow agent certification. Even assuming that all relevant escrow agents are located within the United States (a question addressed at greater length in Appendix G), the specific regulations governing their behavior are relevant. Intelligence collections of digital data can proceed with few difficulties if regulations permit escrow agents to make keys available to national security authorities on an automated basis and without the need to request keys one by one. On the other hand, if the regulations forbid wholesale access to keys (and the products in question do not include a "universal key" that allows one key to decrypt messages produced by many devices), escrowed encryption would provide access primarily to specific encrypted communications that are known to be intrinsically interesting (e.g., known to be from a particular party of interest). However, escrowed encryption without wholesale access to keys would not provide significant assistance to intelligence collections undertaken on a large scale. cellular telephones; these products are expected to be available in the second quarter of 1996.13 Finally, AT&T makes no particular secret of the fact that its Surity line of secure voice communication products employs Clipper chip technology, but that fact is not featured in the product literature; potential consumers would have to know enough to ask a knowledgeable sales representative. 13 AT&T news release, "AT&T, Cycomm International Develop Digital Voice Encryption," November 1, 1995.  Available on-line at http://www.att.com/press/1195/951101. mma.html.

OCR for page 167
Page 176 5.2.2 The Capstone/Fortezza Initiative14 The Capstone/Fortezza effort supports escrowed encryption for data storage and communications, although a FIPS for this application has not been issued. Specifically, the Capstone chip is an integrated-circuit chip that provides a number of encryption services for both stored computer data and data communications. For confidentiality, the Capstone chip uses the Skipjack algorithm, the same algorithm that is used in the Clipper chip (which is intended only for voice communications, including low-speed data and fax transmission across the public switched telephone network, and the same mechanism to provide for key escrowing. The agents used to hold Capstone keys are also identical to those for holding Clipper keys—namely, the Departments of Treasury and Commerce. In addition, the Capstone chip (in contrast to the Clipper chip) provides services that conform to the Digital Signature Standard (FIPS-186) to provide digital signatures that authenticate user identity and the Secure Hash Standard (FIPS-180); the chip also implements a classified algorithm for key exchange (usually referred to as the Key Exchange Algorithm (KEA)) and a random number generator. The Capstone chip is the heart of the Fortezza card.15 The Fortezza card is a PC-card (formerly known as a PCMCIA card) intended to be plugged into any computer with a PC-card expansion slot and appropriate support software; with the card in place, the host computer is able to provide reliable user authentication and encryption for confidentiality and certify data transmission integrity in any communication with any other computer so equipped. The Fortezza card is an example of a hardware token that can be used to ensure proper authentication.16 Note also 14 Technically speaking, Clipper and Capstone/Fortezza are not separate initiatives. The Capstone program had been under way for a number of years prior to the public announcement of the Clipper chip in 1993, and the Clipper chip is based entirely on technology developed under the Capstone program. The Clipper chip was developed when the incoming Clinton Administration felt it had to address the problem of voice encryption. However, while Clipper and Capstone/Fortezza are not technically separate programs, the public debate has engaged Clipper to a much greater degree than it has Capstone. For this reason, this report discusses Clipper and Capstone/Fortezza separately. 15 The Fortezza card was previously named the Tessera card; the name was changed when previous trademark claims on "Tessera" were discovered. 16 To ensure that the holder of the Fortezza card is in fact the authorized holder, a personal identification number (PIN) is associated with the card: only when the proper PIN is entered will the Fortezza card activate its various functions. While concerns have been raised in the security literature that passwords and PINs are not secure when transmitted over open communications lines, the PIN used by the Fortezza card is never used outside the confines of the user's system. That is, the PIN is never transmitted over any network link; the sole function of the PIN is to turn on the Fortezza card, after which an automated protocol ensures secure authentication.

OCR for page 167
Page 177 that there are other hardware PC cards that provide cryptographic functionality similar to that of Fortezza but without the escrow features.17 To date, the NSA has issued two major solicitations for Fortezza cards, the second of which was for 750,000 cards.18 These cards will be used by those on the Defense Messaging System, a communications network that is expected to accommodate up to 2 million Defense Department users in 2005. In addition, Fortezza cards are intended to be available for private sector use. The extent to which Fortezza cards will be acceptable in the commercial market remains to be seen, although a number of product vendors have decided to incorporate support for Fortezza cards in some products.19 5.2.3 The Relaxation of Export Controls on Software Products Using "Properly Escrowed" 64-bit Encryption As noted in Chapter 4, the Administration has proposed to treat software products using a 64-bit encryption key as it currently treats products with encryption capabilities that are based on a 40-bit RC2 or RC4 algorithm, providing that products using this stronger encryption are "properly escrowed." This change is intended to facilitate the global sale of U.S. software products with significantly stronger cryptographic protection than is available from U.S. products sold abroad today. To work out the details of what is meant by "properly escrowed," the National Institute of Standards and Technology held workshops in September and December 1995 at which the Administration released a number of draft criteria for export control (Box 5.3). These criteria are intended to ensure that a product's key escrow mechanism cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. In early 1996, the Administration expressed its intent to move forward rapidly with its proposal and to finalize export criteria and make formal conforming modifications to the export regulations "soon." 17 For example, such devices are made by Cylink and Telequip. See Government Computer News, "Security Device Is 007 in Your Pocket," August 7, 1995, p. 6. 18 Paul Constance, "DoD Plans to Install 750,000 Fortezza Cards," Government Computer News, July 31, 1995, p. 1 for the solicitation. 19 For example, the Netscape Communications Corporation has announced that it will support Fortezza in the next version of its Web browser, while the Oracle Corporation will support Fortezza in the next version of its Secure Network Services product. See Elizabeth Sikorovsky, "Netscape and Oracle Products Support Fortezza Card," Federal Computer Week, October 23, 1995, p. 36.

OCR for page 167
Page 205 making such modifications,49 but there is virtual unanimity in the computer community that modification cannot be prevented forever. How robust must these anti-reverse-engineering features be? The answer is that they must be robust enough that the effort needed to overcome them is greater than the effort needed to develop an encryption system from scratch. • For hardware, reverse engineering takes the form of physical disassembly and/or probing with x-rays of the relevant integrated circuit chips. Such chips can be designed to resist reverse engineering in a way that makes it difficult to understand what various components on the chip do. For example, the coating on a die used to fabricate a chip may be designed so that removal of the coating results in removal of one or more layers of the chip, thus destroying portions of what was to be reverse-engineered. The chip may also be fabricated with decoy or superfluous elements that would distract a reverse engineer. For all of these reasons, reverse engineering for understanding a chip's functions is difficult. However, it is not impossible, and under some circumstances, it is possible to modify a chip. In general, reverse engineering of the circuits and devices inside a chip requires significant expertise and access to expensive tools.50 An important factor that works against implementation secrecy is the wide distribution of devices or products whose implementation is secret. It is difficult to protect a device against reverse engineering when millions of those devices are distributed around the world without any physical barriers (except those on the implementation itself) to control access to them. Everyone with an EES-compliant telephone or a Foretzza card, for 49 For example, Trusted Information Systems Inc. of Glenwood, Md., has advocated an approach to preventing modification that relies on the placement of integrity checks at strategic locations. With such an approach, a change to the disassembled source code would have to be reflected properly in all relevant integrity checks; doing so might well involve disassembly of an entire product rather than of just one module of the product. Nevertheless, such an approach cannot prevent modification, although it can make modification more difficult. Such anti-reverse-engineering features may also increase the difficulty of vendor maintenance of a product. Increased difficulty may be a price vendors must pay in order to have more secure software implementations. 50 Estimates of the cost to reverse-engineer the Clipper chip nondestructively cover a wide range, from "doable in university laboratories with bright graduate students and traditions of reverse engineering" (as estimated by a number of electrical engineers in academia with extensive experience in reverse engineering) to as much as $30 million to $50 million (as estimated in informal conversations between JASON members and DOD engineers). The cost may well be lower if large numbers of chips are available for destructive inspection.

OCR for page 167
Page 206 example, will have access to the chip that provides encryption and key escrow services. The comments above refer to the feasibility of maintaining implementation secrecy. But there are issues related to its desirability as well. For example, implementation secrecy implies that only a limited number of vendors can be trusted to produce a given implementation. Thus, foreign production of Clipper/Capstone-compliant devices under classification guidelines raises problems unless foreign producers are willing to abide by U.S. security requirements. A more important point is that implementation secrecy also demands trust between user and supplier/vendor. Users within government agencies generally trust other parts of the government to provide adequate services as a supplier. But in the private sector, such trust is not necessarily warranted. Users that are unable to determine for themselves what algorithms are embedded in computer and communications products used must trust the vendor to have provided algorithms that do what the user wants done, and the vast majority of users fall into this category. Such opacity functions as a de facto mechanism of secrecy that also impedes user knowledge about the inner workings and that is exploited by the distributors of computer viruses and worms. As a result, choosing between self-implemented source code and a prepackaged program for use in performing certain functions is in many ways analogous to choosing between unclassified and classified algorithms. An information security manager with very high security needs must make trade-offs in assurance vs. cost. In general, the only way to be certain that the algorithms used are the ones claimed to be used is to implement them on one's own. Yet if a manager lacks the necessary knowledge and experience, a self-implementation may not be as secure or as capable as one developed by a trusted vendor. A self-implementer also carries the considerable burden of development costs that a commercial vendor can amortize over many sales. As a result, security-conscious users of products whose inner workings are kept secret must (1) trust the vendor implicitly (based on factors such as reputation), or (2) face the possibility of various extreme scenarios. Here are two: • The hardware of a secret device can be dynamically modified; for example, electrically erasable read-only memories can direct the operation of a processor. One possible scenario with secret hardware is that a chip that initially provides Clipper-chip functionality might be reprogrammed when it first contacts a Clipper/Capstone-compliant device to allow nonescrowed but unauthorized access to it; such a means of "infection" is common with computer viruses. In other words, the Skipjack

OCR for page 167
Page 207 algorithm may have been embedded in the chip when it was first shipped, but after the initial contact, the algorithm controlling the chip is no longer Skipjack. • An algorithm that is not Skipjack is embedded by the manufacturer in chips purporting to be Clipper or Capstone chips. Since the utility of a vector test depends on the availability of an independent implementation of the algorithm, it is impossible for the user to perform this test independently if the user has no reference point. As a result, the user has no access to an independent test of the chip that is in the user's "Clipper/ Capstone-compliant" device, and so any algorithm might have been embedded.51 Any technically trained person can invent many other such scenarios. Thus, public trust in the technical desirability of the EES and Fortezza for exceptional access depends on a high degree of trust in the government, entirely apart from any fears about compromising escrow agents wherever they are situated. Of course, some of the same considerations go beyond the Skipjack algorithm and the Clipper/Capstone approach. In general, users need confidence that a given product with encryption capabilities indeed implements a given algorithm. Labeling a box with the letters "DES" does not ensure that the product inside really implements DES. In this case, the fact that the DES algorithm is publicly known facilitates testing to verify that the algorithm is implemented correctly.52 If its source code is available for inspection, other security-relevant aspects of a software product can be examined to a certain extent, at least up to the limits of the expertise of the person checking the source code. But for software products without source code, and especially for hardware products that cannot easily be disassembled, and even more so for hardware products that are specifically designed to resist disassembly, confidence in the nonalgorithm security aspects of the product is more a matter of trusting the vendor than of the user making an independent technical verification of 51 According to Dorothy Denning, the review team for Skipjack (see footnote 5 of this chapter) compared the output from Clipper chips with output from the software version of Skipjack that the review team obtained for review to verify that the algorithm on the chips was the same as the software version (personal communication, Dorothy Denning, Georgetown University, March 1996). 52 As described in Chapter 4, the product tester can use the product to encrypt a randomly chosen set of values with a randomly chosen key, and compare the encrypted output to the known correct result obtained through the use of a product known to implement the algorithm correctly. This is known as a vector test.

OCR for page 167
Page 208 an implementation.53 In some sectors (e.g., banking, classified military applications), however, independent technical verification is regarded as essential. Finally, a given product may properly implement an algorithm but still be vulnerable to attacks that target the part of the product surrounding the implementation of the algorithm. Such vulnerabilities are most common in the initial releases of products that have not been exposed to public test and scrutiny. For example, a security problem with the Netscape Navigator's key-generation facility could have been found had the implementation in which the key generator was embedded been available for public examination prior to its release, even though the encryption algorithm itself was properly implemented.54 5.11 THE HARDWARE-SOFTWARE CHOICE IN PRODUCT IMPLEMENTATION After the Clipper initiative was announced, and as the debate over escrowed encryption broadened to include the protection of data communications and stored data, the mass market software industry emphasized that a hardware solution to cryptographic security—as exemplified by the Clipper chip—would not be satisfactory. The industry argued with some force that only a software-based approach would encourage the widespread use of encryption envisioned for the world's electronic future, making several points: • Customers have a strong preference for using integrated cryptographic products. While stand-alone products with encryption capabilities could be made to work, in general they lack operational convenience for the applications that software and systems vendors address. • Compared to software, hardware is expensive to manufacture. In particular, the relevant cost is not simply the cost of the hardware encryption device compared to a software encryption package,55 but also the cost of any modifications to the hardware environment needed to accept 53 Such a comment is not meant to preclude the possibility of an independent certifying authority, a kind of "Consumers' Union" for cryptography equipment and products. Such organizations have been proposed to evaluate and certify computer security, and as of this writing, three U.S. firm have received NIST approval to evaluate the conformance of products to FIPS 140-1, the FIPS for cryptography modules. 54 This security problem is referenced in footnote 34, Chapter 2. The lack of prior vetting for Netscape Navigator is described by Kathleen Murphy, "A Second Security Breach," Web Week, Volume 1(6), October 1995, p. 8. 55 In a recent contract, a vendor agreed to provide Fortezza cards at $69 per card. See Paul Constance, "After Complaining $99 Was Too Low, Fortezza Vendors Come in at $69," Government Computer News, October 2, 1995, p. 6.

OCR for page 167
Page 209 the hardware encryption device.56 For example, one major company noted to the committee that adoption of the Fortezza card, a card that fits into the PC-card slots available on most laptop computers, would be very expensive in its desktop computing environment, because most of its desktop computers do not have a PC-card slot and would have to be modified to accept the Fortezza card. By contrast, a software encryption product can simply be loaded via common media (e.g., a CD-ROM or a floppy disk) or downloaded via a network. • The fact that hardware is difficult to change means that problems found subsequent to deployment are more difficult to fix. For example, most users would prefer to install a software fix by loading a CD-ROM into their computers than to open up their machines to install a new chip with a hardware fix. • Hardware-based security products have a history of being marketunfriendly. Hardware will, in general, be used only to the extent that the required hardware (and its specific configuration) is found in user installations. Moreover, hardware requirements can be specified for software only when that hardware is widely deployed. For example, a technical approach to the software piracy problem has been known for many years; the approach requires the installation of special-purpose hardware that is available only to those who obtain the software legitimately. This "solution" has failed utterly in the marketplace, and software piracy remains a multibillion-dollar-per-year problem. • Hardware for security consumes physical space and power in products. For example, a hardware-based encryption card that fits into an expansion slot on a computer takes up a slot permanently, unless the user is willing to install and deinstall the card for every use. It also creates an additional power demand on electronic devices where power and battery life are limited. In general, products with encryption capabilities today use software or hardware or both to help ensure security.57 The crux of the hardware- 56 One vendor is manufacturing a circuit board for encryption that fits into a 3.5" floppy disk drive. However, this device does not employ the Capstone/Foretzza approach. See Elizabeth Sikorovsky, "Device Offers Alternative to PC Card-Based Encryption," Federal Computer Week, November 13, 1995, pp. 29 and 35. 57 Note that the dividing line between hardware and software is not always clear. In particular, product designers use the term "firmware" to refer to a design approach that enters software into a special computer memory (an integrated circuit chip) that usually is subsequently unchangeable (read-only memory; ROM). Sometimes an alternate form of memory is used that does permit changes under controlled conditions (electrically programmable ROM; EPROM). Such software-controlled hardware (microprogrammed hardware) has the convenience that the functionality of the item can be updated or changed without redesign of the hardware portion.

OCR for page 167
Page 210 software debate is what is good enough to ensure security. The security needed to manage electronic cash in the international banking system needs to be much stronger than the security to protect word processing files created by private individuals. Thus, software-based cryptography might work for the latter, while hardware-based cryptography might be essential for the former. Products with encryption capabilities must be capable of resisting attack. But since such products are often embedded in operating environments that are themselves insecure, an attacker may well choose to attack the environment rather than the product itself. For example, a product with encryption capabilities may be hardware-based, but the operating environment may leave the encryption keys or the unencrypted text exposed.58 More generally, in an insecure environment, system security may well not depend very much on whether the cryptography per se is implemented in hardware or software or whether it is weak or strong. In the context of escrowed encryption, a second security concern arises—a user of an escrowed encryption product may wish to defeat the escrow mechanism built into the product. Thus, the escrow features of the product must be bound to the product in a way that cannot be bypassed by some reverse-engineered modification to the product. This particular problem is known as binding or, more explicitly, escrow binding; escrow binding is an essential element of any escrow scheme that is intended to provide exceptional access. Concern over how to solve the escrow binding problem was the primary motivation for the choice of a hardware approach to the Clipper initiative. As suggested in Section 5.10, the functionality of a hardware system designed to resist change is indeed difficult to change, and so hardware implementations have undeniable advantages for solving the escrow binding problem.59 An EES-compliant device would be a telephone without software accessible to the user, and would provide high assurance that the features for exceptional access would not be bypassed. As the debate has progressed, ideas for software-based escrow processes have been proposed. The primary concern of the U.S. government about software implementations is that once a change has been designed and developed that can bypass the escrow features ("break the escrow binding"), such a change can be easily propagated through many different channels and installed with relatively little difficulty. In the committee's view, the important question is whether software solutions to the escrow 58 Peter G. Neumann, Can Systems Be Trustworthy with Software-Implemented Cryptography?, SRI International, Menlo Park, Calif., October 28, 1994. 59A device controlled by software stored in read-only memory is for all intents and purposes the same as "pure hardware" in this context.

OCR for page 167
Page 211 binding problem can provide an acceptable level of protection against reverse engineering. Whether an escrowed encryption product is implemented in software (or hardware for that matter), the critical threshold is the difficulty of breaking the escrow binding (i.e., bypassing the escrowing features) compared to the effort necessary to set up an independent unescrowed encryption system (perhaps as part of an integrated product). If it is more difficult to bypass the escrow features than to build an unescrowed system, then "rogues" who want to defeat exceptional access will simply build an unescrowed system. The bottom  line is that an escrowed encryption product does not have to be perfectly resistant to breaking the escrow binding. A possible mitigating factor is that even if a software "patch" is developed that would break the escrow binding of an escrowed encryption software product, it may not achieve wide distribution even among the criminals who would have the most to gain from such a change. Experience with widely deployed software products (e.g., operating systems) indicates that even when a software fix is made available for a problem in a product, it may not be implemented unless the anomalous or incorrect software behavior is particularly significant to an end user. If this is the case for products that are as critical as operating systems, it may well be true for products with more specialized applications. On the other side of the coin, many parties (e.g., criminals) may care a great deal about the presence of escrowing and thus be highly motivated to find "fixes" that eliminate escrowing. 5.12 RESPONSIBILITY FOR GENERATION OF UNIT KEYS Key generation is the process by which cryptographic keys are generated. Two types of keys are relevant: • A session key is required for each encryption of plaintext into ciphertext; this is true whether the information is to be stored or communicated. Ultimately, the intended recipients of this information (those who retrieve it from storage or those who receive it at the other end of a communications channel) must have the same session key. For maximum information security, a new session key is used with every encryption. (See footnote 7 of this chapter for more discussion.) • A unit key is a cryptographic key associated with a particular product or device owned or controlled by a specific individual. Unit keys are often used to protect session keys from casual observation in escrowed encryption products, but precisely how they are used depends on the specifics of a given product.

OCR for page 167
Page 212 In the most general case, the session key is a random number, and a different one is generated anew for each encryption. But the unit key is a cryptographic variable that typically changes on a much longer time scale than does the session key. In many escrowed encryption schemes, knowledge of the unit key enables a third party to obtain the session key associated with any given encryption. The Clipper/Capstone approach requires that the unit key be generated by the manufacturer at the time of manufacture (''at birth") and then registered prior to sale with escrow agents in accordance with established procedures. Such an approach has one major advantage from the standpoint of those who may require exceptional access in the future—it guarantees registration of keys, because users need not take any action to ensure registration. At the same time, since the Clipper/Capstone approach is based on a hardware-based implementation that is not user-modifiable, a given device has only one unit key for its entire lifetime, although, at some cost, the user may change the Clipper chip embedded in the device.60 If the unit key is compromised, the user's only recourse is to change the chip. A user who does not do so violates one basic principle of information security—frequent changing of keys (or passwords).61 In addition, the fact that all unit keys are known at the time of manufacture raises concerns that all keys could be kept (perhaps surreptitiously) in some master databank that would be accessible without going to the designated escrow agents. The implication is that the user is forced to trust several organizations and individuals involved with the manufacturing process. Such trust becomes an implicit aspect of the secrecy associated with EES-compliant devices. One alternative to unit key generation at birth is the generation (or input) of a new unit key at user request. This approach has the advantage that the user can be confident that no one else retains a copy of the new key without his or her knowledge. The disadvantage is that escrow of that key would require explicit action on the user's part for that purpose. An alternative that has some of the advantages of each approach is to install and register a unit key at birth, but to design the product to allow the user to change the unit key later. Thus, all products designed in this manner would have "default" unit keys installed by the manufacturer 60A Clipper chip costs about $10 when bought in large lots (personal communication, Jimmy Dolphin, Mykotronx, March 22, 1996). Even when including retail mark-up costs and labor, the cost of changing a Clipper chip is likely to be less than $100. 61 However, since the Skipjack algorithm is classified, simple knowledge of the unit key (or the session key) would enable only those with knowledge of the algorithm to decrypt the session key (or the session).

OCR for page 167
Page 213 and recorded with some escrow agent; each of these keys would be different. Users who took the trouble to install a new unit key would have to take an explicit action to escrow it, but in many cases the inconvenience and bother of changing the unit key would result in no action being taken. Thus, valid unit keys would be held by escrow agents in two cases—for products owned by users who did not change the unit key, and for products owned by users who chose to register their new keys with escrow agents. Who is responsible for the collection of unit keys? Under the Clipper/Capstone approach, the responsible party is the U.S. government. But if nongovernment agencies were to be responsible for escrowing keys (see Section 5.8), a large market with many vendors producing many different types of encryption products in large volume could result in a large administrative burden on these vendors. The specific implementation of EES also raises an additional point. As proposed, EES requires that unit keys be given to government authorities upon presentation of legal authorization. If these keys are still available to the authorities after the period of legal authorization has expired, the EES device is forever open to government surveillance. To guard against this possibility, Administration plans for the final Clipper key escrow system provide for automatic key deletion from the decrypting equipment upon expiration of the authorized period. Key deletion is to be implemented on the tamper-resistant device that law enforcement authorities will use to decrypt Clipper-encrypted traffic. However, by early 1996, the deployed interim key escrow system had not been upgraded to include that feature. 5.13 ISSUES RELATED TO THE ADMINISTRATION PROPOSAL TO RELAX EXPORT CONTROLS ON 64-BIT ESCROWED ENCRYPTION IN SOFTWARE As noted in Chapter 4, the Administration has proposed to treat software products with 64-bit encryption using any algorithm as it currently treats products that are based on 40-bit RC2/RC4 algorithms, providing that products using this stronger encryption are "properly escrowed." This change is intended to make available to foreign customers of U.S. software products stronger cryptographic protection than they currently have today. This proposal has raised several issues. 5.13.1 The Definition of "Proper Escrowing" The definition of "proper escrowing" (as the phrase is used in the Administration's proposed new export rules in Box 5.3) is that keys should

OCR for page 167
Page 214 be escrowed only with "escrow agent(s) certified by the U.S. Government, or certified by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements." These agents would not necessarily be government agencies, although in principle they could be. The obvious question is whether foreign consumers will be willing to purchase U.S. products with encryption capabilities when it is openly announced that the information security of those products could be compromised by or with the assistance of escrow agents certified by the U.S. government. While the draft definition does envision the possibility that escrow agents could be certified by foreign governments (e.g., those in the country of sale), formal agreements often take a long time to negotiate, during which time U.S. escrow agents would hold the keys, or the market for such products would fail to develop. For some applications (e.g., U.S. companies doing business with foreign suppliers), interim U.S. control of escrow agents may prove acceptable. But it is easy to imagine other applications for which it would not, and in any case a larger question is begged: What would be the incentive for foreign users to purchase such products from U.S. vendors if comparably strong but unescrowed foreign products with encryption capabilities were available? As the discussion in Chapter 2 points out, integrated products with encryption capabilities are generally available today from U.S. vendors. However, how long the U.S. monopoly in this market will last is an open question. The issue of who holds the keys in an international context is explored further in Appendix G. 5.13.2 The Proposed Limitation of Key Lengths to 64 Bits or Less The most important question raised by the 64-bit limitation is this: If the keys are escrowed and available to law enforcement and national security authorities, why does it matter how long the keys are? In response to this question, senior Administration officials have said that the limitation to 64 bits is a way of hedging against the possibility of finding easily proliferated ways to break the escrow binding built into software, with the result that U.S. software products without effective key escrow would become available worldwide. Paraphrasing the remarks of a senior Administration official at the International Cryptography Institute 1995 conference, "The 64-bit limit is there because we might have a chance of dealing with a breakdown of software key escrow 10 to 15 years down the line; but if the key length implied a work factor of something like triple-DES, we would never [emphasis in original] be able to do it." Two factors must be considered in this argument. One is the likeli-

OCR for page 167
Page 215 hood that software key escrow can in fact be compromised. This subject is considered in Sections 5.10.2 and 5.11. But a second point is the fact that the 64-bit limit is easily circumvented by multiple encryption under some circumstances. Specifically, consider a stand-alone security-specific product for file encryption that is based on DES and is escrowed. Such a product—in its unaltered state—meets all of the proposed draft criteria for export. But disassembly of the object code of the program (to defeat the escrow binding) may also reveal the code for DES encryption in the product. Once the source code for the DES encryption is available, it is a technically straightforward exercise to implement a package that will use the product to implement a triple-DES encryption on a file. 5.14 RECAP Escrowed encryption is one of several approaches to providing exceptional access to encrypted information. The U.S. government has advanced a number of initiatives to support the insertion of escrow features into products with encryption capabilities that will become available in the future, including the Escrowed Encryption Standard, the Capstone/ Fortezza initiative, and a proposal to liberalize export controls on products using escrowed encryption. Its support of escrowed encryption embodies the government's belief that the benefit to law enforcement and national security from exceptional access to encrypted information outweighs the damage owing to loss of confidentiality that might occur with the failure of procedures intended to prevent unauthorized access to the escrow mechanism. Escrowed encryption provides more confidentiality than leaving information unprotected (as most information is today), but less confidentiality than what could be provided by good implementations of unescrowed cryptography. On the other hand, escrowed encryption provides more capability for exceptional access under circumstances of key loss or unavailability than does unescrowed encryption. All users will have to address this trade-off between level of confidentiality and key unavailability. The central questions with respect to escrowed encryption are the following: • With what degree of confidence is it possible to ensure that third parties will have access to encrypted information only under lawfully authorized circumstances? • What is the trade-off for the user between potentially lower levels of confidentiality and higher degrees of confidence that encrypted data will be available when necessary?