[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [interesting-people Home]
Subject: IP: CDT POLICY POST No.24 -- NEW CRYPTO POLICY FLOPS AT CONFERENCE
------------------------------------------------------------------------
****** ******** *************
******** ********* *************
** ** ** *** 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
###
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [interesting-people Home]
Powered by eList eXpress LLC