[This file contains all 4 of the policy handouts from the Sept. 6-7 1995 NIST commercial key escrow meetings. The fourth document is essentially a new Clinton Administration crypto export policy. Commentary provided by Center for Democracy and Technology] ADMINISTRATION CRYPTO POLICY FLOPS AT CONFERENCE On September 6 and 7, the Clinton Administration unveiled a new national cryptography policy at a conference sponsored by the National Institute of Standards and Technology (NIST). CDT believes that the new proposal fails to provide adequate privacy protection, would effectively eliminate the domestic market for non- escrowed encryption applications, and is weighed too heavily toward the interests of the National Security Agency. The administration has proposed to relax export controls on cryptographic applications (both software and hardware) with key lengths up to 64 bits provided that: * The keys required to decrypt a message or file are escrowed with an agent certified by the US government (including private entities) * The product does not decrypt messages or files encrypted with non- escrowed products or products whose escrow mechanisms have been altered or disabled. * As well as eight other criteria (the proposal is attached below). NEW PROPOSAL FAILS TO ADHERE TO CRITERIA IN GORE LETTER TO CANTWELL. In a July 1994 letter to then Representative Maria Cantwell, Vice President Gore announced that the Administration intended to re-examine its cryptography policy. The Gore letter, which was widely viewed as an abandonment of the Clipper Chip Government Key Escrow scheme, pledged to develop a policy framework that would promote the development of encryption systems that would meet the following criteria: * Implementation in hardware of Software * Public, Unclassified Algorithms * Voluntary * Forth Amendment privacy Safeguards * Statutory liability rules to protect users * Multiple Escrow Agents On hearing that the Administration had set out to develop a new encryption policy based on the principles outlined in the Gore letter, the Center for Democracy and Technology was guardedly optimistic that a genuine policy breakthrough was possible. However, having had the opportunity to review the current proposal, every principle, except the first (software implementation) and second (public algorithms), outlined in the July 1994 letter is violated or, in one case, left in doubt, by the September 1995 policy statement. The September 1995 policy statement diverges from the July 1994 letter in the following critical respects. In our view, these divergences represent fundamental defects in the proposed policy. * NOT VOLUNTARY: The current proposal effectively compels all domestic users to use key escrow systems if they ever intend to communicate internationally. Point 6 of the export criteria requires that an exportable system must not interoperate with any system that non- escrow systems. Thus, in order for a user in the United States to communicate with anyone who uses a United States-made system on the Internet but outside of the United States, the American user must employ a key escrow system. Domestic users are not legally compelled to use key escrow products, but the proposed policy forces, in practice, all but the most insular Internet user toward a key escrow system. Moreover, this proposal further illustrates that the Administration seeks to use export controls to push the domestic use of escrowed cryptography. A policy based on such compulsion can hardly be called voluntary. * INADEQUATE SECURITY: Point 1 precludes export of systems with key lengths beyond 64 bits. Though this key size is larger than what is currently exportable, it is a level of security already judged inadequate for some applications. Given the rate at which computing power increases, even a 64 bit key would be subject to attach before long. Ironically, even the Clipper Chip provided a stronger (80 bit) key length The premise of the key escrow policy is to provide law enforcement and national security agencies a "front door" to be used to decrypt messages when the agency obtains proper legal authorization. Yet, the architects of the current policy apparently are not willing to trust that key escrow systems will meet law enforcement needs inasmuch as the key length limit suggests that the Administration is intent on maintaining an extra-legal method of decrypting communications. The Gore letter contains no suggestion that key escrow systems would also be subject to key length limits but the Administration seems to have lost faith in its own proposal. Such a half-hearted effort cannot be the basis of a long-lasting policy. * NO PRIVACY PROTECTION FOR USERS OF ESCROWED SYSTEMS: The ten export principles make no mention of privacy safeguards which the Vice President previously recognized as necessary to safeguard individual privacy and Fourth Amendment principles. Any escrow policy must contain safeguards against abuse and statutory liability provisions for the operators of private escrow systems. * FAILS TO PROMOTE INTERNATIONAL INTEROPERABILITY: Points 6 and 10 of the export criteria raise grave doubts as to the likelihood that the current proposal will give rise to a secure global communications environment. Point 10 forces users in other countries (and their governments) to accept United States-based escrow of all keys until bilateral access agreements are entered into. Such tactics seem unlikely to produce satisfactory international agreements, and hold global communications security hostage to the completion of such agreements. NSA/ADMINISTRATION SEEK TO RUSH IMPLEMENTATION OF NEW POLICY The NIST Key escrow conference was billed as an opportunity to begin a dialogue between the administration and industry on the new cryptography policy. However, as the conference began it quickly became apparent that many of the critical policy issues, including the 64 bit key length, interoperability with non-escrow products, and some requirements for key escrow agents (including whether individuals, corporations, and foreign entities are eligible) have already been decided. The Administrations attempt to rush many of the critical policy decisions drew sharp reaction from virtually all of the conference participants, including CDT, other public interest groups, and representatives from several major software and hardware manufacturers. Although the administration and NSA officials all indicated that they got the message, they still intend to publish a revised policy in the next 30 days for comment. INDUSTRY BALKS Industry reaction to the new policy proposal was, with a few limited exceptions, decidedly negative. Both during formal presentations and in small group sessions, representatives from several of the largest hardware manufacturers and software publishers questioned whether the market would support products designed to adhere to the administration's proposal, particularly in light of the 64 bit key length limit. CDT believes that the administration must make every effort to accommodate the concerns of the public, civil liberties groups, software publishers, hardware manufacturers, users, and other interested parties before adopting any new national cryptography policy. The current proposal fails to address many of the critical concerns of public interest groups and industry, and should be abandoned. NEXT STEPS The administration intends to published a revised policy within the next 30 days (October 7). CDT will closely monitor this issue and will inform you as it develops. PATHS TO RELEVANT DOCUMENTS: More information, including CDT's testimony from the NIST conference, other conference documents, etc. can be found at CDT's Crypto Issues Page: URL:http://www.cdt.org/crypto.html ------------------------------------------------------------------------ August 25, 1995 MEMORANDUM FOR Registrants for the Sept. 6-7, 1995 Key Escrow Issues Meeting From: NIST - Ed Roback Subject: Discussion Papers Attached for your information are two discussion papers for the upcoming September 6-7, 1995 Key Escrow Issues Meeting to be held at NIST. If you have any questions on this material, you may reach me on 301-975-3696. I look forward to seeing you in September. Attachments ------------------------ Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton@micf.nist.gov. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-mail: carlton@micf.nist.gov. 8/25/95 ------------------------------------------------------------------------ 9/1/95 Proposed Cryptography Policy for Software Key Escrow Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #3 Export Criteria Discussion Draft -- 64-bit Software Key Escrow Encryption As discussed at the SPA/AEA meeting on August 17, 1995, the Administration is willing to allow the export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. On the same date, the September 6-7 key escrow issues meeting at NIST was also announced. The two principal topics at the meeting will be: discussion of issues of exportability of 64-bit software key escrow encryption and 2) desirable characteristics for key escrow agents. In order to help make most productive use of the limited time available at the upcoming meeting and to better focus deliberation, the following criteria are being distributed for discussion purposes. Since it is important that final criteria be clear, straightforward, consistent, and implementable, please review these draft criteria and be prepared to discuss how they may be refined and made more specific. --- Draft Export Criteria --- for Software Key Escrow Encryption Software key escrow encryption products meeting the following criteria will be granted special export licensing treatment similar to that afforded other mass-market software products with encryption. 1. The product will use an unclassified encryption algorithm (e.g., DES, RC4) with a key length not to exceed 64 bits. 2. The product shall be designed to prevent multiple encryption (e.g., triple-DES). 3. The key required to decrypt each message or file shall be accessible through a key escrow mechanism in the product, and such keys will be escrowed during manufacture in accordance with #10. If such keys are not escrowed during manufacture, the product shall be inoperable until the key is escrowed in accordance with #10. 4. The key escrow mechanism shall be designed to include with each encrypted message or file, in a format accessible by authorized entities, the identity of the key escrow agent(s), and information sufficient for the escrow agent(s) to identify the key or key components required to decrypt that message. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. 7. The key escrow mechanism allows access to a user's encrypted information regardless of whether that user is the sender or the intended recipient of the encrypted information. 8. The key escrow mechanism shall not require repeated involvement by the escrow agents for the recovery of multiple decryption keys during the period of authorized access. 9. In the event any such product is or may be available in the United States, each production copy of the software shall either have a unique key required for decrypting messages or files that is escrowed in accordance with #10, or have the capability for its escrow mechanism to be rekeyed and any new key to be escrowed in accordance with #10. 10. The product shall accept escrow of its key(s) only with escrow agents certified by the U.S. Government or by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements. Note: Software products incorporating additional encryption methods other than key escrow encryption methods will be evaluated for export on the basis of each encryption method included, as is already the case with existing products. Accordingly, these criteria apply only to the key escrow encryption method incorporated by a software product, and not to other non-escrowed encryption methods it may incorporate. For instance, non-escrowed encryption using a key length of 40 bits or less will continue to be exportable under existing export regulations. ------------------------------------------------------------------------ [Handout at Key Escrow Issues Meeting, at NIST, Gaithersburg, Maryland, September 6, 1995.] Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #4 Example Potential Solutions for the Draft Export Criteria for Software Key Escrow Encryption Example solutions to the export criteria are identified below to help give a better feel for the approaches that implementors may take to satisfy the criteria. The information in this paper is not intended to represent fail-safe, cookie cutter solutions to the criteria, but only to generate more detailed discussions. [Note: the numbered articles are the ten key escrow criteria proposed by the Government in Discussion Papers 1, 2 and 3. The *comments* are the solutions suggested by the Government in this Paper #4.] 1. The product shall use an unclassified encryption algorithm (e.g. DES, RC4) with a key length not to exceed 64 bits. *It is important to understand that key in this context is related to the number of bits needed to decrypt a message which are not available over the communications channel. For some encryption algorithms the key is defined to be a number of bits which are kept secret and a number of bits which are transmitted in the clear (message key / initialization vector / salt). This criterion only specifies the number of secret bits.* 2. The product shall be designed to prevent multiple encryption (e.g. triple-DES). *One way to do this would be for the encryption program to store the ciphertextfile name and the first n (e.g. 16) bytes of cipher for the last k (e.g. 8) encryptions. When the encryption routine is called, the program checks to see if the input file name is in the ciphertextfile list or the first n bytes of the file match any of the k cipher text streams stored. Likewise, a plaintext header could be appended to each ciphertextfile which says the file is encrypted. The encryption program would look for this header before encryption; if found, the program would not proceed with the encryption. These are just examples of what could be done. Each vendor's constraints will be different.* 3. The key required to decrypt each message or file shall be accessible through a key escrow mechanism in the product, and such keys will be escrowed during manufacture in accordance with #10. If such keys are not escrowed during manufacture, the product shall be inoperable until the key is escrowed in accordance with #10. *One way of doing this is for each user to have a Public and Private Escrow Key. The public escrow key is bound in a certificate signed by the Escrow Agent(s). This certificate would contain a key ID, the escrow agents's ID and the Public Escrow key. A header of the encrypted message could contain this certificate along with the message key, encrypted using the Public Escrow key. If the product is not escrowed during manufacture, the software will check to see if it has a valid escrow key prior to encrypting messages.* 4. The key escrow mechanism shall be designed to include with each encrypted message or file, in a format accessible by authorized entities, the identity of the key escrow agent(s), and information sufficient for the escrow agent(s) to identify the key or key components required to decrypt that message. *Following the example for criterion #3, the certificate that contained the user's escrow key would also contain the identity of the escrow agents holding the corresponding pffvate escrow key.* 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch (i.e. the replacement of a block of code by a modified block). *Probably the most important aspect of this criterion is that source code for a product should not be available. Also it is important that the cryptography be integrated into the application in some nontrivial way. One way of achieving this criterion is for the application to store a hash or checksum of the cryptographic code in several places and check the cryptographic code several times during its use. One can prevent a static patch by making the hash or checksums dependent on a program ID code or something else that is unique about that copy of the software. Perhaps one of the best ways to defeat hackers from "patching around" the escrow would be a commitment from vendors to make each new release of the software be immune to existing static patches and patch programs.* 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. *If one follows the steps outlined under criterion #3, a receiving program could verify the escrow certificate contained in the message header, extract the escrow public key, and verify that the encrypted message decryption key is also found in the header. If it is not there, decryption does not proceed.* 7. The key escrow mechanism allows access to a user's encrypted information regardless of whether that user is the sender or the intended recipient of the encrypted information. *The message header could contain the decryption key encrypted under both the sender's public escrow key and the recipient's public escrow key. Then access to either the sender's or recipient's private escrow key would allow access to the decryption key.* 8. The key escrow mechanism shall not require repeated involvement by the escrow agents for the recovery of multiple decryption keys during the period of authorized access. *If the public and private escrow keys are unique to users, then the escrow agents could turn over the private escrow keys to the authorized parties. The private escrow key would allow access to keys encrypted with the corresponding public escrow key and not require repeated involvement with the escrow agents.* 9. In the event any such product is or may be available in the United States, each production copy of the software shall either have a unique key required for decrypting messages or files that is escrowed in accordance with #10, or have the capability for its escrow mechanism to be re-keyed and any new key to be escrowed in accordance with #l0. *Following the example in criterion #3, the software could accept the load of a new escrow certificate. The software could store a "root" public key which is used to verify a certificate containing the escrow agent public key which in turn is used to sign the individual user's escrow certificate. Hence the header might contain both the escrow agent certificate signed by the root and the user certificate signed by the escrow agent(s). Once escrowed, the software could store the ID of the escrow agents and not accept loads of new escrow keys except from those agents.* 10. The product shall accept escrow of its key(s) only with escrow agent(s) certified by the U.S. Government or by foreign governments with which the U.S. Government has formal agreements consistent with US law enforcement and national security requirements. *Following the example in criterion #9, if the "root" authority only signed the certificates of escrow agents (foreign and domestic) approved by the U.S. Government then only keys escrowed by approved escrow agents will be accepted as valid by the software packages.* [End]