FIPS PUB xyz

FEDERAL INFORMATION

PROCESSING STANDARDS PUBLICATION

(Date)

U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and
Technology

**KEY RECOVERY SYSTEMS (KRS)**

(DRAFT)

CATEGORY: COMPUTER SECURITY, CRYPTOGRAPHY

U.S. DEPARTMENT OF COMMERCE, William M. Daley, Secretary

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY,

Dr. Robert Hebner, Acting Director

**Foreword**

The Federal Information Processing Standards Publication Series of the
National Institute of Standards and Technology (NIST) is the official
series of publications relating to standards and guidelines adopted and
promulgated under the provisions of Section 111(d) of the Federal
Property and Administrative Services Act of 1949 as amended by the
Computer Security Act of 1987, Public Law 100‑235. These mandates have
given the Secretary of Commerce and NIST important responsibilities for
improving the utilization and management of computer and related
telecommunications systems in the Federal Government. The NIST, through
the Computer Systems Laboratory, provides leadership, technical
guidance, and coordination of Government efforts in the development of
standards and guidelines in these areas.

Comments concerning Federal Information Processing Standards
Publications are welcomed and should be addressed to the Director,
Computer Systems Laboratory, National Institute of Standards and
Technology, Gaithersburg, MD 20899.

Shukri Wakid, Director

Computer Systems Laboratory

**Abstract**

This standard specifies requirements to be met by government Key
Recovery Systems. Such systems provide for the decryption of stored or
communicated data when access to the data is properly authorized.

Key words: ADP security, computer security, Key Recovery Systems,
Federal Information Processing Standard.

FIPS PUB xyz

**Federal Information**

**Processing Standards Publication xyz**

**(Date)**

**Announcing the Standard for**

**KEY RECOVERY SYSTEMS (KRS)**

Federal Information Processing Standards Publications (FIPS PUBS) are
issued by the National Institute of Standards and Technology (NIST)
after approval by the Secretary of Commerce pursuant to Section 111(d)
of the Federal Property and Administrative Services Act of 1949 as
amended by the Computer Security Act of 1987, Public Law 100‑235.

**Name of Standard**: Key Recovery Systems (KRS).

**Category of Standard**: Computer Security, Cryptography.

**Explanation**: This Standard specifies requirements for Key Recovery
Systems (KRSs). Such systems provide for the recovery of plaintext data
from stored or communicated ciphertext when cryptographic keys are not
otherwise available. Key recovery is motivated by three primary
scenarios:

1.  recovery of stored data on behalf of an organization (or individual)
    e.g., in response to accidental loss of keys

2.  recovery of communicated or stored data by lawfully authorized
    authorities

3.  recovery of stored or communicated data on behalf of an organization
    engaged in internal surveillance activities

The first scenario supports the ability to regain access to data that
would otherwise be lost. The second scenario encompasses data acquired
under the authorization of court orders for wiretaps, search and seizure
orders, civil suit subpoenas, etc. The final scenario encompasses
internal surveillance authorized by an organization.

A KRS manages cryptographic keys in support of data recovery. These
systems must be carefully designed so that plaintext may be recovered in
a timely manner, and so that only authorized recoveries are permitted.
Therefore, security is a critical factor in any KRS design.

The purpose of this standard is to specify requirements for components
of KRSs, and to enable the validation of products claiming conformance.
The standard encompasses system security (from an implementation and
operation perspective) and the availability of recovery components, and
it defines interoperability requirements.

**Approving Authority**: Secretary of Commerce.

**Maintenance Agency**: U.S. Department of Commerce, National Institute
of Standards and Technology (NIST).

**Applicability:** This standard is applicable to all Federal
departments and agencies and their contractors. This standard may be
used in designing, acquiring and implementing general encryption
products and systems that Federal departments and agencies use or
operate, or which are operated for them under contract. Products that
implement cryptography for purposes other than general encryption (e.g.,
digital signatures, password encryption, or access control techniques)
are outside the scope of this standard. To prevent the recovery of
cryptographic keys used for these other purposes, it is incumbent on the
user to ensure that different keys are used for encryption than are used
for other purposes.

This standard shall apply to systems when all of the following are true:

a.  Encryption is or will be employed to achieve the confidentiality of
    communicated or stored data.

b.  Key recovery will be employed.

c.  The data protected by encryption are not classified according to
    Executive Order 12356, entitled "National Security Information," or
    to its successor orders, or to the Atomic Energy Act of 1954,
    amended.

Systems in Federal departments or agencies that process data classified
according to either of the acts cited in \"c\" above may employ
encryption devices approved for classified data protection in order to
protect unclassified data in lieu of this standard.

This standard supersedes FIPS 185. However, products which have been
built to conform to FIPS 185 are still approved for U.S. Government use.
The SKIPJACK encryption algorithm and the Key Exchange Algorithm used by
FIPS 185 products continue to be FIPS approved.

This standard and products conforming to this standard, may be adopted
and used by non-Federal Government organizations on a voluntary basis.

**Applications:** This standard is appropriate for use in the following
applications:

1.  When computer files are encrypted for secure storage or transmission

2.  When electronic mail is encrypted before transmission among
    communicating entities

3.  When electronic voice communications are encrypted for privacy

    1.  Whenever cryptographic keys are backed-up for recovery purposes.

**Implementations**: System components, or parts thereof, conforming to
this standard may be implemented in software, firmware, hardware, or any
combination thereof. All cryptographic modules employed in components of
such systems shall comply with FIPS 140-1. FIPS approved encryption
algorithms (e.g., DES) shall be used in Federal applications of systems
conforming to this standard. The use of new encryption algorithms which
are FIPS approved after the date of the standard is also permitted.

Information about the validation of implementations conforming to this
standard may be found in Section 4 of the attached Specification.
Additional information may be obtained from the National Institute of
Standards and Technology, Information Technology Laboratory, Attn: KRS
Validation, Gaithersburg, MD 20899.

**Export Control**: Implementations of this standard are subject to
export controls as specified in Title 22, Code of Federal Regulations,
Parts 120-130 and Title 15, Code of Federal Regulations, Parts 768
through 799. Exporters are advised to contact the Department of
Commerce, Bureau of Export Administration for more information.

**Patents**: Implementations of this standard may be covered by U.S. and
foreign patents.

**Implementation Schedule:** The effective date of this standard is
\<insert date\>. From approval of this KRS FIPS by the Secretary of
Commerce to its effective date, agencies may purchase products that have
been affirmed in writing from the manufacturer as complying with this
standard. From the effective date until six months after the
establishment of the KRS validation program by NIST, agencies that have
determined a need for KRS products shall purchase products that have
been affirmed in writing by the manufacturer as complying with this
standard. A copy of the written affirmation shall have been sent to the
Director, Information Technology Laboratory, National Institute of
Standards and Technology, Gaithersburg, MD 20899.

For a one year period following the six month period after the
establishment of the KRS validation program, agencies shall purchase
validated KRS products, or products that have been submitted for KRS
validation. After this period, only KRS validated products will be
considered as meeting the provisions of this standard.

**Specifications**: Federal Information Processing Standard (FIPS xyz)
Key Recovery Systems (affixed).

**Cross Index**:

a\. FIPS PUB 46‑2, Data Encryption Standard.

b\. FIPS PUB 81, DES Modes of Operation.

c\. FIPS PUB 140‑1, Security Requirements for Cryptographic Modules.

**Glossary**: The following terms are used as defined below for purposes
of this standard: \[NOTE: THIS SECTION WILL BE REPLACED WITH THE FINAL
GLOSSARY.\]

Authorized key Key recovery either with the permission of the owner of
the data or as

recovery otherwise permitted by law.

Cryptographic Key A system consisting of key recovery agents,
subsystems, and products.

Recovery System Sometimes abbreviated as \"recovery system.\"

(KRS)

Data Voice, facsimile, computer files, electronic mail, and other stored
or communicated information.

Data recovery Decryption of encrypted data with the aid of at least one
data recovery

agent.

Decryption Transformation of ciphertext form of data to plaintext form.

Key recovery agent An organization which provides information which
facilitates key recovery.

Encryption Transformation of plaintext form of data to ciphertext form.

Interoperability The ability of products to communicate with one
another.

Key Recovery

Owner

Product An end user cryptographic device containing a mechanism which
enables key recovery.

Recovery field A field, output by the key recovery mechanism of a
product, which identifies key recovery agents and enables key recovery
agents to identify the key(s) required to decrypt corresponding
ciphertext output by the product.

Recovery subsystem The physical components of a KRS which provide for
the recovery of plaintext when legally authorized.

Registration Agent

Testing laboratory A laboratory which has been accredited by NIST to
test systems, subsystems, key recovery agents, or products for
conformance to this standard.

User

**Qualifications**: The security of a KRS is dependent on several
factors. For example, keys and other critical security parameters must
be protected from compromise; the integrity of system data must be
maintained; and denial of service attacks must be prevented. Conformance
to this standard does not assure that a particular implementation is
secure. The responsible authority in each agency or department shall
assure that an implementation provides an acceptable level of security.
This standard will be reviewed every five years in order to assess its
adequacy.

**Waiver Procedure**: Under certain exceptional circumstances, the heads
of Federal departments and agencies may approve waivers to Federal
Information Processing Standards (FIPS). The head of such agency may
redelegate such authority only to a senior official designated pursuant
to section 3506(b) of Title 44, United States Code. Waiver shall be
granted only when:

a\. Compliance with a standard would adversely affect the accomplishment
of the mission of an operator of a Federal computer system; or

b\. Cause a major adverse financial impact on the operator which is not
offset by Government wide savings.

Agency heads may act upon a written waiver request containing the
information detailed above. Agency heads may also act without a written
waiver request when they determine that conditions for meeting the
standard cannot be met. Agency heads may approve waivers only by a
written decision which explains the basis on which the agency head made
the required finding(s). A copy of each such decision, with procurement
sensitive or classified portions clearly identified, shall be sent to:
National Institute of Standards and Technology; ATTN: FIPS Waiver
Decisions, Technology Building, Room B‑154, Gaithersburg, MD 20899.

In addition, a notice of each waiver granted and each delegation of
authority to approve waivers shall be sent promptly to the Committee on
Government Operations of the House of Representatives and the Committee
on Governmental Affairs of the Senate and shall be published promptly in
the Federal Register.

When the determination on a waiver applies to the procurement of
equipment and/or services, a notice of the waiver determination must be
published in the Commerce Business Daily as a part of the notice of
solicitation for offers of an acquisition or, if the waiver
determination is made after that notice is published, by amendment to
such notice.

A copy of the waiver, any supporting documents, the document approving
the waiver and any supporting and accompanying documents, with such
deletions as the agency is authorized and decides to make under 5 U.S.C.
Sec. 552(b), shall be part of the procurement documentation and retained
by the agency.

