[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Clipper Global (Teil 2)
- To: debate@fitug.de
- Subject: Clipper Global (Teil 2)
- From: plate@cublx1.cube.net (Juergen Plate)
- Date: Thu, 19 Sep 1996 22:38:56 +0200 (MET DST)
- Comment: This Message comes from the debate mailing list.
- Sender: owner-debate@fitug.de
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]