## Overview

The Federal Government has a right and a responsibility to protect the
information and data contained in, processed by, and transmitted between
its IT systems. Ownership of the information is often shared with
individuals, companies, and organizations and therefore requires that
the government protect that information on behalf of and to the
standards of those co-owners.

Protection of information on IT systems is complicated and evolving. One
aspect of such protection is the desire ad perhaps requirement that
certain information or information in specific states provide its own
protection. The method of such self protection is encryption, the
process whereby the information itself is scrambled using methods which
make it easy for authorized entities to decrypt and difficult for all
others to decrypt. Done with sufficient strength and sufficient
protection of the decryption means, the keys, encryption can adequately
protect the information from disclosure to unauthorized parties.
However, the unavailability, lose, or corruption of those keys will also
prevent disclosure to authorized parties. The solution to this problem
is to provide a method of recovering decryption keys by authorized
parties.

The generation, storage, and recovery of decryption keys is also a
complex process, one that needs to be rigidly defined, stringently
implemented, and conscientiously managed and operated to ensure that
both functions to provide its proposed benefit and prevent an
inappropriate increase in vulnerability. For those reasons, it is
necessary to address those aspects 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 Sender, the Encrypted Data Medium, the Receiver,
and the Recovery Data Medium. It should be noted that preparation of
recovery information is the responsibility of the encryption process,
not the recovery process.

The recovery process described in the FIPS includes process and
requirements of recovered key requesters; structure, process and
requirements including performance of the key recovery agents, and a
description of the interactions between the two 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 both the key recovery
process and the security of the keys, and therefore the encryption
information itself. Such supporting components include the vendor
products for the users, for the 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.

To further the understanding of the overall key recovery process,
examples will be presented to delineate a, not the, methods of using key
recovery. Such examples include 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.

## Key Recovery System

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. The key recovery system model is a
generalized

model, which supports a wide variety of different key recovery
techniques and

data applications. The data applications supported by the key recovery
system

model are these:

\* Interactive session between two systems (A to B and B to A).

\* Store-and-forward, such as email (A to B or B to A).

\* Data storage where A and B can be the same system (A = B).

The key recovery system model contains the following components:

\* System A (Crypto-Enabled)

\* System B (Crypto-Enabled)

\* Encrypted Data Medium

\* Recovery Information Medium

\* Requester

\* Key Recovery Agent(s)

The model depicts a key recovery system capable of encrypting data,
creating

key recovery information \-- for a given key \-- and recovering the key
from the

key recovery information, for an authorized request.

### Encryption and Enablement Process

The process of encrypting data and creating key recovery information is

performed by one or more crypto-enabled systems, denoted in the key
recovery

system model as System A and System B. A crypto-enabled system is one
that

can communicate using cryptography, i.e., it can encrypt and decrypt
data. It

is assumed that one or more of the systems (A or B) can create key
recovery

information. The encrypted data and key recovery information produced by
these

systems are maintained on some appropriate medium, denoted in the key
recovery

system model as the Encrypted Data Medium and Recovery Information
Medium,

respectively. The Recovery Information Medium may be the same or
different

from the Encrypted Data Medium.

The four components \-- System A, System B, Encrypted Data Medium, and
Recovery

Information Medium \-- collectively define a subset of the model called
the

\"Encryption and Enablement Process.\"

#### Components and Their Interactions

##### Systems A & B

Systems A and B are systems capable of communicating with each other
using

cryptography (i.e., they are crypto-enabled).

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 cryptographic 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, at a minimum, includes services for
creating

key recovery information. It is also possible for one system (A or B) to

implement a set of key recovery services capable of \"handling\" the key
recovery

information provided by another system, but has no capability to create
key

recovery information by itself. A system that meets this minimal
requirement

is said to be key recovery aware. Thus, the standard contemplates that
two

systems can interoperate in compliance with the standard as long as both

systems are key recovery aware and at least one of the systems is
capable of

creating key recovery information. (NOTE: The term handling\" will need
to be

defined more rigorously in this standard, at some point. This is a TBD
item.)

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.

###### Sender

The Sender is the system that encrypts data, either for storage or for

transmission to a Receiver.

The Sender may or may not create key recovery information.

Typically, the Sender will create key recovery information (i.e., enable
key

recovery) in order to comply with an established key recovery policy.
Key

recovery policy specifies the conditions under which key recovery
information

must be created; it may also indicate which are the allowable key
recovery

agents, and how and where the key recovery information must be
maintained

(stored or transmitted).

However, the Sender may elect to create key recovery information in
situations