**Where to Obtain Copies of the Standard**: Copies of this publication
are for sale by the National Technical Information Service (NTIS), U.S.
Department of Commerce, Springfield, VA 22161. When ordering, refer to
Federal Information Processing Standards Publication xyz (FIPS PUB xyz),
and identify the title. When microfiche is desired, this should be
specified. Prices are published by NTIS in current catalogs and other
issuances. Payment may be made by check, money order, deposit account or
charged to a credit card accepted by NTIS.

**1.1 OVERVIEW**

## Overview

## 

Federal Agencies have a right and a responsibility to protect the
information and data contained in, processed by, and transmitted between
their IT systems. Ownership of the information is often shared with
individuals, companies, and organizations and therefore requires that
the government protect that information on its own behalf and on behalf
of those co-owners. That protection needs to meet or exceed Federal
Government standards and the standards of those co-owners.

Protection of information on IT systems is complicated and evolving. One
aspect of such protection is the requirement that certain information or
information in specific states provide its own protection. An example of
such a state is information in transit on the Internet. The method of
such self protection is encryption, the process whereby the information
is scrambled using methods which make it easy for authorized entities to
decrypt and difficult for all others to decrypt. When sufficient
strength and protection of the decryption key is provided, encryption
can adequately protect the information from disclosure to unauthorized
parties. However, the unavailability, loss, or corruption of those keys
will prevent disclosure to authorized parties. The solution to this
problem is to provide methods of recovering decryption keys by
authorized parties.

The generation, storage, and recovery of decryption keys are complex
processes. These processes need to be rigidly defined, stringently
implemented, and conscientiously managed and operated. Such requirements
are needed to ensure that the processes provide the proposed benefits
and prevent any inappropriate increases in vulnerability. The FIPS
addresses these requirements of the encryption process, the recovery
process, and the supporting components of both processes.

The encryption process described in the FIPS includes their components,
their actions and interfaces, and the sum of their interactions. Such
components include the Encrypting Party (often the Sender of transmitted
data,) the Encrypted Data Medium, the Decrypting Party (often the
Receiver of transmitted data,) the Recovery Data Medium, and the Key
Recovery Agent. It should be noted that the preparation of recovery
information is the responsibility of the encryption process, not the
recovery process.

The recovery process described in the FIPS includes processes and
requirements for recovery requesters; structure, process and
requirements of recovery including performance of the key recovery
agents; and a description of the interactions between the parties
involved in the recovery.

The supporting components described in the FIPS are integral parts of
the key recovery process, and are needed to ensure the functionality of
the key recovery process and the security of the keys. Such supporting
components include the vendor products for the users, for the key
recovery agents, and for the requesters. They also include the
registration agent or process, the methods to authenticate the key
sources, licensing agents, and system policy authorities.

The FIPS does not require a specific process or technique or set of
processes or techniques for compliant systems. Therefore, Key Recovery
systems or Key Recovery capabilities built into existing systems need to
address interoperability, specifically between such systems and both
non-key recovery capable systems and systems using a different form of
FIPS compliant key recovery. While nothing in the FIPS precludes
interoperability between systems that did not previously interoperate,
such new functionality is not a requirement of the FIPS. (***What should
be said about the interoperability on FIPS compliant systems with each
other? Can we say anything about the interoperability with non-compliant
systems? It would be difficult to achieve and difficult to evaluate.***)

To further the understanding of the overall key recovery processes,
examples are presented to describe several general key recovery methods.
These examples illustrate key recovery methods used for Stored Files,
Encrypted Email, Real-time Communications, and the recovery of a
specific key.

NOTE: It should be noted that the output of the TACDFIPSFKMI (TAC) is
technical advice to the Secretary of Commerce regarding the technology
of and technical use of key recovery. The TAC has not addressed and will
not provide policy advice regarding the extent of usage of key recovery
on any IT systems nor the scope of systems covered by the proposed FIPS.

**1.2 Key Recovery System Model**

A key recovery system enables authorized persons to access plaintext
from encrypted data when the decryption key is not otherwise available.
Key recovery is a broad term that applies to many different techniques.

The key recovery system model defines the minimal set of system
components needed to perform key recovery. All FIPS compliant
Cryptographic Key Recovery Systems shall be mappable to the components
of this model. The key recovery system model is a generalized model that
supports a wide variety of different key recovery techniques and data
applications.

The data applications supported by the key recovery system model
include:

-   Interactive communication sessions

```{=html}
<!-- -->
```
-   Store-and-Forward applications

```{=html}
<!-- -->
```
-   Data Storage

0.  

```{=html}
<!-- -->
```
0.  The key recovery system model contains the following components, as
    a minimum:

```{=html}
<!-- -->
```
0.  

-   System A (Encryption-Enabled)

```{=html}
<!-- -->
```
-   System B (Encryption-Enabled)

```{=html}
<!-- -->
```
-   Recovery Information Medium (RIM)

```{=html}
<!-- -->
```
-   Key Recovery Requestor System (Requestor System)

```{=html}
<!-- -->
```
-   Key Recovery Agent(s)

0.  

```{=html}
<!-- -->
```
0.  The model depicts a key recovery system capable of creating key
    recovery information (KRI) for a key to be recovered, and recovering
    the key from the key recovery information.

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  1.2.1 Key Recovery Enablement Process

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  The three components \-- System A, System B and the key recovery
    information Medium \-- collectively define the \"Key Recovery
    Enablement Process\" (see Figure 1). For completeness, Figure 1 also
    includes an Encrypted Data Medium and a Key Distribution Medium. The
    Encrypted Data Medium and Key Distribution Medium are the
    "locations" where the encrypted data and data encryption key are
    stored or communicated, respectively.

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  The process of encrypting data and creating key recovery information
    is performed by one or more encryption-enabled systems, denoted in
    the key recovery system model as *System A* and *System B*. An
    *encryption-enabled* system can encrypt and decrypt data. It is
    required that System A or System B, or both Systems A and B have the
    ability to create key recovery information. However, the key
    recovery system model does not prescribe which system or systems
    must have a key recovery capability. The key recovery information
    produced by these systems is maintained on the *Recovery Information
    Medium*. The Recovery Information Medium may exist over multiple
    "locations", and may be in the same or different locations from the
    Encrypted Data and Key Distribution Mediums.

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  ![](media/image1.emf){width="5.99375in" height="3.29375in"}

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  **Figure 1: Key Recovery Enablement Process**

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  1.2.1.1 Components and Their Interactions

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  1.2.1.1.1 Systems A & B

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  Systems A and B are systems capable of communicating with each other
    using

```{=html}
<!-- -->
```
0.  encryption (i.e., they are encryption-enabled).

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  Each system contains a cryptographic application capable of
    interacting with a like cryptographic application in the other
    system. Each system contains a cryptographic subsystem that provides
    a set of encryption and decryption services to the cryptographic
    application. At least one system (A or B) must have a key recovery
    subsystem capable of providing a set of key recovery services to the
    cryptographic application which includes services for creating key
    recovery information. A system that meets this requirement is said
    to be *key recovery capable*. A system which is able to recognize
    the presence or absence of key recovery information is said to be
    *key recovery aware*. A key recovery aware system may subsequently
    either ignore the key recovery information, or process all or a part
    of the key recovery information. This standard requires that two
    systems can interoperate in compliance with the standard as long as
    at least one of the systems is key recovery capable, and both
    systems are key recovery aware.

```{=html}
<!-- -->
```
0.  

```{=html}
<!-- -->
```
0.  This standard defines two categories of key recovery systems:

```{=html}
<!-- -->
```
0.  

-   Category I: a system which is key recovery aware, and

```{=html}
<!-- -->
```
-   Category II: a system which is both key recovery capable and key
    recovery aware.

A *Category I enabled system* is a key recovery system whose processing
is enforced by a stated key recovery policy. A *Category II enabled
system* is a key recovery system whose KRI creation and processing are
enforced by a stated key recovery policy.

NOTE: In situations where it is convenient to show a directional flow of
the encrypted data, System A may be optionally labeled \"Sender\" or
\"Encryptor\" and System B may be optionally labeled \"Receiver\" or
\"Decryptor.\" However, the key recovery system model itself is intended
to be a generalized model, covering interactive sessions, where each
system may be both a sender and receiver, or both an encryptor or
decryptor.

1.2.1.1.1.1 Encryptor

The Encryptor is the system that encrypts data, either for storage or
for transmission. The Encryptor places the data encrypting key on the
Key Distribution Medium, and places the encrypted data on the Encrypted
Data Medium,.

A Key Recovery Capable Encryptor may (or may not) create key recovery
information for itself and/or its Key Recovery Agent(s), and place the
KRI on the Recovery Information Medium in order to comply with an
established key recovery policy. The key recovery policy specifies the
conditions under which key recovery information must be created; the
policy may also specify the allowable Key Recovery Agents, and how and
where the key recovery information must be maintained (stored or
transmitted). The Encryptor may also elect to create key recovery
information in situations where key recovery is deemed desirable,
although not specifically required by the Encryptor's key recovery
policy. Additionally, the Encryptor may also create key recovery
information for the Decryptor and/or the Decryptor's Key Recovery
Agent(s) in accordance with the Encryptor's key recovery policy.

1.2.1.1.1.2 Decryptor

The Decryptor is the system that decrypts data encrypted by an
Encryptor.

When key recovery information for the Decryptor is not available on the
Recovery Information Medium, a Key Recovery Capable Decryptor may create
key recovery information for itself and/or its Key Recovery Agent(s),
and place the KRI on the Recovery Information Medium in order to comply
with an established key recovery policy (see also 1.2.1.1.1.1
Encryptor). For example, the KRI may be created using the data
encrypting key on the Key Distribution Medium. The Decryptor may also
elect to create key recovery information in situations where key
recovery is deemed desirable, although not specifically required by the
Decryptor's key recovery policy. Additionally, the Decryptor may also
create key recovery information for the Encryptor and/or the Encryptor's
Key Recovery Agent(s) when the Decryptor's policy calls for it to do so.

In situations where key recovery information is received by the
Decryptor, the Decryptor (who is defined to be key recovery aware) may
also perform a verification step to validate the correctness or
integrity of the key recovery information. The verification step could
consist of checking all or part of the received key recovery
information, or any other information that could be used beneficially to
determine the correctness or integrity of the received key recovery
information. Whether the Decryptor performs such a verification step is
a function of the Decryptor's key recovery policy and the key recovery
mechanism employed.

In situations where the Decryptor creates key recovery information for
the Encryptor, the Encryptor (who is also key recovery aware) may
subsequently receive the key recovery information and perform a similar
verification step to validate the correctness or integrity of the key
recovery information. Whether the Encryptor performs such a verification
step is a function of the Encryptor's key recovery policy and the key
recovery mechanism employed.

1.2.1.1.2 Recovery Information Medium (RIM)

The Recovery Information Medium (RIM) represents the \"location(s)\"
where the key recovery information is stored or communicated, such as a
storage device or a communications channel. The key recovery system
model does not prescribe how or where the key recovery information must
be stored or communicated, so long as the Recovery Information Medium is
available.

