**REQUIREMENTS FOR**

**KEY RECOVERY** **PRODUCTS**

(ADVISORY COMMITTEE WORKING DRAFT)

**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 products used by Federal government agencies. These
products 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.

**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.** Requirements for Key Recovery Products.

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

**3. Explanation.** This Standard specifies requirements for key
recovery products. 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 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 functional, security, assurance
and interoperability of key recovery products.

**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,
> January 1994.
>
> d\. DOD 5200.28-STD, Department of Defense Trusted Computer System
> Evaluation Criteria (TCSEC) ("The Orange Book"), National Computer
> Security Center, December 1985.
>
> e\. SC 27 N1953 Evaluation Criteria for IT Security, Part 3 --
> Security Assurance Requirements

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.** To be supplied by the Federal Government.

**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) Requirements for Key Recovery Products (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.** (TBS)

![](media/image1.png){width="6.49375in"
height="3.8930555555555557in"}**12. Patents.** Implementations of this
standard may be covered by U.S. and foreign patents.

**13. Implementation Schedule.** **(TBS)**

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

15. 

16. ==== The glossary was not reviewed by the committee as of 6/19/98
    =====

+---------------+------------------------------------------------------+
| Abstract      | The underlying hardware or firmware abstraction to   |
| Machine       | which the software is written.                       |
+---------------+------------------------------------------------------+
| A             |                                                      |
| ccountability |                                                      |
+---------------+------------------------------------------------------+
| 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       |
| Events        | appear in an audit log (see Section 4).              |
+---------------+------------------------------------------------------+
| A             | Information used to authenticate an entity, e.g., a  |
| uthentication | password, PIN, biometric, or response to a           |
| Data          | challenge.                                           |
+---------------+------------------------------------------------------+
| A             | See "Authentication Data".                           |
| uthentication |                                                      |
| Information   |                                                      |
+---------------+------------------------------------------------------+
| A             | A technique used to authenticate an entity, e.g.,    |
| uthentication | user ID and password, token, biometric or            |
| Mechanism     | challenge-response.                                  |
+---------------+------------------------------------------------------+
| Authentic     | Used to provide a certificate infrastructure to      |
| Public Key    | support the use of public key cryptography within    |
| Source        | the Key Recovery 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.   |
+---------------+------------------------------------------------------+
| Authorized    | A user who is authorized to access a system to       |
| User          | perform one or more actions.                         |
+---------------+------------------------------------------------------+
| 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 is available but need not  |
| Capability    | 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 | A system containing encryption and decryption        |
| End System    | mechanisms.                                          |
+---------------+------------------------------------------------------+
| Data          | Voice, facsimile, computer files, electronic mail,   |
|               | and other stored or communicated information.        |
+---------------+------------------------------------------------------+
| Data Key      | A symmetric key used to encrypt data.                |
+---------------+------------------------------------------------------+
| Data Recovery | The system/subsystem used to recover encrypted data  |
| System        | using a recovered target 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.                           |
+---------------+------------------------------------------------------+
| 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.                    |
+---------------+------------------------------------------------------+
| Evidence of   | \(1\) A proof of the origin of information that      |
| Origin        | cannot be refuted by the originator, e.g., by using  |
|               | a digital signature. (2) Non-repudiation.            |
+---------------+------------------------------------------------------+
| Evidence of   | Should be "Proof of Receipt"?                        |
| Receipt       |                                                      |
+---------------+------------------------------------------------------+
| FIPS 140-1    | Specify basic security requirements for a            |
| Level 1       | cryptomodule. No physical security mechanisms are    |
|               | required in the module beyond the requirement for    |
| Security      | production-grade equipment. Software cryptographic   |
| Requirements  | functions may be performed in a general purpose      |
|               | personal computer.                                   |
+---------------+------------------------------------------------------+
| FIPS 140-1    | Improve upon the physical security of a Level 1      |
| Level 2       | cryptomodule by (1) requiring tamper evident         |
| Security      | coatings or seals, or for pick-resistent locks, (2)  |
| Requirements  | requiring role-based authentication and (3) allowing |
|               | software cryptography in multi-user timeshared       |
|               | systems when used in conjunction with a C2[^1] or    |
|               | equivalent operating system.                         |
+---------------+------------------------------------------------------+
| FIPS 140-1    | Improve upon the Level 1 and 2 requirements for      |
| Level 3       | cryptomodules by (1) requiring tamper detection      |
| Security      | mechanisms, (2) requiring identity-based             |
| Requirements  | authentication, (3) specifying stronger requirements |
|               | for entering and outputting critical security        |
|               | parameters, and (4) allowing software cryptography   |
|               | in multi-user timeshared systems when a B1 or        |
|               | equivalent trusted operating system is employed      |
|               | along with a trusted path for the entry and output   |
|               | of critical security parameters.                     |
+---------------+------------------------------------------------------+
| FIPS          | Meeting all requirements of a specified level of     |
| Compliant     | this standard.                                       |
+---------------+------------------------------------------------------+
| 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.           |
| 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.             |
| Communication |                                                      |
+---------------+------------------------------------------------------+
| Int           | The ability of components or systems to communicate  |
| eroperability | with one another.                                    |
+---------------+------------------------------------------------------+
| Key Escrow    | \(1\) The processes of managing (e.g., generating,   |
|               | storing, transferring, auditing) the cryptographic   |
|               | 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. (3) A method   |
|               | of key recovery where the secret or private 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. |
+---------------+------------------------------------------------------+
| Key Recovery  | Access to information sufficient to recover          |
|               | encrypted data.                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | A Key Recovery Agent System.                         |
| 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  | A cryptographic end system with either a KRI         |
| Capable       | Generation Function or a Key Recovery Validation     |
| System        | Function or both.                                    |
+---------------+------------------------------------------------------+
| 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  | A field, output by the key recovery mechanism of a   |
| Field         | product, that identifies key recovery agents and     |
|               | enables key recovery agents to identify the key(s)   |
|               | required to decrypt corresponding ciphertext output  |
|               | by the product.                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | Recovers a target key using Key Recovery             |
| Function      | Information. Composed of the KRI Requestor Function  |
|               | and KRA Function.                                    |
+---------------+------------------------------------------------------+
| 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      |
| Information   | single key recovery scheme.                          |
| Field (KRIF)  |                                                      |
+---------------+------------------------------------------------------+
| Key Recovery  | A stream of bytes that serves as a container for a   |
| Block (KRB)   | single key recovery scheme-specific KRIF and         |
|               | associates the KRIF 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  | An authorized key recovery as performed by a Key     |
| Service       | Recovery Agent.                                      |
+---------------+------------------------------------------------------+
| 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           | Key Recovery Agent                                   |
+---------------+------------------------------------------------------+
| KRB           | Key Recovery Block                                   |
+---------------+------------------------------------------------------+
| KRI           | Enables a receiver to determine the key recovery     |
| Acquisition   | information (KRI) which is available and acquire KRI |
| Function      | for subsequent processing.                           |
+---------------+------------------------------------------------------+
| KRI Delivery  | Assembles and formats the key recovery information   |
| Function      | (KRI) and makes the KRI available.                   |
+---------------+------------------------------------------------------+
| KRI           | A method of key recovery in which keys, key parts or |
| Encapsulation | key related information is maintained outside a Key  |
|               | Recovery Agent.                                      |
+---------------+------------------------------------------------------+
| KRI           | Generates the key recovery information (KRI) needed  |
| Generation    | to recover the target key and provides the KRI to    |
| Function      | the KRI Delivery Function.                           |
+---------------+------------------------------------------------------+
| KRI           | Manages the KRI after generation for potential       |
| Management    | recovery. Composed of the KRI Delivery Function, KRI |
| Function      | Receive Function and KRI Validation Function.        |
+---------------+------------------------------------------------------+
| KRI Providers | Those entities provide Key Recovery Information      |
|               | (KRI) using a KRI Generation Function.               |
+---------------+------------------------------------------------------+
| KRI           | Checks, authenticates, validates or verifies the     |
| Validation    | available key recovery information.                  |
| Function      |                                                      |
+---------------+------------------------------------------------------+
| KRR           | Key Recovery Requestor System.                       |
+---------------+------------------------------------------------------+
| KRS           | Key Recovery System                                  |
+---------------+------------------------------------------------------+
| Layered       | A product in which security functions are layered.   |
| Product       | For example, a secure application which is           |
|               | implemented on top of a secure operating system is a |
|               | layered product.                                     |
+---------------+------------------------------------------------------+
| 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.                   |
+---------------+------------------------------------------------------+
| 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.                                            |
+---------------+------------------------------------------------------+
| Monolithic    | A product in which security functions are not        |
| Product       | layered. See "Layered Product".                      |
+---------------+------------------------------------------------------+
| Non-Key       | An encryption product whose encryption output is not |
| Recovery      | recoverable through key recovery.                    |
| Product       |                                                      |
+---------------+------------------------------------------------------+
| Presentation  | Providing the information necessary to carrying out  |
| of Evidence   | the assurance activity.                              |
+---------------+------------------------------------------------------+
| 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.      |
+---------------+------------------------------------------------------+
| Proof of      | A proof of the receipt of information so that the    |
| Receipt       | recipient cannot deny having received the            |
|               | information, e.g., using a digital signature by the  |
|               | recipient on the received message.                   |
+---------------+------------------------------------------------------+
| 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.                |
+---------------+------------------------------------------------------+
| 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 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.                            |
+---------------+------------------------------------------------------+
| Security      | \(1\) A set of objects , a security policy , a       |
| Domain        | security authority and a set of relevant activities  |
|               | inwhich the set of elements are subject to the       |
|               | security policy , administered by the security       |
|               | authority , for the specified activities. (2) A set  |
|               | of security-related services, mechanisms, and        |
|               | policies.                                            |
+---------------+------------------------------------------------------+
| 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      | A formal representation of the security policy       |
| Policy Model  | enforced by the product.                             |
+---------------+------------------------------------------------------+
| Security      | A set of security requirements ad specifications to  |
| Target        | be                                                   |
|               |                                                      |
|               | used as the basis for evaluation of an identified    |
|               | product.                                             |
+---------------+------------------------------------------------------+
| Session-based | Interactive communications.                          |
| 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.                   |
+---------------+------------------------------------------------------+
| Source        | The ability to authenticate the identity of the      |
| A             | source of a information.                             |
| uthentication |                                                      |
+---------------+------------------------------------------------------+
| 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.                               |
+---------------+------------------------------------------------------+
| System        | Includes software, hardware, procedures.             |
+---------------+------------------------------------------------------+
| Target key    | The key recovered by a Key Recovery System.          |
+---------------+------------------------------------------------------+
| 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.                    |
| saction-based |                                                      |
| Protocols     |                                                      |
+---------------+------------------------------------------------------+
| Trusted Path  | A mechanism by which a person or process can         |
|               | communicate directly with a cryptographic module and |
|               | which can only be activated by the person, process   |
|               | or module, and cannot be imitated by untrusted       |
|               | software within the module.                          |
+---------------+------------------------------------------------------+
| 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.       |
+---------------+------------------------------------------------------+
| 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. It is the responsibility of an organization operating a
key recovery system to ensure 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.** (TBS)

**17. Where to Obtain Copies of the Standard.** (TBS)

**TABLE OF CONTENTS**

#  {#section .unnumbered}

1 Overview [1](#overview)

1.1 Scope of the Standard [1](#scope-of-the-standard)

1.2 Road Map for the Standard [2](#road-map-for-the-standard)

2 Key Recovery Model [4](#key-recovery-model)

2.1 Key Recovery Information (KRI) Generation Function
[7](#key-recovery-information-kri-generation-function)

2.2 KRI Delivery Function [8](#kri-delivery-function)

2.3 KRI Acquisition Function [9](#__RefHeading___Toc421076033)

2.4 KRI Validation Function [9](#kri-validation-function)

2.5 Requestor Function [10](#requestor-function)

2.6 Key Recovery Agent(s) [11](#key-recovery-agents)

2.7 Interoperability [12](#interoperability-move-to-after-2.8)

2.8 Mapping Components to the Key Recovery Model
[14](#__RefHeading___Toc421076038)

2.9 Key Recovery Techniques
[15](#key-recovery-techniques-move-to-an-appendix)

2.9.1 KRI Encapsulation [15](#kri-encapsulation)

2.9.2 Key Escrow [16](#key-escrow)

2.9.3 Interactions Between Systems Using Different Key Recovery
Techniques
[17](#interactions-between-systems-using-different-key-recovery-techniques)

2.9.3.1 Interactions Between KRI Encapsulation and Key Escrow Techniques
[17](#interactions-between-kri-encapsulation-and-key-escrow-techniques)

2.9.3.2 Interactions Between KRI Encapsulation and Systems with No Key
Recovery
[18](#interactions-between-kri-encapsulation-and-systems-with-no-key-recovery)

2.9.3.3 Interaction Between Key Escrow and Systems with No Key Recovery
[19](#interaction-between-key-escrow-and-systems-with-no-key-recovery)

3 Security Requirements [20](#security-requirements)

3.1 Key Recovery Agent Requirements
[20](#key-recovery-agent-requirements)

3.1.1 Level 1 -- Medium Assurance [20](#level-1-medium-assurance)

3.1.1.1 Cryptographic Functions [20](#cryptographic-functions)

3.1.1.2 Cryptographic Algorithms [20](#cryptographic-algorithms)

3.1.1.3 Confidentiality [20](#confidentiality)

3.1.1.4 Integrity [21](#integrity)

3.1.1.5 Audit [21](#audit)

3.1.1.6 Identification and Authentication
[23](#identification-and-authentication)

3.1.1.7 Access Control [25](#access-control)

3.1.1.8 Authentication of Received Transactions
[26](#authentication-of-received-transactions)

3.1.1.9 Non-Repudiation [26](#non-repudiation)

3.1.1.10 Protection of Trusted Security Functions
[27](#protection-of-trusted-security-functions)

3.1.2 Level 2 -- High Assurance [27](#level-2-high-assurance)

3.1.2.1 Cryptographic Functions [27](#cryptographic-functions-1)

3.1.2.2 Cryptographic Algorithms [27](#cryptographic-algorithms-1)

3.1.2.3 Confidentiality [28](#confidentiality-1)

3.1.2.4 Integrity [28](#integrity-1)

3.1.2.5 Audit [28](#audit-1)

3.1.2.6 Identification and Authentication
[31](#identification-and-authentication-1)

3.1.2.7 Access Control [31](#access-control-1)

3.1.2.8 Authentication of Received Transactions
[33](#authentication-of-received-transactions-1)

3.1.2.9 Non Repudiation [33](#non-repudiation-1)

3.1.2.10 Protection of Trusted Security Functions
[33](#protection-of-trusted-security-functions-1)

3.2 Key Recovery Information Generator
[34](#key-recovery-information-generator-function)

3.2.1 Level 1 -- Medium Assurance Key Recovery Information Generator
[34](#level-1-medium-assurance-key-recovery-information-generator)

3.2.1.1 Cryptographic Functions [34](#cryptographic-functions-2)

3.2.1.2 Cryptographic Algorithms [34](#cryptographic-algorithms-2)

3.2.1.3 Confidentiality [34](#confidentiality-2)

3.2.1.4 Integrity [34](#integrity-2)

3.2.1.5 Identification and Authentication
[35](#__RefHeading___Toc421076076)

3.2.1.6 Access Control [35](#access-control-2)

3.2.2 Level 2 -- High Assurance Key Recovery Information Generator
[35](#level-2-high-assurance-key-recovery-information-generator)

3.2.2.1 Cryptographic Functions [36](#cryptographic-functions-3)

3.2.2.2 Cryptographic Algorithms [36](#cryptographic-algorithms-3)

3.2.2.3 Confidentiality [36](#confidentiality-3)

3.2.2.4 Integrity [36](#integrity-3)

3.2.2.5 Identification and Authentication
[36](#identification-and-authentication-2)

3.2.2.6 Access Control [36](#access-control-3)

3.3 Key Recovery Information Delivery
[36](#key-recovery-information-delivery-function)

3.4 Key Recovery Information Acquisition
[36](#__RefHeading___Toc421076086)

3.5 Key Recovery Information Validator
[37](#key-recovery-information-validator-function)

3.5.1 Level 1 -- Medium Assurance Key Recovery Information Validator
[37](#level-1-medium-assurance-key-recovery-information-validator)

3.5.1.1 Cryptographic Functions [37](#cryptographic-functions-4)

3.5.1.2 Cryptographic Algorithms [37](#cryptographic-algorithms-4)

3.5.1.3 Integrity [37](#integrity-4)

3.5.2 Level 2 -- High Assurance Key Recovery Information Validator
[38](#level-2-high-assurance-key-recovery-information-validator)

3.5.2.1 Cryptographic Functions [38](#cryptographic-functions-5)

3.5.2.2 Cryptographic Algorithms [38](#cryptographic-algorithms-5)

3.5.2.3 Integrity [38](#integrity-5)

3.6 Key Recovery Requestor [38](#key-recovery-requestor)

3.6.1 Level 1 -- Medium Assurance [39](#level-1-medium-assurance-1)

3.6.1.1 Cryptographic Functions [39](#cryptographic-functions-6)

3.6.1.2 Cryptographic Algorithms [39](#cryptographic-algorithms-6)

3.6.1.3 Confidentiality [39](#confidentiality-4)

3.6.1.4 Integrity [40](#integrity-6)

3.6.1.5 Audit [40](#audit-2)

3.6.1.6 Identification and Authentication
[42](#identification-and-authentication-3)

3.6.1.7 Access Control [43](#access-control-4)

3.6.1.8 Authentication of Received Transactions
[43](#authentication-of-received-transactions-2)

3.6.1.9 Non-Repudiation [44](#non-repudiation-2)

3.6.1.10 Protection of Trusted Security Functions
[44](#protection-of-trusted-security-functions-2)

3.6.2 Level 2 -- High Assurance [45](#level-2-high-assurance-1)

3.6.2.1 Cryptographic Functions [45](#cryptographic-functions-7)

3.6.2.2 Cryptographic Algorithms [45](#cryptographic-algorithms-7)

3.6.2.3 Confidentiality [45](#confidentiality-5)

3.6.2.4 Integrity [45](#integrity-7)

3.6.2.5 Audit [45](#audit-3)

3.6.2.6 Identification and Authentication
[46](#identification-and-authentication-4)

3.6.2.7 Access Control [46](#access-control-5)

3.6.2.8 Authentication of Received Transactions
[46](#authentication-of-received-transactions-3)

3.6.2.9 Non Repudiation [46](#non-repudiation-3)

3.6.2.10 Protection of Trusted Security Functions
[47](#protection-of-trusted-security-functions-3)

KRA Availability
[48](#kra-availability-if-we-want-to-make-this-a-level-2-kra-requirement-put-it-there-else-delete-it)

The KRA facility should be required to have the capability to securely
replicate any key recovery information stored in order to support
continued on-line access in case of a facility failure.
[48](#the-kra-facility-should-be-required-to-have-the-capability-to-securely-replicate-any-key-recovery-information-stored-in-order-to-support-continued-on-line-access-in-case-of-a-facility-failure.)

4 Assurance Requirements [50](#assurance-requirements)

4.1 Configuration Management [53](#configuration-management)

4.1.1 Configuration Management ACM_CAP -- CM Capabilities
[53](#configuration-management-acm_cap-cm-capabilities)

4.1.1.1 ACM_CAP.1 Minimal Support [53](#acm_cap.1-minimal-support)

4.1.2 Configuration Management ACM_SCP - CM Scope
[54](#configuration-management-acm_scp---cm-scope)

4.1.2.1 ACM_SCP.2 Problem Tracking CM Coverage
[55](#acm_scp.2-problem-tracking-cm-coverage)

4.2 Delivery and Operation [55](#delivery-and-operation)

4.2.1 Delivery and Operation ADO_DEL -- Delivery
[55](#delivery-and-operation-ado_del-delivery)

4.2.1.1 ADO_DEL.1 Delivery Procedures
[56](#ado_del.1-delivery-procedures)

4.2.1.2 ADO_DEL.2 Detection of Modification
[56](#ado_del.2-detection-of-modification)

4.2.2 Delivery and Operation ADO_IGS - Installation, Generation, and
Start-up
[57](#delivery-and-operation-ado_igs---installation-generation-and-start-up)

4.2.2.1 ADO_IGS.1 Installation, Generation, and Start-up Procedures
[58](#ado_igs.1-installation-generation-and-start-up-procedures)

4.3 Development [58](#development)

4.3.1 Development ADV_FSP - Functional Specification
[58](#development-adv_fsp---functional-specification)

4.3.1.1 ADV_FSP.1 Functional Specification and Security Policy
[59](#adv_fsp.1-functional-specification-and-security-policy)

4.3.1.2 ADV_FSP.2 Functional Specification, Security Policy and Informal
Security Policy Model
[60](#adv_fsp.2-functional-specification-security-policy-and-informal-security-policy-model)

4.3.2 Development ADV_HLD - High-Level Design
[61](#development-adv_hld---high-level-design)

4.3.2.1 ADV_HLD.1 Descriptive High-Level Design
[63](#adv_hld.1-descriptive-high-level-design)

4.3.2.2 ADV_HLD.2 Security Enforcing High-Level Design
[63](#adv_hld.2-security-enforcing-high-level-design)

4.3.3 Development ADV_IMP - Implementation Representation
[64](#development-adv_imp---implementation-representation)

4.3.3.1 ADV_IMP.1 Subset of the Implementation
[65](#adv_imp.1-subset-of-the-implementation)

4.3.4 Development ADV_LLD - Low-Level Design
[66](#development-adv_lld---low-level-design)

4.3.4.1 ADV_LLD.1 Descriptive Low-Level Design
[67](#adv_lld.1-descriptive-low-level-design)

4.3.5 Development ADV_RCR - Representation Correspondence
[68](#development-adv_rcr---representation-correspondence)

4.3.5.1 ADV_RCR.1 Informal Correspondence Demonstration
[69](#adv_rcr.1-informal-correspondence-demonstration)

4.4 Guidance Documents [69](#guidance-documents)

4.4.1 Guidance Documents AGD_ADM Administrator Guidance
[69](#guidance-documents-agd_adm-administrator-guidance)

4.4.1.1 AGD_ADM.1 Administrator Guidance
[70](#agd_adm.1-administrator-guidance)

4.4.2 Guidance Documents AGD_USR - User Guidance
[71](#guidance-documents-agd_usr---user-guidance)

4.4.2.1 AGD_USR.1 User Guidance [72](#agd_usr.1-user-guidance)

4.5 Life Cycle Support [73](#life-cycle-support)

4.5.1 Life Cycle Support ALC_FLR - Flaw Remediation
[73](#life-cycle-support-alc_flr---flaw-remediation)

4.5.1.1 ALC_FLR.1 Basic Flaw Remediation
[73](#alc_flr.1-basic-flaw-remediation)

4.5.1.2 ALC_FLR.2 Flaw Reporting Procedures
[74](#alc_flr.2-flaw-reporting-procedures)

4.6 Tests [75](#tests)

4.6.1 Tests ATE_COV - Coverage [75](#tests-ate_cov---coverage)

4.6.1.1 ATE_COV.1 Complete Coverage - Informal
[75](#ate_cov.1-complete-coverage---informal)

4.6.2 Tests ATE_DPT - Depth [76](#tests-ate_dpt---depth)

4.6.2.1 ATE_DPT.1 Testing - Functional Specification
[76](#ate_dpt.1-testing---functional-specification)

4.6.3 Tests ATE_FUN - Functional Tests
[77](#tests-ate_fun---functional-tests)

4.6.3.1 ATE_FUN.1 Functional Testing [77](#ate_fun.1-functional-testing)

4.6.4 Tests ATE_IND - Independent Testing
[78](#tests-ate_ind---independent-testing)

4.6.4.1 ATE_IND.2 Independent Testing - Sample
[79](#ate_ind.2-independent-testing---sample)

4.6.4.2 ATE_IND.3 Independent Testing - Complete
[80](#ate_ind.3-independent-testing---complete)

4.7 Vulnerability Assessment [81](#vulnerability-assessment)

4.7.1 Vulnerability Assessment AVA_VLA - Vulnerability Analysis
[81](#vulnerability-assessment-ava_vla---vulnerability-analysis)

4.7.1.1 AVA_VLA.1 Developer Vulnerability Analysis
[81](#ava_vla.1-developer-vulnerability-analysis)

4.8 Excluded Assurance Requirements
[82](#excluded-assurance-requirements)

Appendix A: Examples [84](#appendix-a-examples)

Appendix B: Key Recovery Block [90](#appendix-b-key-recovery-block)

Appendix C: Certificate Extensions
[97](#appendix-c-certificate-extensions)

Appendix D: Interoperability Examples
[101](#appendix-d-interoperability-examples)

# 1 Overview {#overview .unnumbered}

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 must meet or exceed Federal
Government standards and the standards of those co-owners.

Encryption is an important tool for protecting the confidentiality of
communicated or stored data. When suitably strong encryption algorithms
are employed and implemented with appropriate assurance, encryption can
prevent the disclosure of communicated or stored data to unauthorized
parties. However, the unavailability, loss, or corruption of the keys
needed to decrypt encrypted data may prevent disclosure to
[authorized]{.underline} parties. To facilitate authorized access to
encrypted data in the face of such failures, this Standard establishes
requirements for of Key Recovery products.

## 1.1 Scope of the Standard {#scope-of-the-standard .unnumbered}

This Standard neither requires nor endorses any specific technology for
use in a KRS. It endeavors to be technology independent, so as not to
unduly impede innovation in this new area. However, it is not the case
that every conceivable key recovery technology will be amenable to
successful evaluation under this Standard, e.g., intrinsically insecure
KRS technologies may not be able to be evaluated.

This Standard presents a general model for a KRS. The model identifies
functions that are intrinsic to any KRS: the generation of Key Recovery
Information (KRI), the management of KRI, requests for key recovery, and
the satisfaction of such requests by one or more Key Recovery Agents
(KRAs). The Standard establishes functional, interoperability, security,
and security assurance requirements that apply to an implementation of
each KRS function.

A product submitted for evaluation under this Standard must embody one
or more of the KRS functions defined in this Standard. There is no
requirement that a product offered for evaluation embody all of the
defined functions; a compliant product may not constitute a complete
KRS. There is no requirement that a single product or a suite of
products from a single vendor embody all of the functions needed to
provide a complete KRS. Thus, the Standard permits the modular
implementation of a KRS, based on the assembly of components from one or
more sources. Since an organization employing key recovery will require
a complete KRS, additional guidance should be provided via other
documents to assist in evaluating the security of a system assembled
from components (from one or more vendors) that have been evaluated
against this standard.

1.  

2.  

3.  

4.  

5.  

6.  

7.  The security of a KRS is dependent on a mix of security disciplines,
    including computer, communication, procedural, physical, and
    personnel security. This Standard addresses only the computer and
    communication aspects of KRS security. Other critical aspects of KRS
    operation are outside the scope of this Standard. For example, a KRS
    must be available and survivable if it is to ensure authorized
    access to encrypted data, but this Standard does not address such
    concerns. Thus, compliance with this standard represents a set of
    necessary but not sufficient conditions for overall KRS security and
    utility.

If key recovery is offered as a service by a trusted third party, that
party could employ components (e.g., a KRA) that comply with this
Standard. However, the use of compliant components does not ensure the
security for a KRS as a whole, nor does it ensure available or
survivable KRS operations, as noted above. Hence, a KRS
[service]{.underline} cannot be said to comply with this Standard.

## 1.2 Road Map for the Standard {#road-map-for-the-standard .unnumbered}

Section 2 of this Standard defines the abstract model for a KRS and
defines the functions essential to KRS operation. Any product claiming
compliance must identify which KRS functions are embodied in the
product. Section 2 establishes functional and interoperability
requirements for identified KRS functions. A product submitted for
certification relative to this FIPS will be evaluated against the
functional and interoperability requirements applicable to the functions
that a vendor asserts are embodied in the product.

Section 3 defines the security requirements for KRS functions. Two
levels of compliance are defined: Level 1 and Level 2. An implementation
of a function at Level 1 provides basic security functionality, whereas
Level 2 offers a higher level of security functionality. The choice of
level *for an application or environment* is context sensitive, a
function of many factors, and this Standard provides no guidance to
prospective users in this regard. However, any product claiming
compliance with this Standard must declare the level at which each
function (for which compliance is claimed) the product is asserted to
comply. Because of the mapping between security levels and security
assurance levels, it is not necessary to separately assert assurance
level compliance.

Section 4 defines security assurance requirements for the implementation
of KRS functions. These requirements are derived from the Common
Criteria \[cite?\], and represent a profile of that security assurance
evaluation criteria for use in this context. Three levels of
(increasing) security assurance are defined: A, B and C. For each KRS
function defined in Section 2, and each security functionality level
defined in Section 3, one of these three assurance levels apply. Thus,
there is a one-to-one correspondence between security functionality and
assurance levels, on a per-function basis.

Appendix A contains illustrative examples of how to map the functions
defined in the model in Section 2 to sample KRS components in the
context of common applications. It also includes examples of how to map
several existing key recovery system technologies to these functions.
These examples are provided to assist vendors and evaluators in
understanding the KRS functional model, but are not normative.

Appendix B describes a Key Recovery Block (KRB) format based on work (in
progress) by the Key Recovery Alliance. The adoption of this format
would facilitate the encapsulation of KRI from different key recovery
schemes and allow validation of the integrity of KRI in a KRS, in
support of requirements specified in Section 2*.* However, use of the
KRB specified in this appendix is not a requirement of the Standard.

Appendix C defines an extension for X.509 v3 certificates and a profile
for other extensions employed in such certificates. Many KRS designs
make use of public key certificates. The extension defined here provides
a standard means of representing certain data supportive of several KRS
requirements. This appendix provides guidance for KRS designers and
standards bodies who choose to make use of X.509 v3 certificates in
support of key recovery, but the Standard does not mandate the use of
X.509 certificates nor of these extensions.

Appendix D contains illustrative examples of how key recovery enabled
systems can be designed to maximize interoperability, both with systems
that do not implement key recovery, and with systems that implement
different key recovery schemes.

# 2 Key Recovery Model {#key-recovery-model .unnumbered}

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

```{=html}
<!-- -->
```
-   a key that can be used to decrypt the encrypted data key.

The information required 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 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 in
storage. 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, 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"}\[fix figure to remove "FUNCTION" at top
level, change "key caching" to "key escrow", and add "Systems" to the
caption\]

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

![](media/image2.png){width="5.989583333333333in"
height="2.1743055555555557in"}\[fix figure to remove "FUNCTION" at top
level, and add "Systems" to the caption, add lines between modules as
specified in discussion\]

The key recovery model addresses multiple key recovery techniques (see
Section 2.8) and supports a wide variety of data applications,
including:

-   Interactive communication sessions

```{=html}
<!-- -->
```
-   Store-and-forward communications

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

A Key Recovery System (KRS) may exist over multiple "locations" (e.g.,
cryptographic end systems, KRA systems, Requestor system, and storage or
transmission media). The normal key \[used by a target application
exchange mechanism need not be affected by the use of key recovery
mechanisms. However, key exchange mechanisms may be used to support the
creation and distribution of key recovery information (e.g., the
integration of KRI into existing key exchange mechanisms is not
precluded). In the future, key exchange protocol designers may find it
beneficial to integrate key recovery into the base design of the
protocol.

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

The functions of the Key Recovery Model specified in this standard must
be implemented in products which, when used together with a key recovery
policy and procedures, form a Key Recovery System. 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 identifies the authorized key requestors and
specifies the conditions under which each is authorized to access data.
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.

The remainder of this section identifies functional and interoperability
requirements for key recovery products which are designed to be
conformant with this standard. Requirements are designated by "Req"
numbers, and the requirement and its number are presented in a bold
font. Explanatory text is provided in subsequent paragraphs.

8.  There shall be a well-defined mapping from the key recovery
    functions of a product to the functions of the key recovery model. A
    vendor must provide a document describing the complete KRS scheme in
    which the product(s) submitted for evaluation are intended to
    operate. It must be possible to test the described interfaces
    between the product(s) and the functions needed to provide a
    complete KRS scheme. \[add text re determining if the submitted
    product is a cryptographic end system\]

A product claiming compliance with the Standard must be mappable to one
or more of the KRS functions defined in this Standard. There is no
requirement that a product offered for evaluation embody all of the
defined functions, nor is there a requirement that a single vendor
provide a complete KRS. The modular implementation of a KRS, based on
the assembly of components from one or more sources, is allowed.
However, a vendor submitting a product for evaluation must provide a
thorough description of how the KRS functions in product fit into a
complete KRS. The description must include all interfaces between the
KRS functions embodied in the submitted product and any KRS functions
with which they interact. For product evaluation, it must be possible to
test these interactions, either by assembling a complete KRS, or through
the use of simulation, test fixtures, or through analytic means.

9.  A product submitted for evaluation must be configurable so that it
    would be possible to interoperate with some product(s) (extant or
    not) to form a complete KRS composed only from compliant KRS
    functions. Each KRS function in the selected subset shall be capable
    of operating independently of the functions outside of the selected
    subset.

A product may be submitted for evaluation of a subset of the KRS
functions it provides. This allows a product to offer both compliant and
non-compliant KRS functions, and receive certification only for the
compliant ones.

10. If a function in a product submitted for evaluation may operate in
    both compliant and non-compliant modes, the product shall be
    configurable so that one can determine unambiguously whether the
    compliant or non-compliant mode of the function will be invoked.

11. 

## 2.1 Key Recovery Information (KRI) Generation Function {#key-recovery-information-kri-generation-function .unnumbered}

12. Each instance of the KRI Generation Function shall generate all or
    part of the KRI. If KRI is generated by more than one instance of
    this function, the set of all KRI generating functions must yield
    KRI sufficient for key recovery.

The KRI Generation Function consists of one or more KRI-generating
entities, also called KRI providers. 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). The way this this
function is implemented often differs among key recovery schemes, hence
no detailed requirements are expressed for this function.

The KRI Generation Function may be distributed over multiple locations
(e.g., systems, or hardware or software components) - all KRI required
to recover a given data key/ciphertext set need not be created by the
same generating entity. For example, the entity generating an encryption
key pair may be different than the entity using that key pair to secure
the data key which was used to encrypt the ciphertext data. See Appendix
A for further examples.

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 escrowing systems (see Section 2.9.2),
initialization and configuration may involve setting parameters that
will allow a secure communication channel to be established between a
cryptographic end system and a KRA for the escrowing of private keys.
For KRI encapsulation systems (see Section 2.9.1), initialization may
involve obtaining authentic copies of the KRA public key(s) for
subsequent use in encapsulating the KRI by the cryptographic end system.
\[swap order of the last two sentences\]These are critical aspects of
the overall Key Recovery System, but their definition is beyond the
scope of this document.

13. An instance of the KRI Generation Function assembles and formats all
    or part of the KRI for use by other key recovery functions.

The KRI Generation Function generates, assembles and formats the KRI, as
appropriate, for consumption by the KRI Validation Function, the Key
Recovery Requestor Function and the KRA Function. The format of the KRI
and its delivery method is generally specific to a key recovery
technique. Information may be acquired from multiple sources (e.g., one
or more CA certificates, a key generation device or a time stamping
device) in order to generate the required KRI necessary for a given key
recovery technique.

A method is required for associating encrypted data with the KRI that
can be used to recover that data. This may be accomplished in a product
by (1) providing plaintext information pointing to the KRI within a
structure containing the encrypted data, (2) providing plaintext
information pointing to the encrypted data within a structure containing
the KRI, (3) by a well-defined placement of the KRI and the encrypted
data (e.g., within the same message), (4) by acquiring information from
another source associated with the encrypted data (e.g., by examining a
certificate to determine that a key is escrowed), or (5) by a
combination of such techniques.

14. The KRI Generation Function is responsible for ensuring the validity
    of its output.

This includes all information generated by the function itself, as well
as information generated by other sources (e.g., another KRI Generation
Function, a CA, time stamping authority, etc.) which are used in the
assembly and format process. In some instances this requirement may be
met by authenticating the sources of inputs to KRI generation, as
opposed to validating the inputs themselves.

15. The KRI Generation Function shall provide the generated KRI to the
    KRI Delivery Function.

16. A Level 2 product must not provide a facility to deactivate KRI
    generation.

Fort a Level 1 product, KRI generation may be configurable, but in a
Level 2 product there must be no facility to deactivate KRI generation.

## 2.2 KRI Delivery Function {#kri-delivery-function .unnumbered}

The KRI Delivery Function makes the generated KRI available for
validation and recovery (e.g., by storing or transmitting the KRI). The
KRI Delivery Function may be distributed over multiple locations (e.g.,
systems, or hardware or software components).

17. When KRI is delivered in conjunction with a standard communication
    protocol, the transmission format shall be determined by that
    protocol standard.

There are a number of standard communication protocols that allow the
use of encryption to protect the data carried by that protocol. When KRI
is introduced into one of these communication protocols, it must be done
in a manner that preserves the ability to communicate present in the
protocol prior to the introduction of key recovery (see Section 2.7,
Interoperability). \[redundant, given 2.7?\]

18. The KRI Delivery Function shall store KRI with persistence and
    availability commensurate with that of the corresponding stored
    ciphertext.

KRI for a given data key/ciphertext pair must be available for the
duration of time that the given ciphertext exists. If the ciphertext is
decrypted and subsequently not available in its original ciphertext form
(e.g., stored in plaintext or re-encrypted with a different data key),
then the original KRI is no longer required. The KRI Delivery function
is expected to call upon normally available storage system resources to
effect appropriate persistence and availability, but no extraordinary
measures need be employed.

19. The KRI Delivery Function shall make the KRI available to the key
    requestor function or KRAs or both.

The KRI Delivery Function shall make the KRI available to the key
requestor function 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 one or more
locations known to and accessible by the Key Recovery Requestor (i.e.,
the requestor(s)).

20. The KRI Delivery Function (for level 2 compliance) shall make the
    KRI available to the KRI Acquisition Function .

The KRI Delivery Function must provide the KRI produced by the KRI
Generation Function to the KRI Acquisition Function, for relay to the
KRI Validation Function. The method of delivery may be via a
communication channel, storage device or directly between modules within
the same system.

##  {#section-1 .unnumbered}

## 

21. 

## 

## 

## 2.4 KRI Validation Function {#kri-validation-function .unnumbered}

22. If KRI Validation fails, access to plaintext at the cryptographic
    end system shall be denied.

23. The KRI Validation Function shall provide a capability for ensuring
    the availability of KRI.

24. 

The KRI Validation Function ensures that KRI is valid and usable for key
recovery. The intent of this function is to provide assurance that a key
requestor can use KRI to successfully recover a target key in order to
recover encrypted data. This function is required only for Level 2
products. Several methods of validation may be performed, including:

-   Checking certificates for the presence of KRI (e.g., KRA identities,
    key recovery technique),

```{=html}
<!-- -->
```
-   Checking that KRI is available for a KRA (e.g., in a recipient list
    or a key recovery block),

```{=html}
<!-- -->
```
-   Authenticating the source of the KRI,

```{=html}
<!-- -->
```
-   Validating the integrity of KRI associated with the encrypted data
    (e.g., received in the same message), and

```{=html}
<!-- -->
```
-   Verifying that the KRI can actually be used to recover the data key
    needed to decrypt the encrypted data (e.g., the correct target key
    can be produced).

-   Creating KRI, either when no KRI is received or in lieu of accepting
    and verifying KRI that is received, or if validation of received KRI
    is not successful. (In the last example, failure of the received
    validation is "overridden" by the receiver's generation of KRI.) In
    this case, a KRI Generation Function must be available.

## 2.5 Requestor Function {#requestor-function .unnumbered}

The Requestor Function authenticates the entity making the request to
the Key Recovery Agent. The Requestor Function consists of the requestor
and a Requestor Subsystem (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 Subsystem to interact with one or more Key Recovery Agents,
must be an authorized request \-- the requestor and the Requestor
Subsystem that issues a request for a key recovery service must be
authorized under system policy to access the data that can be decrypted
using the recovered target key. Furthermore, the requestor and the
Requestor Subsystem must establish their right to access that data. The
authentication and authorization process is beyond the scope of this
standard.

25. For given KRI, the Requestor Function shall have the ability to
    recover a target key by interacting with one or more Key Recovery
    Agents.

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 may then be used to recover the data using a Data Recovery
System. This later system is not specified in this standard.

KRI may be designed so that one KRA may not be able to provide all the
information necessary to recover a target key. For example, each KRA may
be able to provide key components which are then combined to reconstruct
the target key.

\[change "key chaching" to "key escrow"\]

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

## 2.6 Key Recovery Agent(s) {#key-recovery-agents .unnumbered}

A Key Recovery Agent (KRA), is a trusted function that performs a key
recovery service in response to an authorized request made by a
Requestor System on behalf of a requestor.

26. The KRA shall store keys, key components or any other information
    required to satisfy the recovery of a target key .

27. A Key Recovery Agent shall have the ability to process the KRI
    provided by the Requestor Function. Processing by the Key Recovery
    Agent shall yield some or all of the information required to decrypt
    data acquired by a Requestor.

The key recovery service performed by a KRA consists of processing all
or part of the KRI provided to the KRA by the Requestor System, and
returning an output value to the Requestor System. The output value may
be either the target key, or multiple key parts or key related
information which will allow the reconstruction of the target key.

## 2.7 Interoperability \[move to after 2.8\] {#interoperability-move-to-after-2.8 .unnumbered}

This standard establishes interoperability requirements for several
types of key recovery system products: cryptographic end systems, Key
Recovery Agents and Key Recovery Requestors. No interoperability
requirements are imposed on communication between a cryptographic end
system and a Key Recovery Agent (KRA). In this latter case, the
imposition of interoperability requirements is viewed as potentially too
restrictive in light of the wide range of key recovery technologies that
this Standard attempts to embrace.

This standard will define a syntax for communication between a Key
Recovery Requestor (KRR) and a KRA. This syntax applies only to
electronic key recovery transactions effected via a communication medium
(e.g., telephone, LAN or Internet). Key recovery transactions effected
via storage media (e.g., diskette or tape) or via direct interaction
(e.g., self recovery on a PC) are not covered by these requirements.
These syntactic requirements have been established to reduce life cycle
costs for users of key recovery systems and because it appears to be
feasible to do so without introducing undue constraints on technology
options. Section 5 (to be supplied) defines the syntax for this
communication. No interoperability requirements are imposed on
communication among KRAs from different vendors.

Interoperability requirements for cryptographic end systems apply only
to the use of key recovery for communicated data, not for data storage.
With regard to such systems, interoperability requirements apply only in
the context of systems that communicate in an interoperable, encrypted
fashion, exclusive of the use of key recovery technology. Such systems
fall into two categories: those that make use of "standard"
communication protocols and those that make use of "proprietary"
protocols. For this standard, the phrase "standard communication
protocol" encompasses any communication protocol that has been adopted
by a generally-recognized protocol standards organization, including the
International Telecommunication Union (ITU), Organization ??
International Standardization (ISO), the American National Standards
Institute (ANSI), the Institute of Electrical and Electronics Engineers
(IEEE), the Asynchronous Transfer Mode (ATM) Forum and the Internet
Engineering Task Force (IETF).

No interoperability requirements are established for cryptographic end
systems that engage in encrypted communications using proprietary
communication protocols. Such systems typically exhibit limited
interoperability (except within individual vendor product lines) due to
the use of non-standard protocols. Still, vendors who choose to
incorporate key recovery technology in their products are encouraged to
do so in a fashion that minimizes disruption to the installed product
base in order to facilitate communication between key recovery products
and non-key recovery products.

28. Interoperability of cryptographic end systems must be preserved when
    communicating with key recovery capable or non-key recovery capable
    end systems.

When key recovery is introduced into a system using a standard
(encrypted) communication protocol, it must be done in a fashion that
preserves interoperability, i.e., if two systems were able to
communicate securely prior to the introduction of key recovery
technology, then they must be able to do so after the introduction of
the technology. Some key recovery capable systems may be configured so
that they will refuse to communicate with other systems unless it can be
determined that the other systems are employing key recovery. If this
feature is activated, it may prevent interoperability between otherwise
interoperable systems. However, the presence of this configurable
feature does not exempt a system from meeting the interoperability
requirements detailed below. There are two general approaches to meeting
this requirement.

If a key escrow scheme \[see Appendix ?\] is employed, the (extant)
secure communication protocol employed by the cryptographic end systems
need not be modified to carry any key recovery information, and thus,
interoperability is inherently preserved. Note that in this case,
interoperability is preserved both among key recovery capable systems,
and between key recovery capable and non-key recovery capable systems.
If no changes are made to the secure communication protocol, including
any supporting key and/or certificate management protocols, then it may
or may not be possible for communicating systems to determine if key
recovery is being employed. If a key escrow scheme elects to transmit
some information in a secure communication protocol to indicate that key
recovery is enabled, then it must do so in a fashion that does not
impair interoperability. For example, if X.509 public key certificates
are employed to support secure communication, an extension can be added
to each certificate specifying the KRA(s) for the subject. If such an
extension is employed and not marked "critical", this approach complies
with the interoperability requirement established here. However, if such
an extension were employed and marked "critical", this would not be
compliant, as it would inhibit interoperability with non-key recovery
aware systems. See Appendix C for a proposed X.509 certificate
extension.

If a KRI encapsulation scheme \[see Appendix ?\] is employed, the key
recovery information will be carried in the secure communication
protocol. In some standard, secure communication protocols, it is
possible to carry this information in a fashion that preserves
interoperability without modifying the protocol. For example, in a
secure e-mail protocol (e.g., MSP, PGP, S/MIME or X.411) \[provide cites
for each\], an additional recipient, representing a KRA, could be added
to the per-recipient token list to provide key recovery on a per message
basis.

In a session key management protocol, one party may transmit per-session
KRI. For example, the IEEE 802.10c Key Management protocol \[cite\]
incorporates an optional field in the Pick-SA-Attrs exchange to carry
KRI. In In ISAKMP \[cite\],one party can transmit a (yet to be defined)
NOTIFY message with a payload containing per-session KRI. A compliant
ISAKMP implementation will silently discard an unrecognized payload,
thus thisinteroperability is preserved. These approaches to key recovery
are compliant with the interoperability requirements established here.

If it is necessary to transport KRI and there is no provision in a
standard communication protocol for doing so in an interoperable
fashion, then it will be necessary to modify/extend the protocol to
carry such information. It is outside the scope of this standard to
specify how key recovery information should be transported in the
context of such protocols. The definition of an interoperable means of
carrying such information is solely the purview of the cognizant
standards body for each affected protocol.

29. A vendor of a cryptographic end system must provide documentation
    demonstrating that the product transports key recovery information
    in a fashion consistent with the specification developed and adopted
    by the cognizant standards body for the protocol in question.

    []{#__RefHeading___Toc421076038 .anchor}2.8 Cryptographic End
    Systems

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. This section
defines the concept of a cryptographic end system, as needed to support
validation of interoperability requirements.

30. A vendor submitting a product for evaluation under this Standard
    must declare the product as a cryptographic end system if it
    encrypts or decrypts application data using a target key and
    incorporates a KRI Generation, KRI Delivery, or KRI Validation
    function.

In order to recover encrypted data, the key recovery information must be
generated in order to allow the recovery of data keys used by that
system. The KRI may be made available in various ways, e.g.,as
encapsulated information which may be stored or communicated with the
encrypted data, or as escrowed data, or both.

The model does not specify which system or systems generate the KRI.
When KRI is generated by cryptographic end 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). A cryptographic end
system generates and processes KRI in accordance with a specified key
recovery policy.

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

Note that cryptographic end system products need not contain a specific
set of key recovery functions (see Appendix A). The use of the functions
within a cryptographic end system can depend on which key recovery
technique is being used and whether the system is acting as a sender or
receiver system. When a key encapsulation application is acting as a
sender, it would typically perform the KRI Generate and Delivery
Functions, whereas when acting as a receiver, it would often perform the
KRI Acquisition and Validation Functions. In a key escrow-based
application, however, the sender may perform the KRI Validation
Function, rather than the receiver.

## 2.9 Key Recovery Techniques \[move to an appendix\] {#key-recovery-techniques-move-to-an-appendix .unnumbered}

Cryptographic end systems that satisfy this key recovery standard use
key recovery techniques which may be broadly categorized into two types,
KRI encapsulation and key escrow. The KRI encapsulation technique
associates key recovery information with the encrypted data in a manner
which allows the KRA to recover the data key. The key escrow technique
makes the cryptographic end system's key, usually a long term key such
as a public/private key pair, directly accessible by a KRA. This section
provides an overview of these two techniques.

### ![](media/image6.png){width="3.9902777777777776in" height="2.4618055555555554in"}2.9.1 KRI Encapsulation {#kri-encapsulation .unnumbered}

Figure 5 illustrates the interaction of two cryptographic end systems
that share or communicate encrypted data using a KRI encapsulation
technique for key recovery. To make the data key recoverable, the KRI
Generation Function within the Cryptographic End System labeled A
(hereinafter referred to as System A) first generates (or acquires) and
encapsulates KRI corresponding to the data key. Then, the KRI is
provided to the KRI Delivery Function.

Cryptographic End System labeled B (hereinafter referred to as System B)
may receive the KRI as well as the encrypted data and key exchange
information. The KRI is received by the KRI Validation Function. Whether
and what type of validation is performed is dependent on the structure
and content of the KRI, the key recovery technique used, and the
validation policy of the receiving cryptographic end system. .

This method works equally well where System A and System B are actually
the same system, as would be the case in a storage application.

\[modify figure 5 to delete "Other KRI"; remove "key" box and lines and
illustrate as "shared key" at A and B\]

### ![](media/image7.png){width="3.9902777777777776in" height="2.6333333333333333in"}2.9.2 Key Escrow {#key-escrow .unnumbered}

Figure 6 illustrates the interaction of two cryptographic end systems
that share or communicate encrypted data using a key escrow technique
for key recovery. For each cryptographic end system, keys, key parts or
key related information to be recovered are delivered to and stored at
the KRA. In this technique, a third party or a cryptographic end system
acts as a KRI Provider, generating and delivering KRI to KRA(s).

In an environment where System A is encrypting data and sending it to
System B, a key escrow KRS scheme allows System A to make the target key
recoverable without the addition of encapsulated KRI. System A can
determine that System B is using an acceptable key escrow technique for
key recovery by acquiring this information from some source (e.g., a
certificate) using its KRI Validation Function. In this case, System A's
normal performance of the key exchange/negotiation protocol may be
sufficient to make the target key recoverable.

If required to do so, System B may verify recoverability by verifying
that its own public key has been escrowed. This allows the normal
performance of the key exchange/negotiation protocol to make the data
key recoverable.

\[change figure 6 to label "Key Escrow KRI" as a "Key Escrow KRA";
remove dotted lines and dotted box; remove "key" box and lines and
illustrate as "shared key" at A and B\]

### 2.9.3 Interactions Between Systems Using Different Key Recovery Techniques {#interactions-between-systems-using-different-key-recovery-techniques .unnumbered}

Cryptographic end systems that interact with systems using different key
recovery techniques may still provide for key recovery. Furthermore,
cryptographic end systems may provide for key recovery even when
communicating with systems with no key recovery capability.

#### 2.9.3.1 Interactions Between KRI Encapsulation and Key Escrow Techniques {#interactions-between-kri-encapsulation-and-key-escrow-techniques .unnumbered}

![](media/image8.png){width="3.9902777777777776in"
height="3.213888888888889in"}may be able to use its KRI Validation
Function to determine that System B uses key escrow (e.g., by examining
System B's certificate). System A can create encapsulated KRI using its
KRI Generation Function and provide it to its KRI Delivery Function.
System B's KRI Provider must independently provide KRI to System B's KRA
prior to any possible recovery of System B's key. In this case, System B
does not need to validate the encapsulated KRI since System B's key has
been escrowed, though may optionally choose to do so.

In Figure 8, System A uses a key escrow technique to provide for key
recovery, whereas System B uses a KRI encapsulation technique. For
System A to provide for key recovery, 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, normal performance of the key exchange mechanism may provide
for the KRI generation and delivery functions.

![](media/image9.png){width="3.9902777777777776in"
height="2.745138888888889in"}

System B may be able to use its KRI Ac Validation Function to determine
the type of key recovery employed by System A and check for the presence
of encapsulated KRI. If System B must either validate or provide for the
data key's recoverability, System B may be able to generate and deliver
encapsulated KRI in accordance with its key recovery technique.

\[change figure 8 to remove dotted line and make arrow between "System
B" and "Encapsulated KRI" boxes bidirectional. Change "Key Escrow KRI"
to "Key Escrow KRA"; remove "Other KRI" box\]

#### 2.9.3.2 Interactions Between KRI Encapsulation and Systems with No Key Recovery {#interactions-between-kri-encapsulation-and-systems-with-no-key-recovery .unnumbered}

In Figure 5, if System A uses KRI encapsulation and System B has no key
recovery capability, System A can provide encapsulated KRI even though
System B cannot verify its recoverability. The encapsulated KRI received
from System A must not cause interoperability problems with System B,
however, as per Section 2.?.

If the roles are reversed and System B initiates a communication, System
A's KRI Validation function will detect that System B has not provided
suitable KRI. If System A must either validate or provide for the data
key's recoverability, System A may be able to itself generate and
deliver encapsulated KRI.

#### 2.9.3.3 Interaction Between Key Escrow and Systems with No Key Recovery {#interaction-between-key-escrow-and-systems-with-no-key-recovery .unnumbered}

In Figure 8, if System A uses Key Escrow and System B has no key
recovery capability, System A can ensure the recoverably of the
communication only if encapsulated information is created by its own 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 A must ensure that System B will be able to
ignore the presence of the KRI in order to permit interoperability.

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

# 3 Security Requirements {#security-requirements .unnumbered}

This section defines security requirements for all of the functions
defined in the KRS model established in Section 2. The security
requirements 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, a product architecture may imply that some of the
requirements do not apply, e.g., a requirement intended to mitigate a
threat that 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.

## 3.1 Key Recovery Agent Requirements {#key-recovery-agent-requirements .unnumbered}

### 3.1.1 Level 1 -- Medium Assurance {#level-1-medium-assurance .unnumbered}

#### 3.1.1.1 Cryptographic Functions  {#cryptographic-functions .unnumbered}

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

#### 3.1.1.2 Cryptographic Algorithms {#cryptographic-algorithms .unnumbered}

32. A KRA function submitted for evaluation shall be configured to use
    only FIPS approved algorithms (where applicable).

If a cryptographic function can be effected using a FIPS approved
algorithm, it must be possible to configure the KRA to make use of this
algorithm. However, if a key recovery scheme requires a cryptographic
function not supported by any FIPS approved algorithms, there is no
requirement to make use of such algorithm, e.g., use of RSA \[cite\] for
key encapsulation.

#### 3.1.1.3 Confidentiality {#confidentiality .unnumbered}

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

33. The KRA shall protect all stored KRI against disclosure to
    unauthorized individuals.

34. The KRA shall protect target key information transmitted -
    electronically or physically communicated- against disclosure to
    unauthorized individuals.

35. The strength of the encryption algorithm used to protect target key
    information shall be greater than or equal to the maximum strength
    of the encryption or key management algorithms employed for data
    encryption or for generation of the keys being recovered.

(Evaluation guidance documents will provide details on how to compare
encryption algorithms in support of this requirement.)

36. The product shall apply confidentiality services to all outgoing
    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 data encryption
    or for generation of the keys being recovered.

#### 3.1.1.4 Integrity {#integrity .unnumbered}

37. The product shall protect all stored KRI against modification.

38. The product shall apply data origin authentication to all outgoing
    transactions (i.e., requests and responses). 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 data encryption or for generation of the keys being
    recovered.

39. The product shall apply data integrity services to all outgoing
    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 data encryption or for
    generation of the keys being recovered.

#### 3.1.1.5 Audit {#audit .unnumbered}

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. Recording of event defined as "auditable" may be
enabled under configuration control. Recording of an event defined as
"always audited" shall not be disableable.

40. 

-   
-   

41. The KRA shall cease operation if it is unable to effect audit
    operations.

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

43. The product shall provide the authorized administrator with the
    ability to manage the audit trail at any time during the operation
    of the product.

44. Keys shall not be included in audit trails.

45. The following events shall be auditable:

```{=html}
<!-- -->
```
(a) Any specific operation performed to process audit data stored in the
    audit trail. (Note: This includes emptying, backup and deletion of
    audit trail);

(b) Any attempt to read, modify or destroy the audit trail;

(c) All requests to use authentication data management mechanisms;

(d) All modifications to the audit configuration that occur while the
    audit collection functions are operating;

(e) All requests to access user authentication data;

(f) Any use of an authentication mechanism. (e.g. login)

(g) All attempts to use the user identification mechanism, including the
    user identity provided;

(h) 

(i) Use of a security-relevant administrative function;

(j) Explicit requests to assume the security administrative role;

(k) The allocation of a function to a security administrative role;

(l) The addition or deletion of a user to/from a security administrative
    role; and

(m) The association of a security-relevant administrative function with
    a role.

(n) The invocation of the non-repudiation service. The audit event shall
    include the 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.

```{=html}
<!-- -->
```
46. The following events always shall be audited.

-   

(a) Requests, responses, and other transactions received by the product,
    including key recovery requests;

(b) Requests, responses, and other transactions generated by the
    product, including key recovery responses; and

(c) 

(d) Start-up and shutdown of the audit functions.

```{=html}
<!-- -->
```
47. The product shall record at least the following information within
    each audit record:

```{=html}
<!-- -->
```
(a) Date and time of the event, type of event, subject (user) identity,
    and success or failure of the event; and

(b) Other information, as described in the functional component audit
    events.

    (To be supplied)

```{=html}
<!-- -->
```
48. The product shall be able to generate a human understandable
    presentation of any audit data.

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

50. The product shall be able to associate each auditable event with the
    identity of the user that caused the event.

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

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

53. 

54. The product shall restrict access to the audit trail to the
    authorized administrator.

#### 3.1.1.6 Identification and Authentication {#identification-and-authentication .unnumbered}

These requirements support 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.

55. The product shall provide functions for initializing and modifying
    KRA personnel authentication data.

56. The product shall restrict the use of the authentication
    initialization and modification functions on the KRA personnel
    authentication data to a security administrator.

57. The product shall allow authorized KRA personnel to use the
    authentication initialization and modification functions to modify
    their own authentication.

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

59. The product shall protect authentication information from
    unauthorized reuse, including replay. (Note: This and the previous
    requirement provide a capability for secure remote login.)

60. The product shall be able to terminate the KRA personnel session
    establishment process after at most five consecutive unsuccessful
    authentication attempts.

61. After the termination of a KRA user session establishment process,
    the product shall be able to disable the user account until the
    account is enabled by a security administrator .

62. The product shall authenticate any KRA user's claimed identity prior
    to performing any functions on the user's behalf.

63. The product shall authenticate each KRA user before performing any
    actions requested by the user.

64. The product shall require a user authentication technology at least
    as good as passwords over a trusted path, or RFC xxx (OTP). Use of a
    suitable biometric, or hardware token also meets this requirement.
    \[requires additional refinement\]

65. If the product makes use of a "trusted path" mechanism to meet the
    preceding I&A requirement, that path between itself and local human
    users shall be logically distinct from other communication paths and
    shall provide assured identification of its endpoints. The local
    human user shall have the ability to initiate communication via this
    trusted path.

#### 3.1.1.7 Access Control {#access-control .unnumbered}

These requirements provide countermeasures against an entity
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 must be used to secure the transactions.
These procedural and physical measures are beyond the scope the
standard.

66. The product shall unambiguously associate a received 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.

67. The product shall release target key information only to authorized
    requestors.

68. The product shall release target key information only if the
    requestor is authorized to receive the data associated with the KRI
    and for the validity period (time interval) specified in the
    request, and only if any additional conditions for release
    (specified in the KRS policy) have been satisfied .

KRA products are not required to support additional conditions for
release as a prerequisite for evaluation. (Note that the Requestor-KRA
syntax should indicate whether the validity period is optional. If it is
always present, the KRA may ignore it if the key recovery scheme does
not allow for time interval-based target key information release.)

69. The product shall ensure that security features are always invoked
    and cannot be bypassed.

70. The product shall maintain a security domain for its own execution
    that protects it from interference and tampering by untrusted
    subjects.

71. The product shall enforce separation between the security domains of
    subjects in the system.

72. 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. (Note:
    The term "security administrative role" refers to generic trusted
    administrative roles. The system administrator role is one, but not
    the only one, of these security administrative roles. Additional
    security administrative roles are defined later in Requirement ??)

In order to meet the preceding requirements, the product must
distinguish security-relevant administrative functions from other
administrative functions. The set of security-relevant administrative
functions must include all functions necessary to install, configure,
and manage the product; minimally, This set must include the
assignment/deletion of authorized users from security administrative
roles, the association of security-relevant administrative commands with
security administrative roles, the assignment/deletion of subjects whose
keys are held, the 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.

73. The product shall be capable of distinguishing the set of KRA
    operators authorized for administrative functions from the set of
    all other users.

74. The product shall allow only specifically authorized KRA operators
    to assume the security administrative role

75. The product shall require an explicit request to be made in order
    for an authorized KRA operator to assume the security administrative
    role.

#### 3.1.1.8 Authentication of Received Transactions {#authentication-of-received-transactions .unnumbered}

76. The product shall verify the source of received transactions.

77. The product shall verify the integrity of received transactions.

78. 

#### 3.1.1.9 Non-Repudiation {#non-repudiation .unnumbered}

These capabilities facilitate the use of a trusted time source to
further support accountability.

79. The product shall provide trustedtime stamps for use in transactions
    with requestors.

80. The product shall generate evidence of origin for transmitted key
    recovery responses.

81. The product shall generate evidence of receipt for the registration
    of target key information.

82. The product shall verify evidence of origin for key recovery
    requests and for target key information registration transactions.

#### 3.1.1.10 Protection of Trusted Security Functions {#protection-of-trusted-security-functions .unnumbered}

83. Before establishing a session with a KRA administrator, the product
    shall display an advisory warning message regarding unauthorized use
    of the product.

84. 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
    may result in criminal prosecution and civil penalties".

85. The product shall restrict the capability to modify the warning
    message to the authorized administrator.

86. Upon successful session establishment, the product shall display the
    date, time, method, and source of the last successful session
    establishment to the KRA administrator.

87. Upon successful session establishment, if there have been any
    unsuccessful session establishment attempts since the last
    successful session establishment, the product shall display the
    date, time, method, and location of the most recent unsuccessful
    attempt to session establishment and the number of unsuccessful
    attempts.

88. The data specified above shall not be removed without KRA
    administrator intervention.

### 3.1.2 Level 2 -- High Assurance {#level-2-high-assurance .unnumbered}

#### 3.1.2.1 Cryptographic Functions {#cryptographic-functions-1 .unnumbered}

89. KRA cryptographic modules shall be compliant with FIPS 140-1, Level
    3 or higher.

    Note: This requirement does not apply to cryptographic modules used
    for KRA administrator I&A.

#### 3.1.2.2 Cryptographic Algorithms {#cryptographic-algorithms-1 .unnumbered}

Same as Level 1.

#### 3.1.2.3 Confidentiality {#confidentiality-1 .unnumbered}

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 the following:

90. The system shall be designed for multiple KRAs. Two or more KRAs
    shall be required for a requestor to obtain the target key.

#### 3.1.2.4 Integrity {#integrity-1 .unnumbered}

Same as Level 1.

#### 3.1.2.5 Audit {#audit-1 .unnumbered}

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.
\[revise to reflect fewer differences between level 1 and level 2 audit
requirements\]

Includes all the requirements of Level 1 and

91. 

92. The following actions shall be auditable:

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

```{=html}
<!-- -->
```
-   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; and

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

93. 

#### 3.1.2.6 Identification and Authentication {#identification-and-authentication-1 .unnumbered}

Level 2 enhances assurance by requiring use of a hardware token for user
authentication. 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.
(Note: If the crypto officer is invoking a KRA cryptographic module
function, authentication may be effected directly to the module and is
exempt from the following newly added requirement. In this case, the
FIPS 140-1 level 3 module I&A requirements apply.) \[reflect this change
to section 3.1.1.6, adjusting for 140-1 level 2 use there\]

All Level 1 requirements \[replaces some level 1 I&A requirements\] and
the following:

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

#### 3.1.2.7 Access Control {#access-control-1 .unnumbered}

Level 2 requires multi-party access controls for the 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:

95. The KRA shall be capable of requiring multi-party (at least 2)
    authorization in support of the release of target key information.

Note that although the KRA must support multi-party authorization for
release of target key information, a product that may be configured to
operate with single-party authorization also would be compliant.

The following requirements are to provide for strict role separation

96. The product shall restrict the ability to perform a
    security-relevant administrative function to the security
    administrative role(s) authorized to use that function. \[revise to
    clarify difference from old #52\]

97. The product shall be capable of distinguishing the set of users
    authorized for administrative functions from the set of all other
    users. \[revise to clarify difference from old #53\]

98. The product shall allow only specifically authorized users to assume
    only those security administrative roles for which they have been
    authorized. \[revise to clarify difference from old #54\]

99. 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 system administrator role. \[revise to clarify
    difference from old #55\]

100. The product shall define a set of security administrative roles
     that minimally includes system administrator, system operator,
     crypto officer and audit administrator.

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

102. The system operator shall change the system configuration and
     operate the system.

103. The crypto officer shall manage the cryptographic keys.

104. The audit administrator shall manage the audit log and audit
     profiles.

105. The product shall associate each security-relevant administrative
     function with at least one security administrative role.

106. The product shall enforce checks for valid input values for
     security-relevant administrative functions as described in the
     Administrative guidance.

     Note that the "Administrative guidance" document is a
     vendor-supplied document.

#### 3.1.2.8 Authentication of Received Transactions {#authentication-of-received-transactions-1 .unnumbered}

Same as Level 1.

#### 3.1.2.9 Non Repudiation {#non-repudiation-1 .unnumbered}

Same as Level 1.

107. 
108. 
109. 
110. 

#### 3.1.2.10 Protection of Trusted Security Functions {#protection-of-trusted-security-functions-1 .unnumbered}

All Level 1 requirements and the following:

111. 

112. 

113. 

114. 

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

116. The product shall preserve a secure state when the abstract machine
     tests fail.

     \[add clarifying comments re the implications of the two preceding
     requirements. Get text from Santosh\]

## 3.2 Key Recovery Information Generator Function {#key-recovery-information-generator-function .unnumbered}

### 3.2.1 Level 1 -- Medium Assurance Key Recovery Information Generator {#level-1-medium-assurance-key-recovery-information-generator .unnumbered}

Note that these requirements generally are applicable to cryptographic
end system products.

#### 3.2.1.1 Cryptographic Functions  {#cryptographic-functions-2 .unnumbered}

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

#### 3.2.1.2 Cryptographic Algorithms {#cryptographic-algorithms-2 .unnumbered}

118. A KRI Generation function submitted for evaluation shall be
     configured to use only FIPS approved algorithms (where applicable).

     See \[old requirement #15\] for additional clarifying details.

#### 3.2.1.3 Confidentiality {#confidentiality-2 .unnumbered}

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.

119. Transmitted target key information must be protected via
     encryption. The strength of the algorithm used to protect the
     target key information shall be greater than or equal to the
     maximum strength of the encryption and key management algorithms
     employed for data encryption or for generation of the keys being
     recovered.

     \[change all other instances of this crypto strength requirement.
     This still needs more work.\]

#### 3.2.1.4 Integrity {#integrity-2 .unnumbered}

There are no integrity requirements at Level 1. \[reconcile this with
Level 1 validation requirements; note possible implications of not
generating integrity check re Level 2 interoperability.\]

120. 

121. 

122. 

123. 

124. 

125. 

126. 

127. []{#__RefHeading___Toc421076076 .anchor}3.2.1.5 Identification and
     Authentication

128. All cryptographic modules shall implement role-based
     authentication.

129. One of the roles shall be the system administrator role.

#### 3.2.1.6 Access Control {#access-control-2 .unnumbered}

130. The KRI Generator shall allow only the system administrator to
     configure this function.

131. At a minimum, the configuration shall include activation and
     deactivation of thisfunction.

Note that a product in which KRI generation is always active need not
meet the requirements of this section nor of Section 3.2.1.5.

### 3.2.2 Level 2 -- High Assurance Key Recovery Information Generator {#level-2-high-assurance-key-recovery-information-generator .unnumbered}

#### 3.2.2.1 Cryptographic Functions  {#cryptographic-functions-3 .unnumbered}

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

#### 3.2.2.2 Cryptographic Algorithms {#cryptographic-algorithms-3 .unnumbered}

Same as Level 1.

#### 3.2.2.3 Confidentiality {#confidentiality-3 .unnumbered}

Same as Level 1.

#### 3.2.2.4 Integrity {#integrity-3 .unnumbered}

All of Level 1 requirements and the following:

133. The product shall generate KRI to allow the KRI Validator Function
     to verify that the KRIcan be successfully used to recover the
     target key.

     **Note that an instance of a KRI** **Generation Function** **may
     not provide all of the** **data required for the KRI Validation
     Function.**

#### 3.2.2.5 Identification and Authentication {#identification-and-authentication-2 .unnumbered}

No requirements at this level.

#### 3.2.2.6 Access Control {#access-control-3 .unnumbered}

No requirements at this level.

## 3.3 Key Recovery Information Delivery Function {#key-recovery-information-delivery-function .unnumbered}

No Security requirements.

##  {#section-5 .unnumbered}

## .

## 3.5 Key Recovery Information Validator Function {#key-recovery-information-validator-function .unnumbered}

Note that a KRS composed from Level 1 products need not include a KRI
Validator Function.

### 3.5.1 Level 1 -- Medium Assurance Key Recovery Information Validator {#level-1-medium-assurance-key-recovery-information-validator .unnumbered}

#### 3.5.1.1 Cryptographic Functions  {#cryptographic-functions-4 .unnumbered}

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

#### 3.5.1.2 Cryptographic Algorithms {#cryptographic-algorithms-4 .unnumbered}

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

\[change to reflect old #15 revised wording\]

#### 3.5.1.3 Integrity {#integrity-4 .unnumbered}

The purpose of the integrity requirements is to ensure that the key
recovery information can be used to successfully decrypt the
communication when the receiver can successfully decrypt the
communication. Level 1 requirements counter the threat of an outsider
corrupting the key recovery information. Level 2 requirements counter
the threat of the sender corrupting the key recovery information. \[add
a requirement to require that validation is a configurable option\]

======== end of committee review of the document 6/19/98 ===========

136. Prior to decrypting the data, the KRI validator shall verify that
     the KRI acquired was that intended by the KRI generator.

137. Prior to decrypting the data, the KRI validator shall verify that
     the association of the key recovery information with the encrypted
     data was that intended by the KRI Generator.

138. Prior to decrypting the data, the KRI validator shall verify the
     integrity of the association of the key recovery information to the
     encrypted data.

See Section 3.2.1.4 "Key Recovery Information Generator -- Integrity"
for an example of how the above integrity requirements can be satisfied.

### 3.5.2 Level 2 -- High Assurance Key Recovery Information Validator {#level-2-high-assurance-key-recovery-information-validator .unnumbered}

#### 3.5.2.1 Cryptographic Functions  {#cryptographic-functions-5 .unnumbered}

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

#### 3.5.2.2 Cryptographic Algorithms {#cryptographic-algorithms-5 .unnumbered}

Same as Level 1.

#### 3.5.2.3 Integrity {#integrity-5 .unnumbered}

The product shall meet at least one of the following (i.e., is required
to meet only one of the following, but may meet more than one) integrity
requirements:

\[add a requirement to require that validation is a configurable
option\]

140. The validator shall ensure that the KRI received is accurate, i.e.,
     the information can be used to perform key recovery successfully.
     The validtor only needs to meet the Level 1 integrity requirements
     when interoperating with a product supporting a different scheme.

141. A KRI Generator Function in the receiving cryptographic end system
     shall generate accurate key recovery information for received
     encrypted data.

142. The receiving cryptographic end system shall not be able to obtain
     the correct data decryption key if the received key recovery
     information is not accurate.

## 3.6 Key Recovery Requestor {#key-recovery-requestor .unnumbered}

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

### 3.6.1 Level 1 -- Medium Assurance {#level-1-medium-assurance-1 .unnumbered}

#### 3.6.1.1 Cryptographic Functions  {#cryptographic-functions-6 .unnumbered}

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

#### 3.6.1.2 Cryptographic Algorithms {#cryptographic-algorithms-6 .unnumbered}

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

#### 3.6.1.3 Confidentiality {#confidentiality-4 .unnumbered}

145. The requestor shall protect key recovery information received
     and/or stored against disclosure to unauthorized individuals.
     (Note: Storing the data in encrypted form and implementing access
     controls \[on the corresponding keys ?\]is one way to meet this
     requirement.)

146. The requestor shall protect the 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.)

147. 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 data encryption or for
     generation of the keys being recovered.

#### 3.6.1.4 Integrity {#integrity-6 .unnumbered}

148. The product shall apply data origin authentication to all requests.
     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 data encryption or for
     generation of the keys being recovered.

149. 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 data encryption or for
     generation of the keys being recovered.

#### 3.6.1.5 Audit {#audit-2 .unnumbered}

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

151. 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; and

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

152. The following actions always shall be audited. Keys shall not be
     included in the audit:

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

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

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

154. The product shall be able to generate a human understandable
     presentation of any audit data stored in the permanent audit trail.

155. The audit trail shall not store old or new authentication
     information (e.g., passwords)

156. The product shall be able to associate each auditable event with
     the identity of the user that caused the event.

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

158. 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 (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.)

159. The product shall store generated audit records in a permanent
     audit trail.

160. The product shall restrict access to the audit trail to the
     authorized administrator. (Note: This requirement implies providing
     integrity to the audit trail)

#### 3.6.1.6 Identification and Authentication {#identification-and-authentication-3 .unnumbered}

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

161. The product shall provide functions for initializing and modifying
     user authentication data.

162. The product shall restrict the use of these functions on the user
     personnel authentication data for any user to the authorized
     administrator.

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

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

165. The product shall be able to terminate the user session
     establishment process after five unsuccessful authentication
     attempts. (Note: If the product terminates the session after less
     than five unsuccessful attempts, the product meets the above
     requirement.)

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

167. The product shall authenticate any user's claimed identity prior to
     performing any functions on the user's behalf.

168. The product shall uniquely identify each user before performing any
     actions requested by the user.

169. 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: This requirement implies that
     the product (as opposed to procedural means and management
     instructions) will enforce the password length, aging, etc. type
     requirements.) \[see corrections and comments from earlier use of
     this text in req ??\]

#### 3.6.1.7 Access Control {#access-control-4 .unnumbered}

These requirements provide countermeasures against an entity
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.

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

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

172. The product shall ensure that security features are always invoked
     and cannot be bypassed.

173. The product shall maintain a security domain for its own execution
     that protects it from interference and tampering by untrusted
     subjects.

174. The product shall enforce separation between the security domains
     of subjects in the system.

#### 3.6.1.8 Authentication of Received Transactions {#authentication-of-received-transactions-2 .unnumbered}

175. The product shall verify the source of received transactions.

176. The product shall verify the integrity of received transactions.

177. The product shall decrypt the received transactions which are
     encrypted. \[this is not a security requirement; it's a function
     requirement and so obvious as to be omitted\]

#### 3.6.1.9 Non-Repudiation {#non-repudiation-2 .unnumbered}

178. The product shall be able to provide reliable time stamps for its
     own use.

179. The product shall be able to generate evidence of receipt for
     received transactions. (Note: This requirement means using the
     reliable time stamp 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 a requestor.)
     \[digital signatures?\]

#### 3.6.1.10 Protection of Trusted Security Functions {#protection-of-trusted-security-functions-2 .unnumbered}

180. Before establishing a session with a user, the product shall
     display an advisory warning message regarding unauthorized use of
     the product.

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

182. The product shall restrict the capability to modify the warning
     message to the authorized administrator.

183. Upon successful session establishment, the product shall display
     the date, time, method, and location of the last successful session
     establishment to the user.

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

185. The data specified above shall not be removed without user
     intervention.

### 3.6.2 Level 2 -- High Assurance {#level-2-high-assurance-1 .unnumbered}

#### 3.6.2.1 Cryptographic Functions {#cryptographic-functions-7 .unnumbered}

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

####  3.6.2.2 Cryptographic Algorithms {#cryptographic-algorithms-7 .unnumbered}

Same as Level 1.

#### 3.6.2.3 Confidentiality {#confidentiality-5 .unnumbered}

Same as level 1.

#### 3.6.2.4 Integrity {#integrity-7 .unnumbered}

Same as level 1.

####  3.6.2.5 Audit  {#audit-3 .unnumbered}

Includes all the requirements of Level 1 and the following:

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

188. The product shall provide the authorized administrator with the
     ability to manage the audit trail at any time during the operation
     of the product.

189. The following actions shall be auditable:

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

```{=html}
<!-- -->
```
-   All attempted uses of the trusted path functions;

```{=html}
<!-- -->
```
-   Identification of the initiator and target of the trusted path;

```{=html}
<!-- -->
```
-   Attempts to provide invalid inputs for administrative functions; and

```{=html}
<!-- -->
```
-   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.

#### 3.6.2.6 Identification and Authentication  {#identification-and-authentication-4 .unnumbered}

All Level 1 requirements and the following:

190. The product shall make use of token based user authentication. The
     token shall meet FIPS 140-1 Level 2 requirements. \[but this may
     unduly exclude better solutions unless it is liberally interpreted,
     see SafeKeyper-style device comment earlier\]

#### 3.6.2.7 Access Control {#access-control-5 .unnumbered}

All Level 1 requirements and the following:

191. Two or more users shall be required to request the recovery
     information from a KRA. \[why phrased differently here, i.e, why
     not say multi-party authorization?\]

192. The product shall enforce checks for valid input values for
     security-relevant administrative functions as described in the
     Administrative guidance.

#### 3.6.2.8 Authentication of Received Transactions {#authentication-of-received-transactions-3 .unnumbered}

Same as Level 1.

#### 3.6.2.9 Non Repudiation {#non-repudiation-3 .unnumbered}

Includes the Level 1 requirements and the following:

193. The product shall generate evidence of origin for transmitted key
     recovery requests or responses. (Note: This requirement shall also
     support the reliable time stamp service by including the time in
     the evidence.)

194. The product shall provide a capability to verify the evidence of
     origin of information to the recipient.

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

196. The product shall provide the originator with the ability to
     request evidence of receipt on information.

#### 3.6.2.10 Protection of Trusted Security Functions {#protection-of-trusted-security-functions-3 .unnumbered}

All Level 1 requirements and the following:

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

198. The local human users shall have the ability to initiate
     communication via the trusted path.

199. The product shall require the use of the trusted path for initial
     user authentication.

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

201. The product shall preserve a secure state when abstract machine
     tests fail.

**THE FOLLOWING ARE NOT REQUIREMENTS, BUT INFORMATIVE TEXT TO BE USED
SOMEWHERE OR TO BE DELETED.**

### KRA Availability \[if we want to make this a level 2 KRA requirement put it there, else delete it\] {#kra-availability-if-we-want-to-make-this-a-level-2-kra-requirement-put-it-there-else-delete-it .unnumbered}

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

#### The KRA facility should be required to have the capability to securely replicate any key recovery information stored in order to support continued on-line access in case of a facility failure. {#the-kra-facility-should-be-required-to-have-the-capability-to-securely-replicate-any-key-recovery-information-stored-in-order-to-support-continued-on-line-access-in-case-of-a-facility-failure. .unnumbered}

The KRA facility should have a secure backup of the key recovery
information stored in order to rebuild the key recovery database in case
of KRA system failure.

###### **Ancillary Components** {#ancillary-components .unnumbered}

###### **Registration Agent** **\[is it in the model anymore?\]** {#registration-agent-is-it-in-the-model-anymore .unnumbered}

###### Registration Agents maintain information on key recovery products and corresponding key recovery protocol (schemes). The registration agent should be able to ensure the accuracy and maintain the integrity of the product information. {#registration-agents-maintain-information-on-key-recovery-products-and-corresponding-key-recovery-protocol-schemes.-the-registration-agent-should-be-able-to-ensure-the-accuracy-and-maintain-the-integrity-of-the-product-information. .unnumbered}

###### **Integrity/Authenticity** **\[if we keep an RA function, then put these in as requirements for it, otherwise delete them\]** {#integrityauthenticity-if-we-keep-an-ra-function-then-put-these-in-as-requirements-for-it-otherwise-delete-them .unnumbered}

###### These features 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.  {#these-features-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. .unnumbered}

###### The Registration Agent must verify authentication and integrity services for the received product information. \[what exactly does this mean?\] {#the-registration-agent-must-verify-authentication-and-integrity-services-for-the-received-product-information.-what-exactly-does-this-mean .unnumbered}

###### The Registration Agent must apply authentication and integrity services to the product information it transmits. {#the-registration-agent-must-apply-authentication-and-integrity-services-to-the-product-information-it-transmits. .unnumbered}

###### The Registration Agent must ensure that the product information it maintains is not modified by unauthorized parties. {#the-registration-agent-must-ensure-that-the-product-information-it-maintains-is-not-modified-by-unauthorized-parties. .unnumbered}

######  {#section-7 .unnumbered}

###### **Licensing Agent** **\[not in the model?\]** {#licensing-agent-not-in-the-model .unnumbered}

###### Licensing Agents perform compliance audits of the KRAs to ensure that the KRAs operate in accordance with the KRA's stated policy. {#licensing-agents-perform-compliance-audits-of-the-kras-to-ensure-that-the-kras-operate-in-accordance-with-the-kras-stated-policy. .unnumbered}

###### **Authentic Public Key Source (APKS AKA Public Key Infrastructure (PKI))** **\[clean up and retain\]** {#authentic-public-key-source-apks-aka-public-key-infrastructure-pki-clean-up-and-retain .unnumbered}

###### **Standards** {#standards .unnumbered}

###### The APKS should carry out transactions in accordance with the Minimum Interoperability Specifications for PKI Components (MISPC) {#the-apks-should-carry-out-transactions-in-accordance-with-the-minimum-interoperability-specifications-for-pki-components-mispc .unnumbered}

###### **Security/Certificate Policy:**  {#securitycertificate-policy .unnumbered}

###### 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. {#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. .unnumbered}

###### For Level 1, the APKS should meet the medium Certificate Policy. For Level 2, the APKS should meet the high Certificate Policy. {#for-level-1-the-apks-should-meet-the-medium-certificate-policy.-for-level-2-the-apks-should-meet-the-high-certificate-policy. .unnumbered}

# 4 Assurance Requirements {#assurance-requirements .unnumbered}

The assurance in a KRS compliant product can be achieved using the
Common Criteria Evaluation Assurance Levels (EALs). The Common Criteria
(CC) defines seven hierarchical assurance levels, EAL1 through EAL7.
Some aspects of the Common Criteria assurance levels are excessive for
the KRS compliance validation program, thus, this section contains 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 KRS compliant 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 as 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) requirements which must be satisfied for
the component. The second set of elements is a list of contents and
presentation requirements for the assurance evidence for that element.
The third and last set of elements is what an independent evaluator
should do to assess the contents and presentation items which are
provided.

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

Three Assurance Levels (AL) are defined for this standard. These levels
are somewhat related to the Common Criteria assurance levels, but are
not derived from the Common Criteria assurance levels. The assurance
levels for the classes, families and components of key recovery products
are listed in Table 1. Subsequent sections provide further detail.

202. The KRA and Key Recovery Requestor Functions shall be required to
     meet the assurance requirements for AL B and AL C for Security
     Levels 1 and 2, respectively, as defined in Tables 1 and 2.

203. The KRI Generation and Validation Functions shall be required to
     meet the assurance requirements for AL A and AL B for Security
     Levels 1 and 2, respectively, as defined in Tables 1 and 2.

Table 2 provides a summary of assurance level requirements for the
various KRS functions.

It should be noted that the assurance requirements are applied to test
the product functionality and security features.

**Assurance Concept**

The assurance concepts and notations in this standard are based on the
Common Criteria. The assurance concept consists of a hierarchical
refinement of the requirements. At the top-level, the assurance
requirements are broken down into classes. The classes include,
configuration management, delivery and operation, development, guidance
documents, life-cycle support, testing, and vulnerability analysis. Each
class is broken down into families. For example, the development class
contains families such as functional specification, high-level design,
low-level design, implementation representation, etc. Each family
consists of one or more components. Each component contains three sets
of elements. The first set is the product developer actions. The second
set is the requirements for content and presentation of information. The
third and final set contains the evaluator actions.

**Assurance Notations**

The notation used for assurance requirements is based on the Common
Criteria. Each class is defined as three characters; the first character
is always "A" for assurance; the remaining two characters are meaningful
for the class; e.g., CM for configuration management, DV for
development, TE for testing, etc. The three letter assurance class is
followed by an underscore "\_" and a three letter meaningful name for
the family, e.g., FSP for functional specification. The family is
followed by "." and a component number. *The component number is
followed by a "." and a two character element indicator.* Each component
contains three sets of numbered elements. *The first character of the
element indicator is a sequential number within the set. The second
character indicates the set : "D" for a developer action, "C" for
content and presentation, and "E" for an evaluator action.*

In Table 1 below, the numbers in the last three columns identify the
components of each family that must be satisfied in order to provide the
appropriate assurance level. For example, for assurance family
**ADV_FSP** (see Section 4.3.1), assurance level A specifies that
component 1 applies. Component 1 is identified as **ADV_FSP.1**, and the
requirements are listed in Section 4.2.1.1, ADV_FSP.1 Functional
Specification and Security Policy. For assurance levels B and C,
component 2 applies. Component 2 is identified as **ADV_FSP.2**, and the
requirements are listed in Section 4.3.1.2, ADV_FSP.2 Informal Security
Policy Model.

**Table 1: KRS Assurance Levels**

+---------------+---------------------------+-------+--------+-------+
| **Assurance   | **Assurance Family**      | **AL  | **AL   | **AL  |
| Class**       |                           | A**   | B**    | C**   |
+---------------+---------------------------+-------+--------+-------+
| **            | **ACM_CAP**               |       | 1      | 1     |
| Configuration |                           |       |        |       |
| Management**  | CM Capabilities           |       |        |       |
+---------------+---------------------------+-------+--------+-------+
|               | **ACM_SCP**               |       |        | 2     |
|               |                           |       |        |       |
|               | CM Scope                  |       |        |       |
+---------------+---------------------------+-------+--------+-------+
| **Delivery    | **ADO_DEL**               |       | 1      | 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**               | 1     | 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      | 3     |
|               |                           |       |        |       |
|               | Independent Testing       |       |        |       |
+---------------+---------------------------+-------+--------+-------+
| **            | **AVA_VLA**               |       | 1      | 1     |
| Vulnerability |                           |       |        |       |
| Assessment**  | Vulnerability Analysis    |       |        |       |
+---------------+---------------------------+-------+--------+-------+

**Table 2: Assurance Levels for KRS Functions**

  -------------------------- -------------------- -----------------------
  **KRS Function**           **Security Level 1** **Security Level 2**

  KRA                        AL B                 AL C

  Key Recovery Requestor     AL B                 AL C

  KRI Generation             AL A                 AL B

  KRI Delivery               AL A                 AL B

  KRI Acquisition            AL A                 AL B

  KRI Validation             AL A                 AL B
  -------------------------- -------------------- -----------------------

## 4.1 Configuration Management {#configuration-management .unnumbered}

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

### 4.1.1 Configuration Management ACM_CAP -- CM Capabilities {#configuration-management-acm_cap-cm-capabilities .unnumbered}

**Objectives**

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 from the early
design stages through all subsequent maintenance efforts. The objectives
of this assurance requirement include the following:

1.  ensuring that the product 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 is required to determine those items
under

evaluation that are subject to the criteria requirements.

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

#### 4.1.1.1 ACM_CAP.1 Minimal Support  {#acm_cap.1-minimal-support .unnumbered}

**Developer action elements:**

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

205. ACM_CAP.1.2D: The developer shall provide CM documentation.

**Content and presentation of evidence elements:**

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

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

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

**Evaluator action elements:**

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

### 4.1.2 Configuration Management ACM_SCP - CM Scope  {#configuration-management-acm_scp---cm-scope .unnumbered}

**Objectives**

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.

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

#### 4.1.2.1 ACM_SCP.2 Problem Tracking CM Coverage {#acm_scp.2-problem-tracking-cm-coverage .unnumbered}

**Developer action elements:**

210. ACM_SCP.2.1D: The developer shall provide CM documentation.

**Content and presentation of evidence elements:**

211. ACM_SCP.2.1C: 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.

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

**Evaluator action elements:**

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

## 4.2 Delivery and Operation {#delivery-and-operation .unnumbered}

### 4.2.1 Delivery and Operation ADO_DEL -- Delivery {#delivery-and-operation-ado_del-delivery .unnumbered}

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

**Application notes**

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

#### 4.2.1.1 ADO_DEL.1 Delivery Procedures {#ado_del.1-delivery-procedures .unnumbered}

**Developer action elements:**

214. ADO_DEL.1.1D: The developer shall provide documentation about the
     procedures for the delivery of the product or parts of the product
     to the user.

215. ADO_DEL.1.2D: The developer shall use the delivery procedures.
     \[NOTE: IS THIS TESTABLE?\]

**Content and presentation of evidence elements:**

216. ADO_DEL.1.1C: The delivery documentation shall describe the
     procedures to be employed when distributing versions of the product
     to a user\'s site.

**Evaluator action elements:**

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

#### 4.2.1.2 ADO_DEL.2 Detection of Modification {#ado_del.2-detection-of-modification .unnumbered}

**Developer action elements:**

218. ADO_DEL.2.1D: The developer shall provide documentation about the
     procedures for the delivery of the product or parts of the product
     to the user.

219. ADO_DEL.2.2D: The developer shall use the delivery procedures.
     \[NOTE: IS THIS TESTABLE?\]

**Content and presentation of evidence elements:**

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

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

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

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

**Evaluator action elements:**

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

### 4.2.2 Delivery and Operation ADO_IGS - Installation, Generation, and Start-up {#delivery-and-operation-ado_igs---installation-generation-and-start-up .unnumbered}

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

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

#### 4.2.2.1 ADO_IGS.1 Installation, Generation, and Start-up Procedures  {#ado_igs.1-installation-generation-and-start-up-procedures .unnumbered}

**Developer action elements:**

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

**Content and presentation of evidence elements:**

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

**Evaluator action elements:**

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

## 4.3 Development {#development .unnumbered}

### 4.3.1 Development ADV_FSP - Functional Specification {#development-adv_fsp---functional-specification .unnumbered}

**Objectives**

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

and behavior of the product. It is a refinement of the statement of
functional requirements for the product. The functional specification
must show that all defined functional requirements are addressed, and
that the security policy is enforced by the product.

**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,
the functional specification shall contain the specification of the
interaction (protocol) among various product components.

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

The evaluator of the product 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) is
necessary; specific functional requirements are violated and the product
fails to meet its requirements; and

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

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

In all cases, it is important that the evaluator evaluate the product 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.

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

#### 4.3.1.1 ADV_FSP.1 Functional Specification and Security Policy {#adv_fsp.1-functional-specification-and-security-policy .unnumbered}

**Developer action elements:**

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

229. ADV_FSP.1.2D: The developer shall provide a product security
     policy.

**Content and presentation of evidence elements:**

230. ADV_FSP.1.1C: The functional specification shall describe the
     product using an informal style.

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

232. ADV_FSP.1.3C: The functional specification shall include evidence
     that demonstrates that the product is completely represented.

**Evaluator action elements:**

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

234. ADV_FSP.1.2E: The evaluator shall determine that the functional
     specification is consistent with the product security policy.

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

#### 4.3.1.2 ADV_FSP.2 Functional Specification, Security Policy and Informal Security Policy Model  {#adv_fsp.2-functional-specification-security-policy-and-informal-security-policy-model .unnumbered}

**Developer action elements:**

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

237. ADV_FSP.2.2D: The developer shall provide a product security
     policy.

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

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

**Content and presentation of evidence elements:**

240. ADV_FSP.2.1C: The functional specification shall describe the
     product using an informal style.

241. ADV_FSP.2.2C: The functional specification shall include an
     informal presentation of the syntax and semantics of all external
     product interfaces.

242. ADV_FSP.2.3C: The functional specification shall include evidence
     that demonstrates that the product is completely represented.

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

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

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

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

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

**Evaluator action elements:**

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

249. ADV_FSP.2.2E: The evaluator shall determine that the functional
     specification is consistent with the product security policy.

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

### 4.3.2 Development ADV_HLD - High-Level Design {#development-adv_hld---high-level-design .unnumbered}

**Objectives**

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

The high-level design refines the functional specification into modules.
For each module of the product, the high-level design describes its
purpose and function and identifies the security functions enforced by
the module. The interrelationships of all modules are also defined in
the high-level design. These interrelationships will be represented as
external interfaces for data flow, control flow, etc., as appropriate.

**Application notes**

In addition to the content indicated in the following requirements,

251. 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 in terms
of modules. The term \`\`module\'\' is used here to express the idea of
decomposing the product into a relatively small number of parts. While
the developer is not required to actually have \`\`modules\'\', 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 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) is necessary; specific
functional requirements are violated and the product fails to meet its
requirements; and specific functional requirements have not been
addressed and further analysis (of another product representation) is
necessary. Whenever more analysis is necessary, the evaluator is
expected to carry that information forward to the analysis of other
product representations. If requirements are not addressed after the
analysis of the last provided product representation, this also
represents a failure of the product evaluation.

In all cases, it is important that the evaluator evaluate the product 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 module

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

This distinction is made because modules do not necessarily relate to
specific security functions. While a given module may correspond
directly to a security function, or even multiple security functions, it
is also possible that many modules must be combined to implement a
single security function.

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

#### 4.3.2.1 ADV_HLD.1 Descriptive High-Level Design  {#adv_hld.1-descriptive-high-level-design .unnumbered}

**Developer action elements :**

252. ADV_HLD.1.1D: The developer shall provide the high-level design of
     the product.

**Content and presentation of evidence elements:**

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

254. ADV_HLD.1.2C: The high-level design shall describe the structure of
     the product in terms of modules.

255. ADV_HLD.1.3C: The high-level design shall describe the security
     functionality provided by each module of the product.

256. ADV_HLD.1.4C: The high-level design shall identify the interfaces
     of the modules of the product.

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

**Evaluator action elements:**

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

259. ADV_HLD.1.2E: The evaluator shall determine if the functional
     requirements in the product are addressed by the design.

#### 4.3.2.2 ADV_HLD.2 Security Enforcing High-Level Design  {#adv_hld.2-security-enforcing-high-level-design .unnumbered}

**Developer action elements :**

260. ADV_HLD.2.1D: The developer shall provide the high-level design of
     the product.

**Content and presentation of evidence elements:**

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

262. ADV_HLD.2.2C: The high-level design shall describe the structure of
     the product in terms of modules.

263. ADV_HLD.2.3C: The high-level design shall describe the security
     functionality provided by each module of the product.

264. ADV_HLD.2.4C: The high-level design shall identify the interfaces
     of the modules of the product.

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

266. ADV_HLD.2.6C: The high-level design shall describe the separation
     of the product into security policy enforcing modules and other
     modules.

**Evaluator action elements:**

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

268. ADV_HLD.2.2E: The evaluator shall determine if the functional
     requirements in the product are addressed by the design.

### 4.3.3 Development ADV_IMP - Implementation Representation  {#development-adv_imp---implementation-representation .unnumbered}

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

**Application notes**

The implementation representation is used to express the notion of the
least abstract representation of the product, specifically the one that
is used to create the product 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 is expected to make determinations
regarding the functional requirements in the security target 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) is necessary; specific
functional requirements are violated and the product 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 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 representations, this
represents a failure of the product 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
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).

#### 4.3.3.1 ADV_IMP.1 Subset of the Implementation {#adv_imp.1-subset-of-the-implementation .unnumbered}

**Application notes**

The implementation representation needs to be provided for the security
relevant functions of the product. 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.

**Developer action elements:**

269. ADV_IMP.1.1D: The developer shall provide the implementation
     representations for a selected subset of the product.

**Content and presentation of evidence elements:**

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

**Evaluator action elements:**

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

272. ADV_IMP.1.2E: The evaluator shall determine if the KRS functional
     requirements are addressed by the representation of the product.
     \[NOTE: DOES THIS MEAN THAT THE FUNCTIONAL REQUIREMENTS NEED TO BE
     IDENTIFIED AS SUCH SO THAT THERE IS NO CONFUSION WITH SECURITY OR
     OPERATIONAL REQUIREMENTS?\]

### 4.3.4 Development ADV_LLD - Low-Level Design  {#development-adv_lld---low-level-design .unnumbered}

**Objectives**

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

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

**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 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) is necessary; specific functional requirements are
violated and the product fails to meet its requirements; and specific
functional requirements have not been addressed and further analysis (of
another product representation) is necessary. Whenever more analysis is
necessary, the evaluator is expected to carry that information forward
to the analysis of other product representations. If requirements are
not addressed after the analysis of the last provided product
representation, this also represents a failure of the product
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
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.

#### 4.3.4.1 ADV_LLD.1 Descriptive Low-Level Design  {#adv_lld.1-descriptive-low-level-design .unnumbered}

**Application notes**

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

**Developer action elements:**

273. ADV_LLD.1.1D: The developer shall provide the low-level design of
     the product.

**Content and presentation of evidence elements:**

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

275. ADV_LLD.1.2C: The low-level design shall describe the product in
     terms of modules.

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

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

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

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

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

281. ADV_LLD.1.8C: The low-level design shall identify the interfaces of
     the modules of the product which are visible at the external
     interface of the product.

**Evaluator action elements:**

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

283. ADV_LLD.1.2E: The evaluator shall determine if the functional
     requirements in the KRS are addressed by the representation of the
     product.

### 4.3.5 Development ADV_RCR - Representation Correspondence  {#development-adv_rcr---representation-correspondence .unnumbered}

**Objectives**

The correspondence between the various representations (i.e. functional
requirements expressed in the KRS, 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.

**Application notes**

The developer must demonstrate to the evaluator that the most detailed,
or least abstract, representation of the product is an accurate,
consistent, and complete instantiation of the functions expressed as
functional requirements in this standard. 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
representation, and then make a determination as to whether the
functional requirements in this standard 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 this standard as well as the
product, functional specification, high-level design, low-level design,
and implementation representation.

#### 4.3.5.1 ADV_RCR.1 Informal Correspondence Demonstration  {#adv_rcr.1-informal-correspondence-demonstration .unnumbered}

**Developer action elements:**

284. ADV_RCR.1.1D: The developer shall provide evidence that the least
     abstract product representation provided is an accurate,
     consistent, and complete instantiation of the functional
     requirements expressed in this standard.

**Content and presentation of evidence elements:**

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

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

**Evaluator action elements:**

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

288. ADV_RCR.1.2E: The evaluator shall analyze the correspondence
     between the functional requirements expressed in this standard and
     the least abstract representation provided by the developer in
     order to ensure accuracy, consistency, and completeness.

## 4.4 Guidance Documents {#guidance-documents .unnumbered}

### 4.4.1 Guidance Documents AGD_ADM Administrator Guidance  {#guidance-documents-agd_adm-administrator-guidance .unnumbered}

**Objectives**

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

**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 with regard to the product
security environment and the security objectives described in this
standard are appropriately covered in the administrator guidance.

Those topics that are relevant to administrator guidance for the
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.

#### 4.4.1.1 AGD_ADM.1 Administrator Guidance  {#agd_adm.1-administrator-guidance .unnumbered}

**Developer action elements:**

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

**Content and presentation of evidence elements:**

290. AGD_ADM.1.1C: The administrator guidance shall describe how to
     administer the product in a secure manner.

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

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

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

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

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

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

297. AGD_ADM.1.8C: The administrator guidance shall contain instructions
     regarding how to configure the product.

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

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

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

**Evaluator action elements:**

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

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

### 4.4.2 Guidance Documents AGD_USR - User Guidance {#guidance-documents-agd_usr---user-guidance .unnumbered}

**Objectives**

User guidance refers to written material that is intended to be used by
non-administrative (human) users of the product. User guidance describes
the security functions provided by the product 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 and a measure of confidence that non-malicious users and
application providers will understand the secure operation of the
product and will use it as intended.

**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 with regard to the product
security environment and the security objectives described in this
standard are appropriately covered in the user guidance.

Those topics in this standard 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.

#### 4.4.2.1 AGD_USR.1 User Guidance  {#agd_usr.1-user-guidance .unnumbered}

**Developer action elements:**

303. AGD_USR.1.1D: The developer shall provide user guidance.

**Content and presentation of evidence elements:**

304. AGD_USR.1.1C: The user guidance shall describe the product and
     interfaces available to the user.

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

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

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

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

**Evaluator action elements:**

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

## 4.5 Life Cycle Support {#life-cycle-support .unnumbered}

### 4.5.1 Life Cycle Support ALC_FLR - Flaw Remediation  {#life-cycle-support-alc_flr---flaw-remediation .unnumbered}

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

**Application notes**

None

#### 4.5.1.1 ALC_FLR.1 Basic Flaw Remediation  {#alc_flr.1-basic-flaw-remediation .unnumbered}

**Developer action elements:**

310. ALC_FLR.1.1D: The developer shall document the flaw remediation
     procedures.

**Content and presentation of evidence elements:**

311. ALC_FLR.1.1C: The flaw remediation procedures documentation shall
     describe the procedures used to track all reported security flaws
     in each release of the product.

312. ALC_FLR.1.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.

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

314. ALC_FLR.1.4C: The flaw remediation procedures documentation shall
     describe the methods used to provide flaw information and
     corrections to product users.

**Evaluator action elements:**

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

#### 4.5.1.2 ALC_FLR.2 Flaw Reporting Procedures  {#alc_flr.2-flaw-reporting-procedures .unnumbered}

**Developer action elements:**

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

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

**Content and presentation of evidence elements:**

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

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

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

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

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

**Evaluator action elements:**

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

## 4.6 Tests {#tests .unnumbered}

### 4.6.1 Tests ATE_COV - Coverage  {#tests-ate_cov---coverage .unnumbered}

**Objectives**

This family addresses those aspects of testing that deal with
completeness of testing. That is, it addresses the extent to which the
product security functions are tested, whether or not the testing is
sufficiently extensive to demonstrate that the product operates as
specified, and whether or not the order in which testing proceeds
correctly accounts for functional dependencies between the portions of
the product being tested.

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

#### 4.6.1.1 ATE_COV.1 Complete Coverage - Informal  {#ate_cov.1-complete-coverage---informal .unnumbered}

**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, there is
no more than an informal explanation to support this assertion.

**Developer action elements:**

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

**Content and presentation of evidence elements:**

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

**Evaluator action elements:**

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

### 4.6.2 Tests ATE_DPT - Depth  {#tests-ate_dpt---depth .unnumbered}

**Objectives**

The components in this family deal with the level of detail to which the
product is tested. The 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. Additionally, the components of this family,
especially as testing is more concerned with the internals of the
product, are more likely to discover any malicious code that has been
inserted.

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

#### 4.6.2.1 ATE_DPT.1 Testing - Functional Specification {#ate_dpt.1-testing---functional-specification .unnumbered}

**Objectives**

The functional specification of a product provides a high level
description of the external workings of the product. Testing at the
level of the functional specification, in order to demonstrate the
presence of any flaws, provides assurance that the product 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.

**Developer action elements:**

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

**Content and presentation of evidence elements:**

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

**Evaluator action elements:**

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

### 4.6.3 Tests ATE_FUN - Functional Tests  {#tests-ate_fun---functional-tests .unnumbered}

**Objectives**

Functional testing establishes that the product exhibits the properties
necessary to satisfy the functional requirements of this standard.
Functional testing provides assurance that the product satisfies at
least the security functional requirements, although it cannot establish
that the product does no more than what was specified. The
\`\`Functional tests\'\' family 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.

**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 to determine that no new security
relevant flaws have been introduced as a result of eliminating
discovered security relevant flaws.

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

#### 4.6.3.1 ATE_FUN.1 Functional Testing {#ate_fun.1-functional-testing .unnumbered}

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

**Developer action elements:**

330. ATE_FUN.1.1D: The developer shall test the product and document the
     results.

331. ATE_FUN.1.2D: The developer shall provide test documentation.

**Content and presentation of evidence elements:**

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

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

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

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

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

**Evaluator action elements:**

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

### 4.6.4 Tests ATE_IND - Independent Testing {#tests-ate_ind---independent-testing .unnumbered}

**Objectives**

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

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

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

Independent testing shall be performed by an independent third party
certified and accredited by the Government.

The Government will supply some tests to validate compliance and
conformance. Examples include: cryptographic algorithms and
cryptographic protocols. The evaluator (which happens to be the
independent third party) shall execute these government supplied tests
in addition to the tests provided by the developer, and tests developed
by the evaluator.

#### 4.6.4.1 ATE_IND.2 Independent Testing - Sample {#ate_ind.2-independent-testing---sample .unnumbered}

**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 for testing is based on access to the
product, 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 for testing may be based on
other considerations (e.g., the version of the product 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 is based upon all available documentation.

**Developer action elements:**

338. ATE_IND.2.1D: The developer shall provide the product for testing.

**Content and presentation of evidence elements:**

339. ATE_IND.2.1C: The product shall be suitable for testing.

**Evaluator action elements:**

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

341. ATE_IND.2.2E: The evaluator shall test the product to confirm that
     the product operates as specified.

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

#### 4.6.4.2 ATE_IND.3 Independent Testing - Complete {#ate_ind.3-independent-testing---complete .unnumbered}

**Objectives**

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

In this component, the objective is to repeat the developer testing.

**Application notes**

The suitability of the product for testing is based on access to the
product, 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 for testing may be based on
other considerations (e.g., the version of the product 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.

**Developer action elements:**

343. ATE_IND.3.1D: The developer shall provide the product for testing.

**Content and presentation of evidence elements:**

344. ATE_IND.3.1C: The product shall be suitable for testing.

**Evaluator action elements:**

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

346. ATE_IND.3.2E: The evaluator shall test the product to confirm that
     the product operates as specified.

347. ATE_IND.3.3E: The evaluator shall execute all tests in the test
     documentation to verify the developer test results.

## 4.7 Vulnerability Assessment {#vulnerability-assessment .unnumbered}

### 4.7.1 Vulnerability Assessment AVA_VLA - Vulnerability Analysis  {#vulnerability-assessment-ava_vla---vulnerability-analysis .unnumbered}

**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, or
interfere with the authorized capabilities of other users.

**Application notes**

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

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

suggested by the product 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 documentation upon which the
search for flaws was based.

#### 4.7.1.1 AVA_VLA.1 Developer Vulnerability Analysis  {#ava_vla.1-developer-vulnerability-analysis .unnumbered}

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

**Application notes**

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

**Developer action elements:**

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

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

**Content and presentation of evidence elements:**

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

**Evaluator action elements:**

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

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

## 4.8 Excluded Assurance Requirements {#excluded-assurance-requirements .unnumbered}

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

The ADV_INT family relates to modularity, layering, information hiding,
etc. For economic reasons, this family has not been included.

ALC_DVS (Developmental Security), ALC_LCD (Life Cycle Definition), and
ALC_TAT (Tools and Techniques) are excluded in order to provide
engineering independence for the vendors, 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. Cryptanalytic 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. \[but
we put it in anyway?\]

# Appendix A: Examples {#appendix-a-examples .unnumbered}

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

**A.1 Key Recovery Function Distribution**

The functions of a KRS may be integrated into products in a variety of
configurations in order to accommodate different user environments. In
Figure 9, the KRI Generation, Delivery, Acquisition and Validation
functions are provided in a single cryptographic end system 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/image11.png){width="2.470138888888889in"
height="2.359722222222222in"}In Figure 10, the KRI Generation and
Delivery Functions are provided in one product, while the Requestor
Function and KRA Function are in a separate product. This configuration
may be appropriate for a storage application, where files are encrypted
by a user, KRI is attached to the file and thereafter ignored unless the
decryption key becomes unavailable and recovery is required. The user
could then go to a special recovery system in order to recover the
appropriate key.

In Figure 11, 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.

In Figure12, the KRI Generation, Delivery, Acquisition, Validation and
Requestor Functions are provided in a single cryptographic end system.
The KRA Function is a separate product. There may be an electronic
connection between the end user system and the KRA in order to effect
the recovery process.

![](media/image12.png){width="3.4902777777777776in"
height="3.3430555555555554in"}

![](media/image13.png){width="2.479861111111111in"
height="1.9826388888888888in"}

**A.2 Multiple KRI Generation Functions**

Figure 13 provides an example of multiple KRI Generation Functions which
are required to provide the aggregate of KRI needed to recover a target
key. Suppose that System B or a trusted generation service generates an
encryption key pair for System B and provides the public key to a
Certificate Authority (CA) along with other information which will be
useful in providing key recovery. The CA generates a certificate
containing this information. System A uses this certificate along with
other internally generated information to create KRI for messages to be
sent to System B. In this case, System A, the CA and whoever generates
System B's key pair participate in the generation of the KRI that will
allow System B to recover.

**A.3 KRI Generation Scenarios**

Assume that 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.3.1 Interactive Communications**

**A.3.1.1 Between Two Encapsulation Techniques**

![](media/image14.png){width="2.520138888888889in"
height="3.6131944444444444in"}In Figure 5, cryptographic end systems A
and B are two systems that employ two different encapsulation methods
for key recovery, but use 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 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.3.1.2 Between Encapsulated and Key Escrow Techniques**

Figure 8 includes cryptographic end systems A and B that use key escrow
and KRI 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 cryptographic end systems). 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 be conducted with other parties that employ key
recovery techniques, and that KRI is always created for itself in
outgoing communications.

System B wants to initiate a communication session with 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
escrow 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 for itself and its KRA. The data key is then used to
encrypt the data, and the encrypted data and the KRB are sent to system
A.

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.3.2 Store and Forward Communications**

**A.3.2.1 Between Two Key Escrow Key Recovery Schemes**

In Figure 6, cryptographic end Systems A and B employ key escrow 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 key and encrypts the key using the encryption
public key of the receiver SA) for use in the key exchange (key
transport process). Even though System B uses key escrow, there is
nothing yet which allows System B to recover after the outgoing message
is archived. System B encrypts the data key using his own encryption
public key, and places it in a KRB. System B then encrypts the message
with the data 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 key received via the key transport mechanism
and decrypts the received message using that key.

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

In Figure 5, cryptographic end System A uses an encapsulated method of
key recovery. System B 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.3.3 Data Storage**

A.3.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 system decrypts the
appropriate copy of the encrypted data key, and uses the decrypted data
key to decrypt the file.

**A.4 Key Recovery Scenarios**

**A.4.1 Interactive Session**

Referring back to scenario A.3.1.2, when 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.4.2 Store-and-Forward Communications**

In scenario A.3.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.4.3 Data Storage**

In scenario A.3.3.1, System A could create a file for himself (i.e., no
one else is on the access list, so the data 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 {#appendix-b-key-recovery-block .unnumbered}

**B.1 Introduction**

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[^2] 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.

**B.2 KRB Fields**

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.

**B.3 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                                                 
  ----------------- ----------------- ----------------- -----------------

**B.4 Implementation Guidance**

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

**\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--**

[\[]{.underline}THE PRESENCE OF THE PKCS#7 STRUCTURE IS FOR INFORAMTION
PURPOSES ONLY.\]

[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: Certificate Extensions {#appendix-c-certificate-extensions .unnumbered}

**C.1 Introduction**

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 that indicates that the public key is to be used
> for key recovery purposes.
>
> ASN.1 for this has two alternatives:
>
> a\. Recommend adding a bit to the X.509 key usage extension:
> keyRecoveryAgent (9) and mark the key usage extension critical, or
>
> b\. Register the following object as the key purpose object identifier
> and mark it critical. \[violates interop requirements if marked
> critical?\] This seems to be the more appropriate approach rather than
> expecting X.509 to add a bit to the key usage extension.
>
> {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
> csor(3) pki(2) keypurpose(2) krakey(1)}
>
> \(2\) an identification of the key recovery technique(s) with which
> the public key may be used.
>
> It is not clear that this extension is required at all. Santosh
> suggests not having this extension at all. Note that if this extension
> is used, the first extension is not required since this extension
> implies that the public key belongs to the KRA. Thus, it is
> recommended that if this extension is used, the first extension
> (extended key usage) should be dropped. The following is the syntax
> for this private, critical[^3] extension to the certificate:
>
> kRTechnique EXTENSION ::= {
>
> SYNTAX KRTechnique
>
> IDENTIFIED BY id-extensions-kRTechnique }
>
> KRTechnique ::= SEQUENCE {\
> technique technique.&id,\
> parameters OPTIONAL }
>
> *\-- technique is an object identifier. The parameters syntax is
> registered when the technique OID is registered*

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

> \(1\) an indication that the entity has a key recovery capability,
> This is done by using the following private, non-critical extension
>
> keyRecoveryCapable EXTENSION ::= {
>
> SYNTAX SubjectKeyIdentifier
>
> IDENTIFIED BY id-extensions-KeyRecoveryCapable }
>
> KeyRecoveryCapable ::= BOOLEAN DEFAULT FALSE
>
> \(2\) identify the KRA(s), This is done using the following private,
> non-critical extension. Please note that if this extension is
> included, the first extension (key recovery capable) is not required.
>
> kR EXTENSION ::= {
>
> SYNTAX KR
>
> IDENTIFIED BY id-extensions-KR }
>
> KR ::= SEQUENCE SIZE (1\...MAX) OF KRS
>
> KRS ::= SEQUENCE {
>
> technique KRTechnique
>
> SEQUENCE SIZE (1\...MAX) OF AGENT }
>
> AGENT ::= SEQUENCE {
>
> agentName directoryName
>
> agentkey KeyIdentifier -- OPTIONAL
>
> agentpol KRAPolicy -- OPTIONAL}
>
> KRAPolicy ::= OBJECT IDENTIFIER
>
> \(3\) indicate the KRA certificate(s) containing the appropriate KRA
> public key(s). Please note that this is in the KR extension.
>
> \(4\) identify the key recovery technique(s) supported by the entity.
> Please note that this is in the extension for the key recovery (item 2
> above)
>
> \(5\) include any key recovery technique information required. Please
> note that this is in optional parameters extension of the key recovery
> technique.

***CSOR REGISTERED TECHNICAL OBJECTS***

Prefix for CSOR-unique technical objects: {2.16.840.1.101.3}

{joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3)}

\-- Technical Object Identifiers

**\-- Types of information security objects**

id-slabel ID ::= {id-csor 1}

id-pki ID ::= {id-csor 2}

id-arpa ID ::= {id-csor 3}

**\-- Certificate Policies**

\-- {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) pki(2) certpolicies(1)}

**\-- Key Purpose**

\-- {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) pki(2) keypurpose(2)}

id-kRAKey ID ::= {id-keypurpose 1}

**\-- Extensions**

\-- {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) pki(2) extensions(3)}

id-kRTechnique ID ::= {id-extensions 1}

id-kRecoveryCapable ID ::= {id-extensions 2}

id-kR ID ::= {id-extensions 3}

**\-- Key Recovery Schemes**

\-- {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) pki(2) keyrecoveryschemes(4)}

**\-- Key Recovery Policy**

\-- {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) pki(2) krapol(5)}

# Appendix D: Interoperability Examples {#appendix-d-interoperability-examples .unnumbered}

**D.1 Introduction**

**D.2 S/MIME**

The Secure MIME (S/MIME) protocol provides encryption for Internet
electronic mail that uses the MIME encoding format. S/MIME defines two
security wrappers: one for digital signatures and one for encryption. To
encrypt and sign a message, both wrappers are applied. Both of these
wrappers build on the formats defined in PKCS#7 version 1.5. For
encryption, the EnvelopedData wrapper is used. The EnvelopedData wrapper
requires RSA key management, and the RSA public keys must be carried in
certificates.

S/MIME does not include a location that can be used to carry a key
recovery field. However, the key recovery center could be a recipient on
every message, even if the message is not delivered to the key recovery
center. In this way, the key recovery center private key can be used to
recover the message plaintext content.

Key recovery may also be done as part of certificate management. This
technique only works if the originator is a recipient of the message.
That is, a RecipientInfo field for the originator must be included to
ensure that the key used to encrypt the message content is available to
the key recovery center who holds a copy of the originator's RSA private
key.

**D.3 MSP**

The Message Security Protocol (MSP) provides encryption for Internet and
X.400 electronic mail. MSP is used in the Defense Message System, and
MSP is specified in SDN.701. Like S/MIME, MSP supports both digital
signatures and encryption; however, MSP defines one wrapper to provide
both services. MSP is algorithm independent.

MSP includes two locations that could be used to carry a key recovery
field: the token and the extensions. To carry a key recovery field in
the token, a separate object identifier for a new key management
technique must be assigned. This approach would destroy interoperability
with existing implementations. To carry a key recovery field in the
extensions, a non-critical extension is added to the end of the message.
MSP does not encrypt the extensions; therefore a key recovery field
carried in an extension would be accessible.

Alternatively, the key recovery center could be a recipient on every
message, even if the message is not delivered to the key recovery
center. In this way, the key recovery center private key can be used to
recover the message plaintext content.

Key recovery may also be done as part of certificate management. MSP
includes a token for the originator. If the mail transfer system is
unable to deliver the MSP protected message and returns the message to
the originator as part of non-delivery notification, this token allows
the originator to decrypt the message to determine which one was
returned. If the key recovery center holds a copy of the originator's
private key, then the key recovery center can also use the originator
token to decrypt the message content.

**D.4 PEM**

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.5** **IKE**

##  {#section-8 .unnumbered}

[^1]: The C2, B1 and B2 ratings are in accordance with the TCSEC (see
    the cross index in the Announcement section.

[^2]: Note that the KRB is not itself KRI - the KRB *contains* KRI plus
    other information, including an integrity checking value.

[^3]: The extension must be critical since only those who understand it
    in the key recovery context should use this public key.