FIPS PUB xyz

FEDERAL INFORMATION

PROCESSING STANDARDS PUBLICATION

(Date)

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

**KEY RECOVERY STANDARD**

(DRAFT)

CATEGORY: COMPUTER SECURITY, CRYPTOGRAPHY

  -----------------------------------------------------------------------
  This is a working draft of the Technical Advisory Committee to Develop
  a Federal Information Processing Standard for the Federal Key
  Management Infrastructure (TAC). As such, it is not a Federal
  Government document.

  -----------------------------------------------------------------------

**Foreword**

The Federal Information Processing Standards Publication Series of the
National Institute of Standards and Technology (NIST) is the official
publication relating to standards and guidelines adopted and promulgated
under the provisions of Section 5131 of the Information Technology
Management Reform Act of 1996, and the Computer Security Act of 1987,
Public Law 104‑106. Under these mandates, the Secretary of Commerce
promulgates standards and guidance pertaining to the efficiency,
security and privacy of Federal computer systems. The National Institute
of Standards and Technology, through its Information Technology
Laboratory, has the mission of developing standards, guidelines and
associated methods and techniques for computer systems, and providing
technical assistance to industry and government in the implementation of
standards.

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

Shukri Wakid, Director

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

ALTERNATIVE TO THE ABOVE: This standard specifies requirements to be met
by key recovery components used by Federal government agencies. These
components provide for the recovery of keys which will be used for the
decryption of stored or communicated data when access to the data is
properly authorized.

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

FIPS PUB xyz

**Federal Information**

**Processing Standards Publication XXX**

**(Date)**

**Announcing the**

**KEY RECOVERY STANDARD**

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 5131 of
the Information Technology Management Reform Act of 1996, and the
Computer Security Act of 1987, Public Law 104-106.

**1. Name of Standard.** Key Recovery Standard.

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

**3. Explanation.** This Standard specifies requirements for key
recovery components. These components provide for the recovery of keys
to be used for the decryption of stored or communicated ciphertext when
the decryption 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 stored or communicated data on behalf of an organization
    (e.g., for the purposes of monitoring or auditing activities); and

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

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

A Key Recovery System (KRS) manages cryptographic keys in support of
data recovery when normal key access mechanisms fail. 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 key recovery
components, and to enable the validation of components claiming
conformance. The standard encompasses the security (from an
implementation, managerial and operation perspective) and the
availability of key recovery components, as well as defining
interoperability requirements.

**4. Approving Authority**. Secretary of Commerce.

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

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

Other NIST publications may be applicable to the implementation and use
of this standard. A list (NIST Publications List 91) of currently
available computer security publications, including ordering
information, can be obtained from NIST.

**7. Applicability.** This standard is applicable to all Federal
departments and agencies and their contractors. This standard shall be
used in designing, acquiring and implementing encryption and key
recovery components and systems that Federal departments and agencies
use or operate, or which are operated for them under contract.
Components 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 (e.g., digital signatures).

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

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

b.  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 \"b\" 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, components 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 components continue to be FIPS approved.

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

**8. Applications.** This standard is appropriate for use in a variety
of applications, including:

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

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

3.  When electronic voice communications are encrypted for privacy.

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

**10. 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 X of the attached Specification.
Additional information may be obtained from the National Institute of
Standards and Technology, Information Technology Laboratory, Attn: Key
Recovery Validation, Gaithersburg, MD 20899.

**11. Export Control.** Implementations of this standard are subject to
export controls as specified in Title 15, Code of Federal Regulations,
Parts 730-774 and Title 22, Code of Federal Regulations, Parts 120-130.
Exporters are advised to contact the Encryption Policy Controls Division
at the Department of Commerce, Bureau of Export Administration for more
information.

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

**13. Implementation Schedule.** The effective date of this standard is
\<insert date\>. From approval of this FIPS by the Secretary of Commerce
to its effective date, agencies may purchase components 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 validation program by NIST, agencies that have
determined a need for key recovery components shall purchase components
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.

![](media/image1.png){width="6.49375in"
height="3.8930555555555557in"}For a one year period following the six
month period after the establishment of the validation program, agencies
shall purchase validated key recovery components, or components that
have been submitted for validation. After this period, only validated
key recovery components will be considered as meeting the provisions of
this standard.

**14. Glossary.** The following terms are used as defined below for
purposes of this standard:

+---------------+------------------------------------------------------+
| [Abstract     | [The underlying hardware or firmware abstraction to  |
| Ma            | which the software is written.]{.mark}               |
| chine]{.mark} |                                                      |
|               | []{.mark}                                            |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| [Accountab    | []{.mark}                                            |
| ility]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| Assurance     | \(1\) Confidence that an entity meets its security   |
|               | objectives. (2) The degree of confidence that a      |
|               | product correctly implements the security policy.    |
+---------------+------------------------------------------------------+
| [Auditable    | [Events within a key recovery product which may      |
| E             | appear in an audit log (see Sections XX,             |
| vents]{.mark} | XY,...XZ).]{.mark}                                   |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| [A            | [(1) Information used to authenticate an entity,     |
| uthentication | e.g., a password, PIN, biometric, or response to a   |
| Data]{.mark}  | challenge. (2) Information used to verify the        |
|               | claimed identity of a user.]{.mark}                  |
| []{.mark}     |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| [A            | [See "Authentication Data".]{.mark}                  |
| uthentication |                                                      |
| Inform        |                                                      |
| ation]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| [A            | [A technique used to authenticate an entity, e.g.,   |
| uthentication | user ID and password, token, biometric or            |
| Mech          | challenge-response.]{.mark}                          |
| anism]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| Authentic     | Used to provide a certificate infrastructure to      |
| Public Key    | support the use of public key cryptography within    |
| Source        | the Key Recovery System.                             |
+---------------+------------------------------------------------------+
| Authorized    | A user to whom authorization has been granted to     |
| Administrator | perform administrative operations which may affect   |
|               | the enforcement of the trusted system.               |
+---------------+------------------------------------------------------+
| Authorized    | Key recovery either with the permission of the owner |
| key recovery  | of the data or as otherwise permitted by law.        |
+---------------+------------------------------------------------------+
| Authorized    | A request based on a legal and lawful right for      |
| Request       | access [by a data owner or other authorized          |
|               | entity]{.mark}.                                      |
+---------------+------------------------------------------------------+
| [Authorized   | [(1) A user who is authorized to access a system to  |
| User]{.mark}  | perform one or more actions. (2) A user who may      |
|               | perform an operation in accordance with the system   |
| []{.mark}     | security policy.]{.mark}                             |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| Common        | An international standard for security in            |
| Criteria (CC) | information security components.                     |
+---------------+------------------------------------------------------+
| Common        | A predefined set of assurance components that        |
| Criteria      | represents a point on the CC assurance scale.        |
| Evaluation    |                                                      |
| Assurance     |                                                      |
| Level (EAL)   |                                                      |
+---------------+------------------------------------------------------+
| Common        | An implementation-independent set of security        |
| Criteria      | requirements for a category of components which meet |
| Protection    | specific consumer needs.                             |
| Profile       |                                                      |
+---------------+------------------------------------------------------+
| Co            | \(1\) Assurance that the information is not          |
| nfidentiality | 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  | A capability [feature that]{.mark} is available but  |
| Capability    | need not be selected for use.                        |
+---------------+------------------------------------------------------+
| Configuration | Items (e.g., documents, software, hardware) which    |
| Item          | are under configuration control.                     |
+---------------+------------------------------------------------------+
| Configuration | The management of security features and assurances   |
| Management    | through the control of changes made to a system's    |
| (CM)          | hardware, software, firmware, documentation set,     |
|               | test, test fixtures and test documentation           |
|               | throughout the development and operational life of   |
|               | the system.                                          |
+---------------+------------------------------------------------------+
| Cryptographic | Provides a set of cryptographic services (e.g.,      |
| Subsystem     | encryption and decryption) to an application.        |
+---------------+------------------------------------------------------+
| Data          | Voice, facsimile, computer files, electronic mail,   |
|               | and other stored or communicated information.        |
+---------------+------------------------------------------------------+
| Data          | A symmetric key used to encrypt data.                |
| ~             |                                                      |
| ~Encryption~~ |                                                      |
| Key ~~(DEK)~~ |                                                      |
+---------------+------------------------------------------------------+
| ~~Data        | ~~Decryption of encrypted data with the aid of at    |
| recovery~~    | least one data recovery agent.~~                     |
+---------------+------------------------------------------------------+
| ~~Data        | ~~Change to Key Recovery Field~~                     |
| Recovery      |                                                      |
| Field (DRF)~~ |                                                      |
+---------------+------------------------------------------------------+
| Data Recovery | The system/subsystem used to recover encrypted data  |
| System        | using a recovered [target]{.mark} 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.                           |
+---------------+------------------------------------------------------+
| Encapsulated  | A method of key recovery [in which]{.mark} keys, key |
| Key Recovery  | parts or key related information is maintained       |
|               | outside a Key Recovery Agent. ~~Some of the Key      |
|               | Recovery Information is wrapped so that it is        |
|               | protected against disclosure when it is stored       |
|               | outside a security perimeter.~~                      |
+---------------+------------------------------------------------------+
| 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.                    |
+---------------+------------------------------------------------------+
| End User      | A system containing [a]{.mark} user application and  |
| System        | the encryption mechanism used to secure that         |
|               | application. ~~The end user system is supported by   |
|               | the key recovery system (i.e., the end user system   |
|               | may include key recovery components, or another      |
|               | system may provide key recovery on behalf of the end |
|               | user system). The encryption mechanism is controlled |
|               | in accordance with key recovery policy.~~            |
+---------------+------------------------------------------------------+
| ~~Escrow Key  | ~~A method of key recovery where the [secret or      |
| Recovery~~    | private]{.mark} keys, key parts or key related       |
|               | information to be recovered is stored by one or more |
|               | Key Recovery Agents. Other Key Recovery Information  |
|               | may be available elsewhere.~~                        |
+---------------+------------------------------------------------------+
| [Evidence of  | [Should be "Proof of Origin".]{.mark}                |
| O             |                                                      |
| rigin]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| [Evidence of  | [Should be "Proof of Receipt".]{.mark}               |
| Re            |                                                      |
| ceipt]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| FIPS          | Meeting all requirements of [a specified level of    |
| compliant     | this standard]{.mark}.                               |
+---------------+------------------------------------------------------+
| ~~Flaw        | ~~A system analysis and penetration technique in     |
| Hypothesis~~  | which specifications and documentation for the       |
|               | system are analyzed, and flaws in the system are     |
|               | hypothesized.~~                                      |
+---------------+------------------------------------------------------+
| Flaw          | The correction of discovered security flaws in a     |
| Remediation   | product or system.                                   |
+---------------+------------------------------------------------------+
| Functional    | A high level description of the requirements for a   |
| Requirements  | system.                                              |
+---------------+------------------------------------------------------+
| Functional    | High level description of the user-visible interface |
| Specification | and behavior of a system.                            |
+---------------+------------------------------------------------------+
| I             | A description of the implementation (e.g., source    |
| mplementation | code when the implementation is software or          |
| R             | firmware; or drawings and schematics, if the system  |
| epresentation | is hardware).                                        |
+---------------+------------------------------------------------------+
| Independent   | Testing performed by persons other than the          |
| Testing       | developers.                                          |
+---------------+------------------------------------------------------+
| Informal      | An accurate and concise statement of system security |
| Security      | policy expressed informally (i.e., in natural        |
| Policy Model  | language; e.g., English).                            |
+---------------+------------------------------------------------------+
| Informal      | \(1\) Expressed in natural language. (2) Written as  |
|               | prose in natural language.                           |
+---------------+------------------------------------------------------+
| Informal      | [Written in normal language, e.g., English.]{.mark}  |
| style         |                                                      |
| /presentation |                                                      |
+---------------+------------------------------------------------------+
| Integrity     | The property that sensitive data has not been        |
|               | modified or deleted in an unauthorized and           |
|               | undetected manner.                                   |
+---------------+------------------------------------------------------+
| Interactive   | [Two-way communication between end users.]{.mark}    |
| Communication |                                                      |
+---------------+------------------------------------------------------+
| Int           | The ability of components [or systems]{.mark} to     |
| eroperability | communicate with one another.                        |
+---------------+------------------------------------------------------+
| [Key          | [(1) The processes of managing (e.g., generating,    |
| Ca            | storing, transferring, auditing) the cryptographic   |
| ching]{.mark} | keys or key components by one or more entities. (2)  |
|               | A key recovery technique that employs one or more    |
|               | Key Recovery Agents who hold (i.e., cache) keys or   |
|               | key components for their subscribers.]{.mark}        |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| Key           | The encryption of one cryptographic key by another   |
| Encapsulation | key. See "Wrap".                                     |
+---------------+------------------------------------------------------+
| ~~Key         | ~~A key used to encrypt another key. May be a        |
| Encryption    | symmetric key, or the public key of an encryption    |
| Key (KEK)~~   | public/private key pair.~~                           |
+---------------+------------------------------------------------------+
| ~~Key         | ~~(1) The processes of managing (e.g., generating,   |
| Escrow~~      | storing, transferring, auditing) the cryptographic   |
|               | keys or key components by one or more entities.~~    |
+---------------+------------------------------------------------------+
| Key Exchange  |                                                      |
| Field         |                                                      |
+---------------+------------------------------------------------------+
| ~~Ke          | ~~An encryption product whose encryption output is   |
| y-recoverable | recoverable through key recovery.~~                  |
| Product~~     |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | Access to information sufficient to recover          |
|               | encrypted data.                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | [A Key Recovery Agent System.]{.mark}                |
| Agent (KRA)   |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | A key recovery system that performs a recovery       |
| Agent (KRA)   | service in response to an authorized request by a    |
| System        | requestor system on behalf of a requestor.           |
+---------------+------------------------------------------------------+
| Key Recovery  | An element within a Key Recovery System that         |
| Component     | provides key recovery functionality (e.g., KRI       |
|               | generation, KRI management, and/or key recovery      |
|               | function).                                           |
+---------------+------------------------------------------------------+
| Key Recovery  | Recovers a [target]{.mark} key using Key Recovery    |
| Function      | Information. [Composed of the KRI Requestor Function |
|               | and KRA Function.]{.mark}                            |
+---------------+------------------------------------------------------+
| Key Recovery  | Information that is used in the recovery of a key.   |
| Information   | The KRI does not include a plaintext key.            |
| (KRI)         |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | Key recovery information which is specific to a      |
| [Inform       | single key recovery scheme.                          |
| ation]{.mark} |                                                      |
| Field         |                                                      |
| (K            |                                                      |
| R[I]{.mark}F) |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | A stream of bytes that serves as a container for a   |
| Block (KRB)   | single key recovery scheme-specific KR[I]{.mark}F    |
|               | and associates the KR[I]{.mark}F with a set of       |
|               | standard fields in a predefined format.              |
+---------------+------------------------------------------------------+
| Key Recovery  | A policy which specifies the conditions under which  |
| Policy        | 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  | The system/subsystem used by the requestor to        |
| Requestor     | request keys.                                        |
| System        |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  |                                                      |
| Service       |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | Consists of the KRI Generation Function, the KRI     |
| System (KRS)  | Management Function and the Key Recovery Function.   |
|               | Includes software, hardware, procedures and          |
|               | infrastructure.                                      |
+---------------+------------------------------------------------------+
| [KRA]{.mark}  | [Key Recovery Agent]{.mark}                          |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| [KRB]{.mark}  | [Key Recovery Block]{.mark}                          |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| [KRI Delivery | [Assembles and formats the key recovery information  |
| Fun           | (KRI) and makes the KRI available.]{.mark}           |
| ction]{.mark} |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| KRI           | [Generates the key recovery information (KRI) needed |
| Generation    | to recover the target key and provides the KRI to    |
| Function      | the KRI Delivery Function.]{.mark}                   |
+---------------+------------------------------------------------------+
| [KRI          | [Manages the KRI after generation for potential      |
| Management    | recovery. Composed of the KRI Delivery Function, KRI |
| Fun           | Receive Function and KRI Validation                  |
| ction]{.mark} | Function.]{.mark}                                    |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| KRI Providers | Those entities provide [Key Recovery Information     |
|               | (KRI) using a KRI Generation Function.]{.mark}       |
+---------------+------------------------------------------------------+
| [KRI Receive  | [Enables a receiver to determine the key recovery    |
| Fun           | information (KRI) which is available and acquire KRI |
| ction]{.mark} | for subsequent processing.]{.mark}                   |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| [KRI          | [Checks, authenticates, validates or verifies the    |
| Validation    | available key recovery information.]{.mark}          |
| Fun           |                                                      |
| ction]{.mark} | []{.mark}                                            |
+---------------+------------------------------------------------------+
| KRR           | Key Recovery Requestor [System]{.mark}.              |
+---------------+------------------------------------------------------+
| [KRS]{.mark}  | [Key Recovery System]{.mark}                         |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| [Layered      | [A product in which security functions are layered.  |
| Pr            | For example, a secure application which is           |
| oduct]{.mark} | implemented on top of a secure operating system is a |
|               | layered product.]{.mark}                             |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| Least         | \(1\) The most concrete representation of an         |
| Abstract      | implementation (e.g., source code). [(2) The         |
| R             | representation that is closest to the                |
| epresentation | implementation, e.g., source code.]{.mark}           |
+---------------+------------------------------------------------------+
| Licensing     | Authorizes Key Recovery Agents after an evaluation   |
| Agent         | against the FIPS.                                    |
+---------------+------------------------------------------------------+
| Masquerading  | An attempt to gain access to a system by posing as   |
|               | an authorized user.                                  |
+---------------+------------------------------------------------------+
| Message       | A data format that cryptographically binds data      |
| Security      | sensitivity and provides public key cryptography     |
| Protocol      | based security services for the data, including      |
| (MSP)         | confidentiality, integrity, etc.                     |
+---------------+------------------------------------------------------+
| MIME          | Multipurpose Internet Mail Extension [as defined in  |
|               | RFC 2045]{.mark}.                                    |
+---------------+------------------------------------------------------+
| [Monolithic   | [A product in which security functions are not       |
| Pr            | layered. See "Layered Product".]{.mark}              |
| oduct]{.mark} |                                                      |
+---------------+------------------------------------------------------+
| Non-ke        | An encryption product whose encryption output is not |
| y-recoverable | recoverable through key recovery.                    |
| Product       |                                                      |
+---------------+------------------------------------------------------+
| ~~Partial Key |                                                      |
| Escrow~~      |                                                      |
+---------------+------------------------------------------------------+
| Presentation  | [Providing the information necessary to carrying out |
| of Evidence   | the assurance activity.]{.mark}                      |
+---------------+------------------------------------------------------+
| ~~Privacy     | ~~Communications protocol defined in RFCs 1421       |
| Enhanced      | through 1424.~~                                      |
| Mail~~        |                                                      |
+---------------+------------------------------------------------------+
| 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   | A Key Recovery technique which is used to recover    |
| Recovery      | the private key of a public key pair or the secret   |
|               | key used with a symmetric encryption algorithm.      |
+---------------+------------------------------------------------------+
| [Proof of     | [(1) A proof of the origin of information that       |
| O             | cannot be refuted by the originator, e.g., by using  |
| rigin]{.mark} | a digital signature. (2) Non-repudiation.]{.mark}    |
+---------------+------------------------------------------------------+
| [Proof of     | [A proof of the receipt of information so that the   |
| Re            | recipient cannot deny having received the            |
| ceipt]{.mark} | information, e.g., using a digital signature by the  |
|               | recipient on the received message.]{.mark}           |
| []{.mark}     |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| 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      | The ability of a recipient's implementation to       |
| Verification  | verify, with high assurance, that the originating    |
|               | implementation has implemented FIPS compliant        |
|               | [key]{.mark} recovery.                               |
+---------------+------------------------------------------------------+
| Recovery      | A field, output by the key recovery mechanism of a   |
| Field         | product, [that]{.mark} 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    | ~~See Key Recovery Information.~~                    |
| Information~~ |                                                      |
+---------------+------------------------------------------------------+
| Recovery      | The physical components of a KRS which provide for   |
| subsystem     | the recovery of plaintext when legally authorized.   |
+---------------+------------------------------------------------------+
| Registration  | Archives vendor-specific information in order to     |
| Agent         | find, acquire and parse recovery information.        |
+---------------+------------------------------------------------------+
| R             | An accurate and complete mapping from a higher level |
| epresentation | representation to a lower level representation       |
| C             | (e.g., from functional requirements to a functional  |
| orrespondence | 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.).                                         |
+---------------+------------------------------------------------------+
| Requestor     | [An]{.mark} entity that is authorized to request a   |
|               | key recovery.                                        |
+---------------+------------------------------------------------------+
| Requestor     | Interacts with one or more Key Recovery Agents using |
| Function      | Key Recovery Information to recover a data           |
|               | encrypting key.                                      |
+---------------+------------------------------------------------------+
| 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.                            |
+---------------+------------------------------------------------------+
| Secret        |                                                      |
| Sharing       |                                                      |
+---------------+------------------------------------------------------+
| [Security     | [(1) A set of objects , a security policy , a        |
| D             | security authority and a set of relevant activities  |
| omain]{.mark} | inwhich the set of elements are subject to the       |
|               | security policy , administered by the security       |
| []{.mark}     | authority , for the specified activities. (2) A set  |
|               | of security-related services, mechanisms, and        |
|               | policies. (3) The set of security objects that a     |
|               | subject has the ability to access.]{.mark}           |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| Security      | \(1\) A precise specification of the security rules  |
| Policy        | 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      | A formal representation of the security policy       |
| Policy Model  | enforced by the product.                             |
+---------------+------------------------------------------------------+
| Session-based | [Interactive communications.]{.mark}                 |
| Protocols     |                                                      |
+---------------+------------------------------------------------------+
| Session Key   | A key that is used to encrypt and/or decrypt data    |
|               | for a single communications session.                 |
+---------------+------------------------------------------------------+
| Session Key   | Recovery of the Data Encryption Key.                 |
| Recovery      |                                                      |
+---------------+------------------------------------------------------+
| S/MIME        | Secure MIME [as defined by RFC XXX]{.mark}.          |
+---------------+------------------------------------------------------+
| [Source       | [The ability to authenticate the identity of the     |
| Authentic     | source of a information.]{.mark}                     |
| ation]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| Standard      | Any communication protocol adopted by a generally    |
| Communication | recognized standards organization.                   |
| Protocol      |                                                      |
+---------------+------------------------------------------------------+
| Stor          | [One way communications (i.e., from a sender to a    |
| e-and-Forward | receiver) without the involvement of the receiver.   |
| C             | The receiver may acquire the communication at a time |
| ommunications | which is significantly later than the time the       |
|               | communication is sent.]{.mark}                       |
|               |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| System        | Includes software, hardware, procedures.             |
+---------------+------------------------------------------------------+
| [Target       | [The key recovered by a Key Recovery System.]{.mark} |
| key]{.mark}   |                                                      |
|               | []{.mark}                                            |
+---------------+------------------------------------------------------+
| Testing       | A laboratory which has been accredited by NIST to    |
| laboratory    | test systems, subsystems, key recovery agents, or    |
|               | components for conformance to this standard.         |
+---------------+------------------------------------------------------+
| Tran          | [Store-and-forward communications.]{.mark}           |
| saction-based |                                                      |
| Protocols     |                                                      |
+---------------+------------------------------------------------------+
| [Trusted      | [A mechanism by which a person or process can        |
| Path]{.mark}  | communicate directly with a cryptographic module and |
|               | which can only be activated by the person, process   |
| []{.mark}     | or module, and cannot be imitated by untrusted       |
|               | software within the module.]{.mark}                  |
+---------------+------------------------------------------------------+
| Trusted Third | An entity which is trusted by the parties performing |
| Party         | the encryption or decryption processes, but are not  |
|               | identical with those parties.                        |
+---------------+------------------------------------------------------+
| Unwrap        | Decryption of an encrypted key by another key.       |
+---------------+------------------------------------------------------+
| [Verify       | []{.mark}                                            |
| Associ        |                                                      |
| ation]{.mark} |                                                      |
|               |                                                      |
| []{.mark}     |                                                      |
+---------------+------------------------------------------------------+
| Vulnerability | The determination of the vulnerabilities of a        |
| Analysis      | product or system.                                   |
+---------------+------------------------------------------------------+
| Wrap          | Encryption of a cryptographic key by another key.    |
+---------------+------------------------------------------------------+