The key recovery information itself can be managed or handled in a
variety of ways. It may exist for only a brief time during electronic
transmission, or it may exist for a relatively long time on a storage
device.

In situations where the key recovery policy of one system, say System B,
requires that it perform a verification step to validate the correctness
or integrity of the key recovery information generated by the other
system, say System A (see also 1.2.1.1.1.2), the system performing the
validation must have access to the RIM and be able to parse (understand)
the key recovery information stored or communicated on the RIM.

In order to allow interoperability between various key recovery schemes,
a standard format for key recovery information on the Recovery
Information Medium is essential. Each scheme has a distinct set of
information which must be present in order to allow key recovery. That
information shall be contained within a *Key Recovery Field* (KRF). To
ensure the integrity of the KRF, the association of the KRF with the
encrypted data, and to provide the identities of the key recovery scheme
in use and the appropriate Key Recovery Agent(s), the KRF is contained
within a *Key Recovery Block* (KRB). The Recovery Information Medium
shall contain one or more Key Recovery Blocks. The precise format of a
KRB is described in Section TBD.

1.2.1.2 Interaction Summary

The key recovery system model simultaneously embraces the following
three separate applications: (a) interactive session, (b)
store-and-forward, e.g., E-mail, and (c) data storage.

The key recovery system model embraces key recovery systems where one or
both systems have the ability to create key recovery information and
make that key recovery information available by putting it on the RIM.
The model also embraces key recovery systems where one or both systems
have the ability to validate the key recovery information created by the
other system in order to ensure that it is authentic. Table 1 identifies
the possible key recovery information creation capabilites for two
systems (A and B), where System A is the (initial) Encryptor, and System
B is the (initial) Decryptor.

**Table 1: Key Recovery Capabilities**

+---------------+---------+---------+---------------------------------+
| Capability    | System  | System  | Comment                         |
|               | A       | B       |                                 |
| Scenarios     |         |         |                                 |
|               | (I      | (I      |                                 |
| (0=No         | nitial) | nitial) |                                 |
| capability,   | En      | De      |                                 |
| 1=KR Aware,   | cryptor | cryptor |                                 |
| 2=KR Capable  |         |         |                                 |
| & Aware)      |         |         |                                 |
+---------------+---------+---------+---------------------------------+
| 0-0           | No      | No      | **Not addressed by this         |
|               | Cap     | Cap     | standard.** No key recovery     |
|               | ability | ability | information can be created.     |
+---------------+---------+---------+---------------------------------+
| 0-1           | No      | KR      | **Not addressed by this         |
|               | Cap     | Aware   | standard.** Interaction not     |
|               | ability |         | possible if System B has a key  |
|               |         |         | recovery policy for interacting |
|               |         |         | only with Key Recovery Capable  |
|               |         |         | systems. No key recovery        |
|               |         |         | information can be created.     |
+---------------+---------+---------+---------------------------------+
| 0-2           | No      | KR      | **Not addressed by this         |
|               | Cap     | Capable | standard.** Key recovery        |
|               | ability | & Aware | information created only if     |
|               |         |         | System B does so. Key recovery  |
|               |         |         | information can be created only |
|               |         |         | for System B and/or its KRA.    |
+---------------+---------+---------+---------------------------------+
| 1-0           | KR      | No      | **Not addressed by this         |
|               | Aware   | Cap     | standard.** Interaction not     |
|               |         | ability | possible if System A has a key  |
|               |         |         | recovery policy of interacting  |
|               |         |         | only with Key Recovery Capable  |
|               |         |         | systems.                        |
+---------------+---------+---------+---------------------------------+
| 1-1           | KR      | KR      | **Not addressed by this         |
|               | Aware   | Aware   | standard.** Interaction not     |
|               |         |         | possible if System A and B have |
|               |         |         | key recovery policies for       |
|               |         |         | interacting only with Key       |
|               |         |         | Recovery Capable systems. No    |
|               |         |         | key recovery information can be |
|               |         |         | created.                        |
+---------------+---------+---------+---------------------------------+
| 1-2           | KR      | KR      | Key recovery information        |
|               | Aware   | Capable | created if System B does so.    |
|               |         | & Aware | Information can be created for  |
|               |         |         | System B and/or its KRA, and    |
|               |         |         | could be created for System A   |
|               |         |         | and/or its KRA. System A may    |
|               |         |         | have the ability to validate    |
|               |         |         | the key recovery information in |
|               |         |         | a subsequent step in the        |
|               |         |         | interaction.                    |
+---------------+---------+---------+---------------------------------+
| 2-0           | KR      | No      | **Not addressed by this         |
|               | Capable | Cap     | standard.** Key recovery        |
|               | & Aware | ability | information created if System A |
|               |         |         | does so. Information can be     |
|               |         |         | created only for System A       |
|               |         |         | and/or its KRA.                 |
+---------------+---------+---------+---------------------------------+
| 2-1           | KR      | KR      | Key recovery information        |
|               | Capable | Aware   | created if System A does so.    |
|               | & Aware |         | Information can be created for  |
|               |         |         | System A and/or its KRA, and    |
|               |         |         | could be created for System B   |
|               |         |         | and/or its KRA. System B may    |
|               |         |         | have the ability to validate    |
|               |         |         | the key recovery information.   |
+---------------+---------+---------+---------------------------------+
| 2-2           | KR      | KR      | Key recovery information        |
|               | Capable | Capable | created if either system does   |
|               | & Aware | & Aware | so. Either system can create    |
|               |         |         | key recovery information for    |
|               |         |         | itself and its KRA, and could   |
|               |         |         | create key recovery information |
|               |         |         | for the other system and its    |
|               |         |         | KRA. The receiving system may   |
|               |         |         | have the ability to validate    |
|               |         |         | the key recovery information    |
+---------------+---------+---------+---------------------------------+

1.2.1.2.1 Interactive Session Example (Capability Scenarios 1-2 and 2-2)

An example of an interactive session is the case where System B is a
Category II enabled system, but System A is not. That is, System A is
either a Category I system (Key Recovery Aware only), or System A is a
Category II system (Key Recovery Capable) with a policy stating that key
recovery information is not created. System B has a key recovery policy
that states: (1) key recovery information must be created for itself for
messages both transmitted and received when that information is not
present on the Recovery Information Medium, and (2) key recovery
information must also be created for the other party whenever possible.

System A creates a data encrypting key to be used for the communication
session, uses that key to encrypt a message for System B, and places the
encrypted message on the Encrypted Data Medium (the communications
path). System A also encrypts the data encrypting key using the public
encryption key of System B, and places the encrypted key on the Key
Distribution Medium (the same communications path, in this case).

When System B determines that no key recovery information is available
for the message received from System A, System B decrypts the encrypted
key on the Key Distribution Medium (the communications path), and uses
the resulting plaintext data encrypting key to create key recovery
information for itself and/or its Key Recovery Agent. If the necessary
information is available, key recovery information is created for System
A and/or its Key Recovery Agent. All key recovery information is then
placed on the Recovery Information Medium. System B then uses the data
encrypting key to decrypt the received message (the message on the
Encrypted Data Medium).

In subsequent messages received by System A within this interactive
session, System A can process the received messages, and recognize and
perhaps perform some processing of the key recovery information on the
Recovery Information Medium.

1.2.1.2.2 Store-and-Forward Example (Capability Scenarios 2-1 and 2-2)

An example of a store-and-forward scenario is the case where System A is
Category II enabled, and System B is either Category I (Key Recovery
Aware) or Category II (Key Recovery Capable). System A has a key
recovery policy that states: (1) key recovery information must always be
created for itself and/or its Key Recovery Agent, and (2) Key recovery
Information is not created for anyone else. System B is capable of
recognizing and processing the key recovery information on the RIM, but
System B cannot create key recovery information (Key Recovery Aware
only) or has a key recovery policy for not creating key recovery
information.

System A (acting as a sender) creates a data encrypting key, uses that
key to encrypt an e-mail message and sends the encrypted message to
System B (acting as a receiver) on the communications path (the
Encrypted Data Medium). System A creates Key Recovery information for
itself and/or its Key Recovery Agent and prepends that information to
the encrypted message in the message header; key recovery information is
not created for System B. System A also encrypts the data encrypting key
using System B's public encryption key and places the encrypted key in
the header. In this case, the Recovery Information Medium and the Key
Distribution Medium use the same communications path used to transmit
the encrypted data, i.e., the Encrypted Data Medium, the Recovery
Information Medium and the Key Distribution Medium are one and the same.

Upon receipt of the encrypted message, System B recognizes and performs
some processing of the key recovery information received on the Recovery
Information Medium (the key recovery information in the header),
decrypts the data encryption key in the message header, and uses the
decrypted data encryption key to decrypt the message.

1.2.1.2.3 Data Storage Example (Capability Scenarios 2-1 and 2-2)

For data storage applications as well as for the previous examples, the
Encryptor and Decryptor may or may not be the same entity. For this
example, assume that files may be created only by a Category II enabled
system, but may be read by several entities with varying key recovery
capabilities. The file creator (System A) has an established policy of
always creating key recovery information for itself and/or its Key
Recovery Agent. The entity that reads the encrypted file (System B) can
have a key recovery policy of ignoring the presence of any key recovery
information.

System A creates a data encrypting key, uses that key to encrypt a data
file and places the encrypted file on the Encrypted Data Medium (a file
server). System A creates key recovery information which is placed on
the Recovery Information Medium (the same file server), and encrypts the
data encrypting key using an appropriate public encryption key and
places it on the Key Distribution Medium (also the same file server).

When accessing the encrypted file, System B decrypts the data encryption
key on the Key Distribution Medium, and uses the decrypted data
encryption key to decrypt the file.

1.2.2 Key Recovery Process

The Key Recovery Requestor System (Requestor System) and the Key
Recovery Agent(s) form another subportion of the key recovery system
model called the *Key* *Recovery Process* (see Figure 2).

![](media/image2.emf){width="5.99375in" height="3.9916666666666667in"}

**Figure 2: Key Recovery Process**

The process of recovering a key from the key recovery information is
handled by additional key recovery system components \-- denoted in the
key recovery system model as the *Requestor System* and *Key Recovery
Agent(s)*. An authorized requestor \-- with access to the Encrypted Data
Medium and the Recovery Information Medium \-- interacts with one or
more Key Recovery Agents using a Requestor System to recover a
cryptographic key from the key recovery information.

A recovered key can then be used to recover the data, either directly or
indirectly, using a Data Recovery System. The data encrypting key is
said to be recovered *directly* when the recovered key is the same key
that was used to encrypt the data. *Indirect* key recovery occurs when
the recovered key is a key encrypting key that is then used to decrypt
or recover the data encrypting key.

1.2.2.1 Components and Their Interactions

1.2.2.1.1 Key Recovery Requestor System (Requestor System)