where key recovery is deemed desirable, although not specifically
required by

the Sender\'s key recovery policy. The Sender may also create key
recovery

information for the Receiver, in situations where the Receiver is
incapable of

creating its own key recovery information. If the Sender has no need to

create key recovery information, then no key recovery information will
be

created.

###### Receiver

The Receiver is the system that receives encrypted data and decrypts
its.

The Receiver may or may not create key recovery information.

Typically, the Receiver will create key recovery information in order to
comply

with an established key recovery policy (see also 1.2.1.1.1.1 Sender).

However, the Receiver may elect to create key recovery information in

situations where key recovery is deemed desirable, although not
specifically

required by the Receiver\'s key recovery policy. The Receiver may also
create

key recovery information for the Sender, in situations where the Sender
is

incapable of creating its own key recovery information. If the Receiver
has no

need to create key recovery information, then no key recovery
information will

be created.

In situations where key recovery information is received from the
Sender, the

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

##### Encryption Data Medium

The encrypted data medium represents the \"location\" where the
encrypted data

is stored or communicated, such as a storage device or communications
channel.

The key recovery system model does not prescribe how or where the
encrypted

data must be stored or communicated, as long as it can be accessed by an

authorized Requester.

##### Recovery Information Medium

The recovery information medium represents the \"location\" where the
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 recovery information must be stored or communicated, as
long as it

can be accessed by an authorized Requester.

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

#### Interaction Summary

Both systems (A and B) have access to the Encrypted Data Medium. Thus,
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) file storage.

Both systems (A and B) have access to the Recovery Information Medium.
Thus,

the key recovery system model embraces key recovery systems where one or
both

systems have the capability to create recovery information and one or
both

systems can make that recovery information available by putting it on a

Recovery Information Medium. The model also embraces key recovery
systems

where one or both systems have access to the recovery information, thus

allowing each system to potentially validate the recovery information
created

by the other system, to ensure that it is authentic.

In a typical interaction scenario, System A (acting as a sender)
encrypts a

e-mail message and sends it to System B (acting as a receiver). In this
case,

the Encrypted Data Medium is a communications path. System A also
creates key

recovery information, which it appends to the encrypted message in the
form of

a message header. In this case, the Recovery Information Medium is also
the

same communications path used to transmit the encrypted data, i.e., the

Encrypted Data Medium and the Recovery Information Medium are one and
the

same. Upon receipt of the encrypted message, System B validates the
recovery

information and decrypts the message.

### Recovery Process

The Requester and the Key Recovery Agents form another subportion of the
key

recovery system model called the \"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 Requester and Key Recovery Agents. An authorized
Requester \--

with access to the Encrypted Data Medium and the Recovery Information
Medium \--

interacts with one or more Key Recovery Agents to recover the
cryptographic key

from the key recovery information.

A recovered key can then be used to recover the data, either directly or

indirectly. In some cases, the recovered key will be the same key used
to

encrypt the data. In other cases, the recovered key may be a
key-encrypting

key, in a hierarchy of keys. In this case, the recovered key must first
be

used to decrypt the appropriate keys in the hierarchy, to recover the
key that

was used to encrypt the data.

The Requester and the Key Recovery Agents collectively define an
additional

subset of the model called the \"Recovery Process.\"

#### Components and Their Interactions

##### Requester

The Requester is an entity who seeks to recover information that will
allow the

decryption of encrypted data. To this end, the Requester always performs
the

step of key recovery; the step of data recovery is optional.

The Requester is defined as the entity who interacts with one or more
Key

Recovery Agents \-- using key recovery information \-- to recover a key.
Many

different algorithms and procedures can be used to recover a key. For

example, the Requester might interact with one Key Recovery Agent to
recover a

whole key, or the Requester might interact with two or more Key Recovery
Agents

to recover several pieces of information that, in turn, permit the
Requester to

recover or reconstruct the whole key.

The Requester must always have access to the recovery information
corresponding

to the (desired) key to be recovered. However, the Requester will need
access

to the encrypted data only if it performs the additional step of data
recovery.

A request for key recovery service, made by a Requester to a Key
Recovery

Agent, must be an authorized request. In other words, the Requester
issuing 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 Requester must prove its right to access
that

data.

Those 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 Requester 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 assumes the role of the Requester on behalf
of the

individual or enterprise. Under such an arrangement, the Requester could

recover the key, which in turn would be provided to the individual or

enterprise, and the individual or enterprise could then recover the data
using

the recovered key.

TBD: WG1 still needs to define KRA identifying information.

##### 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 Requester. Before honoring
such a