**15.** **Qualifications.** The security requirements specified in this
standard are based upon information provided by many sources within the
Federal government and private industry. The requirements are designed
to protect against adversaries mounting cost-effective attacks on
unclassified government or commercial data. The primary goal in defining
effective security for a system is to make the cost of any attack
greater than the possible payoff.

While the security requirements specified in this standard are intended
to maintain the security of a key recovery component, conformance to
this standard does not guarantee that a particular component is secure.
It is the responsibility of the manufacturer of a key recovery component
to build the component in a secure manner.

Similarly, the use of a key recovery component that conforms to this
standard in an overall system does not guarantee the security of the
overall system. The responsible authority in each agency shall assure
that an overall system provides an acceptable level of security.

Since a standard of this nature must be flexible enough to adapt to
advancements and innovations in key recovery technology, this standard
will be initially reviewed in two years in order to consider new or
revised requirements that may be needed to meet technological changes.

**16. 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. Waivers 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, Building 225 Building, Room A-231, 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]{.underline}.

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]{.underline} 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.

**17. 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. Publication
and ordering information may be found at
[http://www.ntis.gov](http://www.ntis.gov/). When ordering, refer to
Federal Information Processing Standards Publication xyz (FIPS PUB XXX),
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, credit card or
deposit account.

# 

# 

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

2 KEY RECOVERY MODEL

A Key Recovery System (KRS) enables authorized persons to recover
plaintext from encrypted data when the decryption key is not otherwise
available. Key Recovery is a broad term that applies to many different
key recovery techniques. Each technique will result in the recovery of a
key -- herein called the target key. The target key may be either:

-   the data key that can be used to decrypt the data, or

-   a key that can be used to decrypt the encrypted data key.

The information required by each key recovery technique to recover the
target key may be different for each technique. The term "key recovery
information" (KRI) will be used to refer to the aggregate of information
needed by a key recovery technique to recover the target key. The key
recovery information 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. The KRI may be
distributed among multiple location(s) (e.g., at one or more Key
Recovery Agents (KRAs), with a registration authority, associated with
or attached to a message or file, stored with a third party which is
separate from a KRA, in end user systems, in third party systems, at a
CA, in a certificate, or in a requestor facility).

Figure 1 presents a generalized model for a Key Recovery System,
consisting of a KRI Generation Function, A KRI Management Function and a
Key Recovery Function. The model addresses the creation of KRI for the
recovery of the target key, the management of the KRI, and the recovery
of the target key from that KRI.

![](media/image2.png){width="5.989583333333333in"
height="2.1743055555555557in"}

The KRI Management Function is decomposed into a KRI Delivery Function,
a KRI Receive Function and a KRI Validation Function. The Key Recovery
Function is divided into a Requestor Function and a KRA Function. The
resulting six functions are shown in Figure 2.

![](media/image3.png){width="5.0in" height="3.83125in"}

The key recovery model supports a wide variety of different key recovery
techniques and data applications, including:

-   Interactive communication sessions,

-   Store-and-forward communications, and

```{=html}
<!-- -->
```
-   Data storage.

The key recovery model addresses both key caching (i.e., key backup) and
encapsulated KRI techniques, as well as hybrids of these two techniques.
A key caching technique employs one or more Key Recovery Agents (KRAs)
who hold (i.e., cache) keys or key components for their subscribers. In
an encapsulated KRI technique, the KRA(s) do not hold keys belonging to
their subscribers. Instead, a structure is created which contains
information which will allow the Key Recovery Function to recover the
subscriber's key.

\[DISCUSSION: WHICH TERM SHOULD WE USE -- KEY ESCROW, KEY BACKUP OR KEY
CACHING? ANYTHING ELSE?\]

With both key caching and KRI encapsulation, a KRA may be operated by an
organization as an integral part of its own security infrastructure, or
a KRA may be operated by a third party organization. In the case of key
caching by a third party organization, the key caching system is often
called a key escrow system.

A Key Recovery System (KRS) {WILL? MAY?} exist over multiple "locations"
(e.g., end user systems, KRA systems, Requestor system, and storage or
transmission media). The normal key exchange mechanism is not affected
by any key recovery mechanisms, but may be used to support the creation
and distribution of key recovery information.

Appendix "Examples" provides examples of the distribution of functions
of the model within products implementing a Key Recovery System.

**2.1 Key Recovery Information (KRI) Generation Function**

In this model, the KRI Generation Function\--consisting of one or more
KRI-generating entities, also called KRI providers \--generates the KRI
needed to recover the target key and provides the KRI to the KRI
Delivery Function.

A KRI provider could, for example, be the sender or receiver of a
communication, a Certification Authority (CA), a Key Distribution
Center, a Registration Authority, or a component vendor. The KRI may
include the identity of a KRA, the identity of a key, a date and time,
authorization information, an indication of the key recovery type and
manufacturer, an algorithm identifier, an encrypted key, or pointer
information (e.g., information that points to the location or holder of
a key).

During an initialization or configuration stage, and at times of
periodic updates, the KRI-generating entities obtain initialization
information and cryptographic parameters, or otherwise are configured to
establish shared information as necessary with the KRA(s) to allow key
recovery. For example, for key caching systems, initialization and
configuration may involve setting parameters which will allow a secure
communication channel to be established which will allow the private
keys of the end user system to be backed up at the KRA. For KRI
encapsulation systems, initialization may involve obtaining authentic
copies of the KRA public key(s) for subsequent use in encapsulating the
KRI by the end user system. These are critical aspects of the overall
Key Recovery System, but their definition is beyond the scope of this
document.

**2.2 KRI Delivery Function**

The KRI Delivery Function is a required function of KRI Management. The
KRI Delivery Function assembles and formats the KRI (as necessary) and
makes the KRI available (e.g., by storing or transmitting the KRI).

For KRI encapsulation techniques, the target key (or portion of the
target key) or key related information is encrypted by a key associated
with a KRA. This key encrypting key is typically a public encryption key
for the KRA. Additional KRI may accompany the data key, depending on the
key recovery technique. \[NOTE THAT A KEY EXCHANGE MECHANISM MAY CREATE
ENCAPSULATED KRI\].

When a key caching technique is employed for key recovery, the data key
is typically encrypted by a key for which the corresponding decryption
key (e.g., the private key exchange decryption key) has been stored
(i.e., cached), in whole or in part, by one or more KRAs.

**2.3 KRI Receive Function**

In certain cases, e.g., where KRI is transmitted to another system, a
KRI receive function may be needed. The KRI Receive Function enables the
receiving end user system to determine the types of KRI available (e.g.,
by examining received communications or certificates), and finding
and/or acquiring any appropriate KRI for subsequent processing. The
receiving system could be, for example, an end user system, a requestor
system or a KRA.

**2.4 KRI Validation Function**

KRI validation may optionally be performed as part of KRI management.
Several degrees of validation may be performed, including:

-   Checking certificates for the presence of KRI (e.g., KRA identities,
    key recovery technique), \[SHOULD WE SPECIFY THE TYPRE OF
    CERTIFICATE?\]

-   Checking that KRI is available for a KRA (e.g., in a recipient list
    or a key recovery block),

-   Authenticating the source of the KRI,

-   Validating the integrity of KRI associated with the encrypted data
    (e.g., received in the same message), and

-   Verifying that the KRI is able to recover the data key needed to
    decrypt the encrypted data.

**2.5 Requestor Function**

The Requestor Function consists of the requestor and a Requestor System
(see Figure 3). The requestor is an entity who seeks to recover
information that will allow the decryption of encrypted data. A request
for a key recovery service, made by a requestor using a Requestor System
to interact with one or more Key Recovery Agents, must be an authorized
request \-- the requestor and the Requestor System which issues a
request for a key recovery service must have a legal and lawful right to
access the data that can be decrypted using the recovered target key.
Furthermore, the requestor and the Requestor System must establish their
right to access that data.

The requestor provides key recovery information to the requestor
system(s). The requestor system(s) interacts with one or more KRAs to
obtain either the target key, or multiple key parts or key related
information which will allow the reconstruction of the target key. The
target key can then be used to recover the data using a Data Recovery
System which is not specified in this standard.

![](media/image4.png){width="5.24375in" height="2.09375in"}

**2.6 Key Recovery Agent(s)**

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

**2.7 Interoperability**

Key recovery interoperability requirements apply for interoperable
applications when encrypted data is shared or communicated across
multiple end user systems. When KRI is generated for a specific instance
of encrypted data, the KRI should be placed in a commonly understood
structure (e.g., in a key recovery block or in the key exchange
information). The use of this common structure may allow different key
recovery techniques to interoperate and can be used to provide KRI which
is not otherwise available. See Appendix "KRB" for a suggested
structure.

Key recovery interoperability requirements also apply for communications
between a Requestor Function and a KRA. This standard defines a syntax
for communication between a Requestor Function and a KRA which pertains
only to electronic key recovery transactions effected via a
communication medium, e.g., telephone, LAN, Internet, etc. Recovery
transactions effected via other methods, e.g., storage on diskette or
tape, are not covered by these requirements. Section "KRR-KRA"defines
the syntax for this communication syntax. No interoperability
requirements are imposed by this standard on communication among KRAs.

There are a number of standard communication protocols (e.g., SSL,
S/MIME) that allow the use of encryption to protect the data carried by
the protocol. When encapsulated key recovery information is introduced
into one of these communication protocols, it must be done in a manner
that preserves interoperability. Interoperability with respect to this
standard includes communications between:

-   an end user system with a key recovery capability and another end
    user system with no key recovery capability, and

```{=html}
<!-- -->
```
-   two end user systems employing different key recovery techniques.

When this is not possible using the existing protocol, then either the
protocol must be modified or extended to carry the key recovery
information, or a different path may be used. In all cases, there must
be an unambiguous method for coupling the ciphertext with the key
recovery information. It is outside the scope of this standard to
specify how key recovery information is to be transported. The
definition of an interoperable means of carrying such information is
solely the purview of the protocol designer. Appendix "KRB" is provided
in order to assist in the development of key recovery-enabled protocols.

\[THE FOLLOWING PARAGRAPH REALLY BELONGS IN THE ASSURANCE SECTION.\]

> A vendor of a component which implements key recovery that is
> compliant with this standard must provide documentation demonstrating
> that the component transports key recovery information in a fashion
> which is consistent with the specification developed for the protocol
> in question.\[JAN MANNING WOULD LIKE TO DISCUSS THIS.\]

Within a Public Key Infrastructure (PKI), key recovery information may
be provided in the certificates of those entities using or supporting
key recovery. It is beyond the scope of this standard to define the
certificate structures to support key recovery. However, Appendix
"Certificate Extensions" is provided in order to assist in this process.

# 3 KRS {COMPONENTS/PRODUCTS}

The functions of the Key Recovery Model specified in this standard must
be implemented in components or products which, when used together with
a key recovery policy and procedures, form a Key Recovery System. The
key recovery functions within the model may be distributed across these
components as appropriate for the specific key recovery technique and
the key recovery policy adopted for an organization.

A key recovery policy specifies the conditions under which key recovery
information must be created and the conditions under which key recovery
information may be released. The policy may also indicate the allowable
Key Recovery Agent(s), how or where key recovery information must be
maintained, and whether or not the received encrypted information should
be processed when key recovery information is not available. The key
recovery policy could be "hardwired" (e.g.., implemented in a manner
which does not allow key recovery to be bypassed), selectable by a user,
or implemented in policy management tables or modules.

**3.1 End User Systems**

End user systems encrypt and decrypt data. In order for encrypted data
to be recoverable, the capability must exist for key recovery
information to be generated for that system that will allow the recovery
of data keys used by that system. The necessary information needed to
recover the data key may be made available, for example, as encapsulated
information which may be stored or communicated with the encrypted data,
or as cached data or both.

The model does not specify which system or systems generate the KRI.
When KRI is generated by end user systems, the KRI could be generated by
the entity that encrypts data (e.g., the sender) or the entity that
decrypts data (e.g., the receiver). An end user system generates and
processes KRI in accordance with a specified key recovery policy.

![](media/image5.png){width="3.7055555555555557in"
height="2.571527777777778in"}

Figure 4 depicts an end user application with an encryption/decryption
capability. The application has a send/receive function for sending and
receiving data, a key management function for generating and
distributing keys, and an encrypt/decrypt function to encrypt and
decrypt data. The key recovery functions within the end user system
includes a KRI Generation Function, a KRI Delivery Function, a KRI
Receive Function, and a KRI Validation Function.

Note that end user products need not contain this specific set of key
recovery functions (see Appendix "Examples"). The use of the functions
within an end user system can depend on whether the system is acting as
a sender or receiver system. When the application is acting as a sender,
it would typically use the KRI Generate and

Delivery Functions \[AND ALSO THE KRI VALIDATE FUNCTION?\], whereas when
acting as a receiver, it would typically make use of the KRI Recive and
Validaion Functions.

\[IN FIGURE 4, IS THE ARROW BETWEEN THE KRI VALIDATION AND GENERATION
FUNCTIONS APPROPRIATE?\]

**3.1.1 KRI Encapsulation**

![](media/image6.png){width="4.490277777777778in"
height="2.6173611111111112in"}Figure 5 illustrates the interaction of
two end user systems that share or communicate encrypted data using a
KRI encapsulation method for key recovery. For each end user system, key
recovery information (KRI) is encapsulated and made available for later
recovery by a requestor. The system creating the encapsulated KRI (End
User System A) can generate KRI for itself. If KRI is to be made
available for the other party (End User System B), then System A must
acquire enough information to do so (e.g., from a certificate) using its
KRI Receive and Validation functions. The set of KRI to be encapsulated
is then provided to the KRI Delivery Function, where the KRI is
assembled, formatted and wrapped (i.e., encrypted) and delivered.

System B may receive the KRI as well as the encrypted data and key
exchange information. The KRI received by the KRI Receive Function may
be provided to a KRI Validation Function. The amount of validation that
is performed is dependent on the structure and content of the KRI, the
key recovery technique used and the validation policy of the receiving
end user system. Validation may include checking that the key recovery
technique used by System A is appropriate (e.g., by examining System A's
certificate).

**3.1.2 Key Caching**

Figure 6 illustrates the interaction of two end user systems that share
or communicate encrypted data using a key caching method for key
recovery. For each end user system, keys, key parts or key related
information to be recovered are stored (i.e., cached) at the KRA. In
this method, a KRI Provider, using KRI Generation and Delivery
Functions, generates the key information and distributes the appropriate
information to the KRA(s). If the KRI Provider who generates the key
information is not the end user system, then the appropriate key
information must also be supplied to the end user system.

![](media/image7.png){width="4.490277777777778in" height="2.95625in"}

The encrypting party (System A) can determine that the other party
(System B) is using a key caching method of key recovery by acquiring
this information from some source (e.g., a certificate) using its KRI
Validation and Receive Functions. If the data key used to encrypt the
data is available (e.g., as part of the key exchange process),
additional KRI recovery information is not required for System B to
recover. However, for System A to recover, encapsulated information must
be provided (e.g., by encrypting a copy of the data key for System A and
placing it in a recipient list or in a key recovery block) using the KRI
Generation and Delivery Functions (shown by the dotted lines in the
figure). \[NOT SURE HOW TO WORD THIS TO ALLOW FOR THE DIFFERENT KEY
EXCHANGE METHODS.\]

As long as the decrypting party (End User System B) knows that the
encrypted data key is readily available (e.g., as part of the key
exchange process), System B can recover. If it is necessary to determine
that System A is also recoverable, System B must use the KRI Validation
and Receive Functions to determine that System A uses key caching, then
examine the available information to determine that KRI is available for
System A.

**3.1.3 Mixed Methods**

Key recovery may be provided between end user systems with different key
recovery capabilities. Key recovery may also be provided for those key
recovery enabled entities that communicate with other entities with no
key recovery capability.

**3.1.3.1 Between KRI Encapsulation and Key Caching Methods**

In Figure 7, System A uses a KRI encapsulation method for key recovery;
System B uses key caching. System A can use its KRI Receive and
Validation Functions to determine that System B uses key caching (e.g.,
by examining System B's certificate). System A can create encapsulated
KRI for itself using its KRI Generation Function; KRI need not be
created for System B if the data key is supplied to System B in such a
way that the data key is recoverable using System B's cached
information. The generated KRI is provided to System A's KRI Delivery
Function.

![](media/image8.png){width="5.090277777777778in"
height="3.4409722222222223in"}

System B can ignore the encapsulated KRI unless System B's policy is to
ensure that System A is recoverable. In this case, System B's KRI
Receive and Validation Functions acquire information about System A's
key recovery capability (e.g., by examining System A's certificate),
acquire the encapsulated KRI and validate that KRI. Note that the degree
of validation depends on the implementation of System B's validation
function.

![](media/image9.png){width="5.090277777777778in"
height="3.4409722222222223in"}In Figure 8, System A uses Key Caching,
and System B uses KRI Encapsulation. System A can use its KRI Receive
and Validation Functions to determine that System B uses KRI
encapsulation (e.g., by examining System B's certificate). For System A
to recover, encapsulated information must be provided (e.g., by
encrypting a copy of the data key for System A and placing it in a
recipient list or in a key recovery block) using the KRI Generation and
Delivery Functions. Note that for some key exchange schemes, the key
exchange mechanism may perform the KRI generation and delivery
functions. System A could encapsulate another copy of the data key for
System B's KRA if this method is consistent with System B's KRI
encapsulation technique; otherwise, no KRI can be provided for recovery
by System B.

System B can use its KRI Receive and Validate Functions to determine the
type of key recovery employed by System A (e.g., by examining System A's
certificate) and check for the presence of the encapsulated KRI for
System A. If encapsulated KRI is not available for System B, System B
can create encapsulated KRI in accordance with its key recovery
technique.

**3.1.3.2 Between KRI Encapsulation and an End User System with No Key
Recovery**

In Figure 5, if System A uses KRI encapsulation and System B has no key
recovery capability, System A can only provide encapsulated KRI for
itself. The encapsulated KRI received from System A cannot be processed
by System B. If the roles are reversed and System A receives encrypted
data from System B, no KRI is present. If System A needs to recover, it
must add its own encapsulated KRI.

**3.1.3.3 Between Key Caching and an End User System with No Key
Recovery**

In Figure 8, if System A uses Key Caching and System B has no key
recovery capability, System A can recover only if encapsulated
information is created by the KRI Generation and Delivery Functions
(e.g., by encrypting a copy of the data key for System A and placing it
in a recipient list or in a key recovery block). System B must be able
to ignore the presence of the KRI. If the roles are reversed and System
B sends encrypted data to System A, System A can recover if the data key
is recoverable using System A's cached key.

**3.2 Requestor System**

A Requestor System consists of the Requestor Function and associated key
recovery policy and procedures. The key recovery policy and procedures
govern the configuration of the system and the interaction with the
requestor(s) and the KRA(s). Key recovery is not automatic; it must be
specifically requested using the Requestor System. The Requestor System
may exist as a separate component or product, or the Requestor System
may be included in other products (e.g., an end user system or KRA
system). More than one Requestor System may exist within a KRS.

\[WHAT MORE NEEDS TO BE SAID?\]

**3.3 Key Recovery Agent (KRA) System**

A KRA System consists of the KRA Function and associated key recovery
policy and procedures. The key recovery policy and procedures govern the
configuration of the system and the interaction with the requestor
system(s). The KRA System may exist as a separate component or product,
or the Requestor System may be included in other products (e.g.,
included with the Requestor System).

The algorithm for processing the key recovery information is dependent
on the algorithm originally used to protect the key recovery
information, i.e. it is algorithm specific. There are many algorithms
for creating the key recovery information and reconstructing the key
from that key recovery information. For example, the output value
calculated by the KRA 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.

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

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

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

**3.4.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 9.

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

**Figure 9 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 10.

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

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

**3.4.4 Licensing Agent**

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

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

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

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

**3.4.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 11.

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

Figure 11 Private Key Recovery Example - Normal Encrypted Communications

**3.4.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
12.

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

Figure 12 Private Key Recovery Example - Normal Encrypted Storage

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

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

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

**3.4.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 13.

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

Figure 13 Key Encapsulation Example - Normal Encrypted Communications

**3.4.5.2.3 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 14.

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

Figure 14 Key Encapsulation Example - Normal Encrypted Storage

**3.4.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 INTEROPERABILITY

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

**4.2 Interoperability Components**

In order to certify interoperability, it is necessary to describe 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

-   Key Recovery Agent

-   Key Recovery Medium

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

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

**4.4 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 the protocol 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.

# 

# 5 FUNCTIONAL REQUIREMENTS

**5.1 General Requirements**

**5.2 End User System Requirements**

5.2.1 The end user system shall be capable of ensuring that transmission
or storage of encrypted data is contingent on the generation and
availability of the corresponding KRI. [This function may be statically
enabled, or may be controlled by a configuration parameter under the
control of a System Administrator.]{.mark}

5.2.2 An end user system, when used for decryption, shall be capable of
ensuring that authentic KRI is available prior to decryption

**5.3 KRI Generation Function**

5.3.1 The KRI Generation Function generates all or part of the KRI.

5.3.2 The KRI Generation Function shall make the generated KRI available
to the KRI Delivery Function.

**5.4 KRI Delivery Function**

5.4.1 The KRI Delivery Function shall format the KRI for consumption by
the KRI Recognition [\[Receive?\]]{.mark} Function (if present) and Key
Recovery Function and, optionally, for the KRA Function. The format of
the KRI may be KR system-specific. However, if KRI is delivered in
conjunction with a standard communication protocol, the (transmission)
format of the KRI is determined by that protocol standard.

5.4.2 The KRI Delivery Function shall make the KRI available to the key
recovery function (requestors or KRAs or a combination of both). The
term "make available" is system dependent and includes sending the KRI
to the Key Recovery Requestor directly, or depositing the KRI in
location(s) known to and accessible to the Key Recovery Requestor (i.e.,
the requestor(s)). A KRI Delivery Function must ensure that the
persistence and availability of the KRI is commensurate with that of the
transmitted or stored data. For example, in a communication context, KRI
need not be transmitted with every packet, but may have to be
periodically retransmitted to facilitate requestor access for a very
long lived communication session. (Note that the underlying
communication or storage system is not considered to be part of the KRI
Delivery Function.)

5.4.3 The KRI Delivery Function shall provide an implicit or explicit
association between the KRI and the encrypted data.

5.4.4 The KRI Delivery Function shall be capable of ensuring that the
validity of the KRI can be verified by the KRI Validation Function.

**5.5 KRI Recognition [\[Receive?\]]{.mark} Function**

5.5.1 When the receipt of KRI is not transparent to a receiving system
(see interoperability requirements), a KRI Recognition
[\[Receive?\]]{.mark} Function must be employed by the receiver. (The
KRI Recognition [\[Receive?\]]{.mark} Function is required only for key
recovery enabled communication systems.)

**5.6 KRI Validation Function**

5.6.1 For a level 2 compliant component, the KRI Validation Function
shall verify the association between the KRI and the encrypted data.

5.6.2 The KRI Validation Function shall be capable of verifying the
validity of the KRI. The intent of this function is to provide assurance
that a Key Requestor can successfully recover encrypted data using the
KRI. The level of assurance provided [\...]{.mark}

**5.7 [Requestor]{.mark} Function**

5.7.1 For given KRI, the ~~Requestor System within~~ the Requestor
Function shall have the ability to recover a [target]{.mark} key by
interacting with one or more Key Recovery Agents.

5.7.2 For encapsulated KRI, the Requestor Function shall have the
ability to store KRI provided by the KRI Management
[\[Delivery?\]]{.mark} Function.

**5.8 Key Recovery Agent Function**

5.8.1 The KRAs shall have the ability to store the KRI provided by the
KRI Management [\[Delivery?\]]{.mark} Function.

5.8.2 The KRAs shall have the ability to process the KRI provided by the
Requestor Function.

5.8.3 The Key Recovery [Agent]{.mark} Function shall protect the
integrity of the KRI received from the KRI Management
[\[Delivery?\]]{.mark} Function.

**6 SECURITY REQUIREMENTS**

The security requirements for the KRA and for the Requestor functions
have been defined to allow a variety of product architectures. These
include using a monolithic product on which no other software/firmware
can be loaded, using a monolithic product on which other
software/firmware can be loaded, or using a layered product that has a
distinct operating system, application, and cryptographic module.

The requirements for the KRA and the Requestor functions have been
defined so that all of these architectures can be evaluated. This is
especially true of the requirements in the following areas: Audit,
Identification and Authentication, some of the Access Control, and
Protection of Trusted Security Functions.

Furthermore, the product architecture may imply some of the requirements
do not apply, e.g., if the threat a requirement is supposed to mitigate
does not arise in a particular implementation model. For example, if the
product is a monolith on which no other software/firmware can be loaded,
the domain separation, trusted path, and reference validation mechanism
requirements do not apply since the untrusted software threat does not
exist.

**6.1 Key Recovery Agent Requirements**

**6.1.1 Level 1 -- Medium Assurance**

**6.1.1.1 Cryptographic Functions**

6.1.1.1.1 All cryptographic modules shall be FIPS 140-1, Level 2 or
higher compliant.

**6.1.1.2 Cryptographic Algorithms**

6.1.1.2.1 The key recovery scheme shall be implemented so that only FIPS
approved

> algorithms are required to use it. The implementation of these
> algorithms shall
>
> conform to the applicable FIPS.

(Note: It was requested that the above section be moved under
confidentiality. It is left here is since there are aspects to various
schemes that are not related to confidentiality, e.g., source
authentication, binding to encrypted data, integrity, etc. After the
committee reviews this draft, this note will be deleted.)

**6.1.1.3 Confidentiality:**

These requirements are intended to protect against both the outsider and
insider threats. The only insider threat addressed is the unauthorized
user. Authorized insider threat is handled elsewhere using audit, role
separation, and multi-person control.

6.1.1.3.1 The KRA shall protect all key recovery information stored
against disclosure to unauthorized individuals.

6.1.1.3.2 The KRA shall protect key recovery information transmitted -
electronically or physically communicated against disclosure to parties
other than the requestor(s).

6.1.1.3.3 The strength of the algorithm used to protect the key recovery
information shall be greater than or equal to the maximum strength of
the encryption or key management algorithms employed for user traffic
encryption or for generation of the keys being recovered.

**6.1.1.4 Audit**

These requirements are used to create a log of information to allow
oversight by a security officer to detect unauthorized operations by a
key recovery agent.

6.1.1.4.1 The product shall be capable of generating an audit record for
the following events:

• Start-up and shutdown of the audit functions; and

-   All auditable events as defined in the functional components
    included in this standard; (**FAU_GEN.1.1)**

6.1.1.4.2 The following actions shall be auditable:

-   Any specific operation performed to process audit data stored in the
    audit trail. (Note:This include backup and deletion of audit trail)

```{=html}
<!-- -->
```
-   Any attempt to read, modify or destroy the audit trail.

```{=html}
<!-- -->
```
-   All requests to use authentication data management mechanisms.

```{=html}
<!-- -->
```
-   All modifications to the audit configuration that occur while the
    audit collection functions are operating.

```{=html}
<!-- -->
```
-   All requests to access user authentication data

```{=html}
<!-- -->
```
-   Any use of an authentication mechanism. (e.g. login) The
    authentication information shall not be stored in the audit trail.

```{=html}
<!-- -->
```
-   All attempts to use the user identification mechanism, including the
    user identity provided.

```{=html}
<!-- -->
```
-   Any attempt to perform an operation on the audit trail. (including
    emptying the audit trail)

```{=html}
<!-- -->
```
-   Use of a security-relevant administrative function;

```{=html}
<!-- -->
```
-   Explicit requests to assume the security administrative role;

```{=html}
<!-- -->
```
-   The allocation of a function to a security administrative role.

```{=html}
<!-- -->
```
-   The addition or deletion of a user to/from a security administrative
    role.

```{=html}
<!-- -->
```
-   The association of a security-relevant administrative function with
    a specific security administrative role.

6.1.1.4.3 The following actions shall be audited. The keys shall not be
included in the audit:

-   Requests, responses, and other transactions generated by the
    product, including key recovery responses.

```{=html}
<!-- -->
```
-   Requests, responses, and other transactions received by the product,
    including key recovery requests.

6.1.1.4.4 The product shall record within each audit record at least the
following information:

-   Date and time of the event, type of event, subject (user) identity,
    and success or failure of the event; and

```{=html}
<!-- -->
```
-   Other information, as described in the functional component audit
    events **(FAU_GEN.1.2)**

6.1.1.4.5 The product shall be able to generate a human understandable
presentation of any audit data stored in the permanent audit trail.
(**FAU_POP.1.1)**

6.1.1.4.6 The audit trail shall not store the old or new authentication
information (e.g., password)

6.1.1.4.7 The product shall be able to associate each auditable event
with the identity of the user that caused the event. (**FAU_GEN.2.1)**

6.1.1.4.8 The product shall provide the authorized administrator with
the ability to empty the audit trail. (**FAU_MGT.1.1)** (Note: emptying
the audit trail means backup and delete).

6.1.1.4.9 The product shall be able to include or exclude auditable
events from the set of audited events based on the following attributes:
User identity, and/or Event Type **(FAU_SEL.1.1)** (Note: The
requirement applies to the auditable (i.e. optionally audited) events
only. The mandatory audited events must never be excluded or excludable
from the set of audited events.)

6.1.1.4.10 The product shall store generated audit records in a
permanent audit trail. (**FAU_STG.1.1)**

6.1.1.4.11 The product shall restrict access to the audit trail to the
authorized administrator. **(FAU_PRO.1.1)**

(Note: This requirement implies providing integrity to the audit trail)

**6.1.1.5 Identification and Authentication**

These requirements permit the unique identification of key recovery
agent personnel. This facilitates individual accountability via audit
functions and access controls. Requirements are levied on the strength
of the authentication mechanism and the robustness of the authentication
mechanism against attacks by rogue key recovery agent personnel.

These requirements do not apply to electronic transactions (requests and
responses). The electronic transactions may be identified and
authenticated (if the scheme permits) using the access control policy.

6.1.1.5.1 The product shall provide functions for initializing and
modifying KRA personnel authentication data. (**FIA_ADA.3.1)**

6.1.1.5.2 The product shall restrict the use of these functions on the
KRA personnel authentication data for any user to the authorized
administrator. (**FIA_ADA.3.2)**

(Note: The above function shall be assigned to the security
administrator.)

6.1.1.5.3 The product shall allow authorized KRA personnel to use these
functions to modify their own authentication. (**FIA_ADA.3.3)**

6.1.1.5.4 The product shall protect from unauthorized observation,
modification, and destruction authentication data that is stored in the
product.

5.  The product shall protect authentication information from
    unauthorized reuse, including replay.

(Note: The above two requirements provide capability for secure remote
login.)

6.1.1.5.6 The product shall be able to terminate the KRA personnel
session establishment process after five unsuccessful authentication
attempts. (**FIA_AFL.1.1)**

(Note: If the product terminates the session after fewer than five
unsuccessful attempts, the product meets the above requirement)

6.1.1.5.7 After the termination of a KRA user session establishment
process, the product shall be able to disable the user account until
account is enabled by an authorized administrator (i.e., security
administrator). (**FIA_AFL.1.2)**

6.1.1.5.8 The product shall authenticate any KRA user's claimed identity
prior to performing any functions on the user's behalf.
(**FIA_UAU.1.1)**

6.1.1.5.9 The product shall uniquely identify each KRA user before
performing any actions requested by the user. **(FIA_UID.2.1)**

6.1.1.5.10 The product shall provide a mechanism to verify that secrets
(i.e., authentication information such as passwords) meet the FIPS PUB
112 "Password Usage" and Department of Defense Password Management
Guideline (CSC-STD-002-85).

(Note: The above requirement implies that the product (as opposed to
procedural means and management instructions) will enforce the password
length, aging, etc. type requirements. If we do not want product to
enforce the requirement, the above requirement should be deleted)

**6.1.1.6 Access Control**

These requirements provide countermeasures against entities masquerading
as an authorized requestor or key recovery information generator. The
requirements in this section address the security of electronic
communication between the KRA and the requestor or information
generator. If these interactions are not electronic, then physical and
procedural means may be used to secure the transactions. These
procedural and physical measures are beyond the scope the standard.

6.1.1.6.1 The product shall verify the source of received transactions.
(**FPT_ACP.1.1)**

6.1.1.6.2 The product shall verify the integrity of received
transactions.

6.1.1.6.3 The product shall decrypt the received transactions which are
encrypted. (**FPT_ACP.1.2)**

6.1.1.6.4 The product shall apply source authentication to all
transactions (i.e., requests and responses). (**FPT_ACP.1.3)** The
strength of the algorithm used for authentication shall be greater than
or equal to the maximum strength of the encryption or key management
algorithms employed for user traffic encryption or for generation of the
keys being recovered.

6.1.1.6.5 The product shall apply integrity services to all
transactions. The strength of the algorithm used for integrity shall be
greater than or equal to the maximum strength of the encryption or key
management algorithms employed for user traffic encryption or for
generation of the keys being recovered.

6.1.1.6.6 The product shall apply confidentiality services to all
transactions. The strength of the algorithm used for confidentiality
shall be greater than or equal to the maximum strength of the encryption
or key management algorithms employed for user traffic encryption or for
generation of the keys being recovered.

6.1.1.6.7 The product shall unambiguously associate the response to an
outstanding request. The strength of the algorithm used for the
association shall be greater than or equal to the maximum strength of
the encryption or key management algorithms employed for user traffic
encryption or for generation of the keys being recovered.

6.1.1.6.8 The product shall release the keys only to authorized users.

6.1.1.6.9 The product shall release a key only if the requester is
authorized to receive the key associated with the user specified in the
request and for the validity period (time interval).

6.1.1.6.10 The product shall ensure that security features are always
invoked and cannot be bypassed. **(FPT_RVM.1.1)**

6.1.1.6.11 The product shall maintain a security domain for its own
execution that protects it from interference and tampering by untrusted
subjects. (**FPT_SEP.1.1)**

6.1.1.6.12 The product shall enforce separation between the security
domains of subjects in the system. (**FPT_SEP.1.2)**

6.1.1.6.13 The product shall distinguish between security-relevant
administrative functions from other functions. (**FPT_TSA.2.1)**

6.1.1.6.14 The set of security-relevant administrative functions shall
include all functions necessary to install, configure, and manage the
product; minimally, this set shall include assignment/deletion of
authorized users from security administrative roles, association of
security-relevant administrative commands with security administrative
roles, assignment/deletion of subjects whose keys are held,
assignment/deletion of parties who may be provided the keys, product
cryptographic key management, actions on the audit log, audit profile
management, and changes to the system configuration. (**FPT_TSA.2.2)**

6.1.1.6.15 The product shall restrict the ability to perform
security-relevant administrative functions to a security administrative
role that has a specific set of authorized functions and
responsibilities. (**FPT_TSA.2.3)**

(Note: The term security administrative role refers to generic trusted
administrative roles. Security administrator role is one, but not the
only one, of these security administrative roles.)

6.1.1.6.16 The product shall be capable of distinguishing the set of KRA
operators authorized for administrative functions from the set of all
other users. (**FPT_TSA.2.4)**

6.1.1.6.13 The product shall allow only specifically authorized KRA
operators to assume the security administrative role. (**FPT_TSA.2.5)**

6.1.1.6.14 The product shall require an explicit request to be made in
order for an authorized KRA operator to assume the security
administrative role. (**FPT_TSA.2.6)**

**6.1.1.7 Non-Repudiation**

These capabilities facilitate trusted time source to further support
accountability.

6.1.1.7.1 The product shall be able to provide reliable time stamps for
its own use. **(FPT_STM.1.1)**

6.1.1.7.2 The product shall be able to generate evidence of receipt for
received transactions. (**FCO_NRR.2.1)**

(Note: The above requirement means using the reliable time stamp to
requirement to put a trusted time stamp on the receipt. Furthermore,
this requirement means that the product shall be able to generate
evidence of receipt of: registration or deposit of key recovery
information from users, and requests from requestor)

**6.1.1.8 Availability**

These requirements are intended to provide the capability for a key
recovery agent to recover in the event of a system failure or
compromise. They act as a counter to the threat of the unauthorized
destruction of the key recovery information or capabilities at the key
recovery agent facility.

6.1.1.8.1 The KRA facility shall have the capability to securely
replicate any key recovery information stored.

(Note: The intent of the above requirement is for continued on-line
access in case of a facility failure. In light of that, should this be a
requirement on the component since it is a system architecture issue.
Please note that the multiple KRAs requirement at Level 2 is to prevent
one KRA from compromising key recovery information)

6.1.1.8.2 The KRA facility shall have a secure backup of the key
recovery information stored.

(Note: The intent of the above requirement is for ability to rebuild the
key recovery database in case of KRA system failure. In light of that,
should this be a requirement on the component since this a facility
operations related issue)

**6.1.1.9 Protection of Trusted Security Functions**

6.1.1.9.1 Before establishing a session with KRA operator, the product
shall display an advisory warning message regarding unauthorized use of
the product. (**FTA_TAB.2.1)**

6.1.1.9.2 The default advisory warning message displayed by the product
shall be as follows: "This system shall be used only by authorized
personnel and only for authorized key recovery purposes. Violation shall
result in criminal prosecution and civil penalties". (**FTA_TAB.2.2)**

6.1.1.9.3 The product shall restrict the capability to modify the
warning message to the authorized administrator. (**FTA_TAB.2.3)**

6.1.1.9.4 Upon successful session establishment, the product shall
display the date, time, method, and port of the last successful session
establishment to the KRA operator. (**FTA_TAH.1.1)**

6.1.1.9.5 Upon successful session establishment, the product shall
display the date, time, method, and location of the last unsuccessful
attempt to session establishment and the number of unsuccessful attempts
since the last successful session establishment. (**FTA_TAH.1.2)**

6.1.1.9.6 The data specified above shall not be removed without KRA
operator intervention. **(FTA_TAH.1.3)**

**6.1.2 Level 2 -- High Assurance**

**6.1.2.1 Cryptographic Functions**

6.1.2.1.1 All cryptographic modules shall be FIPS 140-1, Level 3 or
higher compliant.

**6.1.2.2 Cryptographic Algorithms**

Same as Level 1

**6.1.2.3 Confidentiality:**

Level 2 requires additional protection against the insider threat of a
rogue key recovery agent by requiring multi-party control on access to
the key recovery information.

All level 1 requirements and;

6.1.2.3.1 The system shall be designed for multiple KRAs. Two or more
KRAs shall be required to obtain the key recovery information.

**6.1.2.4 Audit:**

Level 2 adds a real time alarm to the security officer in the event of
the audit trail becoming full to prevent audit data from being lost. It
also requires the auditing of additional events consistent with the
additional security requirements (i.e. trusted path) added at Level 2.

Includes all the requirements of Level 1 and;

6.1.2.4.1 The product shall generate an alarm to the authorized
administrator if the size of the audit data in the audit trail exceeds a
pre-defined limit. (**FAU_MGT.4.1)**

6.1.2.4.2 The product shall provide the authorized administrator with
the ability to manage the audit trail at any time during the operation
of the product. (**FAU_MGT.4.2)**

6.1.2.4.3 The following actions shall be auditable:

-   Execution of the tests of the underlying machine and the results of
    the tests.

-   All attempted uses of the trusted path functions.

-   Identification of the initiator and target of the trusted path.

-   Attempts to provide invalid inputs for administrative functions

-   The invocation of the non-repudiation service. The audit event shall
    include identification of the information, the destination, and a
    copy of the evidence provided. The event shall exclude all private
    and secret keys in encrypted or unencrypted form.

**6.1.2.5 Identification and Authentication**

Level 2 enhances assurance by supporting a hardware token. This provides
an additional countermeasure to the threat of an attack on the
authentication mechanism and the subsequent unauthorized access to key
recovery information or critical functions.

All Level 1 requirements and the following;

6.1.2.5.1 The product shall support a token based authentication. The
token shall meet FIPS 140-1 Level 2 requirements.

**6.1.2.6 Access Control**

Level 2 requires multi-party access controls for release of key recovery
information and establishes roles and responsibilities for key recovery
facility personnel as additional countermeasures to the threat of a
single rogue key recovery agent.

All Level 1 requirements and the following;

6.1.2.6.1 The KRA shall embody a facility for multi-party (at least 2)
authorization in support of the release of key material.

(Note: The following requirements are to provide for strict role
separation)

6.1.2.6.2 The product shall distinguish security-relevant administrative
functions from other functions. (**FPT_TSA.3.1)**

6.1.2.6.3 The set of security-relevant administrative functions shall
include all functions necessary to install, configure, and manage the
product; minimally, this set shall include assignment/deletion of
authorized users from security administrative roles, association of
security-relevant administrative commands with security administrative
roles, assignment/deletion of subjects whose keys are held,
assignment/deletion of parties who may be provided the keys, product
cryptographic key management, actions on the audit log, audit profile
management, and changes to the system configuration. (**FPT_TSA.3.2)**

6.1.2.6.4 The product shall restrict the ability to perform a
security-relevant administrative function to the security administrative
role(s) authorized to use that function. (**FPT_TSA.3.3)**

6.1.2.6.5 The product shall be capable of distinguishing the set of
users authorized for administrative functions from the set of all other
users. (**FPT_TSA.3.4)**

6.1.2.6.6 The product shall allow only specifically authorized users to
assume only those security administrative roles for which they have been
authorized. (**FPT_TSA.3.5)**

6.1.2.6.7 The product shall require an explicit request to assume a
specific security administrative role to be made in order for an
authorized user to assume that security administrative role.
(**FPT_TSA.3.6)**

6.1.2.6.8 The product shall define a set of security administrative
roles that minimally includes security administrator, system operator,
crypto officer and audit administrator. (**FPT_TSA.3.7)**

6.1.2.6.9 The security administrator shall perform the following
functions: assignment/deletion of authorized users from security
administrative roles, association of security-relevant administrative
commands with security administrative roles, assignment/deletion of
subjects whose keys are held, and assignment/deletion of parties who may
be provided the keys.

6.1.2.6.10 The system operator shall change system configuration and run
the system.

6.1.2.6.11 The crypto officer shall manage the cryptographic keys.

6.1.2.6.12 The audit administrator shall manage audit log and audit
profiles.

6.1.2.6.13 The product shall associate each security-relevant
administrative function with at least one security administrative role.
(**FPT_TSA.3.8)**

6.1.2.6.14 The product shall enforce checks for valid input values for
security-relevant administrative functions as described in the
Administrative guidance. (**FPT_TSU.1.1)**

**6.1.2.7 Non Repudiation**

Level 2 requires additional capabilities to prove the origin of
transmissions to allow recipients to counter the threat of an adversary
spoofing as a Key Recovery Agent.

All Level 1 requirements and the following:

6.1.2.7.1 The product shall generate evidence of origin for transmitted
key recovery requests or responses. (**FCO_NRO.1.1)**

(Note: The above requirement shall also the reliable time stamp service
to include the time in the evidence)

6.1.2.7.2 The product shall provide a capability to verify the evidence
of origin of information to the recipient. (**FCO_NRO.1.3)**

6.1.2.7.3 The product shall provide a capability to verify the evidence
of receipt of proof of receipt to the originator of message (i.e.,
recipient of proof of receipt). (**FCO_NRR.2.3)**

6.1.2.7.4 The product shall provide the originator the ability to
request evidence of receipt on information. **(FCO_NRR.2.3)**

**6.1.2.8 Availability**

Same as Level 1.

**6.1.2.9 Protection of Trusted Security Functions**

Same as Level 1 and the following:

6.1.2.9.1 The product shall provide a communication path between itself
and local human users that is logically distinct from other
communication paths and provides assured identification of its
endpoints. (**FTP_TRP.1.1)** (This communication path is generally
called a trusted path.)

6.1.2.9.2 The local human users shall have the ability to initiate
communication via the trusted path. (**FTP_TRP.1.2)**

6.1.2.9.3 The product shall require the use of the trusted path for
initial user (i.e., KRA operator) authentication. (**FTP_TRP.1.3)**

6.1.2.9.4 The product shall provide the authorized administrator with
the capability to demonstrate the correct operation of the
security-relevant functions provided by the underlying abstract machine.
(**FPT_AMT.1.1)**

6.1.2.9.5 The product shall preserve a secure state when abstract
machine tests fail. (**FPT_FLS.1.1)**

**6.2 Key Recovery Information Generator**

**6.2.1 Level 1 -- Medium Assurance Key Recovery Information Generator**

**6.2.1.1 Cryptographic Functions**

6.2.1.1.1 All cryptographic modules shall be FIPS 140-1, Level 1
compliant.

**6.2.1.2 Cryptographic Algorithms**

6.2.1.2.1 The key recovery scheme shall be implemented so that only FIPS
approved algorithms are required to use it. The implementation of these
algorithms shall conform to the applicable FIPS standard(s).

**6.2.1.3 Confidentiality**

This requirement is intended to minimize the vulnerability created by
the key recovery mechanism. The key recovery mechanism should not be
weaker and thus easier to attack than the original encryption mechanism.

6.2.1.3.1 The strength of the algorithm used to protect the key recovery
information shall be greater than or equal to the maximum strength of
the encryption or key management algorithms employed for user traffic
encryption or for generation of the keys being recovered.

4.  **Integrity**

These requirements counter the threat of a single end user or an
outsider corrupting the key recovery information.

6.2.1.4.1 The product shall provide the capability to detect
modifications to key recovery information.

6.2.1.4.2. The product shall unambiguously associate the key recovery
information with the data.

6.2.1.4.3 The product shall provide the capability to detect
modifications to the association of the key recovery information to the
data.

**6.2.1.5** **Key Recovery** **Configurability**

6.2.1.5.1 The key recovery mechanism in the end user product shall be
always activated/deactivated by the system administrator.

(Note: The above requirement will be taken out if it appears some place
else.)

(Note: In order to meet the above requirement the crypto module FIPS
140-1 level 1 requirement must be augmented to provide role-based
authentication.)

**6.2.2 Level 2 -- High Assurance Key Recovery Information Generator**

**6.2.2.1 Cryptographic Functions**

6.2.2.1.1 All cryptographic modules shall be FIPS 140-1, Level 2
compliant.

**6.2.2.2 Cryptographic Algorithms**

Same as Level 1

**6.2.2.3 Confidentiality**

Same as Level 1

**6.2.2.4 Integrity**

All of Level 1 requirements and;

6.2.2.4.1 The product shall provide the capability for the decryptor to
verify that the key recovery information can be successfully used to
decrypt the data.

**6.2.2.5** **Configurability**

6.2.2.5.1 The key recovery mechanism shall be always activated in the
end user product.

(Note: The above requirement will be taken out if it appears some place
else.)

**6.3 Key Recovery Information Delivery**

**6.3.1 Level 1 -- Key Recovery Information Delivery**

**6.3.1.1 Availability**

**6.3.1.2** The product shall make the key recovery information
available on the key recovery information medium.

**6.3.2 Level 2 -- Key Recovery Information Delivery**

Same as Level 1.

**6.4 Key Recovery Information Recognizer**

No security requirements.

**6.5 Key Recovery Information Validator**

**6.5.1 Level 1 -- Medium Assurance Key Recovery Information Validator**

**6.5.1.1 Cryptographic Functions**

6.5.1.1.1 All cryptographic modules shall be FIPS 140-1, Level 1
compliant.

**6.5.1.2 Cryptographic Algorithms**

6.5.1.2.1 The key recovery scheme shall be implemented so that only FIPS
approved algorithms are required to use it. The implementation of these
algorithms shall conform to the applicable FIPS standard(s).

6.5.1.3 Integrity. These requirements counter the threat of a single end
user or an outsider corrupting the key recovery information.

6.5.1.3.1 The product shall provide the capability to verify integrity
of recovery information.

6.5.1.3.2 The product shall have the capability to verify the
association of the key recovery information with the data.

6.5.1.3.3 The product shall provide the capability to verify the
integrity of the association of the key recovery information to the
data.

**6.5.2 Level 2 -- High Assurance Key Recovery Information Validator**

**6.5.2.1 Cryptographic Functions**

6.5.2.1.1 All cryptographic modules shall be FIPS 140-1, Level 2
compliant.

**6.5.2.2 Cryptographic Algorithms**

Same as Level 1

**6.5.2.3 Integrity**

All of Level 1 requirements and;

6.5.2.3.1 The product shall provide the capability to verify that the
key recovery information can be successfully used to decrypt the data.

**6.6** **Key Recovery Requestor**

The security requirements for the KRA and for the Requestor functions
have been defined to allow a variety of product architectures. These
include using a monolithic product on which no other software/firmware
can be loaded, using a monolithic product on which other
software/firmware can be loaded, or using a layered product that has a
distinct operating system, application, and cryptographic module.

The requirements for the KRA and the Requestor functions have been
defined so that all of these architectures can be evaluated. This is
especially true of the requirements in the following areas: Audit,
Identification and Authentication, some of the Access Control, and
Protection of Trusted Security Functions.

Furthermore, the product architecture may imply some of the requirements
do not apply, e.g., if the threat a requirement is supposed to mitigate
does not arise in a particular implementation model. For example, if the
product is a monolith on which no other software/firmware can be loaded,
the domain separation, trusted path, and reference validation mechanism
requirements do not apply since the untrusted software threat does not
exist.

**6.6.1 Level 1 -- Medium Assurance**

**6.6.1.1 Cryptographic Functions**

6.6.1.1.1 All cryptographic modules shall be FIPS 140-1, Level 2 or
higher compliant.

**6.6.1.2 Cryptographic Algorithms**

6.6.1.2.1 The key recovery requests and responses shall be implemented
so that only FIPS approved algorithms are required to use them. The
implementation of these algorithms shall conform to the applicable FIPS
standard(s).

**6.6.1.3 Confidentiality**

6.6.1.3.1 The requestor shall protect key recovery information received
and/or stored against disclosure to unauthorized individuals. (Note:
Storing the data encrypted and implementing access controls is one way
to meet this requirement)

6.6.1.3.2 The requestor shall protect key recovery request (specially
the identities of subjects and time periods, if applicable) transmitted
against disclosure to parties other than the KRA. (Note: Encryption of
the request is one way to meet this requirement.)

**6.6.1.4 Audit**

6.6.1.4.1 The product shall be capable of generating an audit record for
the following events:

-   Start-up and shutdown of the audit functions; and

```{=html}
<!-- -->
```
-   All auditable events as defined in the functional components
    included in this standard; (**FAU_GEN.1.1)**

6.6.1.4.2 The following actions shall be auditable:

-   Any specific operation performed to process audit data stored in the
    audit trail. (Note:

-   This include backup and deletion of audit trail)

-   Any attempt to read, modify or destroy the audit trail.

-   All requests to use authentication data management mechanisms.

-   All modifications to the audit configuration that occur while the
    audit collection functions are operating.

-   All requests to access user authentication data

-   Any use of an authentication mechanism. (e.g. login) The
    authentication information shall not be stored in the audit trail.

-   All attempts to use the user identification mechanism, including the
    user identity provided.

-   Any attempt to perform an operation on the audit trail.

-   Use of a security-relevant administrative function;

-   Explicit requests to assume the security administrative role;

-   The allocation of a function to a security administrative role.

-   The addition or deletion of a user to/from a security administrative
    role.

-   The association of a security-relevant administrative function with
    a specific security administrative role.

6.6.1.4.3 The following actions shall be audited. The keys shall not be
included in the audit:

-   Requests, responses, and other transactions generated by the
    product, including key recovery responses.

-   Requests, responses, and other transactions received by the product,
    including key recovery requests.

6.6.1.4.4 The product shall record within each audit record at least the
following information:

-   Date and time of the event, type of event, subject (user) identity,
    and success or failure of the event; and

```{=html}
<!-- -->
```
-   Other information, as described in the functional component audit
    events **(FAU_GEN.1.2)**

6.6.1.4.5 The product shall be able to generate a human understandable
presentation of any audit data stored in the permanent audit trail.
(**FAU_POP.1.1)**

6.6.1.4.6 The audit trail shall not store the old or new authentication
information (e.g., password)

6.6.1.4.7 The product shall be able to associate each auditable event
with the identity of the user that caused the event. (**FAU_GEN.2.1)**

6.6.1.4.8 The product shall provide the authorized administrator with
the ability to empty the audit trail. (**FAU_MGT.1.1)** (Note: emptying
the audit trail means backup and delete).

6.6.1.4.9 The product shall be able to include or exclude auditable
events from the set of audited events based on the following attributes:
User identity, and/or Event Type **(FAU_SEL.1.1)** (Note: The
requirement applies to the auditable events only. The always audited
events must never be excluded or excludable from the set of audited
events.)

6.6.1.4.10 The product shall store generated audit records in a
permanent audit trail. (**FAU_STG.1.1)**

**6.6.1.4.11** The product shall restrict access to the audit trail to
the authorized administrator. **(FAU_PRO.1.1)**

(Note: This requirement implies providing integrity to the audit trail)

**6.6.1.5 Identification and Authentication**

The requirements in this section are for the identification and
authentication of the various requestor personnel. These requirements do
not apply to electronic transactions (requests and responses).

6.6.1.5.1 The product shall provide functions for initializing and
modifying user authentication data. (**FIA_ADA.3.1)**

6.6.1.5.2 The product shall restrict the use of these functions on the
user personnel authentication data for any user to the authorized
administrator. (**FIA_ADA.3.2)**

6.6.1.5.3 The product shall allow authorized users to use these
functions to modify their own authentication data in accordance with the
identification and authentication policy. (**FIA_ADA.3.3)** (Note: The
identification and authentication policy is to permit each person to
change his/her authentication information.)

6.6.1.5.4 The product shall protect from unauthorized observation,
modification, and destruction authentication data that is stored in the
product.

6.6.1.5.5 The product shall be able to terminate the user session
establishment process after five unsuccessful authentication attempts.
(**FIA_AFL.1.1)**

(Note: If the product terminates the session after less than five
unsuccessful attempts, the product meets the above requirement)

6.6.1.5.6 After the termination of a user session establishment process,
the product shall be able to disable the user account until account is
enabled by an authorized administrator (i.e., security administrator).
(**FIA_AFL.1.2)**

6.6.1.5.7 The product shall authenticate any user's claimed identity
prior to performing any functions on the user's behalf.
(**FIA_UAU.1.1)**

6.6.1.5.8 The product shall uniquely identify each user before
performing any actions requested by the user. **(FIA_UID.2.1)**

6.6.1.5.9 The product shall provide a mechanism to verify that secrets
(i.e., authentication information such as passwords) meet the FIPS PUB
112 "Password Usage" and Department of Defense Password Management
Guideline (CSC-STD-002-85).

(Note: The above requirement implies that the product (as opposed to
procedural means and management instructions) will enforce the password
length, aging, etc. type requirements. If we do not want the product to
enforce the requirement, the above requirement should be deleted)

**6.6.1.6 Access Control**

These requirements provide countermeasures against entities masquerading
as an authorized requestor. The requirements in this section address the
security of electronic communication between the KRA and the requestor.
If these interactions are not electronic, then physical and procedural
means may be used to secure the transactions. These procedural and
physical measures are beyond the scope the standard.

6.6.1.6.1 The product shall verify the source of received transactions.
(**FPT_ACP.1.1)**

6.6.1.6.2 The product shall verify the integrity of received
transactions.

6.6.1.6.3 The product shall decrypt the received transactions which are
encrypted. (**FPT_ACP.1.2)**

6.6.1.6.4 The product shall apply source authentication to all requests.
(**FPT_ACP.1.3)** The strength of the algorithm used for authentication
shall be greater than or equal to the maximum strength of the encryption
or key management algorithms employed for user traffic encryption or for
generation of the keys being recovered.

6.6.1.6.5 The product shall apply integrity services to all requests.
The strength of the algorithm used for integrity shall be greater than
or equal to the maximum strength of the encryption or key management
algorithms employed for user traffic encryption or for generation of the
keys being recovered.

6.6.1.6.6 The product shall apply confidentiality services to all
requests. The strength of the algorithm used for confidentiality shall
be greater than or equal to the maximum strength of the encryption or
key management algorithms employed for user traffic encryption or for
generation of the keys being recovered.

6.6.1.6.7 The product shall verify the association of the response to an
outstanding request.

6.1.1.6.8 The product shall ensure that the key recovery information is
destroyed (e.g., by zeroizing) when it is no longer required, when it is
no longer valid (e.g., time expiry), when the KRA requires its deletion,
or when the legal authority to it expires, whichever occurs first.

6.6.1.6.9 The product shall ensure that security features are always
invoked and cannot be bypassed. **(FPT_RVM.1.1)**

6.6.1.6.10 The product shall maintain a security domain for its own
execution that protects it from interference and tampering by untrusted
subjects. (**FPT_SEP.1.1)**

6.6.1.6.11 The product shall enforce separation between the security
domains of subjects in the system. (**FPT_SEP.1.2)**

**6.6.1.7 Non-Repudiation**

6.6.1.7.1 The product shall be able to provide reliable time stamps for
its own use. **(FPT_STM.1.1)**

(Note: We want to rely more on the KRA for time. But, having requestor
time stamp does not hurt)

6.6.1.7.2 The product shall be able to generate evidence of receipt for
received transactions. (**FCO_NRR.2.1)**

(Note: The above requirement means using the reliable time stamp to
requirement to put a trusted time stamp on the receipt. Furthermore,
this requirement means that the product shall be able to generate
evidence of receipt of: registration or deposit of key recovery
information from users, and requests from requestor).

**6.6.1.8 Protection of Trusted Security Functions**

6.6.1.8.1 Before establishing a session with a user, the product shall
display an advisory warning message regarding unauthorized use of the
product. (**FTA_TAB.2.1)**

6.6.1.8.2 The default advisory warning message displayed by the product
shall be as follows: "This system shall be used only by authorized
personnel and only for authorized key recovery purposes. Violation shall
result in criminal prosecution and civil penalties". (**FTA_TAB.2.2)**

6.6.1.8.3 The product shall restrict the capability to modify the
warning message to the authorized administrator. (**FTA_TAB.2.3)**

6.6.1.8.4 Upon successful session establishment, the product shall
display the date, time, method, and location of the last successful
session establishment to the user (**FTA_TAH.1.1)**

6.6.1.8.5 Upon successful session establishment, the product shall
display the date, time, method, and location of the last unsuccessful
attempt to session establishment and the number of unsuccessful attempts
since the last successful session establishment. (**FTA_TAH.1.2)**

6.6.1.8.6 The data specified above shall not be removed without user
intervention. **(FTA_TAH.1.3)**

**6.6.2 Level 2 -- High Assurance**

**6.6.2.1 Cryptographic Functions**

6.6.2.1.1 All cryptographic modules shall be FIPS 140-1, Level 3 or
higher compliant.

**6.6.2.2 Cryptographic Algorithms**

Same as Level 1

**6.6.2.3 Confidentiality**

Level 1 requirements and;

**6.6.2.4 Audit**

Includes all the requirements of Level 1 and;

6.6.2.4.1 The product shall generate an alarm to the authorized
administrator if the size of the audit data in the audit trail exceeds a
pre-defined limit. (**FAU_MGT.4.1)**

6.6.2.4.2 The product shall provide the authorized administrator with
the ability to manage the audit trail at any time during the operation
of the product. (**FAU_MGT.4.2)**

6.6.2.4.3 The following actions shall be auditable:

-   Execution of the tests of the underlying machine and the results of
    the tests.

-   All attempted uses of the trusted path functions.

-   Identification of the initiator and target of the trusted path.

-   Attempts to provide invalid inputs for administrative functions

-   The invocation of the non-repudiation service. The audit event shall
    include identification of the information, the destination, and a
    copy of the evidence provided. The event shall exclude all private
    and secret keys in encrypted or unencrypted form.

**6.6.2.5 Identification and Authentication** Same as Level 1 and;

6.6.2.5.1 The product shall support and token based authentication. The
token shall meet FIPS 140-1 Level 2 requirements.

**6.6.2.6 Access Control**

Same as Level 1 and the following;

6.6.2.6.1 Two or more users shall be required to request the recovery
information from a KRA.

6.6.2.6.2 The product shall enforce checks for valid input values for
security-relevant administrative functions as described in the
Administrative guidance. (**FPT_TSU.1.1)**

**6.6.2.7 Non Repudiation**

Includes the Level 1 requirements and;

6.6.2.7.1 The product shall generate evidence of origin for transmitted
key recovery requests or responses. (**FCO_NRO.1.1)**

(Note: The above requirement shall also the reliable time stamp service
to include the time in the evidence)

6.6.2.7.2 The product shall provide a capability to verify the evidence
of origin of information to the recipient. (**FCO_NRO.1.3)**

6.6.2.7.3 The product shall provide a capability to verify the evidence
of receipt of proof of receipt to the originator of message (i.e.,
recipient of proof of receipt). (**FCO_NRR.2.3)**

6.6.2.7.4 The product shall provide the originator the ability to
request evidence of receipt on information. **(FCO_NRR.2.3)**

**6.6.2.8 Protection of Trusted Security Functions**

Same as Level 1 and the following:

6.6.2.8.1 The product shall provide a communication path between itself
and local human users that is logically distinct from other
communication paths and provides assured identification of its
endpoints. (**FTP_TRP.1.1)**

6.6.2.8.2 The local human users shall have the ability to initiate
communication via the trusted path. (**FTP_TRP.1.2)**

6.6.2.8.3 The product shall require the use of the trusted path for
initial user authentication. (**FTP_TRP.1.3)**

6.6.2.8.4 The product shall provide the authorized administrator with
the capability to demonstrate the correct operation of the
security-relevant functions provided by the underlying abstract machine.
(**FPT_AMT.1.1)**

6.6.2.8.5 The product shall preserve a secure state when abstract
machine tests fail. (**FPT_FLS.1.1)**

Ancillary Components

**6.7 Registration Agent**

Registration Agents maintain information on key recovery products and
corresponding key recovery protocol (schemes). Thus, the requirement on
a registration agent is to ensure the accuracy and maintain the
integrity of this product information.

**6.7.1 Integrity/Authenticity**

These requirements counter the threat of an adversary spoofing as the
registration agent and of unauthorized access to the information and
critical functions at the registration agent.

6.7.1.1 The Registration Agent shall verify authentication and integrity
services for the received product information.

6.7.1.2 The Registration Agent shall apply authentication and integrity
services to the product information it transmits.

6.7.1.3 The Registration Agent shall ensure that the product information
it maintains is not modified by unauthorized parties.

**6.8 Licensing Agent**

Licensing Agents shall perform a compliance audit of the KRA to ensure
that the KRA operates in accordance with the KRA's stated policy.

**6.9 Authentic Public Key Source (APKS AKA Public Key Infrastructure
(PKI))**

**6.9.1 Standards**

**6.9.1.1** The APKS shall carry out transactions in accordance with the
Minimum Interoperability Specifications for PKI Components (MISPC)

**6.9.2 Security/Certificate Policy**

The security of PKI and the degree to which the binding between an
entity (subject or subscriber) and public key can be trusted, is
determined by the Certificate Policy. Certificate Policy is defined and
described in Certificate Policy Framework. Using this Framework, NIST
has developed Baseline Security Requirements. NIST plans to enhance
these for up to three more strictly superior policies. Thus, in order to
define the security requirements for the APKS, we only need to select
the proper certificate policy. Please note the certificate policy
security requirements are quite comprehensive. For details, see IETF
PKIX Part IV: Certificate Policy Framework.

6.9.2.1 For Level 1, the APKS shall meet the medium Certificate Policy.
For Level 2, the APKS shall meet the high Certificate Policy.

END OF NEW DOCUMENT \*\*\*\*\*\*

6.2.1.4.2 The key recovery information shall provide source
authentication.

6.2.1.4.3 The end user product shall be capable of securely binding
(i.e., with integrity) the key recovery information to the encrypted
communications.

6.2.1.4.4 The end user product shall be capable of verifying the source
and integrity of key recovery information

6.2.1.5 **Key Recovery** **Functionality**

6.2.1.5.1 The key recovery mechanism in the end user product shall be
always activated/deactivated by the system administrator.

(Note: The above requirement will be taken out if it appears some place
else.)

**6.2.2 Level 2 -- Mandatory Enforcement of Key Recovery**

**6.2.2.1 Cryptographic Functions**

6.2.2.1.1 All cryptographic modules shall be FIPS 140-1, Level 2
compliant.

**6.2.2.2 Cryptographic Algorithms:** Same as Level 1

**6.2.2.3 Confidentiality**: Same as Level 1

**6.2.2.4 Integrity/Authenticity**: Same as Level 1

6.2.2.5 **Key Recovery** **Functionality**

6.2.2.5.1 The key recovery mechanism shall be always activated in the
end user product.

(Note: The above requirement will be taken out if it appears some place
else.)

## 

## 7 INTEROPERABILITY REQUIREMENTS

**7.1 General Requirements**

**7.1.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.** Certification shall be determined through the
functionality of, and interactions between, the system components as
defined by this mapping.

**7.2.1 Interoperable 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.

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

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

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

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

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

**7.1.8 The KR request message containing the subject key recovery field
and/or encrypted data shall be both digitally signed and encrypted.**
These services shall be applied to the KRR message to prevent forgery,
or manipulation of KRR data, as well as to provide auditability for KR
requests.

**7.2 KRR TO KRA REQUIREMENTS**

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

**7.2.2 A key recovery request body shall include the following:**

-   **Originator identity**

-   **Recipient identity**

-   **Current date and time**

-   **Date and time of encrypted key/data capture**

-   **Key recovery block**

-   **Optional: subject passphrase**

-   **Optional: MIME formatted encrypted data**

**7.2.2.1 Individual items within the request transaction body shall be
delimited by blank lines.**

-   **Originator-id: \<**identifying information\>

-   **Recipient-id:** **\<**identifying information\>

-   **Date-Time:** \<date/time string\>

-   **Capture-Time:** \<date/time string\>

-   **KRB:** \<printably encoded recovery block\>

-   **Passphrase:** \<subject authentication data\>

-   **Encrypted-Data:** \<MIME encoded data\>

**7.2.2.2 EXAMPLE: Key Recovery Request**

**7.2.3 A key recovery response body shall include the following:**

-   **KRA identity information**

-   **KRR identity information**

-   **Recipient identity**

-   **Current date and time**

-   **Date and time of key/data recovery**

-   **Printably encoded key**

-   **Optional: MIME formatted data**

    **7.2.3.1 Individual items within the response transaction body
    shall be delimited by blank lines.**

```{=html}
<!-- -->
```
-   **KRA-id: \<**identifying information\>

-   **KRR-id: \<**identifying information\>

-   **Recipient-id:** **\<**identifying information\>

-   **Date-Time:** \<date/time string\>

-   **Recovery-Time:** \<date/time string\>

-   **DEK:** \<printably encoded encryption key\>

-   **Data:** \<MIME encoded data\>

    **7.2.3.2 EXAMPLE: Key Recovery Response**

# 8 ASSURANCE REQUIREMENTS

The assurance in a CKRS compliant product can be achieved using the
Common Criteria Evaluation Assurance Level (EAL). The Common Criteria
defines seven hierarchical assurance levels EAL1 through EAL7. The
Common Criteria assurance levels may be overkill for the CKRS compliance
validation program.

Thus, the following is a tailored list of assurance requirements. These
requirements are derived from the Common Criteria Part 3 (Assurance
Requirements). Specifying assurance requirements in the common criteria
language will help in converting the FIPS into a Common Criteria
Protection Profile and in validating CKRS compliance products under the
Common Criteria (CC) Evaluation Methodology.

For the sake of clarity, it should be noted that the CC structure for
assurance requirements is hierarchical follows. At the highest level,
the requirements are categorized into classes. The classes are further
decomposed into families. The families are decomposed into components.
Each component has three sets of elements. The first set of elements is
the list of developer (vendor) actions to satisfy the component. The
second set of elements are a list of contents and presentation for the
assurance evidence for that element. The third and last set of elements
are what an independent evaluator should do to assess the contents and
presentation.

A later section of this report also explains why the remaining Common
Criteria assurance requirements are not recommended.

We have defined three assurance levels. These levels are somewhat
related to the Common Criteria assurance levels, but not derived from
the Common Criteria assurance levels. We term these assurance levels
basic, enhanced, and delux. The components in the assurance levels are
listed in Table 1. A later section of the report describes these
components and elements.

The assurance can be applied commensurate with the CKRS component
sensitivity. For example the KRA must have high degree of assurance,
where as the client may have a lower degree of assurance. The CKRS
components for assurance purposes can be broken down in the following
areas: KRA, clients, other trusted components such as CA, and other
components such as registration agents. Table 2 contains a matrix of
which assurance levels make sense for each environment. For entities
such as the CA, if there are assurance and security requirements or
standards, these standards may (should) be used in lieu of the
recommendations in Table 2. Furthermore, it does not make sense for
clients and other components to have higher assurance than the KRA and
other trusted components (e.g., CA). Thus, the assurance for the KRA and
CA should be equal to or greater than assurance for the clients and
other components. Basic assurance is not recommended for the KRA and CA.

**Table 1: CKRS Assurance Levels**

+---------------+--------------------------+-------+---------+--------+
| **Assurance   | **Assurance Family**     | **Ba  | **Enh   | **D    |
| Class**       |                          | sic** | anced** | elux** |
+---------------+--------------------------+-------+---------+--------+
| **            | **ACM_CAP**              |       | 1       | 1      |
| Configuration |                          |       |         |        |
| Management**  | CM Capabilities          |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ACM_SCP**              |       |         | 2      |
|               |                          |       |         |        |
|               | CM Scope                 |       |         |        |
+---------------+--------------------------+-------+---------+--------+
| **Delivery    | **ADO_DEL**              |       |         | 2      |
| and           |                          |       |         |        |
| Operation**   | Delivery                 |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ADO_IGS**              | 1     | 1       | 1      |
|               |                          |       |         |        |
|               | Installation, Generation |       |         |        |
|               | and Start-up             |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ADV_FSP**              | 1     | 2       | 2      |
|               |                          |       |         |        |
|               | Functional Specification |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ADV_HLD**              | 1     | 2       | 2      |
|               |                          |       |         |        |
|               | High-Level Design        |       |         |        |
+---------------+--------------------------+-------+---------+--------+
| **            | **ADV_IMP**              |       |         | 1      |
| Development** |                          |       |         |        |
|               | Implementation           |       |         |        |
|               | Representation           |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ADV_LLD**              |       |         | 1      |
|               |                          |       |         |        |
|               | Low-Level Design         |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ADV_RCR**              |       |         | 1      |
|               |                          |       |         |        |
|               | Representation           |       |         |        |
|               | Correspondence           |       |         |        |
+---------------+--------------------------+-------+---------+--------+
| **Guidance    | **AGD_ADM**              | 1     | 1       | 1      |
| Documents**   |                          |       |         |        |
|               | Administrator Guidance   |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **AGD_USR**              | 1     | 1       | 1      |
|               |                          |       |         |        |
|               | User Guidance            |       |         |        |
+---------------+--------------------------+-------+---------+--------+
| **Life Cycle  | **ALC_FLR**              | 2     | 2       | 2      |
| Support**     |                          |       |         |        |
|               | Flaw Remediation         |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ATE_COV**              | 1     | 1       | 1      |
|               |                          |       |         |        |
|               | Coverage                 |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ATE_DPT**              | 1     | 1       | 1      |
|               |                          |       |         |        |
|               | Depth                    |       |         |        |
+---------------+--------------------------+-------+---------+--------+
| **Tests**     | **ATE_FUN**              | 1     | 1       | 1      |
|               |                          |       |         |        |
|               | Functional Tests         |       |         |        |
+---------------+--------------------------+-------+---------+--------+
|               | **ATE_IND**              | 2     | 2       | 2      |
|               |                          |       |         |        |
|               | Independent Testing      |       |         |        |
+---------------+--------------------------+-------+---------+--------+
| **            | **AVA_VLA**              |       | 1       | 1      |
| Vulnerability |                          |       |         |        |
| Assessment**  | Vulnerability Analysis   |       |         |        |
+---------------+--------------------------+-------+---------+--------+

**Table 2: Assurance for CKRS Components**

  ----------------- ----------------- ----------------- -----------------
  **Component**     **Basic**         **Enhanced**      **Delux**

  KRA                                 Yes               Yes

  Other Trusted                       Yes               Yes
  (e.g., CA)                                            

  Client            Yes               Yes               Yes

  Other             Yes               Yes               Yes
  ----------------- ----------------- ----------------- -----------------

# 

# 8.1 Configuration Management ACM_CAP -- CM Capabilities

**8.1.1 Objectives**

Configuration management (CM) is an aspect of establishing that the
functional requirements and specifications are realized in the
implementation. CM meets these objectives by requiring discipline and
control in the processes of refinement and modification of the
product/system. CM systems are put in place to ensure the integrity of
the configuration items that they control, by providing a method of
tracking these configuration items, and by ensuring that only authorized
users are capable of changing them.

The capabilities of the CM system address the likelihood that accidental
or unauthorized modifications of the configuration items will occur. The
CM system should ensure the integrity of the product/system from the
early design stages through all subsequent maintenance efforts. The
objectives of this assurance requirement include the following:

1.  ensuring that the product/system is correct and complete before it
    is sent to the consumer; and

2.  ensuring that no configuration items are missed during evaluation.

Clear identification of the product/system is required to determine
those items under

evaluation that are subject to the criteria requirements.

**8.1.2 Application notes**

There is a requirement that a configuration list be provided. The
configuration list contains all configuration items which are maintained
by the CM system.

## 8.1.3 ACM_CAP.1 Minimal support 

**8.1.3.1 Developer action elements**

**8.1.3.1.1 ACM_CAP.1.1D:** The developer shall use a CM system.

**8.1.3.1.2 ACM_CAP.1.2D:** The developer shall provide CM
documentation.

**8.1.3.2 Content and presentation of evidence elements**

**8.1.3.2.1 ACM_CAP.1.1C:** The CM documentation shall include a
configuration list.

**8.1.3.2.2 ACM_CAP.1.2C:** The configuration list shall describe the
configuration items that comprise the product.

**8.1.3.2.3 ACM_CAP.1.3C:** The CM documentation shall describe the
method used to uniquely identify the product configuration items.

**8.1.3.3 Evaluator action elements**

**8.1.3.3.1 ACM_CAP.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.2 Configuration Management ACM_SCP - CM Scope 

**8.2.1 Objectives**

Configuration management (CM) is an aspect of establishing that the
functional requirements and specifications are realized in the
implementation. CM meets these objectives by requiring discipline and
control in the processes of refinement and modification of the
product/system. CM systems are put in place to ensure the integrity of
the configuration items that they control, by providing a method of
tracking these configuration items, and by ensuring that only authorized
users are capable of changing them.

The objective is to ensure that all necessary configuration items are
tracked by the CM system. This helps to ensure that the integrity of
these configuration items is protected through the capabilities of the
CM system. The objectives of this assurance requirement include the
following:

1.  ensuring that the implementation representation (i.e., code) is
    tracked; and

2.  ensuring that all necessary documentation, including problem
    reports, are tracked during development and operation.

A CM system can control changes only to those items that have been
placed under

CM\. The implementation representation, design, tests, user and
administrator documentation, security flaws, and CM documentation should
be placed under CM. The ability to track security flaws under CM ensures
that security flaw reports are not lost or forgotten, and allows a
developer to track security flaws to their resolution.

**8.2.2 Application notes**

There is a requirement that the implementation representation be tracked
by the CM system. The implementation representation refers to all
hardware, software, and firmware that comprise the physical
product/system. In the case of a software-only product, the
implementation representation may consist solely of source and object
code, but in other cases, the implementation representation may refer to
a combination of software, hardware, and firmware. There is a
requirement that security flaws be tracked by the CM system. This
requires that information regarding previous security flaws and their
resolution be maintained, as well as details regarding current security
flaws.

## *8.2.3 ACM_SCP.2 Problem tracking CM coverage*

**8.2.3.1 Developer action elements**

**8.2.3.1.1 ACM_SCP.2.1D:** The developer shall provide CM
documentation.

**8.2.3.2 Content and presentation of evidence elements**

**8.2.3.2.1 ACM_SCP.2.1.C**: As a minimum, the following shall be
tracked by the CM system: the implementation representation, design
documentation, test documentation, user documentation, administrator
documentation, CM documentation, and security flaws.

**8.2.3.2.2 ACM_SCP.2.2C:** The CM documentation shall describe how
configuration items are tracked by the CM system.

**8.2.3.3 Evaluator action elements**

**8.2.3.3.1 ACM_SCP.2.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.3 Delivery and Operation ADO_DEL -- Delivery

**8.3.1 Objectives**

The requirements for delivery call for system control and distribution
facilities and procedures that provide assurance that the recipient
receives the product that the sender intended to send, without any
modifications. For a valid delivery, what is received must correspond
precisely to the master copy, thus avoiding any tampering with the
actual version, or substitution of a false version.

**8.3.2 Application notes**

This assurance requirement should be applied to sensitive components
whose modification can compromise security.

## *8.3.3 ADO_DEL.2 Detection of modification*

**8.3.3.1 Developer action elements**

**8.3.3.1.1 ADO_DEL.2.1D:** The developer shall provide documentation
about the procedures for delivery of the product/system or parts of it
to the user.

**8.3.3.1.2 ADO_DEL.2.2D:** The developer shall use the delivery
procedures.

**8.3.3.2 Content and presentation of evidence elements**

**8.3.3.2.1 ADO_DEL.2.1C:** The delivery documentation shall describe
the procedures to be employed when distributing versions of the
product/system to a user\'s site.

**8.3.3.2.2 ADO_DEL.2.2C:** The delivery documentation shall state how
the procedures are to be employed to detect modifications.

**8.3.3.2.3 ADO_DEL.2.3C:** The delivery documentation shall describe
how the various procedures and technical measures provide for the
detection of modifications, or any discrepancy between the developer\'s
master copy and the version received at the user site.

**8.3.3.2.4 ADO_DEL.2.4C:** The delivery documentation shall describe
how the various procedures allow detection of attempted masquerading
even in cases in which the developer has sent nothing to the user\'s
site.

**8.3.3.3 Evaluator action elements**

**8.3.3.3.1 ADO_DEL.2.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.4 Delivery and Operation ADO_IGS - Installation, Generation, and Start-up

**8.4.1 Objectives**

Installation, generation, and start-up procedures are useful for
ensuring that the

product has been installed, generated, and started in a secure manner as
intended by

the developer.

**8.4.2 Application notes**

The generation requirements are applicable only to the products that
provide the ability to

generate an operational product from source or object code.

The installation, generation, and start-up procedures may exist as a
separate document, but would typically be grouped with other
administrative guidance.

## *8.4.3 ADO_IGS.1 Installation, generation, and start-up procedures* 

**8.4.3.1 Developer action elements**

**8.4.3.1.1 ADO_IGS.1.1D:** The developer shall document procedures to
be used for the secure installation, generation, and start-up of the
product/system.

**8.4.3.2 Content and presentation of evidence elements**

**8.4.3.2.1 ADO_IGS.1.1C:** The documentation shall describe the steps
necessary for secure installation, generation, and start-up of the
product/system.

**8.4.3.3 Evaluator action elements**

**8.4.3.3.1 ADO_IGS.1.1E:** The evaluator shall confirm that the
information provided meets all

requirements for content and presentation of evidence.

# 8.5 Development ADV_FSP - Functional Specification

**8.5.1 Objectives**

The functional specification is a high-level description of the
user-visible interface

and behavior of the product/system. It is a refinement of the statement
of functional requirements for the product/system. The functional
specification must show that all

defined functional requirements are addressed, and that the
product/system security policy is enforced by the system.

**8.5.2 Application notes**

In addition to the content indicated in the following requirements, the
functional

specification shall also include any additional specific detail
specified by the

documentation notes in the related functional components. For example,
it shall contain the specification of the interaction (protocol) among
various product/system components.

The developer must provide evidence that the product/system is
completely represented by the functional specification. While a
functional specification for the entire product/system would allow an
evaluator to determine the product/system boundary, it is not necessary
to require that specification when other evidence could be provided to
demonstrate the product/system boundary.

The evaluator of the product/system is expected to make determinations
regarding the relevance of the functional specification to the
functional requirements. In the course of the functional specification
evaluation, there are essentially three types of evaluator
determination: specific functional requirements are met and no further
work (e.g., with a less abstract representation of the product/system)
is necessary; specific functional requirements are violated and the
product/system fails to meet its requirements; and

specific functional requirements have not been addressed and further
analysis (of

another product/system representation) is necessary. Whenever additional
analysis is necessary, the evaluator is expected to carry that
information forward to the analysis of other product/system
representations. If requirements are not addressed after the analysis of
the last provided product/system representation, this also represents a
failure of the product/system evaluation.

In all cases, it is important that the evaluator evaluate the
product/system as a unit since in many cases the security functions must
cooperate to meet specific functional requirements and also each
security function must not interfere with the operation

of any other security function.

An informal security policy model can be representation of the security
policy in any notation, including a series of statements in the English
Language.

## *8.5.3 ADV_FSP.1 Functional specification and security policy*

**8.5.3.1 Developer action elements**

**8.5.3.1.1 ADV_FSP.1.1D:** The developer shall provide a functional
specification.

**8.5.3.1.2 ADV_FSP.1.2D:** The developer shall provide a product/system
security policy.

**8.5.3.2 Content and presentation of evidence elements**

**8.5.3.2.1 ADV_FSP.1.1C:** The functional specification shall describe
the product/system using an informal style.

**8.5.3.2.2 ADV_FSP.1.2C:** The functional specification shall include
an informal presentation of syntax and semantics of all external
product/system interfaces.

**8.5.3.2.3 ADV_FSP.1.3C:** The functional specification shall include
evidence that demonstrates that the product/system is completely
represented.

**8.5.3.3 Evaluator action elements**

**8.5.3.3.1 ADV_FSP.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.5.3.3.2 ADV_FSP.1.2E:** The evaluator shall determine that the
functional specification is consistent with the product/system security
policy.

**8.5.3.3.3 ADV_FSP.1.3E:** The evaluator shall determine if the
functional requirements are addressed by the representation of the
product/system, i.e., the functional specification.

## 8.5.4 ADV_FSP.2 Informal security policy model 

**8.5.4.1 Developer action elements**

**8.5.4.1.1 ADV_FSP.2.1D:** The developer shall provide a functional
specification.

**8.5.4.1.2 ADV_FSP.2.2D:** The developer shall provide a product/system
security policy.

**8.5.4.1.3 ADV_FSP.2.3D: The developer shall provide an informal
security policy model.**

**8.5.4.1.4 ADV_FSP.2.4D: The developer shall provide a demonstration of
correspondence between the informal security policy model and the
functional specification.**

**8.5.4.2 Content and presentation of evidence elements**

**8.5.4.2.1 ADV_FSP.2.1C:** The functional specification shall describe
the product/system using an informal style.

**8.5.4.2.2 ADV_FSP.2.2C:** The functional specification shall include
an informal presentation of syntax and semantics of all external
product/system interfaces.

**8.5.4.2.3 ADV_FSP.2.3C:** The functional specification shall include
evidence that demonstrates that the product/system is completely
represented.

**8.5.4.2.4 ADV_FSP.2.4C:** The demonstration of correspondence between
the informal security policy model and the functional specification
shall describe how the functional specification satisfies the informal
security policy model.

**8.5.4.2.5 ADV_FSP.2.5C:** The demonstration of correspondence between
the informal security policy model and the functional specification
shall show that there are no security functions in the functional
specification that conflict with the informal security policy model.

**8.5.4.2.6 ADV_FSP.2.6C:** The informal security policy model shall
describe the rules and characteristics of all policies of the
product/system that can be modeled.

**8.5.4.2.7 ADV_FSP.2.7C:** The informal security policy model shall
include a rationale that demonstrates that policies that are modeled are
satisfied by the informal security policy model.

**8.5.4.2.8 ADV_FSP.2.8C**: The informal security policy model shall
justify that all policies that can be modeled are represented in the
informal security policy model.

**8.5.4.3 Evaluator action elements**

**8.5.4.3.1 ADV_FSP.2.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.5.4.3.2 ADV_FSP.2.2E:** The evaluator shall determine that the
functional specification is consistent with the product/system security
policy.

**8.5.4.3.3 ADV_FSP.2.3E:** The evaluator shall determine if the
functional requirements are addressed by the representation of the
product/system, i.e., the functional specification.

# 8.6 Development ADV_HLD - High-Level Design

**8.6.1 Objectives**

The high-level design of a product/system provides a description of the
product/system in terms of major structural units (i.e., subsystems) and
relates these units to the functions that they contain. The high-level
design provides assurance that the product/system provides an
architecture appropriate to implement the claimed functional
requirements.

The high-level design refines the functional specification into
subsystems. For each

subsystem of the product/system, the high-level design describes its
purpose and function and identifies the security functions enforced by
the subsystem. The interrelationships

of all subsystems are also defined in the high-level design. These
interrelationships will be represented as external interfaces for data
flow, control flow, etc., as appropriate.

**8.6.2 Application notes**

In addition to the content indicated in the following requirements, the
high-level design shall also include any additional specific detail
specified by the documentation notes in the related functional
components.

The developer is expected to describe the design of the product/system
in terms of subsystems. The term \`\`subsystem\'\' is used here to
express the idea of decomposing the product/system into a relatively
small number of parts. While the developer is not required to actually
have \`\`subsystems\'\', the developer is expected to represent a
similar level of decomposition. For example, a design may be similarly
decomposed using \`\`layers\'\', \`\`domains\'\', or \`\`servers\'\'.

The evaluator of the product/system is expected to make determinations
regarding the functional requirements in the product relevant to the
high-level design. In the course of the high-level design evaluation,
there are essentially three types of evaluator determination: specific
functional requirements are met and no further work (e.g., with a less
abstract representation of the product/system) is necessary; specific
functional requirements are violated and the product/system fails to
meet its requirements; and specific functional requirements have not
been addressed and further analysis (of another product/system
representation) is necessary. Whenever more analysis is necessary, the
evaluator is expected to carry that information forward to the analysis
of other product/system representations. If requirements are not
addressed after the analysis of the last provided product/system
representation, this also represents a failure of the product/system
evaluation.

In all cases, it is important that the evaluator evaluate the
product/system as a unit since in many cases the security functions must
cooperate to meet specific functional requirements and also each
security function must not interfere with the operation of any other
security function.

The term \`\`security functionality\'\' is used to represent operations
that a subsystem

performs that have some effect on the security functions implemented by
the product.

This distinction is made because design constructs, such as subsystems
and

modules, do not necessarily relate to specific security functions. While
a given

subsystem may correspond directly to a security function, or even
multiple security

functions, it is also possible that many subsystems must be combined to
implement

a single security function.

The term \`\`security policy enforcing subsystems\'\' refers to a
subsystem that contributes to the enforcement of the security policy.

## 8.6.3 ADV_HLD.1 Descriptive high-level design 

**8.6.3.1 Developer action elements**

**8.6.3.1.1 ADV_HLD.1.1D:** The developer shall provide the high-level
design of the product/system.

**8.6.3.2 Content and presentation of evidence elements**

**8.6.3.2.1 ADV_HLD.1.1C:** The presentation of the high-level design
shall be informal.

**8.6.3.2.2 ADV_HLD.1.2C:** The high-level design shall describe the
structure of the product/system in terms of subsystems.

**8.6.3.2.3 ADV_HLD.1.3C:** The high-level design shall describe the
security functionality provided by each subsystem of the product/system.

**8.6.3.2.4 ADV_HLD.1.4C:** The high-level design shall identify the
interfaces of the subsystems of the product/system.

**8.6.3.2.5 ADV_HLD.1.5C:** The high-level design shall identify any
underlying hardware, firmware, and/or software required by the
product/system with a presentation of the functions provided by the
supporting protection mechanisms implemented in that hardware, firmware,
or software.

**8.6.3.3 Evaluator action elements**

**8.6.3.3.1 ADV_HLD.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.6.3.3.2 ADV_HLD.1.2E:** The evaluator shall determine if the
functional requirements in the product/system are addressed by the
design.

## 8.6.4 ADV_HLD.2 Security enforcing high-level design 

**8.6.4.1 Developer action elements**

**8.6.4.1.1 ADV_HLD.2.1D:** The developer shall provide the high-level
design of the product/system.

**8.6.4.2 Content and presentation of evidence elements**

**8.6.4.2.1 ADV_HLD.2.1C:** The presentation of the high-level design
shall be informal.

**8.6.4.2.2 ADV_HLD.2.2C:** The high-level design shall describe the
structure of the product/system in terms of subsystems.

**8.6.4.2.3 ADV_HLD.2.3C:** The high-level design shall describe the
security functionality provided by each subsystem of the product/system.

**8.6.4.2.4 ADV_HLD.2.4C:** The high-level design shall identify the
interfaces of the subsystems of the product/system.

**8.6.4.2.5 ADV_HLD.2.5C:** The high-level design shall identify any
underlying hardware, firmware, and/or software required by the
product/system with a presentation of the functions provided by the
supporting protection mechanisms implemented in that hardware, firmware,
or software.

**8.6.4.2.6 ADV_HLD.2.6C:** The high-level design shall describe the
separation of the product/system into security policy enforcing and
other subsystems.

**8.6.4.3 Evaluator action elements**

**8.6.4.3.1 ADV_HLD.2.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.6.4.3.2 ADV_HLD.2.2E:** The evaluator shall determine if the
functional requirements in the product/system are addressed by the
design.

# 8.7 Development ADV_IMP - Implementation Representation 

**8.7.1 Objectives**

The description of the implementation in the form of source code,
firmware, hardware drawings, etc. captures the detailed internal
workings of the product in support of analysis.

**8.7.2 Application notes**

The implementation representation is used to express the notion of the
least abstract representation of the product/system, specifically the
one that is used to create the product/system itself without further
design refinement. Source code which is then compiled or a hardware
drawing which is used to build the actual hardware are examples of parts
of an implementation representation.

The evaluator of the product/system is expected to make determinations
regarding the functional requirements in the ST relevant to the
implementation. In the course of the implementation evaluation, there
are essentially three types of evaluator determination: specific
functional requirements are met and no further work (e.g., with a more
abstract representation of the product/system) is necessary; specific
functional requirements are violated and the product/system fails to
meet its requirements; and specific functional requirements have not
been addressed and further analysis is necessary.

However, since the implementation is the least abstract representation
it is likely that further analysis cannot be performed unless the
product/system representations have not been evaluated in the usual
order (i.e., most abstract to least abstract). If requirements are not
addressed after the analysis of all product/system representations, this
represents a failure of the product/system evaluation. Note that this
more comprehensive failure determination requirement is realized in the
Representation correspondence (ADV_RCR) family.

In all cases, it is important that the evaluator evaluates the
product/system as a unit since, in many cases, the security functions
must cooperate to meet specific functional requirements and each
security function must not interfere with the operation of any other
security function.

It is expected that evaluators will use the implementation to directly
support other evaluation activities (e.g., vulnerability analysis, test
coverage analysis).

## 8.7.3 ADV_IMP.1 Subset of the implementation

**Application notes**

The implementation representation needs to be provided for the security
relevant functions of the product/system. Any hardware, software, and/or
firmware that does not contribute to the security need not be provided,
analyzed, or tested. However, an explanation must be provided, and the
evaluator must agree that the excluded items are not security relevant.

**8.7.3.1 Developer action elements**

**8.7.3.1.1 ADV_IMP.1.1D:** The developer shall provide the
implementation representations for a selected subset of the
product/system.

**8.7.3.2 Content and presentation of evidence elements**

**8.7.3.2.1 ADV_IMP.1.1C:** The implementation representations shall
unambiguously define the product/system to a level of detail such that
it can be generated without further design

decisions.

**8.7.3.3 Evaluator action elements**

**8.7.3.3.1 ADV_IMP.1.1E:** The evaluator shall confirm that the
information provided meets all

requirements for content and presentation of evidence.

**8.7.3.3.2 ADV_IMP.1.2E:** The evaluator shall determine if the CKRS
functional requirements are addressed by the representation of the
product/system.

# 8.8 Development ADV_LLD - Low-Level Design 

**8.8.1 Objectives**

The low-level design of a product/system provides a description of the
internal workings of the product/system in terms of modules and their
interrelationships and dependencies. The low-level design provides
assurance that the subsystems have been correctly and effectively
refined.

For each module of the product/system, the low-level design describes
its purpose, function, interfaces, dependencies, and the implementation
of any security policy enforcing functions.

**8.8.2 Application notes**

In addition to the content indicated in the following requirements, the
low-level design shall also include any additional specific detail
specified by the documentation notes in the related functional
components.

The evaluator of the product/system is expected to make determinations
regarding the

functional requirements relevant to the low-level design. In the course
of the low-level design evaluation, there are essentially three types of
evaluator determination: specific functional requirements are met and no
further work (e.g., with a less abstract representation of the
product/system) is necessary; specific functional requirements are
violated and the product/system fails to meet its requirements; and
specific functional requirements have not been addressed and further
analysis (of another product/system representation) is necessary.
Whenever more analysis is necessary, the evaluator is expected to carry
that information forward to the analysis of other product/system
representations. If requirements are not addressed after the analysis of
the last provided product/system representation, this also represents a
failure of the product/system evaluation. Note that this more
comprehensive failure determination requirement is realised in the
Representation correspondence (ADV_RCR) family.

In all cases, it is important that the evaluator evaluates the
product/system as a unit since, in many cases, the security functions
must cooperate to meet specific functional requirements and also each
security function must not interfere with the operation

of any other security function.

## 8.8.3 ADV_LLD.1 Descriptive low-level design 

**Application notes:**

Only representations for modules in the product/system need to be
provided.

**8.8.3.1 Developer action elements**

**8.8.3.1.1 ADV_LLD.1.1D:** The developer shall provide the low-level
design of the product/system.

**8.8.3.2 Content and presentation of evidence elements**

**8.8.3.2.1 ADV_LLD.1.1C:** The presentation of the low-level design
shall be informal.

**8.8.3.2.2 ADV_LLD.1.2C:** The low-level design shall describe the
product/system in terms of modules.

**8.8.3.2.3 ADV_LLD.1.3C:** The low-level design shall describe the
purpose of each module.

**8.8.3.2.4 ADV_LLD.1.4C:** The low-level design shall define the
interrelationships between the modules in terms of provided
functionality and dependencies on other modules.

**8.8.3.2.5 ADV_LLD.1.5C:** The low-level design shall describe the
implementation of all security policy enforcing functions.

**8.8.3.2.6 ADV_LLD.1.6C:** The low-level design shall describe the
interfaces of each module in terms of their syntax and semantics.

**8.8.3.2.7 ADV_LLD.1.7C:** The low-level design shall provide a
demonstration that the product/system is completely represented.

**8.8.3.2.8 ADV_LLD.1.8C:** The low-level design shall identify the
interfaces of the modules of the product/system visible at the external
interface of the product/system.

**8.8.3.3 Evaluator action elements**

**8.8.3.3.1 ADV_LLD.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.8.3.3.2 ADV_LLD.1.2E:** The evaluator shall determine if the
functional requirements in the CKRS are addressed by the representation
of the product/system.

# 8.9 Development ADV_RCR - Representation Correspondence 

**8.9.1 Objectives**

The correspondence between the various representations (i.e. functional
requirements expressed in the CKRS, functional specification, high-level
design, low-level design, implementation) addresses the correct and
complete instantiation of the requirements to the least abstract
representation provided. This conclusion is achieved by step-wise
refinement and the cumulative results of correspondence determinations
between all adjacent abstractions of representation.

**8.9.2 Application notes**

The developer must demonstrate to the evaluator that the most detailed,
or least abstract, representation of the product/system is an accurate,
consistent, and complete instantiation of the functions expressed as
functional requirements in the CKRS. This is accomplished by showing
correspondence between adjacent representations at a commensurate level
of rigor.

The evaluator must analyze each demonstration of correspondence between
abstractions, as well as the results of the analysis of each
product/system representation, and then make a determination as to
whether the functional requirements in the CKRS have been satisfied.

This family of requirements is not intended to address correspondence
relating to the security policy model. Rather, it is intended to address
correspondence between the requirements in the CKRS as well as the
product/system, functional specification, high-level design, low-level
design, and implementation representation.

## *8.9.3 ADV_RCR.1 Informal correspondence demonstration* 

**8.9.3.1 Developer action elements**

**8.9.3.1.1 ADV_RCR.1.1D:** The developer shall provide evidence that
the least abstract product/system representation provided is an
accurate, consistent, and complete instantiation of the functional
requirements expressed in the CKRS.

**8.9.3.2 Content and presentation of evidence elements**

**8.9.3.2.1 ADV_RCR.1.1C:** For each adjacent pair of product/system
representations, the evidence shall demonstrate that all parts of the
more abstract representation are refined in the less abstract
representation.

**8.9.3.2.2 ADV_RCR.1.2C:** For each adjacent pair of product/system
representations, the demonstration of correspondence between the
representations may be informal.

**8.9.3.3 Evaluator action elements**

**8.9.3.3.1 ADV_RCR.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.9.3.3.2 ADV_RCR.1.2E:** The evaluator shall analyze the
correspondence between the functional requirements expressed in the CKRS
and the least abstract representation provided to ensure accuracy,
consistency, and completeness.

# 8.10 Guidance Documents AGD_ADM Administrator Guidance 

**8.10.1 Objectives**

Administrator guidance refers to written material that is intended to be
used by those persons responsible for configuring, maintaining, and
administering the product/system in a correct manner for maximum
security. Because the secure operation of the product/system is
dependent upon the correct performance of the product/system, persons
responsible for performing these functions are trusted by the
product/system. Administrator guidance is intended to help
administrators understand the security functions provided by the
product/system, including both those functions that require the
administrator to perform security-critical actions and those functions
that provide security-critical information.

**8.10.2 Application notes**

The requirements AGD_ADM.1.2C and AGD_ADM.1.11C encompass the aspect
that any warnings to the users of a product/system with regard to the
product/system security

environment and the security objectives described in the CKRS are
appropriately covered in the administrator guidance.

Those topics that are relevant to administrator guidance for
understanding and proper application of the security functions should be
considered for inclusion in the administrator guidance requirements. An
example of an administrator guidance document is a reference manual.

## *8.10.3 AGD_ADM.1 Administrator guidance* 

**8.1.0.3.1 Developer action elements**

**8.1.0.3.1.1 AGD_ADM.1.1D:** The developer shall provide administrator
guidance addressed to system administrative personnel.

**8.1.0.3.2 Content and presentation of evidence elements**

**8.1.0.3.2.1 AGD_ADM.1.1C:** The administrator guidance shall describe
how to administer the product/system in a secure manner.

**8.1.0.3.2.2 AGD_ADM.1.2C:** The administrator guidance shall contain
warnings about functions and privileges that should be controlled in a
secure processing environment.

**8.1.0.3.2.3 AGD_ADM.1.3C:** The administrator guidance shall contain
guidelines on the consistent and effective use of the security functions
within the product/system.

**8.1.0.3.2.4 AGD_ADM.1.4C:** The administrator guidance shall describe
the difference between two types of functions: those which allow an
administrator to control security parameters, and those which allow the
administrator to obtain information only.

**8.1.0.3.2.5 AGD_ADM.1.5C:** The administrator guidance shall describe
all security parameters under the administrator\'s control.

**8.1.0.3.2.6 AGD_ADM.1.6C:** The administrator guidance shall describe
each type of security-relevant event relative to the administrative
functions that need to be performed, including changing the security
characteristics of entities under the control of the product/system.

**8.1.0.3.2.7 AGD_ADM.1.7C:** The administrator guidance shall contain
guidelines on how the security functions interact.

**8.1.0.3.2.8 AGD_ADM.1.8C:** The administrator guidance shall contain
instructions regarding how to configure the product/system.

**8.1.0.3.2.9 AGD_ADM.1.9C:** The administrator guidance shall describe
all configuration options that may be used during the secure
installation of the product/system.

**8.1.0.3.2.10 AGD_ADM.1.10C:** The administrator guidance shall
describe details, sufficient for use, of procedures relevant to the
administration of security.

**8.1.0.3.2.11 AGD_ADM.1.11C:** The administrator guidance shall be
consistent with all other documents supplied for evaluation.

**8.10.3.3 Evaluator action elements**

**8.10.3.3.1 AGD_ADM.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.10.3.3.2 AGD_ADM.1.2E:** The evaluator shall confirm that the
installation procedures result in a secure configuration.

# 8.11 Guidance Documents AGD_USR - User Guidance

**8.11.1 Objectives**

User guidance refers to written material that is intended to be used by
non-administrative (human) users of the product/system. User guidance
describes the security functions provided by the product/system and
provides instructions and guidelines, including warnings, for its secure
use.

The user guidance provides a basis for assumptions about the use of the
product/system and a measure of confidence that non-malicious users and
application providers will understand the secure operation of the
product/system and will use it as intended.

**8.11.2 Application notes**

The requirement AGD_USR.1.3.C and AGD_USR.1.5C encompass the aspect that
any warnings to the users of a product/system with regard to the
product/system security environment and the security objectives
described in the CKRS are appropriately covered in the user guidance.

Those topics in CKRS that are relevant to user guidance aimed at the
understanding and proper use of the security functions should be
considered for inclusion in the user guidance requirements. Examples of
user guidance are reference manuals, user guides, and on-line help.

## *8.11.3 AGD_USR.1 User guidance* 

**8.11.3.1 Developer action elements**

**8.11.3.1.1 AGD_USR.1.1D:** The developer shall provide user guidance.

**8.11.3.2 Content and presentation of evidence elements**

**8.11.3.2.1 AGD_USR.1.1C:** The user guidance shall describe the
product/system and interfaces available to the user.

**8.11.3.2.2 AGD_USR.1.2C:** The user guidance shall contain guidelines
on the use of security functions provided by the product/system.

**8.11.3.2.3 AGD_USR.1.3C:** The user guidance shall contain warnings
about functions and privileges that should be controlled in a secure
processing environment.

**8.11.3.2.4 AGD_USR.1.4C:** The user guidance shall describe the
interaction between user-visible security functions.

**8.11.3.2.5 AGD_USR.1.5C:** The user guidance shall be consistent with
all other documentation delivered for evaluation.

**8.11.3.3 Evaluator action elements**

**8.11.3.3.1 AGD_USR.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.12 Life Cycle Support ALC_FLR - Flaw Remediation 

**8.12.1 Objectives**

Flaw remediation requires that discovered flaws be tracked and corrected
by the developer. Although future compliance with flaw remediation
procedures cannot be

determined at the time of the product/system evaluation, it is possible
to evaluate the policies and procedures that a developer has in place to
track and correct flaws, and to

distribute the flaw information and corrections.

**8.12.2 Application notes**

None

## 8.12.3 ALC_FLR.2 Flaw reporting procedures 

**8.12.3.1 Developer action elements**

**8.12.3.1.1 ALC_FLR.2.1D:** The developer shall document the flaw
remediation procedures.

**8.12.3.1.2 ALC_FLR.2.2D:** The developer shall establish a procedure
for accepting and acting upon user reports of security flaws and
requests for corrections to those flaws.

**8.12.3.2 Content and presentation of evidence elements**

**8.12.3.2..1 ALC_FLR.2.1C:** The flaw remediation procedures
documentation shall describe the procedures used to track all reported
security flaws in each release of the product/system.

**8.12.3.2.2 ALC_FLR.2.2C:** The flaw remediation procedures shall
require that a description of the nature and effect of each security
flaw be provided, as well as the status of finding a correction to that
flaw.

**8.12.3.2.3 ALC_FLR.2.3C:** The flaw remediation procedures shall
require that corrective actions be identified for each of the security
flaws.

**8.12.3.2.4 ALC_FLR.2.4C:** The flaw remediation procedures
documentation shall describe the methods used to provide flaw
information and corrections to product/system users.

**8.12.3.2.5 ALC_FLR.2.5C:** The procedures for processing reported
security flaws shall ensure that any reported flaws are corrected and
the correction issued to product/system users.

**8.1.2.3.3 Evaluator action elements**

**8.1.2.3.3.1 ALC_FLR.2.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.13 Tests ATE_COV - Coverage 

**8.13.1 Objectives**

This family addresses those aspects of testing that deal with
completeness of

testing. That is, it addresses the extent to which the product/system
security functions are

tested, whether or not the testing is sufficiently extensive to
demonstrate that the product/system operates as specified, and whether
or not the order in which testing proceeds correctly accounts for
functional dependencies between the portions of the product/system being
tested.

**8.13.2 Application notes**

The specific documentation required by the coverage components will be
determined, in most cases, by the documentation stipulated in the level
of ATE_FUN that is specified.

## *8.1.3.3 ATE_COV.1 Complete coverage - informal* 

**Objectives**

In this component, the objective is that testing completely address the
security

functions.

**Application notes**

While the testing objective is to completely cover the product/system,
there is no more than informal explanation to support this assertion.

**8.13.3.1 Developer action elements**

**8.13.3.1.1 ATE_COV.1.1D:** The developer shall provide an analysis of
the test coverage.

**8.13.3.2 Content and presentation of evidence elements**

**8.1.3.3.2.1 ATE_COV.1.1C:** The analysis of the test coverage shall
demonstrate that the tests identified in the test documentation cover
the product/system.

**8.13.3.3 Evaluator action elements**

**8.13.3.3.1 ATE_COV.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.14 Tests ATE_DPT - Depth 

**8.14.1 Objectives**

The components in this family deal with the level of detail to which the
product/system is tested. Testing of security functions is based upon an
increasing depth of information derived from the analysis of the
representations.

The objective is to counter the risk of missing an error in the
development of the product/system. Additionally, the components of this
family, especially as testing is more concerned with the internals of
the product/system, are more likely to discover any malicious code that
has been inserted.

**8.14.2 Application notes**

The specific amount and type of documentation and evidence will, in
general, be

determined by that required by the level of ATE_FUN selected.

## *8.14.3 ATE_DPT.1 Testing - functional specification*

**Objectives**

The functional specification of a product/system provides a high level
description of the

external workings of the product/system. Testing at the level of the
functional specification, in order to demonstrate the presence of any
flaws, provides assurance that the product/system functional
specification has been correctly realized.

**Application notes**

The functional specification representation is used to express the
notion of the most

abstract representation of the product/system.

**8.14.3.1 Developer action elements**

**8.14.3.1.1 ATE_DPT.1.1D:** The developer shall provide the analysis of
the depth of testing.

**8.14.3.2 Content and presentation of evidence elements**

**8.14.3.2.1 ATE_DPT.1.1C:** The depth analysis shall demonstrate that
the tests identified in the test documentation are sufficient to
demonstrate that the product/system operates in accordance with the
functional specification of the product/system.

**8.14.3.3 Evaluator action elements**

**8.14.3.3.1 ATE_DPT.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.15 Tests ATE_FUN - Functional Tests 

**8.15.1 Objectives**

Functional testing establishes that the product/system exhibits the
properties necessary to satisfy the functional requirements of CKRS.
Functional testing provides assurance that the product/system satisfies
at least the security functional requirements, although it cannot
establish that the product/system does no more than what was specified.
The family \`\`Functional tests\'\' is focused on the type and amount of
documentation or support tools required, and what is to be demonstrated
through testing.

This family contributes to providing assurance that the likelihood of
undiscovered

flaws is relatively small.

**8.15.2 Application notes**

Procedures for performing tests are expected to provide instructions for
using test programs and test suites, including the test environment,
test conditions, test data parameters and values. The test procedures
should also show how the test results are

derived from the test inputs.

The developer shall eliminate all security relevant flaws discovered
during testing.

The developer shall test the product/system to determine that no new
security relevant flaws have been introduced as a result of eliminating
discovered security relevant flaws.

Tests shall include examination of procedures and documents that assist
in implementing the product/system security policy.

## *8.15.3 ATE_FUN.1 Functional Testing*

**Objectives**

The objective is for the developer to demonstrate that all security
functions perform as specified. The developer is required to perform
testing and to provide test documentation.

**8.15.3.1 Developer action elements**

**8.15.3.1.1 ATE_FUN.1.1D:** The developer shall test the product/system
and document the results.

**8.15.3.1.2 ATE_FUN.1.2D:** The developer shall provide test
documentation.

**8.15.3.2 Content and presentation of evidence elements**

**8.15.3.2.1 ATE_FUN.1.1C:** The test documentation shall consist of
test plans, test procedure descriptions, and test results.

**8.15.3.2.2 ATE_FUN.1.2C:** The test plans shall identify the security
functions to be tested and describe the goal of the tests to be
performed.

**8.15.3.2.3 ATE_FUN.1.3C:** The test procedure descriptions shall
identify the tests to be performed and describe the scenarios for
testing each security function.

**8.15.3.2.4 ATE_FUN.1.4C:** The test results in the test documentation
shall show the expected results of each test.

**8.15.3.2.5 ATE_FUN.1.5C:** The test results from the execution of the
tests by the developer shall demonstrate that each security function
operates as specified.

**8.15.3.3 Evaluator action elements**

**8.15.3.3.1 ATE_FUN.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

# 8.16 Tests ATE_IND - Independent Testing

**8.16.1 Objectives**

The objective is to demonstrate that the security functions perform as
specified.

Additionally, an objective is to counter the risk of an incorrect
assessment of the test outcomes on the part of the developer which
results in the incorrect implementation of the specifications, or
overlooks code that is non-compliant with the specifications.

**8.16.1 Application notes**

The testing specified in this family can be performed by a party other
than the evaluator (e.g., an independent laboratory, an objective
consumer organization).

This family deals with the degree to which there is independent
functional testing of the product/system. Independent functional testing
may take the form of repeating the developer\'s functional tests in
whole or in part. It may also take the form of the augmentation of the
developer\'s functional tests, either to extend the scope or the depth
of the developer\'s tests.

## 8.16.3 ATE_IND.2 Independent testing - sample

**Objectives**

The objective is to demonstrate that the security functions perform as
specified.

In this component, the objective is to select and repeat a sample of the
developer

testing.

**Application notes**

The suitability of the product/system for testing is based on the access
to the product/system, and the supporting documentation and information
required to run tests. The need for documentation is supported by other
assurance families (e.g., ATE_FUN)

Additionally, the suitability of the product/system for testing may be
based on other considerations (e.g., the version of the product/system
submitted by the developer is not the final version).

The developer is required to perform testing and to provide test
documentation and test results. This is addressed by the ATE_FUN family.

Testing may be selective and shall be based upon all available
documentation.

**8.16.3.1 Developer action elements**

**8.16.3.1.1 ATE_IND.2.1D:** The developer shall provide the
product/system for testing.

**8.16.3.2 Content and presentation of evidence elements**

**8.16.3.2.1 ATE_IND.2.1C:** The product/system shall be suitable for
testing.

**8.16.3.3 Evaluator action elements**

**8.16.3.3.1 ATE_IND.2.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.16.3.3.2 ATE_IND.2.2E:** The evaluator shall test the product/system
to confirm that the product/system operates as specified.

**8.16.3.3.3 ATE_IND.2.3E** The evaluator shall execute a sample of
tests in the test documentation to verify the developer test results.

# 8.17 Vulnerability Assessment AVA_VLA - Vulnerability Analysis 

**8.17.1 Objectives**

Vulnerability analysis is an assessment to determine whether
vulnerabilities could allow malicious users to violate the security
policy. These vulnerabilities will be identified during the evaluation
by flaw hypotheses,

Vulnerability analysis deals with the threats that a malicious user will
be able to discover flaws that will allow access to resources (e.g.,
data), allow the ability to interfere with or alter the product/system,
or interfere with the authorized capabilities of other users.

**8.17.2 Application notes**

The vulnerability analysis should consider the contents of all the
product/system deliverables for the targeted evaluation assurance level.

Obvious vulnerabilities are those that allow common attacks or those
that might be

suggested by the product/system interface description. Obvious
vulnerabilities are those in the public domain, details of which should
be known to a developer, publicly available, or available from NIST.

The evidence identifies all the product/system documentation upon which
the search for flaws was based.

## *8.17.3 AVA_VLA.1 Developer vulnerability analysis* 

**Objectives**

A vulnerability analysis is performed by the developer to ascertain the
presence of \`\`obvious\'\' security vulnerabilities.

The objective is to confirm that no identified security vulnerabilities
can be exploited in the intended environment for the product/system.

**Application notes**

Obvious vulnerabilities are those which are open to exploitations which
require a minimum of understanding of the product/system, skill,
technical sophistication, and

resources.

**8.17.3.1 Developer action elements**

**8.17.3.1.1 AVA_VLA.1.1D:** The developer shall perform and document an
analysis of the product/system deliverables searching for obvious ways
in which a user can violate the security policy.

**8.17.3.1.2 AVA_VLA.1.2D:** The developer shall document the
disposition of identified vulnerabilities.

**8.17.3.2 Content and presentation of evidence elements**

**8.17.3.2.1 AVA_VLA.1.1C:** The evidence shall show, for each
vulnerability, that the vulnerability cannot be exploited in the
intended environment for the product/system.

**8.17.3.3 Evaluator action elements**

**8.17.3.3.1 AVA_VLA.1.1E:** The evaluator shall confirm that the
information provided meets all requirements for content and presentation
of evidence.

**8.17.3.3.2 AVA_VLA.1.2E:** The evaluator shall conduct penetration
testing, based on the developer vulnerability analysis, to ensure that
obvious vulnerabilities have been addressed.

This section contains the Common Criteria assurance requirements that
are recommended for exclusion.

ADV_INT family relates to modularity, layering, information hiding, etc.
For economic reasons, this family is applied to deluxe assurance level
only.

ALC_DVS (Developmental Security), ALC_LCD (Life Cycle Definition), and
ALC_TAT (Tools and Techniques) are excluded in order to provide vendors
engineering independence, spur commercial product development, and align
assurance requirements with the commercial practices.

AVA_CCA (Covert Channel Analysis), AVA_SOF (Strength of Function, e.g.,
work factor for cryptographic operation) are excluded since they are not
particularly relevant here. AVA_CCA in non-discretionary policy
environments can be implemented using procedural controls such as
executing trusted software only. Cryptanalysis work factors will be
provided or implied by the FIPS cryptographic algorithms.

AVA_MSU (Misuse Analysis) is excluded since obvious flaws and known
flaws will come under AVA_VLA (Vulnerability Analysis). Given this is a
standard for SBU data, vulnerability analysis may be an overkill.

APPENDIX A

**EXAMPLES**

# A.1 Key Recovery Function Distribution

![](media/image16.png){width="2.5in" height="3.2in"}The functions of a
KRS may be integrated into products in a variety of configurations in
order to accommodate different user environments. In Figure 15, the KRI
Generation, Delivery, Receive and Validation functions are provided in a
single end user product. The Requestor and KRA functions are each
available as independent products. The separate Requestor System might
be appropriate in an organization which prefers to centralize the key
recovery process.

![](media/image17.png){width="2.0in" height="2.0in"}

In Figure 17, the KRA function is bundled with the KRI Generation and
Delivery Functions. This might be appropriate for an environment in
which the KRA generates the encryption key pair, sends it off to the
user and/or a CA for certification, and caches a copy of the private key
for potential recovery at a later time.

![](media/image18.png)

![](media/image19.png){width="3.0in" height="2.7597222222222224in"}

**A.2 KRI Generation Scenarios**

**A.2.1 Interactive Communications**

Each system has an encryption public key certificate (hereafter called
an encryption certificate) that identifies the key recovery method and
the identity of the KRA(s). Encryption certificates are also available
for the KRAs.

**A.2.1.1 Between Two Encapsulation Techniques**

In Figure 5, end user systems A and B are two systems that employ two
different encapsulation methods for key recovery, but using a common key
recovery block (KRB). A key transport method of key exchange is used
(e.g., the data key is encrypted using the receiver's encryption public
key). System A has a key recovery policy stating that key recovery
information is not created for interactive communications. System B has
a key recovery policy that states: (1) key recovery information must be
created for itself for all communications when that information is not
present, 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 and encrypts the data key using the public encryption key of
System B (obtained from System B's encryption certificate). System A
sends the encrypted key as part of the normal key exchange process.
System A then encrypts a message for System B, and sends the encrypted
message on the communications path.

When System B determines that no key recovery information is available
for the message received from System A (i.e., no KRB is present), System
B decrypts the encrypted data key (received as part of the key exchange
process), and uses the resulting plaintext data key to create key
recovery information for itself and/or its Key Recovery Agent. The KRI
is placed in a KRB in accordance with its key recovery scheme. By
examining System A's certificate, the identity of System A's KRA(s) can
be determined and the KRA encryption certificate(s) can be acquired. If
System B can create a KRB for System A's key recovery technique and all
information is available, key recovery information is created for System
A and/or its Key Recovery Agent(s). System B then uses the data key to
decrypt the received message. The newly created key recovery information
is then attached to the next message in the communication session and
sent back to System A.

In subsequent messages received by System A within this interactive
session, System A can recognize the presence of the KRI (perhaps perform
some processing of the KRI in the KRB) and decrypt the received
messages.

**A.2.1.2 Between Encapsulated and Key Caching Techniques**

Figure 8 includes end user systems A and B that use key caching and
encapsulation methods of key recovery, respectively. System B uses a
KRB. A key agreement method of key exchange is used (e.g., the
encryption public and private keys pairs of both parties to a
communication are used along with randomly generated values to generate
a shared data key at the end user systems). End user system A has a key
recovery policy that requires that all incoming communications must have
KRI available for the sender. System B has a policy stating that
communications will only conducted with other parties that employ key
recovery techniques, and that KRI is always created for itself in
outgoing communications.

End user system B wants to initiate a communication session with end
user system A. By obtaining system A's encryption certificate, system B
obtains system A's public encryption key as well as determining that
system A uses a key caching method of key recovery. System B initiates a
key exchange with System A to agree upon a data key, then encapsulates
the data key and other KRI in a KRB. The data key is then used to
encrypt the data, and the encrypted data and the KRB are sent to system
A.

End user system A (probably during the key exchange process) determines
that System B uses an encapsulated method of key recovery by examining
system B's encryption certificate. When the initial message is received
from system B, system A is able to recognize that there is a KRB for
system B. System A then proceeds to decrypt the received message.

**A.2.2 Store and Forward Communications**

**A.2.2.1 Between Two Key Caching Key Recovery Schemes**

In Figure 6, end user systems A and B employ key caching methods of key
recovery. A key transport method of key exchange is used. System B has a
policy stating that all outgoing email messages will be archived and
recoverable (i.e., KRI must be available to recover encrypted email
messages that have been archived). System A is able to recover incoming
encrypted email messages if key transport is used for key exchange.

System B generates a data encrypting key and encrypts the key using the
encryption public key of the receiver (system A) for use in the key
exchange (key transport process). Even though system B uses key caching,
there is nothing yet which allows system B to recover after the outgoing
message is archived. System B encrypts the data encrypting key using his
own encryption public key, and places it in a KRB. System B then
encrypts the message with the data encrypting key, and sends the
encrypted message and system A's copy of the encrypted data key to
system A. The encrypted message and the KRB are archived.

System A decrypts the data encrypting key received via the key transport
mechanism and decrypts the received message using that key.

**A.2.2.2 Between an Encapsulated Scheme and an End User System with No
Key Recovery Capability**

In Figure 5, end user system A uses an encapsulated method of key
recovery. End user system E has no key recovery capability. A key
transport method of key exchange is in use (e.g., the data key is
encrypted by the receiver's encryption public key). 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 A retains a copy of
all outgoing email messages. System A sends the KRB along an alternate
path from that of the encrypted messages; this allows system B to ignore
key recovery information so that interoperability is possible.

System A creates a data key, then creates Key Recovery information for
itself and/or its Key Recovery Agent, and places the KRI in a KRB. The
KRB is sent along the alternate communication path. The data key is
encrypted by system B's encryption public key (obtained from System B's
encryption certificate) and then used to encrypt an e-mail message. The
encrypted key is placed in the message header (the method of key
transport that is employed in this example) and sent with the encrypted
message to System B.

Upon receipt of the encrypted message and key exchange information ,
System B decrypts the data encryption key in the message header, and
uses the decrypted data encryption key to decrypt the message.

**A.2.3 Data Storage**

**A.2.3.1 Creation by an End User with an Encapsulated Scheme; Read
Access by Anyone**

For data storage applications, the Encryptor and Decryptor may not be
the same entity (e.g., shared files). In Figure 5, end user system A
uses an encapsulated method for key recovery. System A's organization
has a policy stating that key recovery information must exist for all
stored data. Read only access can be granted to a list of other systems
in the organization, whether or not those systems have a key recovery
capability.

System A creates a data key and uses the encryption public key of each
system on the access list to encrypt a copy of the data key for that
system (including itself). System A also encrypts the data key using the
encryption public key of the organization's KRA. The data key is then
used to encrypt the data. All copies of the encrypted key are placed in
a file along with the encrypted data.

When accessing the encrypted file, the acquiring end user system
decrypts the appropriate copy of the encrypted data key, and uses the
decrypted data key to decrypt the file.

**A.3 Key Recovery Scenarios**

**A.3.1 Interactive Session**

Referring back to scenario "Examples".2.1.2, when end user system A
initially tries to participate in the key exchange process, it is
discovered that the private key of the encryption public key pair is
lost. System A immediately requests the recovery of its private key from
the KRA using its automated ability to request key recovery. When the
private key is provided, system A can continue with the key exchange
process and participate in the determination of the data key to be used
for the communication session.

**A.3.2 Store-and-Forward Communications**

In scenario "Examples".2.2.1, the email message received by system A is
stored in the in-box until read. Suppose that the user receives a large
number of email messages before reading them. When attempting to read
the encrypted messages, it is discovered that the private key of the
encryption public key pair is corrupted. The user requests a recovery of
the private key from the key recovery function, uses the recovered
private key to decrypt the data key for each message, and then uses the
data key to decrypt the associated message.

**A.3.3 Data Storage**

In scenario "Examples".2.3.1, System A could create a file for himself
(i.e., no one else is on the access list, so the data encrypting key is
not encrypted for anyone else). At some later time, the user needs to
retrieve the file, but has lost access to his decryption key. The data
key can be recovered by sending the copy of the key which was encrypted
using the KRA's encryption public key to the KRA for decryption

**APPENDIX B**

**KEY RECOVERY BLOCK**

When different key recovery products that employ KRI encapsulation need
to interoperate with one another, one of the major obstacles is the
inability of the receiver product to recognize and validate the key
recovery information received from the sender product. In order to allow
the interoperability of various key recovery techniques which require
the use of KRI encapsulaton, a common structure \-- a Key Recovery Block
(KRB) \-- may be required. The KRB serves as a container for
technique-specific key recovery information, and supports generic
mechanisms to identify and validate the contained key recovery
information. Various levels of validation may be performed depending on
the key recovery techniques used by the sending and receiving parties,
including:

**•** Verification of the presence of the KRB,

**•** Validation of the integrity of the KRB,

• Authentication of the source and validation of the integrity of the
KRB \[WILL THIS BE THE CASE? INFO MAY NEED TO BE ADDED\], and

**•** Verification that the KRI can be used to recover the data key.

The KRB is independent of the encryption algorithm used to protect the
confidentiality of the data, and independent of the communication or
storage protocol used to carry the encrypted data.

The KRB should include the following fields of information:

-   The KRB version number,

-   The KRB length -- beginning at the version number and ending at the
    last word/byte of the Integrity Field,

-   Object Identifier (OID) for the key recovery technique used to
    generate the KRI field.

-   Encrypted Data Sensitivity (EDS) Field Type:

> Type = 0: NONE (no EDS field is specified)

-   Encrypted Data Sensitivity (EDS) Field Length:

> Number of {words/bytes} in the EDS field.

-   Encrypted Data Sensitivity (EDS) Field-- the sensitivity of the data
    recoverable by this KRB \[THIS NEED WAS IDENTIFIED IN THE BUSINESS
    REQUIREMENTS PAPER PRODUCED BY THE KEY RECOVERY ALLIANCE -- SEE
    SCENARIO 13, 2^ND^ COLUMN, 4^TH^ ITEM\] .

-   KRI Field length -- in {words,bytes}.

-   KRI Field (KRIF) -- the KRI as specified by the indicated key
    recovery technique using the format employed by that technique,

-   Encrypted Data Locator (EDL) Field Type -- identifies the method
    used to generate the EDL Field. Defined methods include:

> type = 0: NONE (no EDL field was calculated)

-   Encrypted Data Locator (EDL) Field Length:

> Number of {words/bytes} in the EDL field.

-   Encrypted Data Locator (EDL) Field:

> The value of the Encrypted Data Locator Field. This is reserved for
> possible future use in locating the encrypted data that may be
> recovered using this KRB.

-   Integrity Field Type:

> Identifies the method used to generate the Integrity Field. Defined
> methods include:
>
> type = 0: NONE (no integrity field was calculated)
>
> type = 1: SEMANTIC (no integrity field was calculated)
>
> type = 2: PROTOCOL (no integrity field was calculated)
>
> type = 3: CONF-HMAC-SHA-1-96 (integrity field calculated using HMAC
> and SHA-1 and the confidentiality key associated with the KRF -
> described in RFC 2104 and draft-ietf-ipsec-hmac-sha196-00.txt)
>
> type = 4: CONF-HMAC-MD5-96 (integrity field calculated using HMAC and
> MD5 and the confidentiality key associated with the KRF
>
> type = 5: INTEG-HMAC-SHA-1-96 (integrity field calculated using HMAC
> and SHA-1 and the integrity key associated with the session -
> described in RFC 2104 and draft-ietf-ipsec-hmac-sha196-00.txt)
>
> type = 6: INTEG-HMAC-MD5-96 (integrity field calculated using HMAC and
> MD5 and the integrity key associated with the session - described in
> RFC 2104 and draft-ietf-ipsec-hmac-md5-96-00.txt)
>
> type = 7: SIGNATURE-PKCS7 (integrity field calculated as a PKCS #7
> envelope with ContentType = \"signed data\" - described in the PKCS #7
> specification. The data content that is carried within the PKCS#7
> envelope is the hash of the KRF. The hash algorithm used is the same
> one that is specified within the PKCS#7 Content.

-   Integrity Field Length:

> Number of {words/bytes} in the Integrity Field. The Integrity Field
> Length must be consistent with the Integrity Field Type:

  ---------------------------------- ------------------------------------
  Integrity Field Type               Integrity Field Length

  0                                  0

  1                                  0

  2                                  0

  3                                  5

  4                                  4

  5                                  5

  6                                  4

  7                                  Varies
  ---------------------------------- ------------------------------------

-   Integrity Field Value:

> The value of the Integrity Field that is calculated over all fields of
> the KRB except for the Integrity Field Value itself.
>
> For Integrity Field Types 0 through 2, the Integrity Field value does
> not exist. For Integrity Field Types 3 and 5, the Integrity Field
> Value is a 20 byte hash of the KRF using HMAC and SHA-1. For Integrity
> Field Types 4 and 6, it is a 16 byte hash of the KRF using HMAC and
> MD5.
>
> For Integrity Field Type 7, the Integrity Field Value is a PKCS#7
> envelope \[SEE ENVELOPE STRUCTURE BELOW\] whose content is a hash of
> the relevant fields of the KRB using the digestAlgorithmIdentifier
> specified within the PKCS#7 Content.

\[NOTE: THE FOLLOWING MAY NEED TO BE REMOVED OR EXTENSIVELY REVISED
BASED ON THE THE FIPS VALIDATION REQUIREMENTS.\]

[Further Notes on the Integrity Field]{.underline}:

Certain key recovery products do not require any verification of the
KRIF to be done at the receiving side. These products should use
Integrity Field Type \"NONE\", indicating that KRIF verification is
unnecessary.

Certain other products use technique-specific validation methods for the
KRIF since these may be potentially stronger than the KRIF integrity
checking techniques that are supported by the KRB. Products of this
class should construct KRBs with Integrity Field Type \"SEMANTIC\",
implying that the KRIF should be validated semantically using the
technique-specific algorithm. A major drawback of using semantic
validation techniques is that interoperability between products using
dissimilar key recovery techniques may not be supportable.

Some key recovery products are based on secure communication protocols
which provide integrity protection for the KRB when it is carried as an
integral part of the secure association. This class of products should
use Integrity Field Type \"PROTOCOL\", implying that the KRIF need not
be checked for integrity since the carrier protocol provides integrity
protection for the entire KRB.

Finally, there are a class of key recovery products which require KRIF
validation by the receiver who cannot rely on the carrier protocol to
provide integrity protection to the KRB, and require interoperability
between heterogeneous key recovery systems. This class of products
should use the supported integrity checking mechanisms of the KRB by
using Integrity Field Types 3 to 7. The Integrity Field should contain
the value corresponding to the specified type.

Certain products may like to use keyed-hash based integrity checks for
the KRB. These products will generate KRBs with Integrity Field Types 3
to 6. The keyed-hash Integrity Field Types are defined for systems that
use a single key for confidentiality and integrity protection, as well
as systems using separate confidentiality and integrity keys. Types 3
and 4 use the confidentiality key associated with the session in
generating the HMAC value, while types 5 and 6 use the integrity key
associated with a session for the HMAC. A careful analysis of the
cryptographic system is required when the same key does double duty as
the encryption key and the HMAC key for the key recovery block.

Certain products may like to use digital signature techniques to
validate the integrity of the KRB. These products will generate KRBs
with Integrity Field Type 7, which denotes that the Integrity Field
Value is a PKCS#7 envelope that carries a digital signature over the
relevant fields of the KRB. The PKCS#7 format was chosen as a vehicle
for carrying the signature value since it allows the pertinent
certificates (needed for signature verification) to be conveniently
packaged in a well-known format. It may be noted that the Content within
the PKCS#7 envelope is a hash of the relevant fields of the KRB. Thus,
the actual signature carried within the PKCS#7 envelope will be
calculated on the hash of the KRB, rather than the KRB itself.

It may be noted that a product that generates a KRB specifies the
Integrity Field Type based on its assumptions about its operating
environment and its policy related to KRIF verification. Similarly, the
types of KRBs that may be accepted by a receiver product are based on
the receiver\'s assumptions about its operating environment and its
policy related to KRIF verification. This proposal in no way mandates
that a receiver product accept a KRB with all possible integrity Field
Types; it leaves the usage and acceptability of specific Integrity Field
Types to the discretion of the sending and receiving products.

The KRB format can also be used very conveniently to identify the KRIF
carried within it. Certain vendors may like to use the KRB format for
KRIF identification purposes only, but may not want to incur the
overhead of generating and verifying the integrity field. It is
recommended that these vendors use Integrity Field Type \"NONE\".

The KRB integrity field is a \"robust\" mechanism for verifying the
integrity of the enclosed KRIF. The integrity field is not susceptible
to typical man-in-the-middle attacks (MITM). Modification of the
Integrity Field Type is not useful to an attacker, since the
communicating peers have a security association that demands specific
Integrity Field Types. Substitution of the KRIF and the corresponding
Integrity Field value (for types 3 to 6) does not succeed, since the
MITM does not have the session key necessary to generate a valid
Integrity Field value for the bogus KRIF that was substituted.

KRB Format: \[NEED TO DECIDE HOW DEEPLY TO SPECIFY THE KRB. SHOULD
PROBABLY SPECIFY ENOUGH THAT ANY PROTOCOL USING THE KRB INFORMATION
WOULD USE THE SAME STRUCTURE, ALLOWING DEVELOPERS TO DESIGN TO THE SAME
FORMAT.\]

  ----------------- ----------------- ----------------- -----------------
  31                23                15                7

  Version                             KRB Length        

  Key Recovery                                          
  Technique OID                                         

  EDS Field Type                      EDS Field Length  

  Encrypted Data                                        
  Sensitivity (EDS)                                     

  Reserved                            KRIF Length       

  Key Recovery                                          
  Information Field                                     
  (KRIF)                                                

  EDL Field Type                      EDL Field Length  

  Encrypted Data                                        
  Locator (EDL)                                         
  Field                                                 

  Integrity Field                     Integrity field   
  Type                                length            

  Integrity Field                                       
  Value                                                 
  ----------------- ----------------- ----------------- -----------------

[Implementation Guidance]{.underline}:

Vendors that are compliant with the common KRB format, would design
their products so that their KRIF (in its proprietary format) is placed
within the common KRB defined above. The appropriate information should
be provided in the other fields of the KRB. When a compliant product
receives a KRB with an integrity field, the product can validate the
KRIF embedded within the KRB, either by using the KRB integrity field,
or the technique-specific validation algorithm (if known).

[PKCS #7 Structure]{.underline}

PKCS #7 contains the following fields:

-   Version

-   Digest Algorithm ID

-   Content

-   Certificates (opt.)

-   CRLs (Opt.)

-   Signer Info

> version,
>
> issuer & serial ID,
>
> digest algorithm ID,
>
> authenticated attribute (opt.),
>
> encrypted digest,
>
> unauthenticated attributes (opt.)

Note: There may be multiple Signer Info fields.

APPENDIX C

In order to facilitate the recovery of a key in a Public Key
Infrastructure (PKI), the appropriate certificates should be extended to
include key recovery information. Modifications may include:

• The encryption certificate for a KRA should include:

> \(1\) a key usage bit which indicates that the public key is to be
> used for key recovery purposes, and
>
> \(2\) an identification of the key recovery technique(s) with which
> the public key may be used.

-   A certificate for the entity using key recovery should include:

> \(1\) an indication that the entity has a key recovery capability,
>
> \(2\) identify the KRA(s),

(3) indicate the KRA certificate(s) containing the appropriate KRA
    public key(s),

(4) identify the key recovery technique(s) supported by the entity, and

(5) include any key recovery technique information required

    **APPENDIX D**

# INTEROPERABILITY

### D.1 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.

### D.2 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.

## D.3 S/MIME {#d.3-smime .unnumbered}

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.

## D.4 MSP {#d.4-msp .unnumbered}

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.

## D.5 PEM {#d.5-pem .unnumbered}

The Privacy Enhanced Mail (PEM) protocol provides encryption for
Internet electronic mail. PEM defines one encapsulation mechanism 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.

### D.6 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

**D.6.1. PURPOSE**

This technical note proposes a scheme for inserting a key recovery block
(KRB) into the Internet Security Association Key Management Protocol
(ISAKMP).

**D.6.2. OVERVIEW**

The requirements for the key recovery approach are that it MUST:

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

-   Allow interoperation of products from different vendors which have
    implemented different key recovery infrastructures.

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

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

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

    **D.6.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

-   Identify Protection exchange

-   Authentication Only exchange

-   Aggressive exchange

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

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

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

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

-   The type and length fields are prepended to the KRB. The type field
    is an IANA registered number indicating \"additional key management
    information.\"

-   The key recovery block is placed into the Notification Data field of
    a notification payload. The notify message type is set to 16384
    (connected).

-   The remainder of the notification payload fields are filled in just
    as they would be for a normal connected notification.

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

6.  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        | MjVer  | M |       | E |           |     | Flags          |
| Payload     |        | n |       | x |           |     |                |
|             |        | V |       | c |           |     | COMMIT = 0     |
| HASH = 8    |        | e |       | h |           |     |                |
|             |        | r |       | a |           |     | ENCRYPTION = 0 |
|             |        |   |       | n |           |     |                |
|             |        |   |       | g |           |     |                |
|             |        |   |       | e |           |     |                |
|             |        |   |       | T |           |     |                |
|             |        |   |       | y |           |     |                |
|             |        |   |       | p |           |     |                |
|             |        |   |       | e |           |     |                |
|             |        |   |       |   |           |     |                |
|             |        |   |       | I |           |     |                |
|             |        |   |       | N |           |     |                |
|             |        |   |       | F |           |     |                |
|             |        |   |       | O |           |     |                |
|             |        |   |       | R |           |     |                |
|             |        |   |       | M |           |     |                |
|             |        |   |       | A |           |     |                |
|             |        |   |       | T |           |     |                |
|             |        |   |       | I |           |     |                |
|             |        |   |       | O |           |     |                |
|             |        |   |       | N |           |     |                |
|             |        |   |       | A |           |     |                |
|             |        |   |       | L |           |     |                |
|             |        |   |       | = |           |     |                |
|             |        |   |       | 5 |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Message ID  |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Length      |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Hash        |        |   |       |   |           |     |                |
| payload     |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Next        |        |   | RES   |   |           | P   |                |
| Payload     |        |   | ERVED |   |           | ayl |                |
|             |        |   |       |   |           | oad |                |
| NOTIFY = 11 |        |   |       |   |           | Len |                |
|             |        |   |       |   |           | gth |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Hash Data   |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| N           |        |   |       |   |           |     |                |
| otification |        |   |       |   |           |     |                |
| payload     |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Next        |        |   | RES   |   |           | P   |                |
| Payload     |        |   | ERVED |   |           | ayl |                |
|             |        |   |       |   |           | oad |                |
| NONE = 0    |        |   |       |   |           | Len |                |
|             |        |   |       |   |           | gth |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Domain of   |        |   |       |   |           |     |                |
| Int         |        |   |       |   |           |     |                |
| erpretation |        |   |       |   |           |     |                |
| (DOI)       |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Protocol-ID |        |   | SPI   |   |           | Not |                |
|             |        |   | Size  |   |           | ify |                |
|             |        |   |       |   |           | M   |                |
|             |        |   |       |   |           | ess |                |
|             |        |   |       |   |           | age |                |
|             |        |   |       |   |           | T   |                |
|             |        |   |       |   |           | ype |                |
|             |        |   |       |   |           |     |                |
|             |        |   |       |   |           | CON |                |
|             |        |   |       |   |           | NEC |                |
|             |        |   |       |   |           | TED |                |
|             |        |   |       |   |           | =   |                |
|             |        |   |       |   |           | 16  |                |
|             |        |   |       |   |           | 384 |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| Security    |        |   |       |   |           |     |                |
| Parameter   |        |   |       |   |           |     |                |
| Index (SPI) |        |   |       |   |           |     |                |
+-------------+--------+---+-------+---+-----------+-----+----------------+
| N           |        |   |       |   | Not       |     |                |
| otification |        |   |       |   | ification |     |                |
| Data        |        |   |       |   | 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.

2.  The hash functions are performed as described in ISAKMP and Oakley.
    This validates the contents of the notification payload.

3.  The notification payload is processed.

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

-   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. (Three of the authors are from
> the Government and the fourth is from Terisa Systems. Unfortunately,
> none are members of the key recovery alliance.) These issues are
> identified in the summary.
>
> **D.6.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.

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

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

```{=html}
<!-- -->
```
-   IP Security Architecture

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

-   Defines two mechanisms for cryptographic protection of IP datagrams

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

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

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

-   Integrity, authentication, and confidentiality for IP datagrams

-   Alone, in combo with AH, or nested

-   Host-host, GW-GW, host-GW

-   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 (??)

-   draft-ietf-ipsec-esp-v2-00.txt (July 97)

-   draft-ietf-ipsec-auth-header-01.txt (July 97)

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

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

-   Define fields previously defined in transform docs

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

-   Minimize combinatorial explosion of transforms

-   Little-to-no impact on key recovery approach Key Recovery Header
    (KRH)

-   New, third mechanism for key recovery

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

-   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