The requestor is an entity who seeks to recover information that will
allow the decryption of encrypted data. To this end, the requestor uses
a Requestor System to perform key recovery; data recovery is performed
using a Data Recovery System and the recovered key. The Data Recovery
System is outside the scope of this standard.

The Requestor System must always have access to the key recovery
information corresponding to the (desired) key to be recovered. The
Requestor System interacts with one or more Key Recovery Agents \--
using that key recovery information \-- to recover a key. Many different
algorithms and procedures can be used to recover a key, depending on the
key recovery scheme used to create the key recovery information. For
example, the Requestor System might interact with one Key Recovery Agent
to recover a whole key, or the Requestor System might interact with two
or more Key Recovery Agents to recover several pieces of information
that, in turn, permit the Requestor System to recover or reconstruct the
whole key.

A request for a key recovery service, made by a requestor using a
Requestor System to a Key Recovery Agent, must be an authorized request.
In other words, the requestor and the Requestor System which issues a
request for key recovery service must have a legal and lawful right to
access the data, in whole or in part, that can be decrypted, either
directly or indirectly, using the key which is recovered from the given
set of key recovery information. Furthermore, the requestor and the
Requestor System must establish their right to access that data.

Requestors with the right to access the data \"unlocked\" by a given set
of key recovery information would include the individual or enterprise
that \"owns\" the data, and any person or party with a lawful right to
access the data, e.g., law enforcement acting under the authority of a
valid warrant or court order, or an agent acting under the authority of
another party with a right-of-access to the data.

NOTE: The functions performed by a Requestor System may be separated and
performed by two or more components, if doing so would be advantageous.
For example, it may be more cost effective for an individual or
enterprise to employ the services of a trusted third party who uses the
Requestor System on behalf of the individual or enterprise. Under such
an arrangement, the Requestor System could recover the key, which in
turn would be provided to the individual or enterprise (the requestor),
and the individual or enterprise could then recover the data using the
recovered key and the Data Recovery System.

1.2.2.1.2 Key Recovery Agent

The Key Recovery Agent is a trusted entity who performs a recovery
service in response to an authorized request made by a Requestor System
on behalf of a requestor. Before honoring such a request, the Key
Recovery Agent authenticates the Requestor System's right to receive the
requested recovery service. The recovery service consists of processing
all or part of the key recovery information provided by the Requestor
System to the Key Recovery Agent, and returning an output value to the
Requestor System.

The algorithm for processing the key recovery information is dependent
on the algorithm originally used to create the key recovery information,
i.e. it is algorithm specific. There are also many algorithms for
creating and processing the key recovery information. For example, the
output value calculated by the Key Recovery Agent could be a whole key,
or it could be a key part or piece of information that the Requestor
System will use in combination with other recovered parts or pieces of
information to reconstruct or recover the whole key.

NOTE: The present standard does not prescribe a particular algorithm or
method for creating and processing the key recovery information, or for
recovering or reconstructing the key. It is the intent of the FIPS not
to require a specific key recovery algorithm.

NOTE: It is assumed that, where necessary, the components in the key
recovery system model can make use of cryptography to protect the
secrecy and integrity of the information transmitted from one component
to another.

1.2.2.2 Interaction Summary

In a typical key recovery scenario, the requestor \-- who is provided
with, or who acquires, a set of key recovery information, and who can
establish its right to access the data \"unlocked\" by the key to be
recovered from that key recovery information -- uses the Requestor
System to send a request for key recovery service to one or more Key
Recovery Agents. With each such request, the Requestor System provides
an appropriate portion of the key recovery information to each Key
Recovery Agent, which may be all or part of the key recovery
information. The request can be transmitted using electronic or manual
means.

Before processing the key recovery service request, the Key Recovery
Agent authenticates the Requestor System\'s right to receive the
requested key recovery service. Each Key Recovery Agent processes its
respective portion of the key recovery information and constructs an
output value, which is returned to the Requestor System, either using
electronic or manual means.

If only one Key Recovery Agent is involved, the output value could be
the whole key, and the Requestor System is finished. On the other hand,
two or more Key Recovery Agents could provide key parts or pieces of
information that the Requestor System would use to reconstruct or
recover the whole key. It is also possible for multiple instances of a
single Key Recovery Agent to exist for redundancy, where any one of
these can unilaterally satisfy the request made by a Requestor System.

If the Requestor System is operated by a third party who performs a key
recovery service on behalf of some other person or party, then the
Requestor System returns the recovered key to that person or party (the
requestor).

After the Requestor System has recovered the cryptographic key from the
key recovery information, the key may be provided to a Data Recovery
System along with the encrypted data which is to be recovered in order
to obtain the plaintext data.

**1.3 Supporting Components**

Specific implementations of the Key Recovery System model may require
"supporting" components to support the interactions between the main Key
Recovery System components. This section describes these supporting
components and provides examples of how they may be used in a Key
Recovery System.

1.3.1 Product Vendors

End User Product Vendors, Key Recovery Agent Product Vendors, and
Requestor Product Vendors produce products for use in the Key Recovery
System, and provide information to the Registration Agent as necessary.

1.3.2 Registration Agent

The Registration Agent receives and archives vendor-specific information
required by the Requestor to find, acquire, and parse recovery
information obtained from the recovery information medium.

Recovery information may include the following: (1) product serial
number, (2) vendor identification number, (3) recovery fields, (4)
certificates, and (5) session information.

1.3.3 Authentic Public Key Source

In some implementations, an Authentic Public Key Source will be used to
provide a certificate infrastructure to support the use of public key
cryptography within the Key Recovery System.

In a Key Recovery System which provides Private Key Recovery-based
recovery, the Authentic Public Key Source may be very similar to a
conventional Certification Authority, but will provide for the binding
of recoverable public/private keypairs to users as shown in Figure 3.

![](media/image3.emf){width="5.990972222222222in"
height="4.165972222222222in"}

**Figure 3 Example Hierarchy in Private Key Recovery System**

In a Key Recovery System based on Key Encapsulation, the Authentic
Public Key Source may instead bind public keys to legitimate Key
Recovery Agents as shown in Figure 4.

![](media/image4.emf){width="5.990277777777778in"
height="3.6347222222222224in"}

**Figure 4 Example Hierarchies in Key Encapsulation Key Recovery
System**

1.3.4 Licensing Agent

The Licensing Agent is responsible for evaluating candidate Key Recovery
Agents for compliance to this FIPS.

1.3.5 Key Recovery System Implementation Examples

The following two sections describe two possible types of
implementations for the Key Recovery System which require the use of
supporting components. Neither example purports to be the only method of
satisfying this standard\--instead these examples are intended to
illustrate how these supporting components fit into a Key Recovery
System implementation.

1.3.5.1 Private Key Recovery Example

The core of a Private Key Recovery-based Key Recovery System is the Key
Recovery Agent(s) capability to recovery System A and System B's private
key exchange key. This example discusses component interactions for four
phases: (1) establishment, (2) normal encrypted communications, (3)
normal encrypted storage, and (4) recovery.

1.3.5.1.1 Establishment

First, the Key Recovery System's Authentic Public Key Source must
generate and securely maintain a public/private keypair. The public
portion of this keypair will be embedded or loaded into the Key Recovery
System's components. The private portion of the keypair will be used to
digitally sign component information to authorize its use in the Key
Recovery System.

To establish a Private Key Recovery-based Key Recovery System, End User
Product Vendors must describe to the Registration Agent how their
systems (A and B) deposit the key exchange field into the Encrypted Data
Medium and the Recovery Information Medium. End User Product Vendors
must also embed the Authentic Public Key Source root public key into
their systems (A and B) to enable authentication of interactions with
other Key Recovery System components.

Key Recovery Agent Product Vendors must also embed the Authentic Public
Key Source root public key into the Key Recovery Agent Product. Key
Recovery Agents must demonstrate to the Licensing Agent that they will
secure user private keys in accordance with the Key Recovery System
policy. Once approved by the Licensing Agent, the Key Recovery Agent
will be authorized via the Authentic Public Key Source. This
authorization will allow systems (A and B) and Requestors to verify the
legitimacy of a Key Recovery Agent.

Systems (A and B) make their public/private key exchange keypair
recoverable via a Key Recovery Agent prior to participating in the Key
Recovery System. Systems (A and B) can verify that they are
communicating with a legitimate Key Recovery Agent by verifying the Key
Recovery Agent information using the Authentic Public Key Source. The
Key Recovery Agent will then issue a certificate to the System (A and B)
verifying that the public/private keypair is recoverable.

1.3.5.1.2 Normal Encrypted Communications

System A provides for key recovery whenever it performs a key exchange
with System B provided System B's private key is recoverable by a Key
Recovery Agent. System A can determine if System B's private key is
recoverable by verifying System B's certificate (using the Authentic
Public Key Source root public key embedded in the product). System A
then generates the key exchange field by wrapping (encrypting) the data
encryption key with System B's public key. System A deposits the key
exchange field and key recovery information into the Recovery
Information Medium. The encrypted data to be communicated to System B is
deposited into the Encrypted Data Medium. This scenario is shown in
Figure 5.

![](media/image5.emf){width="5.990277777777778in"
height="4.065972222222222in"}

Figure 5 Private Key Recovery Example - Normal Encrypted Communications

1.3.5.1.3 Normal Encrypted Storage

System A provides for key recovery whenever it encrypts data for storage
by wrapping (encrypting) the data encryption key with its own public
key, the private portion of which is recoverable by a Key Recovery
Agent. During data encryption, System A deposits the appropriate key
recovery information into the Recovery Information Medium portion of the
storage medium (e.g. a file header). This scenario is shown in Figure 6.

![](media/image6.emf){width="5.99375in" height="4.336111111111111in"}

Figure 6 Private Key Recovery Example - Normal Encrypted Storage

1.3.5.1.4 Recovery

A properly authorized Requestor may recover the data encryption key by
first retrieving information from the Registration Agent on how the key
recovery information has been deposited in the Recovery Information
Medium. The Requestor then retrieves the key recovery information from
the Recovery Information Medium to determine the Key Recovery Agent.
Next, the Requestor retrieves the key exchange field and sends it to the
Key Recovery Agent. The Key Recovery Agent verifies the authenticity of
the request, decrypts the key exchange field using the user's
recoverable private key, and securely returns the unwrapped data
encryption key to the Requestor.

The Requestor uses the recovered data encryption key to decrypt the
encrypted data which was gathered from the Encrypted Data Medium.

1.3.5.2 Key Encapsulation Example

The core of a Key Encapsulation-based Key Recovery System is the
encapsulation (wrapping) of the data encryption key using the public key
of a legitimate Key Recovery Agent(s). This example discusses component
interactions for four phases: (1) establishment, (2) normal encrypted
communications, (3) normal encrypted storage, and (4) recovery.

1.3.5.2.1 Establishment