request, the Key Recovery Agent authenticates the Requester\'s right to
receive

the requested recovery service. The recovery service consists of
processing

all or part of the recovery information, provided by the Requester to
the Key

Recovery Agent, and returning an output value to the Requester.

The algorithm for processing the recovery information is dependent on
the

algorithm originally used to create the recovery information, i.e. it is

algorithm specific. There are many possible algorithms for creating and

processing the 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 Requester 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 recovery information, or for recovering
or

reconstructing the key.

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.

#### Interaction Summary

In a typical key recovery scenario, the Requester \-- who is provided
with, or

who acquires, a set of key recovery information, and who can \"prove\"
its right

to access the data \"unlocked\" by the key to be recovered from that key
recovery

information \-- sends a request for key recovery service to one or more
Key

Recovery Agents. With each such request, the Requester provides an
appropriate

portion of the recovery information to each Key Recovery Agents, which
may be

all or part of the key recovery information.

Before processing the key recovery service request, the Key Recovery
Agent

authenticates the Requester\'s right to receive the requested key
recovery

service. Each Key Recovery Agent processes its respective portion of the

recovery information and constructs an output value, which is returned
to the

Requester.

If only one Key Recovery Agent is involved, the output value could be
the whole

key, and the Requester is finished. On the other hand, if two or more
Key

Recovery Agents are involved, the output values could be key parts or
pieces of

information that the Requester would use to reconstruct or recover the
whole

key.

If the Requester is a third party who performs a key recovery service on
behalf

of some other person or party, then the Requester returns the recovered
key to

that person or party. However, if the Requester has also been engaged to

perform a data recovery service, the Requester \-- who is provided the
encrypted

data \-- will decrypt the provided encrypted data with the recovered key
and

return the recovered data to the person or party.

## Supporting Components

### Product Vendors

#### End User Product Vendors

##### Description

###### End User Product Vendors produce end user products for use in the Key Recovery System.

##### Requirements

###### The End User Product Vendor shall provide evidence that their product has met component assurance testing as defined by the System Policy Authority, including testing in the following areas: (1) confidentiality, (2) integrity, (3) authentication, (4) tamper resistance, (5) key recovery block generation, (6) key recovery block verification, (7) interoperability, (8) availability and (9) reliability.

###### The End User Product Vendor shall provide information to the Registration Agent specifying how the product sends data to the Encrypted Data Medium and the Recovery Information Medium.

###### The End User Product Vendor shall embed the appropriate System Root Key into the product for use in the Key Recovery System.

#### Key Recovery Agent Product Vendors

##### Description

###### Key Recovery Agent Product Vendors produce key recovery agent products for use in the Key Recovery System.

##### Requirements

###### The Key Recovery Agent Product Vendor shall provide evidence that their product has met component assurance testing as defined by the System Policy Authority, including testing in the following areas: (1) confidentiality, (2) integrity, (3) authentication, (4) tamper resistance, (5) survivability, (6) availability, (7) auditability, (8) access control, and (9) interoperability.

###### The Key Recovery Agent Product Vendor shall embed the appropriate System Root Key into the product for use in the Key Recovery System.

#### Requester Product Vendors

##### Description

###### Requester Product Vendors produce requester products for use in the Key Recovery System.

###### Requester products (1) retrieve relevant key recovery information from the Registration Agent, (2) gather and parse information from the Recovery Information Medium, (3) send/receive information to/from Key Recovery Agents, and (4) recover plaintext data by using the recovered key(s) and information gathered from the Encrypted Data Medium.

##### Requirements

###### The Requester Product Vendor shall provide evidence that their product has met component assurance testing as defined by the System Policy Authority, including testing in the following areas: (1) confidentiality, (2) integrity, (3) authentication, (4) tamper resistance, (5) auditability, (6) access control, (7) interoperability, (8) availability, and (9) reliability.

######  The Requester Product Vendor must embed the appropriate System Root Key into the product for use in the Key Recovery System.

### Registration Agent

#### Description

##### The Registration Agent receives and archives vendor-specific information required by the Requester 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.

#### Requirements

##### The Registration Agent, when authorized to do so by the System Policy Authority, shall specify the information that must be provided by vendors of Key Recovery System components.

##### The Registration Agent shall verify that the information provided by product vendors meets the specified criteria.

##### The Registration Agent shall notify the Licensing Agent of a product vendor's compliance with the Registration Agent's criteria.

##### The Registration Agent shall make information provided by vendors available to Requesters in a tamper-evident form.

### Authentic Public Key Source

#### Description

