Interesting People mailing list archives
IP: CDT POLICY POST No.24 -- NEW CRYPTO POLICY FLOPS AT CONFERENCE
From: David Farber <farber () central cis upenn edu>
Date: Mon, 11 Sep 1995 15:42:44 -0400
------------------------------------------------------------------------ ****** ******** ************* ******** ********* ************* ** ** ** *** POLICY POST ** ** ** *** ** ** ** *** September 11, 1995 ** ** ** *** Number 24 ******** ********* *** ****** ******** *** CENTER FOR DEMOCRACY AND TECHNOLOGY ------------------------------------------------------------------------ A briefing on public policy issues affecting civil liberties online ------------------------------------------------------------------------ CDT POLICY POST Number 24 September 11, 1995 CONTENTS: (1) Administration's New Crypto Policy Flops At Conference (2) The Administration's Proposal (2) Subcribe To The CDT Policy Post Distribution List (3) About CDT, Contacting Us This document may be re-distributed freely provided it remains in its entirety. ------------------------------------------------------------------------- (1) 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 ------------------------------------------------------------------------ (2) THE ADMINISTRATION'S NEW CRYPTOGRAPHY POLICY 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. --------------------------------------------------------------------------- General information on CDT can be obtained by sending mail to info () cdt org World-Wide-Web: http://www.cdt.org/ ftp: ftp://ftp.cdt.org/pub/cdt/ snail mail: Center For Democracy and Technology 1001 G Street, NW Suite 700 East Washington, DC 20001 voice: +1.202.637.9800 fax: +1.202.637.0968 ###
Current thread:
- IP: CDT POLICY POST No.24 -- NEW CRYPTO POLICY FLOPS AT CONFERENCE David Farber (Sep 11)