First, the Key Recovery System's Authentic Public Key Source must
generate and securely maintain a public/private keypair. The public
portion of this keypair will be embedded or loaded into Key Recovery
System components. The private portion of the keypair will be used to
digitally sign component information to authorize its use in the Key
Recovery System.

To establish a Key Encapsulation-based Key Recovery System, End User
Product Vendors must describe to the Registration Agent how their
systems (A and B) deposit the key exchange field into the Recovery
Information Medium. End User Product Vendors must also embed the
Authentic Public Key Source root public key into their systems (A and B)
to enable authentication of interactions with other Key Recovery System
components.

Key Recovery Agent Product Vendors must also embed the Authentic Public
Key Source root public key into the Key Recovery Agent Product. Key
Recovery Agents must demonstrate to the Licensing Agent that they will
secure their private keys in accordance with the Key Recovery System
policy. Once approved by the Licensing Agent, the Key Recovery Agent
will be authorized via the Authentic Public Key Source. This
authorization will allow systems (A and B) and Requestors to verify the
legitimacy of a Key Recovery Agent.

Systems (A and B) must load a public key from the Key Recovery Agent
prior to participating in the Key Recovery System. The Key Recovery
Agent issues a certificate to the System (A and B) verifying that the
corresponding public/private keypair may be used to encapsulate data
encryption keys for future recovery.

1.3.5.2.2 Normal Encrypted Communications

System A provides for key recovery whenever it performs a key exchange
by encapsulating the data encryption key in the public key(s) provided
by the Key Recovery Agent(s) and depositing the resulting key recovery
field(s) into the Recovery Information Medium. System B can determine if
System A has properly provided for key recovery by verifying the
integrity of the key recovery field. The encrypted data to be
communicated to System B is deposited into the Encrypted Data Medium.

Note, System A may also generate a key exchange field by wrapping the
data encryption key with System B's public key. Unlike the Private Key
Recovery example, however, the key exchange field is not deposited in
the Recovery Information Medium since it does not facilitate recovery.
This scenario is shown in Figure 7.

![](media/image7.emf){width="5.990277777777778in"
height="4.075694444444444in"}

Figure 7 Key Encapsulation Example - Normal Encrypted Communications

1.3.5.3.2 Normal Encrypted Storage

System A provides for key recovery whenever it encrypts data for storage
by wrapping (encrypting) the data encryption key with the public key(s)
provided by the Key Recovery Agent(s) and depositing the resulting key
recovery field(s) into the Recovery Information Medium. Additionally,
System A deposits the appropriate key recovery information into the
Recovery Information Medium portion of the storage medium (e.g. a file
header).

Note, System A may also generate a key exchange field by wrapping the
data encryption key with its own public key. Unlike the Private Key
Recovery example, however, the key exchange field is not deposited in
the Recovery Information Medium since it does not facilitate recovery.
This scenario is shown in Figure 8.

![](media/image8.emf){width="5.99375in" height="4.336111111111111in"}

Figure 8 Key Encapsulation Example - Normal Encrypted Storage

1.3.5.2.4 Recovery

A properly authorized Requestor may recover the data encryption key by
first retrieving information from the Registration Agent on how the key
recovery information has been deposited in the Recovery Information
Medium. The Requestor then retrieves the key recovery information from
the Recovery Information Medium to determine the Key Recovery Agent.
Next, the Requestor retrieves the key recovery field and sends it to the
Key Recovery Agent. The Key Recovery Agent verifies the authenticity of
the request, decrypts the key recovery field using the corresponding
private key, and securely returns the recovered data encryption key to
the Requestor.

The Requestor uses the recovered data encryption key to decrypt the
encrypted data which was gathered from the Encrypted Data Medium.

4.  **SYSTEM POLICY**

1.4 A Cryptographic Key Recovery System shall provide a *policy
establishment* mechanism that enables an appropriately designated
administrator to implement system policy. Each installed instance of a
CKRS should reference a system policy, but the system policy may vary
from instance to instance. At a minimum, the system policy shall define
each of the following.

1.4.1 Affected data types.

1.4.1.1 In a system comprising store data, the system policy shall
define whether or not stored data is to be made available for recovery.

1.4.1.2 In a system comprising electronic mail, the system policy shall
define whether or not electronic mail is to be made available for
recovery.

1.4.1.3 In a system comprising real-time communications, the system
policy shall define whether or not real-time communications are to be
made available for recovery.

1.4.2 Access policy.

1.4.2.1 For each affected data type for which recovery has been
selected, the system policy shall define the recovery mechanism to be
used, i.e. precisely how the key recovery is to be done -- particularly
when a variety of key recovery options are available.

1.4.2.2 For each affected data type for which recovery has been
selected, the system policy shall define what recovery agent or agents
shall be used.

1.4.2.3 For each recovery agent and affected data type selected, the
system policy shall define what requestors may recover the data.

1.4.2.4 For each requestor selected, the system policy shall define the
conditions under which each recovery agent shall make the data available
to the requestor.

1.4.2.5 For each recovery agent and affected data type, the system
policy shall define what measures are to be taken by the recovery agent
to prevent destruction of the data.

1.4.3 Data integrity policy.

1.4.3.1 For each recovery agent and affected data type, the system
policy shall define the requirements for maintaining integrity of the
data.

1.4.3.2 For each recovery agent and affected data type, the system
policy shall define whether a cryptographic "proof" of data integrity
shall be required (perhaps utilizing digital signature) and, if so, a
security confidence level for this "proof" (e.g. bit length).

1.4.3.3 For each recovery agent and affected data type, the system
policy shall define what (if any) measures are required to provide
"proof" (perhaps utilizing digital signatures verifiable by a third
party) of the source of the recovered data.

1.4.3.4 For each recovery agent and affected data type, the system
policy shall define the auditing procedures to be followed by the
recovery agent.

1.4.4 Interoperability policy.

1.4.4.1 For each affected data type, the system policy shall define what
(if any) interoperability restrictions are to be placed on the system.

1.4.4.2 For each affected data type, the system policy shall define what
(if any) interoperability conditions require a warning to the user.

**1.5 Interoperability**

# 

**Key Recovery Classifications**

> Key recovery may be broadly categorized into two types, private key
> recovery and session key recovery. Private key recovery may be
> implemented as a decryption key backup system implemented at public
> key pair, or symmetric KEK, generation time. In a public key
> cryptosystem, the KRA may optionally be specified in the user's
> encryption key certificate. When so implemented, private key recovery
> does not affect the interoperability of cryptographic applications.

Session key recovery is concerned with direct third party access to the
DEK. This is accomplished by requiring the cryptographic application to
designate the KRA as a cryptographic recipient of the encrypted data. To
recover the decrypted data, a requestor must have access to the
encrypted data and the key recovery field containing the DEK for the
data. Numerous techniques have been proposed to make session keys
recoverable. Setting aside variations specifically addressing secret
sharing, partial key escrow, timestamping, and certificates, these
techniques may be broadly categorized as algorithms which allow
authorized access to the DEK through the use of a key recovery block
within the cryptographic protocol.

**Protocol Classifications**

> The protocols which are to be session key recoverable fall broadly
> into two categories, transaction-based and session-based protocols.
> Application interoperability for the former is affected by the
> protocol's ability to support the designation of multiple
> cryptographic recipients. Insofar as the protocol supports multiple
> cryptographic recipients per transaction, a DEK wrapped for the
> designated KRA may be added without affecting interoperability. If it
> does not, then the addition of key recovery will cause recoverable and
> non-recoverable implementations to be non-interoperable.
>
> Session-based protocols exchange a session DEK during session
> initialization. The session DEK is then used to encrypt multiple PDU's
> for the duration of the session. This mode of operation is
> distinguished from transaction-based protocols which utilize a DEK for
> a single PDU. If session setup supports variable length fields during
> this initialization, a DEK wrapped for the KRA may be added without
> affecting application interoperability. If the initialization fields
> are fixed length, the addition of key recovery to these protocols will
> likely preclude interoperability with non-recoverable implementations.

**Requirements**

> **(5.1) In order to be FIPS compliant, there shall be a well-defined
> mapping from each component of the model to the implementation seeking
> certification.** Interoperability certification shall be determined
> through the interactions between the system components as defined by
> this mapping.

**(5.2)** I**nteroperable protocols which incorporate a FIPS-compliant
key-recovery mechanism must remain interoperable.** Users of FIPS
compliant implementations for the same protocol must have assurance that
these implementations will interoperate.

> **(5.7) Compliant systems which implement private key recovery shall
> not affect protocol interoperability.** **Such systems may optionally
> specify a KRA in the user certificate.** As long as the originator is
> not required to retain the ability to subsequently decipher traffic,
> there are no interoperability issues in implementing private key
> recovery within a particular protocol.

**(5.3) Multiple techniques for key recovery shall be supported by the
FIPS.** These will include both private key and session key recovery
schemes.

> **(5.4)** **Receiver verification is desirable, but shall not be
> required for compliance.** High assurance receiver verification that
> an originator is using a recoverable implementation is a stated
> objective of this FIPS. If receiver verification is mandatory, then a
> single method of verification must be defined for such verification.
> If multiple methods are allowed, two compliant implementations using
> the same protocol may be unable to communicate. Further, verification
> may be dependent upon the KR mechanism used, implying that the
> specification of a single verification method may disallow some KR
> methods. It is worth noting that a finite set of verification methods
> poses the same problem as the single method assumed.

**(5.5) When possible, the addition of compliant key recovery shall not
affect interoperability with non-recoverable implementations.** To
promote the use of FIPS compliant implementations, it is desirable for
compliant implementations to interoperate with the existing installed
base.

**(5.11) The recovery request itself shall utilize FIPS-compliant key
recovery system.** To provide a means to monitor rogue KRR's and/or
KRA's it is necessary to incorporate compliant mechanisms for KRR to KRA
communications.

# **FIPS Interoperability Working Group #5**

**Overview**

> The scope of this section is limited to discussion of issues related
> to the interoperability of key recoverable implementations within
> standards-based secure protocols. Although the addition of key
> recovery to a non-standard protocol should ideally maintain
> interoperability, the associated design decisions are assumed to be
> the purview of the individual product vendors.
>
> For the purposes of this section of the FIPS, two areas of
> interoperability are addressed. The first concerns the
> interoperability of individual protocols with, and without, the
> addition of FIPS-compliant key recovery. In particular, it is a
> requirement that compliant implementations of each protocol
> interoperate. To promote the use of this FIPS, the interoperability of
> recovery-enabled and non-recovery-enabled implementations is also at
> issue.
>
> A second area of interoperability to be addressed concerns the
> interoperability between a KRR and a KRA. To facilitate the
> verification and service of key recovery requests, an electronic
> protocol for servicing these requests must be defined. Given the
> nature of these requests, a secure messaging protocol is appropriate
> for these transactions.

**Interoperability Components**

> In order to certify interoperability, it is necessary to descibe the
> issues previously discussed within the framework of the Key Recovery
> FIPS Model. Interoperability can then be defined by the component
> interactions within this model which consists of the:

-   Key Recovery Requestor

```{=html}
<!-- -->
```
-   Key Recovery Agent

```{=html}
<!-- -->
```
-   Key Recovery Medium

```{=html}
<!-- -->
```
-   Data Recovery Medium

> Interoperability between the KRR and a specific KRA is only an issue
> for electronic service requests and responses. These secure
> transactions may be sent using any of a variety of standard
> transaction-based security protocols. Interoperability compliance is
> determined by the ability of the KRR and KRA to process these
> transactions.
>
> At the protocol level there are should be no interoperability issues
> associated with private key recoverable schemes. This is attributable
> to the fact that when using private key recovery, the KRM and the DRM
> are entirely separate. Thus the addition of KR to the protocol has no
> effect at runtime.
>
> Conversely, session key recovery implies that the KRM and the DRM are
> the same. As a result the addition of session key recovery may pose
> interoperability issues with the protocol.

**Interoperability Requirements**

**5.1 An algorithm-independent secure Multipurpose Internet Mail
Extensions (MIME) format shall be utilized for electronic KRR to KRA
exchanges.** These transactions shall be cryptographically secured with
an assurance commensurate with the cryptosystem being recovered.
Compliant systems may choose from multiple well defined MIME formats.
These include the S/MIMEv3, PGP-MIME, and MOSS formats.

**5.2 A key recovery request shall include the following:**

-   **originator identiy**

```{=html}
<!-- -->
```
-   **recipient identity**

```{=html}
<!-- -->
```
-   **current date and time**

```{=html}
<!-- -->
```
-   **date and time of key/data capture**

**5.3 A key recovery response shall include the following:**

-   **KRA identiy**

```{=html}
<!-- -->
```
-   **KRR identity**

```{=html}
<!-- -->
```
-   **current date and time**

```{=html}
<!-- -->
```
-   **date and time of key/data recovery**

```{=html}
<!-- -->
```
-   **requested key/data**

***[APPENDIX]{.underline}***

***Interoperability of Non-Key-Recoverable and Key-Recoverable
Systems***

> The interoperability of a non-key-recoverable product with a
> key-recoverable one appears to depend not so much on the key-recovery
> technique, as on whether or not there is a DRF or space for the
> addition of a KRF. If the session-based system uses a
> session-establishment protocol that ignores additional fields, then
> this is not an issue. However, for those products designed for a
> specific number of messages to be exchanged, often with a fixed
> length, the addition of a DRF received from a key-recoverable product
> will break interoperability. For these products, choosing a
> key-recovery technique that does not use a DRF may preserve
> interoperability.
>
> As a simple example, suppose two secure voice products each have fixed
> RSA private/public key pairs. Each generates a random number and
> exchanges it encrypted with the other's public key. Each decrypts the
> other's random number using its own private key and forms the session
> key by combining the two random numbers. If these products were
> modified to escrow the private keys, then with a recording of the key
> exchange, a KRA could form the session key. The addition of this
> key-recovery method does not use a DRF, and will not prevent a product
> whose private key is not escrowed from interoperating with a product
> whose private key is escrowed.

***Interoperability of Different Key-Recovery Techniques***

> Whether or not two session-based systems will interoperate when each
> has implemented a different key-recovery technique depends on the
> techniques chosen and the key-exchange protocol design.
>
> One example would be the case of a system that used a DRF and one that
> did not, with the further stipulation that each used the same basic
> key exchange. As a simple illustration, consider products A and B that
> each have a fixed RSA private-public key pair and use a
> session-establishment protocol, such that the one initiating the
> secure session generates a random session key and sends it to the
> other, encrypted with the other's public key. Product A sends no DRF,
> but can tolerate receiving one, and ignores it. Product A has escrowed
> its private key. Product B, on the other hand, has not escrowed its
> private key, but when it generates the session key, sends it encrypted
> with A's public key and sends a DRF containing the session key
> encrypted with product B's KRA's public key. Designed in this manner,
> A and B will interoperate with two different key-recovery techniques.
>
> Since this type of solution depends on an underlying key exchange
> protocol, and since so many exist for session-based systems, one could
> imagine a different key-recovery solution for each. Moreover, some key
> exchange protocols are expressly designed to build in key recovery
> with various properties.

## S/MIME

> The Secure MIME (S/MIME) protocol provides encryption for Internet
> electronic mail that uses the MIME encoding format. S/MIME defines two
> security wrappers: one for digital signatures and one for encryption.
> To encrypt and sign a message, both wrappers are applied. Both of
> these wrappers build on the formats defined in PKCS#7 version 1.5. For
> encryption, the EnvelopedData wrapper is used. The EnvelopedData
> wrapper requires RSA key management, and the RSA public keys must be
> carried in certificates.
>
> S/MIME does not include a location that can be used to carry a key
> recovery field. However, the key recovery center could be a recipient
> on every message, even if the message is not delivered to the key
> recovery center. In this way, the key recovery center private key can
> be used to recover the message plaintext content.
>
> Key recovery may also be done as part of certificate management. This
> technique only works if the originator is a recipient of the message.
> That is, a RecipientInfo field for the originator must be included to
> ensure that the key used to encrypt the message content is available
> to the key recovery center who holds a copy of the originator's RSA
> private key.

## MSP

> The Message Security Protocol (MSP) provides encryption for Internet
> and X.400 electronic mail. MSP is used in the Defense Message System,
> and MSP is specified in SDN.701. Like S/MIME, MSP supports both
> digital signatures and encryption; however, MSP defines one wrapper to
> provide both services. MSP is algorithm independent.
>
> MSP includes two locations that could be used to carry a key recovery
> field: the token and the extensions. To carry a key recovery field in
> the token, a separate object identifier for a new key management
> technique must be assigned. This approach would destroy
> interoperability with existing implementations. To carry a key
> recovery field in the extensions, a non-critical extension is added to
> the end of the message. MSP does not encrypt the extensions; therefore
> a key recovery field carried in an extension would be accessible.
>
> Alternatively, the key recovery center could be a recipient on every
> message, even if the message is not delivered to the key recovery
> center. In this way, the key recovery center private key can be used
> to recover the message plaintext content.
>
> Key recovery may also be done as part of certificate management. MSP
> includes a token for the originator. If the mail transfer system is
> unable to deliver the MSP protected message and returns the message to
> the originator as part of non-delivery notification, this token allows
> the originator to decrypt the message to determine which one was
> returned. If the key recovery center holds a copy of the originator's
> private key, then the key recovery center can also use the originator
> token to decrypt the message content.

## PEM

> The Privacy Enhanced Mail (PEM) protocol provides encryption for
> Internet electronic. PEM defines one encapsulation mechanism one for
> digital signatures and encryption. PEM is defined in Internet RFCs
> 1421 through 1424. Two forms of key management are supported for
> encryption: RSA key management using certificates and out-of-band
> distribution of symmetric key encryption keys.
>
> PEM includes one location that could be used to carry a key recovery
> field: the Key-Info header line. This header line is used for both
> forms of key management. To carry a key recovery field in the Key-Info
> line, a separate Date Encryption Key protection algorithm identifier
> must be assigned. This approach would destroy interoperability with
> existing implementations.
>
> Key recovery may also be done as part of certificate management. RFC
> 1421 recommends that a Key-Info header line be included for the
> originator as well as each recipient. This technique only works if the
> originator Key-Info header line is included. That is, a Key-Info
> header line for the originator must be included to ensure that the key
> used to encrypt the message content is available to the key recovery
> center who holds a copy of the originator's RSA private key. RFC 1424
> specifies the certificate management for PEM, and a single RSA key is
> used for key management and digital signature. Thus, this form of key
> recovery permits a malicious key recovery center to masquerade as the
> originator by generating signed PEM messages. These unauthorized
> messages could also be encrypted.

***ISAKMP \-- Work in progress by the Key Recovery Alliance***

> Both items below are the product of work-in-progress by the KRA
> technical WG. Please treat them with the appropriate sensitivity.
>
> *KRA members*
>
> Enclosed below is my updated proposal for providing key recovery in
> ISAKMP. I believe this will work from a protocol standpoint. However,
> we need to work with the IETF reps in our respective companies so that
> they can lobby the ISAKMP authors to meet our requirements.
>
> Proposed ISAKMP key recovery approach
>
> 5-14-97: Initial version
>
> 5-30-97: Updated to reduce Phase 1/2 confusion
>
> **1. PURPOSE**
>
> This technical note proposes a scheme for inserting a key recovery
> block (KRB) into the Internet Security Association Key Management
> Protocol (ISAKMP).
>
> **2. OVERVIEW**
>
> The requirements for the key recovery approach are that it MUST:

-   Comply with Government requirements for recovery, including tamper
    resistance.

```{=html}
<!-- -->
```
-   Allow interoperation of products from different vendors which have
    implemented different key recovery infrastructures.

```{=html}
<!-- -->
```
-   Allow a smooth migration from non-key recovery to key recovery such
    that products that implement key recovery can interoperate with
    products that do not implement key recovery.

> Three approaches were considered.

-   *Approach 1*: Give the recovery center your secret portion of the
    Diffie Hellman exchange. This approach was rejected because it does
    not work with the key recovery approaches already developed by some
    vendors. In addition, it gives the Government access to the
    authentication keys in addition to the encryption keys.

```{=html}
<!-- -->
```
-   *Approach 2*: Create a new ISAKMP exchange type. This approach was
    rejected because it fails to meet requirement 3 above. In addition,
    the political climate within the IETF makes it unlikely that this
    approach would make it through the standards process.

```{=html}
<!-- -->
```
-   *Approach 3*: Notification message. This approach is presented
    below. It minimizes the impact on ISAKMP specifications while
    meeting other requirements.

> The notification message approach uses the ISAKMP Header commit bit to
> prevent the use of keying material until the KRB has been received and
> validated by the peer ISAKMP implementation.
>
> The approach places a KRB into the Notification Data field of the
> Notification Payload. This information is authenticated by the
> authentication key (SKEYID_a) for the ISAKMP SA. This makes the
> approach tamper resistant.
>
> The details of the approach are presented in the following section.
>
> **3. DETAILED DISCUSSION**
>
> This section provides a detailed discussion of key recovery within the
> ISAKMP. It provides background on ISAKMP, discusses the
> sender/receiver packet processing and the packet contents.
>
> The ISAKMP specification is still an Internet draft. The latest
> version of this document may be obtained from
>
> http://www.ietf.cnri.reston.va.us/ids.by.wg/ipsec.html
>
> Much of the information in this section is taken directly from the
> February 21, 1997, version of the spec.
>
> The ISAKMP specification defines the following five exchange types.

-   Base exchange

```{=html}
<!-- -->
```
-   Identify Protection exchange

```{=html}
<!-- -->
```
-   Authentication Only exchange

```{=html}
<!-- -->
```
-   Aggressive exchange

```{=html}
<!-- -->
```
-   Informational exchange

