[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Clipper Global (Teil 2)

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]

                  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

     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

     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.

              U.S. PAA<-------------->Non-U.S. PAA
          |    |   |   \                 |     |
         CA1   |   |     \     CC        |     |
               |   |       \----------->CAa   CAb
              CA2  |

      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

          -->  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

     -    User A encrypts the archive key with his public key
          exchange key (of which the private component is

     -    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

     -    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

     -    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.


     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.


+    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

+    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.


+    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

+    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

+    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