[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Clipper Global
- To: debate@fitug.de
- Subject: Clipper Global
- From: Heiko Recktenwald <UZS106@IBM.RHRZ.Uni-Bonn.DE>
- Date: Thu, 19 Sep 96 08:58:51 MEZ
Draft Key Escrow Paper
[Thanks to Mr. Ed Roback, CSL/Computer Security Division,
NIST, for promptly faxing this document to John Young on May
21, 1996. Transcribed by JY and DN.]
____________________________________________________________
Executive Office of the President
Office of Management and Budget
Washington, D.C. 20503
May 20, 1996
MEMORANDUM FOR INTERESTED PARTIES
SUBJECT: Draft Paper, "Enabling Privacy, Commerce, Security
and Public Safety in the Global Information
Infrastructure"
FROM: Bruce W. McConnell [Initials]
Edward J. Appel [Initials]
Co-Chairs, Interagency Working Group on
Cryptography Policy
Attached for your review and comment is a draft paper
entitled "Enabling Privacy, Commerce, Security and Public
Safety in the Global Information Infrastructure." It presents
a vision and course of action for developing a cryptographic
infrastructure that will protect valuable information on
national and international networks.
The draft paper is the result of the many discussions we
have had with interested parties concerning the use of
encryption. While those discussions have explored the use of
both key recoverable encryption and non-recoverable
encryption, the draft paper addresses an infrastructure which
uses key recoverable encryption. We believe such a key
management infrastructure, voluntary and supported by *private
sector* key management organizations, is the prospect of the
near future. It would permit users and manufacturers free
choice of encryption algorithm, facilitate international
interoperability, preserve law enforcement access, and, most
importantly, provide strong system security and integrity.
Recognizing that a robust infrastructure is not yet a
reality, we are also considering measures to liberalize export
policy for some non-escrowed products. Appendix II of the
draft paper begins to summarize current policy, and we intend
to expand and improve that section.
We believe that clearly articulating such a vision will
accelerate the ability of the United States to realize the
full advantages of the global network for commerce, security
and public safety. However, such a vision cannot become a
reality unless it is widely shared. Therefore, rather than
being a finished product, the attached paper is a draft which
we ask you to help us improve. We hope it will contribute to
constructive discussion and promote a clearer understanding of
each others' needs and concerns regarding the use of
encryption.
We welcome your comments and look forward to further
discussion. Written comments may be sent to our attention,
Room 10236, NEOB, Washington, D.C. 20503.
[End cover letter]
____________________________________________________________
[Note: All 25 pages of the typeset report have the word
"Draft" printed in large letters across the text.]
[Head note of report] Last Modified: May 17, 1996
____________________________________________________________
Enabling Privacy, Commerce, Security and Public Safety in the
Global Information Infrastructure
____________________________________________________________
Statement of the Issue
This paper outlines a course of action for developing an
infrastructure that will protect valuable national information
resources on national and international networks. Government
and industry must work together to create a security
management infrastructure and attendant products that
incorporate robust cryptography without undermining national
security and public safety. A policy for escrow of
cryptographic keys which provides a basis for bilateral and
multilateral government agreements must be determined so that
industry can produce products for worldwide interoperability.
Industry will participate in defining algorithms and protocol
standards, and will develop key escrow encryption products
suitable for the protection of both government and private
sector information and which will assure timely, lawful,
government decryption access. Government will help set
standards for the Key Management Infrastructure (KMI) and
deliver a market for robust security products. A KMI
infrastructure and attendant key escrow products will provide
many benefits, both domestic and internationally, as the US
begins to realize the advantages of the global network for
improve commerce, security and public safety.
____________________________________________________________
I. Introduction
Government can no longer monopolize state of the art
cryptography. It is no longer acceptable to argue that the
only information of a compelling national security interest is
government information. It is unrealistic to believe that
government can produce solutions which keep ahead of today's
rapidly changing information technology. Increasingly, all
institutions, military, civil, or corporate, will communicate
across common links. The nation's commerce is moving to
networking. With these enormous changes, means must be found
to responsibly raise the quality of cryptographic services
without jeopardizing effective law enforcement, imperilling
public safety.
Industry and government must partner in the development
of a public key-based key management infrastructure and
attendant products that will assure participants can transmit
and receive information electronically with confidence in the
information's integrity, authenticity, and origin and which
will assure timely lawful government access. When we conduct
transactions, we rely on face-to-face interactions, or
obtaining a signature on a paper, to have confidence that
commitments will be fulfilled. Policies and infrastructure are
needed to assure we can have at least the same degree of
confidence when we interact electronically. Government bears
a significant responsibility to ensure the information
infrastructure has the features that are essential to such
confidence.
There is a more compelling rationale for the government
to be a partner in the development of the KMI. Not only has
the Information Age sparked fundamental changes in the way we
interact, but reliance on information systems makes our
institutions vulnerable to an unprecedented degree. Almost all
institutions upon which public safety and national security
depend, ranging from the power grid to military command and
control, are at severe risk because of their presence in and
dependence upon a global information infrastructure.
But the proliferation of quality cryptographic services
is not without risk. Keys can be lost, stolen, or forgotten --
rendering encrypted data useless. Additionally, the widespread
use of encryption without safety features such as key recovery
can pose serious risks to society. It will put at risk
important law enforcement and national security investigations
where electronic surveillance and search and seizure are
essential in preserving and prosecuting crimes, and more
importantly, in saving human life.
Public key cryptography allows for secure authenticated
transactions with any party, known or unknown, with assurance
of data integrity and non-repudiation of the transaction.
These features, together with increased network reliability,
are needed to support electronic commerce, public services,
redefined business processes and national security. But to
achieve its promise, public key cryptography must be based on
a key management infrastructure and attendant products that
tie individual and coprorate identities to their public key
through a series of Certificate Authorities (CA). The key
management infrastructure to do this on a global scale will be
very large and complex, but it is an essential foundation.
Without a KMI of trusted certificate authorities, users cannot
know with whom they are dealing on the network, or sending
money to, or who signed a document, or if the document was
intercepted and changed by a third part. Therefore, users will
demand a strong key management infrastructure, which may, in
turn, be based on a voluntary system of commercial certificate
authorities (CAs) operating within prescribed policy and
performance guidelines. To achieve the environment for such an
approach, a number of principles need to be accepted by
government, industry, and other users:
+ Participation in the KMI will be voluntary. Key escrow in
the KMI will occur naturally through mutually trusted
authorities.
+ There will be a transition period during which legacy
equipments which do not support key recovery can be used
to communicate with users in emerging full featured KMIs.
Government, industry, and users will need to address the
legitimate needs of those currently using non-key
recovery products to communicate with users of the full-
featured KMI in a manner that protects legitimate
government and public safety concerns. This will provide
a stable transition path.
+ Products that operate with an escrowed KMI need to be
developed with industry taking the lead.
+ Industry can continue to lead in establishing standards
for public key certificates, encryption algorithms,
protocols, data recovery, and security servcies.
+ Certificate authorities will operate within performance
standards set by law.
+ Agreements between governments will serve as the basis
for international cross certification.
+ Self-escrow will be permitted under specific
circumstances.(1)
+ Export controls on Key Escrow products will be relaxed
progressively as the infrastructure matures.
----------
(1) The escrow agency must meet performance requirements for
law enforcement access.
____________________________________________________________
II. Key Management Infrastructure
In a key management infrastructure (KMI) based on public
key cryptography, each user has one or more pairs of public
and private keys. The public and private keys differ in a such
a way that it is computationally infeasible to determine the
private key from the public key. This allows the public key to
be revealed without endangering the security of the private
key. Users can communicate securely without having to share a
"secret"; they only need to know each other's public key and
that each public key is certified by a trusted authority.
Without assurance on the "binding" of a user to a specific
public key, these keys have little or no value.
Public key cryptography supports security services such
as authentication, confidentiality, data integrity and
nonrepudiation. Access to a user's encrypted data for which
the key is lost is a security related service referred to as
data recovery. Providing a secure and trusted means of storing
private keys within the Key Management Infrastructure is one
means of providing data recovery. This capability naturally
supports law enforcement access, under legal warrants. Thus,
the user desire for data recovery and law enforcement's
potential need for access can be accommodated in a single
locale, so long as the user trusts the key storage and law
enforcement has confidentiality of access.(2)
----------
(2) For a survey of escrow mechanisms see Dorothy Denning's
article in the March 1996 Journal of Communications of
the ACM. More in depth articles on solutions to escrow
can be found in *Building in Big Brother*, a collection
of papers edited by Professor Lance Hoffman that
contains both technical and political responses to
Clipper/Capstone.
____________________________________________________________
[Diagram]
Escrow
--> Authority (private key database)
| |
| |
| | public keys
| | Escrow and
private | V Certificate
key | Certificate Authorities
(either | Authority can be combined
way) | | into one entity
| |
| | public key certificate
| | (binds IDs and keys)
| |
| V
--> User A (private keys and certificates)
____________________________________________________________
The simplest model for a KMI meets government access
requirements by relying on the certificate authorities (CAs).
However, the hierarchy could be structured to include a
separate Escrow Authority (EA) to provide law enforcement
access. Provision for split keys to enhance personal privacy
and security can be incorporated into the KMI. Either of these
mechanisms lessens the burden of key escrow on users and on
the producers of security products.
To participate in the network a user needs a public key
certificate signed by a CA which "binds" the user's identity
to their public key. One condition of obtaining a certificate
is that sufficient information (e.g., private keys or other
information as appropriate) has been escrowed with a certified
escrow authority to allow access to a user's data or
communications.(3) (As noted before, this might be the CA or
an independent escrow authority). The certificate creation
process is pictured above.
For users to have confidence in the KMI, CAs must meet
minimum standards for security, performance, and liability. A
Policy Approving Authority (PAA) certifies CAs for operation.
The PAA sets rules and responsibilities for ensuring the
integrity of the CAs. The PAA is also responsible for setting
CA performance criteria to meet law enforcement needs.
If law enforcement has obtained legal authority to access
a user's encrypted data or communications, it would certify
that authorization to the escrow authority. The escrow
authority will then relinquish information sufficient to
access the user's communication.
----------
(3) This applies only to keys used for confidentiality
purposes and not keys used for signing purposes.
____________________________________________________________
III. Some Issues
Difficult issues include i) how to refine the application
of export controls, ii) whether and to what extent to permit
self-escrow, iii) whether legislation is required and, if so,
what it should accomplish, and iv) the certainty and extent
that tovernment-togovernment agreements can be established to
ensure timely law enforcement access to keys/information held
by a foreign country. This section of the White paper briefly
explores each.
Export Controls
The most contentious issue surrounding encryption is
export control policy. Encryption exports are controlled to
all destinations in the interest of U.S. national security/
foreign policy under the Arms Export Control Act. These export
controls are often criticized as an impediment to the fielding
of interoperable security across the GII and the
competitiveness of U.S. industry. The government is mindful of
these criticisms and has initiated a number of reforms to ease
the impact export controls have on manufacturers and users of
encryption. The task, then, is to find a method of applying
export controls that meets the interest of national security,
public safety, privacy, and competitiveness.
Freedom to choose any mutually trusted certificate
authority may accommodate the above interests.(4) In addition,
allowing ready export of products of any bit length to markets
where the key management infrastructure, which complies with
statuatory constraints, is in place to permit government
access to keys, would provide both a level market for U.S.
manufacturers and higher quality security products for users.
Products that meet defined performance requirements and which
will not operate until the key is escrowed with an appropriate
certificate authority will address commercial, public safety
and national security needs. Some law enforcement and national
security concerns would be protected since government agencies
would be able to obtain escrowed keys pursuant to government-
to-government agreements.
----------
(4) A mutually trusted authority is an escrow agent trusted
by users to store keys and trusted by law enforcement to
provide access upon certification of lawful authority.
Transition
We are working toward a policy that permits licensing of
key recovery encryption systems regardless of algorithm, bit
length, or whether implemented in hardware or software, once
needed infrastructure and government-to-government agreements
are in place. In the interim we recognize that the policy must
make it worthwhile for manufacturers and users to invest in
escrowed KMI. With these objectives in mind, and consistent
with applicable statutes, the interim policy will consider:
Prior to formal government-to-government agreements:
+ Permitting export of products that use an escrowed KMI to
approved markets, e.g., Europe or Australia, consistent
with the policies of the destination country.
Prior to multi-national Public Key Infrastructure with Key
Recovery:
+ Reviewing, on a case-by-case basis, proposals to export
products which require the use of an escrowed KMI to any
destination with which the U.S. has a government-to-
government key escrow agreement.
+ Continuing and expanding the administration's previously
announced key escrow initiative by permitting the export
of 64 bit S/W or 80 bit H/W key escrow products that meet
defined performance requirements, after one-time review,
to any destination if keys will be escrowed in the U.S.,
or in foreign countries with which the U.S. has a
govvernment-to-government key escrow agreement.
In any condition:
+ Permitting the export of other products on a case-by-case
determination that such exports are consistent with US
interests.
The proposals for an interim export control policy are
founded on the assumption that the products will require the
use of an escrowed KMI in a country with which the U.S. has a
government-to-government agreement. Note that the contemplated
exports are to civil end-users; exports to military end-users
will require more extensive product review. The existing
policies applicable to unescrowed products provide substantial
flexibility and will continue as currently defined throughout
the transition period (see Appendix II). Additional requests
for near-term relief will be considered on a case-by-case
basis consistent with existing practice.
The interim policy also reflects a judgment that overseas
escrow of key will generally be permissible with suitable
government-to-government arrangements. There is a concern that
U.S. products with keys escrowed in the U.S. will not be
saleable overseas. Hence, it may be possible to permit
overseas escrow in Europe, even before government-to-
government arrangments are completed. This exception is
possible since the European countries are already moving to
implement key escrow systems and we can reasonably expect to
enter into law enforcement agreements in the near term. The
OECD's goal of negotiating multilateral cryptography
guidelines by 31 December 1996 is further evidence of European
intent and momentum in infrastructure development.
The interim policy reflects a differentiation between
hardware and software products, i.e., hardware products with
greater bit lengths are treated more favorably under this
policy. Hardware implementations of products permit more
confident binding between encryption and the key management,
limiting the risk that the encryption can be easily stripped
from the key management and used independently of key
recovery. Software does not provide similar protection. This
said, the interim policy to permit export of 64 bit software
key recovery products would reflect a significant increase
over the bit length restrictions applicable to non-key
recovery products.
Self-Escrow
Self-escrow will be a principal concern of many large
corporations that want to provide corporate data recovery,
protect against loss of proprietary data from use of an
outside escrow agent, and simply for reasons of efficiency and
cost. Hence, self-escrow must be considered as an acceptable
option.
Escrow requires less architecture if the CA can be the
escrow authority. However, in those cases in which an
indidividual or corporation serves as its own certificate
authority, government organizations could be compelled to
request escrowed key from the subject of an investigation. The
investigation could be compromised under such circumstances.
While this risk could be avoided by adding independent escrow
authorities as another layer in the PKI, such a solution would
be costly and inefficient.
A solution is a national policy which allows CAs for an
organization to serve as escrow authorities if they can meet
necessary performance requirements. These requirements should
be determined by government in consultation with industry and
should address timeliness, security, confidentiality of
requests for, or release of, keys, and independence of the
escrow authority from the rest of the organization. To this
end, the government should seek legislation that would shield
organization certificate authorities from internal pressures
in the course of law enforcement investigations.
Legislation
There is some consensus that the ultimate legislative
package should include provisions to criminalize the
unauthorized disclosure/use of escrowed key, provisions to
authorize civil actions by victims against those responsible
for the unauthorized disclosure/use of escrowed key,
provisions specifying the circumstances in which escrowed key
may be requested and released (e.g., death of a family member
or employee), and establishing liability protection for
certificate authorities who exercizes due prudence in the
fulfillment of their performance obligations.
Those who endorse a larger government role would seek
legislation that would, for example, establish the government
as a major participant in the PAA, which would be responsible
to establish policies and guidelines governing certificate
issuance. In this case, the government would be authorized to
assure establishment of standards for the PKI that adequately
provide for systems security and law enforcement access.
Inasmuch as the integrity and reliability of the whole range
of network centered activities, including electronic commerce,
will depend on the integrity and reliability of the key
management certificate process, there is good reason for
government to play a substantial role.
The enabling legislation envisioned here should reflect
the stated needs of industry and users. To that end,
government must work closely with industry and other affected
parties to develop such legislation.
Government to Government Agreements
There is an expressed need by all govenments to have
access to information affecting their own security or public
safety. Inevitably there will be situations in which the U.S.
will want access to keys in a foreign country that concern
criminal activities in violation of U.S. laws and vice versa.
The security and other technical protocols that will serve as
the framework of the GII should ensure key recovery is
possible in either circumstance. The U.S. government should
seek to frame and execute law enforcemnet agreements that:
+ will allow for timely access when authorized
+ minimally impact security products
+ operate within guidelines established for key recovery
methods including trusted third parties and self-escrow
standards used in the U.S.
It whould be recognized that no agreement can guarantee
access to keys/information held in a foreign country, but
established agreements might serve as a framework to request
lawful access to keys/information. Such arrangements will be
based on the philosophy that authorized government access must
be preserved consistent with the legally recognized privacy
interests of the citizens of each country.
____________________________________________________________
IV. Actions
Several issues discussed in this paper raise substantial
policy questions that will not be easily resolved. The
government, however, has an interest in seeing good security
products populate the NII and GII as soon as possible.
To demonstrate resolve and good faith, the United States
Government should immediately:
1. Collaborate with industry and existing standards
groups, to develop Key Management Infrastructure
and attendant products performance requirements
(with a working draft completed within 6 months);
2. Collaborate with industry on a Federal Information
Procccessing Standard (FIPS) within government that
specifies a suite of algorithms and protocols for
encryption, key exchange, and digital signature
functions sufficient to protect government
information. The resulting FIPS should provide for
key recovery operations and should be mandatory for
government use.
3. Establish a security management infrastructure for
government use which complies with the standards
developed jointly by industry and government. This
is the first step in providing a market for
industry products which support the new FIPS.
4. Determine an appropriate government agency to work
with industry in specifying security requirements
for products used in network security applications
for protecting highly sensitive information.
5. Collaborate with industry to formulate legislation
to establish viable key management infrastructure.
Such legislation would, inter alia, set policies
for assuring the integrity of escrowed key,
establish an appropriate government role in this
PAA, and address civil liability issues.
6. Negotiate with other governments arrangements for
access to escrowed keys consistent with national
sovereignty, national security, and public safety.
As trusted partners, industry and government can share
expertise and tackle intractable problems such as the insecure
operating system. In times past, the cryptographic algorithm
was the core of the solution: now it is the easy part. The
debate over algorithms and bit lengths should end: it is time
for industry and governments to work together to secure the
GII in such a way that does not put the world at risk.
____________________________________________________________
Appendix I: One View of a KMI
The discussion given here is intended to provide a
description of how a KMI might be designed and operated
consistent with the tenets of the White Paper. This
description is not intended to preclude consideration of
other, equally suitable, implementations.
Introduction to KMI Based Escrow
In a KMI based on public key cryptography, each user has
one or more pairs of public and private keys. The public and
private keys differ in such a way that it is computationally
infeasible to determine the private key from the public key.
This allows the public key to be revealed without endangering
the security of the private key. Users can communicate
securely without having to share a "secret", they only need to
know each other's public key. In practice, users may have
multiple public/private key pairs.
The key pairs may be used in applications such as key
exchanges and digital signatures. To make use of such
applications, a user's public keys must be available to
intended recipients in a manner that the recipient can
confidently associate the user with his/her public key.
Without assurances on the "binding" of user identities to a
specific public key, these keys have little or no value.
Thus, in the context of public key cryptography, the
strength of cryptographic mechanisms relates to protecting the
confidentiality of the private keys and the integrity of the
public keys. Ultimately, the viability of public key
cryptographic applications is dependent on the evolution of a
key management infrastructure.
KMI and Certificates
The KMI supports the integrity of public keys through the
generation and distribution of public key certificates. The
role of a certificate is to cryptographically bind a specific
user indentity with a public key and other security related
information. A trusted sytem entity, generally called a
Certificate Authority (CA), obtains information from an
individual sufficient to verify the individual is who he says
he is. The CA then generates and digitally signs a certificate
specific to that individual using the CA's private signature
key. Any system user can then validate the contents of that
certificate by verifying the CA's digital signature (via the
CA's public signature key).
Certificate contents must be bound together by a
mechanism which can be authenticated. The certificate format
commonly used is based on the structure defined by the CCITT
X.509 Recommendation. This has worldwide support in industry
and governments.
The concept of a CA can be easily extended to apply to a
large system of users where a single CA is not feasible.
Providing interoperability within a system containing multiple
CAs leads to a hierarchical structure. At the very top of the
hierarchy is a Root entity which is often referred to as a
Policy Approving Authority (PAA). The PAA represents the
single node in the hierarchy that all system users trust. The
PAA creates the overall guidelines and policies for the
operation of the KMI. The PAA exists to ensure the security
and integrity of each and every entity within the hierarchy.
Security and integrity are enforced by PAA certifying the
public keys of subordinate CAs. Each of these subordinate CAs
may also certify the public keys of other CAs or users. A
sample hierarchy is pictured below. The PAA public signature
key is possessed by all those in the hierarchy.
____________________________________________________________
[Hierarchical Diagram]
PAA
|
CA1 CA2 CA3
| | |
CA4 CA5 CA6 CA7
| | | |
(------------------ Users ----------------)
____________________________________________________________
Any two users within a defined hierarchy can validate
each other's public key certificates through a common
certification path. A certification path is an ordered
sequence of certificates between the entity to be validated
and the trusted point in the hierarchy, i.e., PAA. This
defines a path of trust. Validation of any system certificate
requires that each certificate in the certification path be
checked by verifying the digital signature over each
certificate.
To maintain trust in the path, the entities making up
certificate authorities must follow prescribed rules for
identifying users, issuing certificates, and protecting keys.
Adherence to these regulations can be enforced by a PAA or as
a condition of cross certification between two Certificate
Authorities.
After a CA generates a certificate, it is transferred to
the user along with the certificates in the user's
certification path. Distribution of certificates among system
entities can be accomplished by sending them via e-mail
(quickly becomes unwieldy) or through the use of a Directory
System. Other users can then request and retrieve certificates
directly from a Directory Server.
The hierarchical structure is designed to support
multiple communities of users who may need to communicate with
each other. It is also possible that some communities of users
in the system could remain autnomous and yet still be able to
communicate with users outside their immediate community of
interest. The PAA provides the means for such inter-community
communication by functioning as the single mutually trusted
authority for the entire hierarchy.
Cross Certification
There could exist one or more PAAs within the U.S. and
non-U.S. KMIs. To permit communication between users of
different PAA domains, a common certification path must exist.
Cross certification will be based on the existence of accepted
policies and standard certification criteria. PAAs from each
KMI could then cross certify each other. This is accomplished
by each PAA countersigning the registered public key
certificates of the other. This cross certifying of
certificates provides a valid certification path for all users
in the respective KMIs.
____________________________________________________________
[Diagram]
CC
U.S. PAA<-------------->Non-U.S. PAA
| | | \ | |
CA1 | | \ CC | |
| | \----------->CAa CAb
CA2 |
|
CA3
Cross Certification Options Between Distinct KMIs
____________________________________________________________
This scenario permits specific entities under one PAA to
have a verifiable certification path for communications with
entities serviced by another PAA. It is important to note,
however, that the integrity of this cross certification system
is only assured by limiting cross certification to bilateral
nad direct connection between the two PAAs involved. One PAA
should not rely on the representation of another that a third
PAA has been authenticated.
Key Recovery Performance Criteria
Key recovery provides for backup storage of a user's
private keys. This backup capability helps ensure the
availability of a user's data even after it has been
encrypted. It also provides for an effective means for law
enforcement access. Key recovery requirements whould be viewed
from the perspective of the individual, the corporation, or
governments that require access. Most of the criteria to be
discussed have a dimension for key recovery on an individual
basis as well as from a corporate or government perspective.
The criteria can be grouped into three categories.
1. Key Integrity:
+ Confidentiality - Key recovery storage and release
mechanisms must preclude simple exploitation.
+ Availability - Key recovery data must be available when
subject to authorized release.
2. Key Accessibility:
+ Responsiveness - Timely access to key recovery
information requires 24 hour responsiveness and real time
accessibility requires a two hour response window to
authorized requests.
+ Confidentiality - Confidentiality must be maintained on
all requests for release of key recovery information.
+ Proof of Approval - Trustworthy on-line or off-line
mechanisms must exist to support identification and
authorized release of key recovery information.
3. Key Recovery Use:
+ Subject Message Recovery - All information related to the
subject of the recovery request must be accessible
through the release of key recovery information
pertaining only to that subject.
+ Release Window - The start and end dates of authorized
key recovery periods must be enforced.
Key Recovery Using KMI
____________________________________________________________
[Diagram]
Escrow
--> Authority (private key database)
| |
| |
| | public keys
| | Escrow and
private | V Certificate
key | Certificate Authorities
(either | Authority can be combined
way) | | into one entity
| |
| | public key certificate
| | (binds IDs and keys)
| |
| V
--> User A (private keys and certificates)
____________________________________________________________
Key recovery fits well within a public key KMI.
Interleaving key recovery within the KMI provides for a
concentration of trust that stands to benefit the individuals
from a confidentiality of private key aspect and facilitates
government access by limiting the number of access points. The
most simple model is to rely on the existing CAs within the
KMI to meet goverment access requiements. If necessary,
however, the hierarchy can be structured to include an Escrow
Authority (EA) as a separate trusted entity.
EA hierarchy is intrinsically shallow when compared with
the depth of the CA hierarchy. The structure is more likened
to a peer group of EAs that all fall under the jurisdiction of
the KMIs PAA which creates guidelines and policies for EA
operation. To become a system endorsed EA entity, an EA must
be certified by the PAA. Certification encompasses
satisfactory implementation of the standards and policies put
forth by the PAA. The PAA provides the standardization for the
escrow functions to occur across multiple EA entities with an
equivalent degree of trust. It is important to stress that
some or all of the elements of the escrow infrastructure may
be the same as those in the certificate infrastructure. The
KMI supports both.
As with the certification of subordinate CAs, the
recognition of a certified status for a particular EA is
embodied by the PAAs digital signature on the public key
certificate of the EA (thus attesting to the validity of the
service they provide). This allows a particular EA to have a
system-wide recognized signature, one that is traceable back
to a common trusted entity, the PAA.
Two examples follow that show how the EA and CA entities
work in tandem to provide both a certificate and data recovery
service for users and law enforcement:
1. Certificate and Recovery Registration.
+ In this example we have a single Escrow Authority
distinct from the Certificate Authoriy. In reality, the
EA may be the same entity as the CA or the EA may be one
of a set of users certified by the government as an EA.
The simple protocol described below follows closely the
key escrow proposal made in 1993 by Silvio Micali of MIT.
+ User A wishes to register, in the form of a public key
certificate, a public key exchange key with his local
certified KMI entity. User A does the following:
- Identifies himself and securely distributes the
public and private components of the key pair he
wishes to have registered to a certified Escrow
Authoriy (EA). This may be done electronically.
Alternately, the EA could generate these keys for
User A.
- Uniquely identifies himself to the CA. This must be
done physically unless User A already possesses a
valid signature key.
- Distributes the public component of the key pair he
wishes to have certified to the CA.
+ The EA does the following:
- Protectively stores the private component.
- Notifies the CA that a valid key pair has been
"escrowed" for user A. (This notification can take
the form of a signed message from the EA that
contains the public key of User A.)
+ The CA does the following:
- Verifies the identity of User A.
- Verifies the signature on the message received from
the EA. This ensures that only properly escrowed
keys are entered into the system.
- Generates a public key certificate that contains
(at least) the public key exchange key acknowledged
by the EA, an identifier representing User A, an
identifier for EA, and validity period for
certificate management.
- Digitally signs the certificate using the CA
private signature key.
- Distributes the certificate to User A (and
potentially to a Directory Service). User A then
verifies the CA signature on the received
certificate as well as the information it contains.
To more fully reflect the Key Integrity Criteria, the EA
entity could in fact be a set of EAs that work in conjunction
with a particular CA. Providing multiple EAs allows for
increased flexibility with respect to the generation, storage,
and recovery of key information. Not only would users have
increased flexibility of choice in selecting a certified EA,
but they essentially have a voice in who is entrusted with
protecting their keys. Specifically, the EA entity could be a
set of EAs, each of which only possesses a portion (key split)
fo User A's private key component. This provides a recovery
mechanism for User A that more directly protects his private
key component since recovery of the key by other than
authorized requests would require collusion on the part of all
EAs, compromise of all EA storage mechanisms, or compromise of
all of the distribution paths used during recovery from each
EA to User A)
2. User Key Recovery: An Archiving Example
+ In this example User A stores (archives) his data in
encrypted form using a locally generated key. He must
have alternate access to that encrypted data. Consider
the following:
- User A generates a private key (session, archive,
message, etc.)
- User A encrypts his informatin with this archive
key.
- User A encrypts the archive key with his public key
exchange key (of which the private component is
escrowed).
- The result of this encryption is stored, along with
public escrow key, in the header portion of the
encrypted file.
- Upon loss of his key exchange key, decryption of
the information is accomplished by requesting
release of the private key exchange key from the
EA.
- User A identifies himself to the EA(s) holding his
private key and requests its release.
+ The EA(s) does the following:
- Positively identifies the requestor.
- Locates and securely transmits the private key
component to User A.
3. Law Enforcement Key Recovery: An e-mail Example
+ In this example the sender of a message, generates a
session key, encrypts the message with the session key
and encrypts the session key he uses to protect his
communications with the recipient's public key exchange
key. This encrypted session key is stored in the header
information of the encrypted message for recipient and
government recovery purposes. The key recovery process
proceeds in the following manner:
- Escrowed data to or from the subject of a lawful
investigation is intercepted.
- The subject's public key certificate is obtained
from the data or a Directory Service.
- The Escrow Authority ID is extracted from the
certificate. This allows law enforcement to locate
the private key components.
- Legal authorization is obtained to receive the
appropriate escrowed private key(s) components.
- Legal authorization is presented to appropriate
EA(s). This may involve working through foreign
governments.
- EA(s) verifies authenticity of request.
- EA(s) securely transmits the private key
component(s) to law enforcement (this could be
accomplished physically or electronically.)
- Law enforcement forms the private key from its
private key component(s) and decrypts to recover
the session key and the message.
Law enforcement will destroy keys at the end of the
authorized period of use. Access can be also be time bounded
directly by users by repeating the registration process.
____________________________________________________________
Appendix II: Current Encryption Export Policies
This appendix has been prepared to state clearly the
existing encryption export control policies and procedures.
While the government recognizes that further progress is
needed in license processing, changes instituted to date have
resulted in a reduction of average license turnaround time of
39 days in 1993 to an average of 13 days in 1995. Further,
over 99% of export licenses for proposed cryptographic
products are approved each year.
Authorities
The export of cryptographic products is regulated by the
Department of State pursuant to the Arms Export Control Act
(AECA) and its implementing International Traffic In Arms
Regulations (ITAR), and by the Department of Commerce pursuant
to the Export Administration Act (EAA) and its implementing
Export Administration Regulations (EAR).
No license is required for the import of cryptographic
hardware or software. There are no federal laws regulating the
use of cryptographic products within the United States. A
license is required for the export of cryptographic products
to all destinations except Canada. Applications are reviewed
by the Department of Defense (NSA) for national security
implications and by State for foreign policy concerns. The
export licensing policy is consistent with U.S. national
security and foreign policy.
The Department of Commerce controls the export of
rudimentary cryptographic products containing cryptographic
functions generally limited to purposes such as data
authentication, password protection, and access control.
Products which are determined to be covered by the Commerce
Control List (CCL), with certain foreign policy exceptions,
may be exported under a General License.
Procedures
+ Autolist - For products reviewed and approved by NSA for
export to approved classes of end users and end uses.
Permits Department of State to process license
applications for such products without further review by
NSA.
+ Distribution Arrangements - Single license vehicle for
export of approved products to classes of end users in
countries or regions. Avoids need for licenses on an
export-by-export basis.
+ Distribution Agreements - Permits single license for
export of approved products to identified distributors.
Again, avoids export-by-export licensing.
+ Personal Use Exemption - Products exported for the
personal use of the exporter are excepted from pre-export
license requirements.
Policies
+ Products designed to use cryptography for access
control/authentication purposes are export controlled as
dual use commodities pursuant to the Export
Administration Act.
+ Product manufacturers determine if their products are
access control/authentication devices.
+ Generally, access control/authentication products are
exportable under general license procedures.
+ Mass-market software products verified as implementing
RC2/RC4 encryption algorithms, with 40-bit key space
limitations, are designated dual use items, to be
controlled under the Export Administration Act, after a
one-time review completed within 7 working days of
submission.
+ Mass-market software implementing other encryption
algorithms and key space lengths for confidentiality are
reviewed on a case-by-case basis for designation as dual
use items and control under the Export Administration
Act. By regulation, reviews must be completed within 15
days of submission.
+ Generally, licenses are approved for export of products
to be used in protecting U.S. proprietary information
(i.e., intellectual property).
+ U.S. companies and their subsidiaries are allowed to
export products with strong encryption for their internal
use.
+ Confidentiality encryption products that incorporate the
Data Encryption Standard (DES) are routinely approved for
export to:
- Financial institutions and financial applications
- Protecting financial information in Electronic
commerce applications
+ Confidentiality encryption products that incorporate the
Data Encryption Standard (DES) are favorably considered
for export to:
- Applications involving protection of personal
medical data
- Parking and toll systems; Debit applications; Other
transaction-based systems in which encryption is
configured to perform identified specific
transactions
____________________________________________________________
[End]