> Key recovery information will be sent in the informational exchange.
>
> The ISAKMP supports the use of a commit flag bit which is carried in
> the ISAKMP header. When the commit bit is set it tells the receiver
> not to use the associated key in an IPSEC SA until the side setting
> the commit bit sends a \"connected\" notify message. This notify
> message is carried within the notification payload of the
> informational exchange.
>
> This bit was intended to give an ISAKMP/IPSEC device time to complete
> ISAKMP processing and move the key to the IPSEC engine before
> encrypted packets were sent. This can also be used to prevent the
> other device from using a key until the KRB has been transmitted.
>
> The commit flag is reset by sending the \"connected\" notify message.
> This message is protected by a keyed hash which uses a derivative of
> the pairwise key created during the key exchange. This keyed hash will
> be calculated over the KRB to provide tamper resistance.
>
> The typical KRB processing is outlined below. For this example assume
> the initiator is required to perform key recovery. The key recovery
> actions could be performed by the initiator, responder, or both.

1.  The ISAKMP Phase 1 exchange is performed as normal.

```{=html}
<!-- -->
```
1.  The initiator of the Phase 2 exchange sets the commit flag in the
    ISAKMP Header (HDR) sent at the start of the OAKLEY quick mode
    exchange. (The responder could also set the commit bit in the packet
    sent from responder to initiator.)

```{=html}
<!-- -->
```
1.  The exchange is completed and the key for IPSEC ESP is produced
    along with other keying material. The associated IPSEC SA cannot be
    used yet.

```{=html}
<!-- -->
```
1.  The initiator prepares the key recovery block and notification
    payload.

-   The inner contents of the key recovery block (KRB) are vendor
    specific but the outermost fields contain common information such as
    the ID of the key recovery agent. (Sarbari Gupta is developing the
    block format.)

```{=html}
<!-- -->
```
-   The type and length fields are prepended to the KRB. The type field
    is an IANA registered number indicating \"additional key management
    information.\"

```{=html}
<!-- -->
```
-   The key recovery block is placed into the Notification Data field of
    a notification payload. The notify message type is set to 16384
    (connected).

```{=html}
<!-- -->
```
-   The remainder of the notification payload fields are filled in just
    as they would be for a normal connected notification.

1.  The initiator computes the HASH over the notification payload per
    the ISAKMP spec. i.e., Hash=prf(SKEYID_a, M-ID, NOTIFY)

```{=html}
<!-- -->
```
1.  The initiator sends the authenticated (but NOT encrypted) packet to
    the responder. The packet has the form HDR, HASH, NOTIFY. The
    detailed structure of this packet is shown below.

> 1 2 3
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
> ISAKMP header
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Initiator !
>
> ! Cookie !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Responder !
>
> ! Cookie !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
>
> ! HASH = 8 ! ! ! INFORMATIONAL ! COMMIT = 0 !
>
> ! ! ! ! = 5 ! ENCRYPTION =0 !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Message ID !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Length !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Hash payload
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Next Payload ! RESERVED ! Payload Length !
>
> ! NOTIFY = 11 ! ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! !
>
> \~ Hash Data \~
>
> ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Notification payload
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Next Payload ! RESERVED ! Payload Length !
>
> ! NONE = 0 ! ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Domain of Interpretation (DOI) !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Protocol-ID ! SPI Size ! Notify Message Type !
>
> ! ! ! CONNECTED = 16384 !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! !
>
> \~ Security Parameter Index (SPI) \~
>
> ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ! Notification Data !
>
> ! Type ! Length !
>
> ! additional key management ! !
>
> ! information = TBD ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> \~ Key Recovery Block \~
>
> ! !
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Informational exchange carrying a key recovery block
>
> The responder processes the informational exchange as follows.

1.  The standard informational exchange processing steps such as
    checking the ISAKMP header fields is performed.

```{=html}
<!-- -->
```
1.  The hash functions are performed as described in ISAKMP and Oakley.
    This validates the contents of the notification payload.

```{=html}
<!-- -->
```
1.  The notification payload is processed.

-   The connected (16384) is acknowledged by resetting the local commit
    flag.

```{=html}
<!-- -->
```
-   The notification data type is examined and found to be \"additional
    key management information.\" The responder does not process this,
    and silently discards it.

> The ISAKMP exchange is now complete, and the key for IPSEC ESP is
> placed into the IPSEC engine.
>
> There are several issues with this approach that must be worked out
> with the authors of the ISAKMP spec. (Unfortunately three of the
> authors are from the Government and the fourth is from Terisa Systems.
> None are members of the key recovery alliance.) These issues are
> identified in the summary.
>
> **4. SUMMARY**
>
> The KRA technical committee needs to provide feedback on this approach
> and determine if it is acceptable. If it is, we must work the
> following issues:

1.  Work with IANA to reserve the required number for the ISAKMP
    notification data type = \"additional key management information.\"
    This number will inform the receiving ISAKMP implementation and law
    enforcement that the key material has been placed on the wire in a
    KRB.

```{=html}
<!-- -->
```
1.  We must also work with the ISAKMP authors to ensure that the
    specification supports this approach. Specific allowances that need
    to be written into the spec are:

-   Implementations MUST accept notification payloads which are not
    encrypted even if an ISAKMP SA has been established. Subsection 4.8
    of the February 21, 1997 spec states \"Once an ISAKMP SA has been
    established, the Informational Exchange MUST be transmitted under
    the protection provided by the ISAKMP SA.\" We can argue that we are
    protecting the integrity but not the confidentiality using the
    ISAKMP SA. Daniel Harkins, an ISAKMP author, agrees that integrity
    is required. We must convince the ISAKMP authors that informational
    exchanges which are authenticated but not encrypted should be
    accepted.

```{=html}
<!-- -->
```
-   Implementation MUST silently discard Notification Data contained in
    a Notification Payload if the Notification Data type is not
    recognized; i.e., when an ISAKMP implementation receives
    notification data of type \"additional key management information,\"
    it discards it.

```{=html}
<!-- -->
```
-   The commit bit MAY be set by either or both parties in an ISAKMP
    exchange.

> If we can resolve these issues, we have a reasonable approach for key
> recovery in ISAKMP.
>
> **IP Security (IPSec)**

-   IP Security Architecture

```{=html}
<!-- -->
```
-   RFC 1825 (August 95)

```{=html}
<!-- -->
```
-   Defines two mechanisms for cryptographic protection of IP datagrams

```{=html}
<!-- -->
```
-   Authentication Header (AH)

```{=html}
<!-- -->
```
-   RFC 1826 (August 95)

```{=html}
<!-- -->
```
-   Integrity and authentication without confidentiality for IP
    datagrams

> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| AUTH-HDR \| UPPER-PROTOCOL \|
>
> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> **IPSec (Cont'd)**

-   Encapsulating Security Payload (ESP)

```{=html}
<!-- -->
```
-   RFC 1827 (August 95)

```{=html}
<!-- -->
```
-   Integrity, authentication, and confidentiality for IP datagrams

```{=html}
<!-- -->
```
-   Alone, in combo with AH, or nested

```{=html}
<!-- -->
```
-   Host-host, GW-GW, host-GW

```{=html}
<!-- -->
```
-   Two modes:

```{=html}
<!-- -->
```
-   Tunnel mode

> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| PROTECTED-IP-DATAGRAM \|
>
> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+

-   Transport mode

> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| ESP-HDR \| PROTECTED-UPPER-PROTOCOL \|
>
> +\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> **IPSec Revisions**

-   New Internet Drafts

```{=html}
<!-- -->
```
-   draft-ietf-ipsec-arch-sec-01.txt (??)

```{=html}
<!-- -->
```
-   draft-ietf-ipsec-esp-v2-00.txt (July 97)

```{=html}
<!-- -->
```
-   draft-ietf-ipsec-auth-header-01.txt (July 97)

```{=html}
<!-- -->
```
-   New ESP Draft

```{=html}
<!-- -->
```
-   More complete framework/context for ESP

```{=html}
<!-- -->
```
-   Define fields previously defined in transform docs

```{=html}
<!-- -->
```
-   I.e., authentication (and anti-replay) information (optional),
    padding, and next protocol

```{=html}
<!-- -->
```
-   Minimize combinatorial explosion of transforms

```{=html}
<!-- -->
```
-   Little-to-no impact on key recovery approach Key Recovery Header
    (KRH)

```{=html}
<!-- -->
```
-   New, third mechanism for key recovery

```{=html}
<!-- -->
```
-   MAY follow AH and MUST precede ESP header

```{=html}
<!-- -->
```
-   MAY be in an authenticated packet with critical Upper Protocol
    information

```{=html}
<!-- -->
```
-   Requires IP Protocol Number from IANA

> +\-\-\-\-\-\-\--+\-\-\--+\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| IP-HDR \| AH \| KRH \| ESP-HDR \| PROTECTED-UPPER-PROTOCOL \|
>
> +\-\-\-\-\-\-\--+\-\-\--+\-\-\-\--+\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \^\^\^\^\^
>
> **KRH Format**

-   Modeled after Authentication Header (AH)

> +\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| Next Header \| Length \| RESERVED \|
>
> +\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| Security Parameter Index \|
>
> +\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\-\--+\-\-\-\-\-\-\-\-\-\-\-\--+
>
> \| \|
>
> \+ Key Recovery Block (variable number of 32-bit words) +
>
> \| \|
>
> +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--+
>
> **KRH Fields**

-   Next Header

```{=html}
<!-- -->
```
-   8 bits; identifies next payload after KRH; values are set of IP
    Protocol Numbers defined by IANA in STD-2

```{=html}
<!-- -->
```
-   Length

```{=html}
<!-- -->
```
-   8 bits; length of KRB in 32-bit words

```{=html}
<!-- -->
```
-   Security Parameter Index (SPI)

```{=html}
<!-- -->
```
-   32 bits; identifies, along with Destination Address (DA), Security
    Association (SA) for datagram; values 1-255 reserved by IANA for
    future use

```{=html}
<!-- -->
```
-   Key Recovery Block (KRB)

```{=html}
<!-- -->
```
-   variable (32-bit words); key recovery information using Common Key
    Recovery Block format; padding issues

> **FIPS GLOSSARY**

Note: The definitions in italics are made up. Those in normal font are
from various sources, including our "document". Bolded text indicates
changes from the previous version.

  ----------------------- -----------------------------------------------------
  **TERM**                **DEFINITION**

  Assurance               \(1\) Confidence that an entity meets its security
                          objectives. (2) The degree of confidence that a
                          product correctly implements the security policy.

  Authentic Public Key    Used to provide a certificate infrastructure to
  Source                  support the use of public key cryptography within the
                          Key Recovery System.

  Authorized key recovery Key recovery either with the permission of the owner
                          of the data or as otherwise permitted by law.

  Authorized Request      A request based on a legal and lawful right for
                          access.

  **Category I Enabled    **A Category I Key Recovery System whose key recovery
  System**                information processing is enforced by a stated key
                          recovery policy.**

  **Category II Enabled   **A Category II Key Recovery System whose key
  System**                recovery information creation and processing is
                          enforced by a stated key recovery policy.**

  **Category I Key        **A system which is Key Recovery Aware only.**
  Recovery System**       

  **Category II Key       **A system which is Key Recovery Capable and Key
  Recovery System**       Recovery Aware.**

  Common Criteria (CC)    **An international standard for security in
                          information security products.**

  Common Criteria         A predefined set of assurance components that
  Evaluation Assurance    represents a point on the CC assurance scale.
  Level (EAL)             

  Common Criteria         An implementation-independent set of security
  Protection Profile      requirements for a category of products which meet
                          specific consumer needs.

  Confidentiality         \(1\) Assurance that the information is not disclosed
                          to unauthorized entities or processes. (2) The
                          property that sensitive information is not disclosed
                          to unauthorized individuals, entities or processes.
                          (3) The property that information is not made
                          available or disclosed to an unauthorized user,
                          process or object.

  Configurable Capability A capability which is available but need not be
                          selected for use.

  Configuration Item      Items (e.g., documents, software, hardware) which are
                          under configuration control.

  Configuration           **The management of security features and assurances
  Management (CM)         through the control of changes made to a system's
                          hardware, software, firmware, documentaton set, test,
                          test fixtures and test documentation throughout the
                          development and operational life of the system.**

  Cryptographic Key       A system consisting of key recovery agents,
  Recovery System (CKRS)  subsystems, and products. Sometimes abbreviated as
                          \"recovery system.\"

  Cryptographic subsystem Provides a set of cryptographic services (e.g.,
                          encryption and decryption) to an application.

  Data                    Voice, facsimile, computer files, electronic mail,
                          and other stored or communicated information.

  Data Encryption Key     A symmetric key used to encrypt data.
  (DEK)                   

  Data recovery           Decryption of encrypted data with the aid of at least
                          one data recovery agent.

  Data Recovery Field     Change to Key Recovery Field.
  (DRF)                   

  Data Recovery System    *The system/subsystem used to recover encrypted data
                          using a recovered key obtained by the Key Recovery
                          Requestor System.*

  Decryption              \(1\) Transformation of ciphertext form of data to
                          plaintext form. (2) The process of changing
                          ciphertext into plaintext.

  Encrypted Data Medium   "Location" where the encrypted data is stored or
                          communicated (e.g., storage device or communications
                          channel).

  Encryption              \(1\) Transformation of plaintext form of data to
                          ciphertext form. (2) A process of transforming
                          plaintext into ciphertext for the purpose of security
                          or privacy. (3) Transforming text into code in order
                          to conceal its meaning. The process of transforming
                          data to an unintelligible form in such a way that the
                          original data either cannot be obtained (one-way
                          encryption), or cannot be obtained without using the
                          inverse decryption process. (3) Conversion of
                          plaintext to ciphertext through the use of a
                          cryptographic algorithm.

  Encryption-enabled      \(1\) Able to encrypt and decrypt information

  FIPS compliant          *Meeting all requirements of the FIPS for a given
                          tier.*

  Flaw Hypothesis         **A system analysis and penetration technique in
                          which specifications and documentation for the system
                          are analyzed, and flaws in the system are
                          hypothesized.**

  Flaw Remediation        **The correction of discovered security flaws in a
                          product or system.**

  Functional Requirements A high level description of the requirements for a
                          system.

  Functional              High level description of the user-visible interface
  Specification           and behavior of a system.

  Implementation          **A description of the implementation (e.g., source
  Representation          code when the implementation is software or firmware;
                          or drawings and schematics, if the system is
                          hardware).**

  Independent Testing     **Testing performed by persons other than the
                          developers.**

  Informal Security       **An accurate and concise statement of system
  Policy Model            security policy expressed informally (i.e., in
                          natural language; e.g., English).**

  Informal                \(1\) Expressed in natural language. (2) Written as
                          prose in natural language.

  Informal                
  style/presentation      

  Integrity               The property that sensitive data has not been
                          modified or deleted in an unauthorized and undetected
                          manner.

  Interactive             
  communication           

  Interoperability        The ability of products to communicate with one
                          another.

  Key Encapsulation       *The encryption of one cryptographic key by another
                          key. See "Wrap".*

  Key Encryption Key      A key used to encrypt another key.
  (KEK)                   

  Key Escrow              \(1\) The processes of managing (e.g., generating,
                          storing, transferring, auditing) **the cryptographic
                          keys or key components by one or more entities.**

  Key Exchange Field      

  Key-recoverable Product **An encryption product whose encryption output is
                          recoverable through key recovery.**

  Key Recovery            Access to information sufficient to recover encrypted
                          data.

  Key Recovery Agent      \(1\) An organization which provides information
  (KRA)                   which facilitates key recovery. (2) A trusted entity
                          which possesses information that can be used either
                          directly or with other information to recover a key.

  Key Recovery Aware      ***A system which is able to recognize the presence
                          or absence of key recovery information on the
                          Recovery Information Medium. Note that the system may
                          subsequently either ignore the key recovery
                          information, or process all or part of the key
                          recovery information.***

  Key Recovery Capable    ***A system which is able to create key recovery
                          information.***

  Key Recovery Enabled    ***A Category I or Category II key recovery system
                          whose key recovery information creation and/or
                          processing is enforced by a stated key recovery
                          policy.***

  Key Recovery Field      ***Key recovery information which is specific to a
  (KRF)                   single key recovery scheme.***

  Key Recovery            ***Information created by a Key Recovery capable
  Information (KRI)       system that will allow the recovery of a key.***

  Key Recovery Block      ***A stream of bytes that serves as a container for a
  (KRB)                   single key recovery scheme-specific KRF and
                          associates the KRF with a set of standard fields in a
                          predefined format.***

  Key recovery policy     A policy which specifies the conditions under which
                          key recovery information must be created and
                          conditions under **which and to whom the key recovery
                          information may be released**; may also indicate the
                          allowable Key Recovery Agent(s) and how or where key
                          recovery information must be maintained.

  Key Recovery Requestor  *The system/subsystem used by the requestor to
  System                  request keys.*

  Key Recovery Service    

  Key Recovery System     ***Includes software, hardware, procedures and
  (KRS)                   infrastructur[e]{.mark}**[.]{.mark}*

  KR-aware                **See Key Recovery Aware.**

  **KR-capable**          **See Key Recovery Capable.**

  KR-enabled              **See Key Recovery Enabled.**

  KRR                     Key Recovery Requestor.

  Least Abstract          **The most concrete representation of an
  Representation          implementation (e.g., source code).**

  Licensing Agent         *Authorizes Key Recovery Agents after an evaluation
                          against the FIPS.*

  Masquerading            **An attempt to gain access to a system by posing as
                          an authorized user.**

  Message Security        **A data format that cryptographically binds data
  Protocol (MSP)          sensitivity and provides public key cryptography
                          based security services for the data, including
                          confidentiality, integrity, etc.**

  MIME                    **Multipurpose Internet Mail Extension**

  Non-key-recoverable     **An encryption product whose encryption output is
  Product                 not recoverable through key recovery.**

  Partial Key Escrow      

  Presentation of         
  Evidence                

  Privacy Enhanced Mail   Communications protocol defined in RFCs 1421 through
                          1424.

  Private Key             \(1\) In an asymmetric (public) key cryptosystem,
                          that key of an entity's key pair which is known only
                          by that entity. (2) A cryptographic key used with a
                          public key cryptographic algorithm, uniquely
                          associated with an entity, and not made public.

  Private Key Recovery    *A Key Recovery technique which is used to recover
                          the private key of a public key pair or the secret
                          key used with a symmetric encryption algorithm*.

  Public Key              \(1\) In an asymmetric key system, that key of an
                          entity's key pair which is publicly known. (2) A
                          cryptographic key used with a public key
                          cryptographic algorithm, uniquely associated with an
                          entity, and which may be made public.

  Receiver Verification   The ability of a recipient's implementation to
                          verify, with high assurance, that the originating
                          implementation has implemented FIPS compliant
                          recovery.

  Recovery-aware          See Key Recovery Aware.

  Recovery-enabled        See Key Recovery Enabled.

  Recovery Field          A field, output by the key recovery mechanism of a
                          product, which identifies key recovery agents and
                          enables key recovery agents to identify the key(s)
                          required to decrypt corresponding ciphertext output
                          by the product. **Note that this definition may
                          currently be different from the definition for "Key
                          Recovery Field" .**

  Recovery Information    See Key Recovery Information.

  Recovery Information    "Location" where the key recovery information is
  Medium (RIM)            stored or communicated (e.g., storage device or
                          communications channel). **The RIM contains the key
                          recovery information.**

  Recovery subsystem      The physical components of a CKRS which provide for
                          the recovery of plaintext when legally authorized.

  Registration Agent      Archives vendor-specific information in order to
                          find, acquire and parse recovery information.

  Representation          **An accurate and complete mapping from a higher
  Correspondence          level representation to a lower level representation
                          (e.g., from functional requirements to a functional
                          specification, from a functional specification to a
                          high level design, from a high level design to a low
                          level design, from a low level design to source code,
                          etc.).**

  Secret Key              A cryptographic key used with a secret key
                          \[symmetric\] cryptographic algorithm, uniquely
                          associated with one or more entities, and which shall
                          not be made public.

  Requestor               An entity that seeks to recover keys that will allow
                          the decryption of encrypted data.

  Secret Sharing          

  Security Policy         \(1\) A precise specification of the security rules
                          under which a cryptographic module may operate,
                          including the security rules derived from the
                          requirements of this standard and the additional
                          security rules imposed by the manufacturer. (2) A set
                          of rules and procedures regulating the use of
                          information including its processing, storage,
                          distribution and presentation.

  Security Policy         
  Enforcing Subsystem     

  Security Policy Model   A formal representation of the security policy
                          enforced by the product.

  Session-based Protocols 

  Session-establishment   
  Protocol                

  Session Key             *A key that is used to encrypt and/or decrypt data
                          for a single communications session.*

  Session Key Recovery    Recovery of the Data Encryption Key.

  S/MIME                  Secure MIME

  Store-and-forward       
  Communications          

  **System**              ***Includes software, hardware, procedures.***

  Testing laboratory      A laboratory which has been accredited by NIST to
                          test systems, subsystems, key recovery agents, or
                          products for conformance to this standard.

  Transaction-based       
  Protocols               

  Trusted Third Party     *An entity which is trusted by the parties performing
                          the encryption or decryption processes, but are not
                          identical with those parties.*

  Unwrap                  *Decryption of an encrypted key by another key.*

  Vulnerability Analysis  *The determination of the vulnerabilities of a
                          product or system.*

  Wrap                    *Encryption of a cryptographic key by another key*
  ----------------------- -----------------------------------------------------