##### The Authentic Public Key Source is a source for obtaining the public keys required by the recovery protocol. It is envisioned that public key cryptography will be used to encrypt recovery information particular to recovery agents. The security of the recovery protocol and the target keys protected by the recovery protocol therefore depends on the authenticity of the public keys which the recovery protocol use.

##### To provide this trust, the Authentic Public Key Source will generate a System Root Key, in a similar fashion to how a certificate authority (CA) generates a root CA key for use in conventional public key infrastructures.

##### This System Root Key will then be used to cryptographically authorize Key Recovery Agents to participate in the Key Recovery System.

##### The System Root Key will also be used by system components to verify that a given Key Recovery Agent has been duly authorized by the Licensing Agent to participate in the system and is therefore "legitimate".

##### Key Encapsulation Example

###### In a key recovery protocol based on encapsulating a session key in a Key Recovery Agent's public key, the Authentic Public Key Source will authenticate a legitimate Key Recovery Agent's public key by cryptographically signing it using the System Root Key.

###### This signature could be contained within a certificate, which could then be verified by End User Products during Key Recovery Block generation and verification.

###### Verification of this certificate to the System Root Key embedded in the End User Product provides sender and receiver with confidence that the Key Recovery Agent and the Key Recovery Agent's public key being used for Key Recovery Block generation are legitimate.

##### Private Key Escrow Example

###### In a key recovery protocol based on escrow of the user's private key with a Key Recovery Agent, the Authentic Public Key Source will authenticate the Key Recovery Agent's public key by cryptographically signing it using the System Root Key.

###### The Key Recovery Agent would similarly cryptographically sign the user's public key, creating a "certificate chain" from the user public/private keypair to the System Root Key.

###### Verification of this "certificate chain" to the System Root Key embedded in the End User Product provides sender and receiver with confidence that the user's private key has been properly escrowed.

#### Requirements

##### The Authentic Public Key Source shall securely generate a public/private keypair, hereinafter referred to as the System Root Key.

##### The private portion of the System Root Key shall be maintained securely in accordance with the policy and procedures specified by the System Policy Authority (i.e. secured in hardware) and shall ensure (1) confidentiality, (2) integrity and (3) survivability.

##### The Authentic Public Key Source shall securely certify the Key Recovery Agent using the System Root Key when authorized to do so by the Licensing Agent.

##### The Authentic Public Key Source shall maintain a secure database of all Key Recovery Agents which it has certified.

##### The Authentic Public Key Source shall furnish the database of certified Key Recovery Agents to a legitimate lawful investigation.

##### The Authentic Public Key Source shall provide for auditability of all security-critical functions.

##### The public portion of the System Root Key shall be securely distributed to Key Recovery System product vendors to facilitate embedding into all security-critical elements of the Key Recovery System.

### Licensing Agent

#### Description

##### The Licensing Agent is responsible for licensing Key Recovery Agents.

#### Requirements

##### The Licensing Agent shall evaluate a candidate Key Recovery Agent based on the requirements specified by the System Policy Authority.

##### The Licensing Agent authorizes the Authentic Public Key Source to enable a candidate Key Recovery Agent to participate in the Key Recovery System.

##### The Licensing Agent shall maintain a secure database of all Key Recovery Agents which it has authorized to participate in the Key Recovery System.

### System Policy Authority

XX1.3.5 A cryptographic Key Recovery System shall provide a *policy
establishment* mechanism that enables an appropriately designated
administrator to implement system policy. At a minimum, the system
policy shall define each of the following.

1.3.5.1 Affected data types.

1.3.5.1.1 The system policy shall define whether or not stored data is
to be made available for recovery.

1.3.5.1.2 The system policy shall define whether or not electronic mail
is to made available for recovery.

1.3.5.1.3 The system policy shall define whether or not real-time
communications are to be made available for recovery.

1.3.5.2 Access policy.

1.3.5.2.1 For each affected data type for which recovery has been
selected, the system policy shall define the recovery mechanism to be
used.

1.3.5.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.3.5.2.3 For each recovery agent selected, the system policy shall
define what requestors may recover the data.

1.3.5.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.3.5.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.3.5.3 Data integrity policy.

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

1.3.5.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 and, if so, a confidence level for this \"proof\".

1.3.5.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 to a third party) of the source of the recovered
data.

1.3.5.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.3.5.4 Interoperability policy.

1.3.5.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.3.5.4.2 For each affected data type, the system policy shall define
what (if any) interoperability conditions require a warning to the user.

#### Description

#### Requirements

## Examples

### Stored File Encryption

### E-mail

### Real time Communication

### Key Recovery Process