KEY RECOVERY STANDARD (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 components used by Federal government agencies. These components provide for the recovery of keys which will be used for the decryption of stored or communicated data when access to the data is properly authorized. Key words: ADP security, computer security, Key Recovery, Federal Information Processing Standard. Federal Information Processing Standards Publication XXX (Date) Announcing the KEY RECOVERY STANDARD Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Management Reform Act of 1996, and the Computer Security Act of 1987, Public Law 104-106. 1. Name of Standard. Key Recovery Standard. 2. Category of Standard. Computer Security, Cryptography. 3. Explanation. This Standard specifies requirements for key recovery components. These components provide for the recovery of keys to be used for the decryption of stored or communicated ciphertext when the decryption keys are not otherwise available. Key recovery is motivated by three primary scenarios: 1. recovery of stored data on behalf of an organization (or individual) e.g., in response to accidental loss of keys; 2. recovery of stored or communicated data on behalf of an organization (e.g., for the purposes of monitoring or auditing activities); and 3. recovery of communicated or stored data by lawfully authorized authorities. The first scenario supports the ability to regain access to data that would otherwise be lost. The second scenario encompasses internal investigation authorized by an organization. The final scenario encompasses data acquired under the authorization of court orders for wiretaps, search and seizure orders, civil suit subpoenas, etc A Key Recovery System (KRS) manages cryptographic keys in support of data recovery when normal key access mechanisms fail. These systems must be carefully designed so that plaintext may be recovered in a timely manner, and so that only authorized recoveries are permitted. Therefore, security is a critical factor in any KRS design. The purpose of this standard is to specify requirements for key recovery components, and to enable the validation of components claiming conformance. The standard encompasses the security (from an implementation, managerial and operation perspective) and the availability of key recovery components, as well as defining interoperability requirements. 4. Approving Authority. Secretary of Commerce. 5. Maintenance Agency. U.S. Department of Commerce, National Institute of Standards and Technology (NIST), Information Technology Laboratory. 6. Cross Index. a. FIPS PUB 46-2, Data Encryption Standard. b. FIPS PUB 81, DES Modes of Operation. c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules, 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) Key Recovery Standard (affixed). 10. Implementations. System components, or parts thereof, conforming to this standard may be implemented in software, firmware, hardware, or any combination thereof. All cryptographic modules employed in components of such systems shall comply with FIPS 140-1. FIPS approved encryption algorithms (e.g., DES) shall be used in Federal applications of systems conforming to this standard. The use of new encryption algorithms which are FIPS approved after the date of the standard is also permitted. Information about the validation of implementations conforming to this standard may be found in Section X of the attached Specification. Additional information may be obtained from the National Institute of Standards and Technology, Information Technology Laboratory, Attn: Key Recovery Validation, Gaithersburg, MD 20899. 11. Export Control. Implementations of this standard are subject to export controls as specified in Title 15, Code of Federal Regulations, Parts 730-774 and Title 22, Code of Federal Regulations, Parts 120-130. Exporters are advised to contact the Encryption Policy Controls Division at the Department of Commerce, Bureau of Export Administration for more information. 12. Patents. Implementations of this standard may be covered by U.S. and foreign patents. 13. Implementation Schedule. The effective date of this standard is . From approval of this FIPS by the Secretary of Commerce to its effective date, agencies may purchase components that have been affirmed in writing from the manufacturer as complying with this standard. From the effective date until six months after the establishment of the validation program by NIST, agencies that have determined a need for key recovery components shall purchase components that have been affirmed in writing by the manufacturer as complying with this standard. A copy of the written affirmation shall have been sent to the Director, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899. For a one year period following the six month period after the establishment of the validation program, agencies shall purchase validated key recovery components, or components that have been submitted for validation. After this period, only validated key recovery components will be considered as meeting the provisions of this standard. 14. Glossary. The following terms are used as defined below for purposes of this standard: Abstract Machine The underlying hardware or firmware abstraction to which the software is written. Accountability 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 Events within a key recovery product which may appear in an audit log (see Section 4). Authentication Data Information used to authenticate an entity, e.g., a password, PIN, biometric, or response to a challenge. Authentication Information See "Authentication Data". Authentication Mechanism A technique used to authenticate an entity, e.g., user ID and password, token, biometric or challenge-response. Authentic Public Key Source Used to provide a certificate infrastructure to support the use of public key cryptography within the Key Recovery System. Authorized key recovery Key recovery either with the permission of the owner of the data or as otherwise permitted by law. Authorized Request A request based on a legal and lawful right for access by a data owner or other authorized entity. Authorized User A user who is authorized to access a system to perform one or more actions. Common Criteria (CC) An international standard for security in information security components. Common Criteria Evaluation Assurance Level (EAL) A predefined set of assurance components that represents a point on the CC assurance scale. Common Criteria Protection Profile An implementation-independent set of security requirements for a category of components which meet specific consumer needs. Confidentiality (1) Assurance that the information is not disclosed to unauthorized entities or processes. (2) The property that sensitive information is not disclosed to unauthorized individuals, entities or processes. (3) The property that information is not made available or disclosed to an unauthorized user, process or object. Configurable Capability A capability feature that is available but need not be selected for use. Configuration Item Items (e.g., documents, software, hardware) which are under configuration control. Configuration Management (CM) The management of security features and assurances through the control of changes made to a system's hardware, software, firmware, documentation set, test, test fixtures and test documentation throughout the development and operational life of the system. Cryptographic End System A system containing encryption and decryption 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 System The system/subsystem used to recover encrypted data 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 Origin (1) A proof of the origin of information that cannot be refuted by the originator, e.g., by using a digital signature. (2) Non-repudiation. Evidence of Receipt Should be "Proof of Receipt"? FIPS 140-1 Level 1 Security Requirements Specify basic security requirements for a cryptomodule. No physical security mechanisms are required in the module beyond the requirement for production- grade equipment. Software cryptographic functions may be performed in a general purpose personal computer. FIPS 140-1 Level 2 Security Requirements Improve upon the physical security of a Level 1 cryptomodule by (1) requiring tamper evident coatings or seals, or for pick-resistent locks, (2) requiring role-based authentication and (3) allowing software cryptography in multi-user timeshared systems when used in conjunction with a C21 or equivalent operating system. FIPS 140-1 Level 3 Security Requirements Improve upon the Level 1 and 2 requirements for cryptomodules by (1) requiring tamper detection mechanisms, (2) requiring identity-based 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 Compliant Meeting all requirements of a specified level of this standard. Flaw Remediation The correction of discovered security flaws in a product or system. Functional Requirements A high level description of the requirements for a system. Functional Specification High level description of the user-visible interface and behavior of a system. Implementation Representation A description of the implementation (e.g., source code when the implementation is software or firmware; or drawings and schematics, if the system is hardware). Independent Testing Testing performed by persons other than the developers. Informal Security Policy Model An accurate and concise statement of system security policy expressed informally (i.e., in natural language; e.g., English). Informal (1) Expressed in natural language. (2) Written as prose in natural language. Informal style/presentation Written in normal language, e.g., English. Integrity The property that sensitive data has not been modified or deleted in an unauthorized and undetected manner. Interactive Communication Two-way communication between end users. Interoperability The ability of components or systems to communicate 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 Agent (KRA) A Key Recovery Agent System. Key Recovery Agent (KRA) System A key recovery system that performs a recovery service in response to an authorized request by a requestor system on behalf of a requestor. Key Recovery Capable System A cryptographic end system with either a KRI Generation Function or a Key Recovery Validation Function or both. Key Recovery Component An element within a Key Recovery System that provides key recovery functionality (e.g., KRI generation, KRI management, and/or key recovery function). Key Recovery Field A field, output by the key recovery mechanism of a 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 Function Recovers a target key using Key Recovery Information. Composed of the KRI Requestor Function and KRA Function. Key Recovery Information (KRI) Information that is used in the recovery of a key. The KRI does not include a plaintext key. Key Recovery Information Field (KRIF) Key recovery information which is specific to a single key recovery scheme. Key Recovery Block (KRB) A stream of bytes that serves as a container for a single key recovery scheme- specific KRIF and associates the KRIF with a set of standard fields in a predefined format. Key Recovery Policy A policy which specifies the conditions under which key recovery information must be created and conditions under which and to whom the key recovery information may be released; may also indicate the allowable Key Recovery Agent(s) and how or where key recovery information must be maintained. Key Recovery Requestor System The system/subsystem used by the requestor to request keys. Key Recovery Service An authorized key recovery as performed by a Key Recovery Agent. Key Recovery System (KRS) Consists of the KRI Generation Function, the KRI Management Function and the Key Recovery Function. Includes software, hardware, procedures and infrastructure. KRA Key Recovery Agent KRB Key Recovery Block KRI Acquisition Function Enables a receiver to determine the key recovery information (KRI) which is available and acquire KRI for subsequent processing. KRI Delivery Function Assembles and formats the key recovery information (KRI) and makes the KRI available. KRI Encapsulation A method of key recovery in which keys, key parts or key related information is maintained outside a Key Recovery Agent. KRI Generation Function Generates the key recovery information (KRI) needed to recover the target key and provides the KRI to the KRI Delivery Function. KRI Management Function Manages the KRI after generation for potential recovery. Composed of the KRI Delivery Function, KRI Receive Function and KRI Validation Function. KRI Providers Those entities provide Key Recovery Information (KRI) using a KRI Generation Function. KRI Validation Function Checks, authenticates, validates or verifies the available key recovery information. KRR Key Recovery Requestor System. KRS Key Recovery System Layered Product A product in which security functions are layered. For example, a secure application which is implemented on top of a secure operating system is a layered product. Least Abstract Representation (1) The most concrete representation of an implementation (e.g., source code). (2) The representation that is closest to the implementation, e.g., source code. Licensing Agent Authorizes Key Recovery Agents after an evaluation against the FIPS. Masquerading An attempt to gain access to a system by posing as an authorized user. Message Security Protocol (MSP) A data format that cryptographically binds data sensitivity and provides public key cryptography based security services for the data, including confidentiality, integrity, etc. MIME Multipurpose Internet Mail Extension as defined in RFC 2045. Monolithic Product A product in which security functions are not layered. See "Layered Product". Non-Key Recovery Product An encryption product whose encryption output is not recoverable through key recovery. Presentation of Evidence Providing the information necessary to carrying out 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 Receipt A proof of the receipt of information so that the 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 Agent Archives vendor-specific information in order to find, acquire and parse recovery information. Representation Correspondence An accurate and complete mapping from a higher level representation to a lower level representation (e.g., from functional requirements to a functional specification, from a functional specification to a high level design, from a high level design to a low level design, from a low level design to source code, etc.). Requestor An entity that is authorized to request a key recovery. Requestor Function Interacts with one or more Key Recovery Agents using 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 Domain (1) A set of objects , a security policy , a 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 Policy (1) A precise specification of the security rules under which a cryptographic module may operate, including the security rules derived from the requirements of this standard and the additional security rules imposed by the manufacturer. (2) A set of rules and procedures regulating the use of information including its processing, storage, distribution and presentation. Security Policy Model A formal representation of the security policy enforced by the product. Security Target A set of security requirements ad specifications to be used as the basis for evaluation of an identified product. Session-based Protocols Interactive communications. Session Key A key that is used to encrypt and/or decrypt data for a single communications session. Session Key Recovery Recovery of the Data Encryption Key. S/MIME Secure MIME as defined by RFC XXX. Source Authentication The ability to authenticate the identity of the source of a information. Standard Communication Protocol Any communication protocol adopted by a generally recognized standards organization. Store-and-Forward Communications One way communications (i.e., from a sender to a receiver) without the involvement of the receiver. The receiver may acquire the communication at a time 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 laboratory A laboratory which has been accredited by NIST to test systems, subsystems, key recovery agents, or components for conformance to this standard. Transaction-based Protocols Store-and-forward communications. 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 Party An entity which is trusted by the parties performing the encryption or decryption processes, but are not identical with those parties. Unwrap Decryption of an encrypted key by another key. Vulnerability Analysis The determination of the vulnerabilities of a product or system. Wrap Encryption of a cryptographic key by another key. 15. Qualifications. The security requirements specified in this standard are based upon information provided by many sources within the Federal government and private industry. The requirements are designed to protect against adversaries mounting cost-effective attacks on unclassified government or commercial data. The primary goal in defining effective security for a system is to make the cost of any attack greater than the possible payoff. While the security requirements specified in this standard are intended to maintain the security of a key recovery component, conformance to this standard does not guarantee that a particular component is secure. It is the responsibility of the manufacturer of a key recovery component to build the component in a secure manner. Similarly, the use of a key recovery component that conforms to this standard in an overall system does not guarantee the security of the overall system. The responsible authority in each agency shall assure that an overall system provides an acceptable level of security. Since a standard of this nature must be flexible enough to adapt to advancements and innovations in key recovery technology, this standard will be initially reviewed in two years in order to consider new or revised requirements that may be needed to meet technological changes. 16. Waiver Procedure. Under certain exceptional circumstances, the heads of Federal departments and agencies may approve waivers to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such authority only to a senior official designated pursuant to section 3506(b) of Title 44, United States Code. Waivers shall be granted only when: a. Compliance with a standard would adversely affect the accomplishment of the mission of an operator of a Federal computer system; or b. Cause a major adverse financial impact on the operator which is not offset by Government wide savings. Agency heads may act upon a written waiver request containing the information detailed above. Agency heads may also act without a written waiver request when they determine that conditions for meeting the standard cannot be met. Agency heads may approve waivers only by a written decision which explains the basis on which the agency head made the required finding(s). A copy of each such decision, with procurement sensitive or classified portions clearly identified, shall be sent to: National Institute of Standards and Technology; ATTN: FIPS Waiver Decisions, Building 225 Building, Room A-231, Gaithersburg, MD 20899. In addition, a notice of each waiver granted and each delegation of authority to approve waivers shall be sent promptly to the Committee on Government Operations of the House of Representatives and the Committee on Governmental Affairs of the Senate and shall be published promptly in the Federal Register. When the determination on a waiver applies to the procurement of equipment and/or services, a notice of the waiver determination must be published in the Commerce Business Daily as a part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that notice is published, by amendment to such notice. A copy of the waiver, any supporting documents, the document approving the waiver and any supporting and accompanying documents, with such deletions as the agency is authorized and decides to make under 5 U.S.C. Sec. 552(b), shall be part of the procurement documentation and retained by the agency. 17. Where to Obtain Copies of the Standard. Copies of this publication are for sale by the National Technical Information Service (NTIS), U.S. Department of Commerce, Springfield, VA 22161. Publication and ordering information may be found at http://www.ntis.gov. When ordering, refer to Federal Information Processing Standards Publication xyz (FIPS PUB XXX), and identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances. Payment may be made by check, money order, credit card or deposit account. TABLE OF CONTENTS 1 OVERVIEW 1 1.1 Scope of the Standard 1 1.2 Road Map for the Standard 3 2 KEY RECOVERY MODEL 5 2.1 Key Recovery Information (KRI) Generation Function 7 2.2 KRI Delivery Function 9 2.3 KRI Acquisition Function 10 2.4 KRI Validation Function 10 2.5 Requestor Function 11 2.6 Key Recovery Agent(s) 12 2.7 Interoperability 13 2.8 Mapping Components to the Key Recovery Model 15 2.9 Key Recovery Techniques 16 2.9.1 KRI Encapsulation 16 2.9.2 Key Escrow 17 2.9.3 Interactions Between Systems Using Different Key Recovery Techniques 18 2.9.3.1 Interactions Between KRI Encapsulation and Key Escrow Techniques 18 2.9.3.2 Interactions Between KRI Encapsulation and Systems with No Key Recovery 19 2.9.3.3 Interaction Between Key Escrow and Systems with No Key Recovery 19 3 SECURITY REQUIREMENTS 21 3.1 Key Recovery Agent Requirements 21 3.1.1 Level 1 - Medium Assurance 21 3.1.1.1 Cryptographic Functions 21 3.1.1.2 Cryptographic Algorithms 21 3.1.1.3 Confidentiality 21 3.1.1.4 Integrity 22 3.1.1.5 Audit 22 3.1.1.6 Identification and Authentication 24 3.1.1.7 Access Control 26 3.1.1.8 Authentication of Received Transactions 27 3.1.1.9 Non-Repudiation 27 3.1.1.10 Protection of Trusted Security Functions 28 3.1.2 Level 2 - High Assurance 28 3.1.2.1 Cryptographic Functions 28 3.1.2.2 Cryptographic Algorithms 28 3.1.2.3 Confidentiality 29 3.1.2.4 Integrity 29 3.1.2.5 Audit 29 3.1.2.6 Identification and Authentication 30 3.1.2.7 Access Control 30 3.1.2.8 Authentication of Received Transactions 32 3.1.2.9 Non Repudiation 32 3.1.2.10 Protection of Trusted Security Functions 32 3.2 Key Recovery Information Generator 33 3.2.1 Level 1 - Medium Assurance Key Recovery Information Generator 33 3.2.1.1 Cryptographic Functions 33 3.2.1.2 Cryptographic Algorithms 33 3.2.1.3 Confidentiality 33 3.2.1.4 Integrity 33 3.2.1.5 Identification and Authentication 34 3.2.1.6 Access Control 34 3.2.2 Level 2 - High Assurance Key Recovery Information Generator 34 3.2.2.1 Cryptographic Functions 34 3.2.2.2 Cryptographic Algorithms 35 3.2.2.3 Confidentiality 35 3.2.2.4 Integrity 35 3.2.2.5 Identification and Authentication 35 3.2.2.6 Access Control 35 3.3 Key Recovery Information Delivery 35 3.4 Key Recovery Information Acquisition 35 3.5 Key Recovery Information Validator 35 3.5.1 Level 1 - Medium Assurance Key Recovery Information Validator 36 3.5.1.1 Cryptographic Functions 36 3.5.1.2 Cryptographic Algorithms 36 3.5.1.3 Integrity 36 3.5.2 Level 2 - High Assurance Key Recovery Information Validator 36 3.5.2.1 Cryptographic Functions 37 3.5.2.2 Cryptographic Algorithms 37 3.5.2.3 Integrity 37 3.6 Key Recovery Requestor 37 3.6.1 Level 1 - Medium Assurance 38 3.6.1.1 Cryptographic Functions 38 3.6.1.2 Cryptographic Algorithms 38 3.6.1.3 Confidentiality 38 3.6.1.4 Integrity 39 3.6.1.5 Audit 39 3.6.1.6 Identification and Authentication 41 3.6.1.7 Access Control 42 3.6.1.8 Authentication of Received Transactions 42 3.6.1.9 Non-Repudiation 43 3.6.1.10 Protection of Trusted Security Functions 43 3.6.2 Level 2 - High Assurance 43 3.6.2.1 Cryptographic Functions 44 3.6.2.2 Cryptographic Algorithms 44 3.6.2.3 Confidentiality 44 3.6.2.4 Integrity 44 3.6.2.5 Audit 44 3.6.2.6 Identification and Authentication 45 3.6.2.7 Access Control 45 3.6.2.8 Authentication of Received Transactions 45 3.6.2.9 Non Repudiation 45 3.6.2.10 Protection of Trusted Security Functions 46 KRA Availability 47 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. 47 4 ASSURANCE REQUIREMENTS 49 4.1 Configuration Management 52 4.1.1 Configuration Management ACM_CAP - CM Capabilities 52 4.1.1.1 ACM_CAP.1 Minimal Support 52 4.1.2 Configuration Management ACM_SCP - CM Scope 53 4.1.2.1 ACM_SCP.2 Problem Tracking CM Coverage 54 4.2 Delivery and Operation 54 4.2.1 Delivery and Operation ADO_DEL - Delivery 54 4.2.1.1 ADO_DEL.1 Delivery Procedures 55 4.2.1.2 ADO_DEL.2 Detection of Modification 55 4.2.2 Delivery and Operation ADO_IGS - Installation, Generation, and Start-up 56 4.2.2.1 ADO_IGS.1 Installation, Generation, and Start-up Procedures 56 4.3 Development 57 4.3.1 Development ADV_FSP - Functional Specification 57 4.3.1.1 ADV_FSP.1 Functional Specification and Security Policy 58 4.3.1.2 ADV_FSP.2 Functional Specification, Security Policy and Informal Security Policy Model 59 4.3.2 Development ADV_HLD - High-Level Design 60 4.3.2.1 ADV_HLD.1 Descriptive High-Level Design 61 4.3.2.2 ADV_HLD.2 Security Enforcing High-Level Design 62 4.3.3 Development ADV_IMP - Implementation Representation 63 4.3.3.1 ADV_IMP.1 Subset of the Implementation 64 4.3.4 Development ADV_LLD - Low-Level Design 65 4.3.4.1 ADV_LLD.1 Descriptive Low-Level Design 65 4.3.5 Development ADV_RCR - Representation Correspondence 67 4.3.5.1 ADV_RCR.1 Informal Correspondence Demonstration 67 4.4 Guidance Documents 68 4.4.1 Guidance Documents AGD_ADM Administrator Guidance 68 4.4.1.1 AGD_ADM.1 Administrator Guidance 68 4.4.2 Guidance Documents AGD_USR - User Guidance 70 4.4.2.1 AGD_USR.1 User Guidance 70 4.5 Life Cycle Support 71 4.5.1 Life Cycle Support ALC_FLR - Flaw Remediation 71 4.5.1.1 ALC_FLR.1 Basic Flaw Remediation 71 4.5.1.2 ALC_FLR.2 Flaw Reporting Procedures 72 4.6 Tests 73 4.6.1 Tests ATE_COV - Coverage 73 4.6.1.1 ATE_COV.1 Complete Coverage - Informal 74 4.6.2 Tests ATE_DPT - Depth 74 4.6.2.1 ATE_DPT.1 Testing - Functional Specification 75 4.6.3 Tests ATE_FUN - Functional Tests 75 4.6.3.1 ATE_FUN.1 Functional Testing 76 4.6.4 Tests ATE_IND - Independent Testing 77 4.6.4.1 ATE_IND.2 Independent Testing - Sample 77 4.6.4.2 ATE_IND.3 Independent Testing - Complete 78 4.7 Vulnerability Assessment 79 4.7.1 Vulnerability Assessment AVA_VLA - Vulnerability Analysis 79 4.7.1.1 AVA_VLA.1 Developer Vulnerability Analysis 80 4.8 Excluded Assurance Requirements 81 APPENDIX A: EXAMPLES 82 APPENDIX B: KEY RECOVERY BLOCK 88 APPENDIX C: CERTIFICATE EXTENSIONS 94 APPENDIX D: INTEROPERABILITY EXAMPLES 98 1 Overview Federal Agencies have a right and a responsibility to protect the information and data contained in, processed by, and transmitted between their IT systems. Ownership of the information is often shared with individuals, companies, and organizations and therefore requires that the government protect that information on its own behalf and on behalf of those co-owners. That protection 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 will prevent disclosure to authorized parties. To ensure authorized access to encrypted data in the face of such failures, it is necessary to provide methods for recovering decryption keys by authorized parties. This Standard establishes requirements for implementations of Key Recovery System (KRS) technology. 1.1 Scope of the Standard This Standard neither requires not endorses any specific technology for use in a KRS. It endeavors to be technology independent, so as to 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 establishes technical, security and interoperability requirements for the components of a KRS. 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 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; 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 a Federal department or agency will require a complete KRS, additional guidance will 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. (Option 1) A product may be submitted for the evaluation of a subset of the KRS functions it provides. If each KRS function in the subset selected is certified as compliant, the product shall be certified compliant with the Standard. This allows a product to offer both compliant and non-compliant KRS functions, and receive certification only for the compliant ones. In this case, those assembling a complete compliant KRS must procure the products necessary to provide a complete set of compliant KRS functions. (Option 2) A product may be submitted for the evaluation of a subset of the KRS functions it provides. If each KRS function in the subset selected is certified as compliant, and the product disables any non-compliant KRS functions it provides when operating in compliant mode, then the product shall be certified compliant with the Standard. This allows a product to offer both compliant and non-compliant KRS functions, and operate in one of two modes: 1) compliant with the Standard by enabling compliant KRS functions and disabling non-compliant KRS functions or 2) non-compliant with the Standard by enabling non-compliant KRS functions. Those assembling a complete compliant KRS must procure the products necessary to provide a complete set of compliant KRS functions. (Option 3) A product shall be submitted for the evaluation of all of the KRS functions it provides. If each KRS function in the product is certified as compliant in one of its operating modes, and all KRS functions can be configured in a compliant mode simultaneously, the product shall be certified compliant with the Standard. This allows a product to offer KRS functions with both compliant and non-compliant modes, as long as each KRS function has a compliant ode and the product can operate with all its KRS functions configured in a compliant mode. Note that it is incumbent upon the vendor to accurately claim the KRS functions the product provides. (Option 4) A product shall be submitted for the evaluation of all the KRS functions it provides. If each KRS function in the product is certified as compliant, and each KRS function in the product can only operate a compliant mode, the product shall be certified compliant with the Standard. This prohibits a product from providing non-compliant KRS functions, or KRS functions that can be configured in both compliant and non-compliant modes. (Option 5) A product shall be submitted for the evaluation of its KRS functions according to one of the options above. If the product is certified compliant according to the criteria in the option chosen above, and there exist products providing certified compliant KRS functions needed for a complete KRS that are not included in the product under evaluation, then the product under evaluation shall be certified compliant with the Standard. This means that a product cannot be certified compliant until there exist products (including the one under evaluation) which together can form a complete compliant KRS. The products may be from one or multiple vendors. This also implies that the first KRS product to be evaluated must provide compliant KRS functions for a complete KRS. 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 cannot be said to comply with this Standard. 1.2 Road Map for the Standard 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. Section 4 defines security assurance requirements for the implementation of KRS functions. These requirements are derived from the Common Criteria, 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 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 defines a Key Recovery Block (KRB) format based on work 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. 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. 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 A Key Recovery System (KRS) enables authorized persons to recover plaintext from encrypted data when the decryption key is not otherwise available. Key Recovery is a broad term that applies to many different key recovery techniques. Each technique will result in the recovery of a key - herein called the target key. The target key may be either: * the data key that can be used to decrypt the data, or * a key that can be used to decrypt the encrypted data key. The information required by each key recovery technique to recover the target key may be different for each technique. The term "key recovery information" (KRI) will be used to refer to the aggregate of information needed by a key recovery technique to recover the target key. The key recovery information can be managed or handled in a variety of ways. It may exist for only a brief time during electronic transmission, or it may exist for a relatively long time on a storage device. The KRI may be distributed among multiple location(s) (e.g., at one or more Key Recovery Agents (KRAs), with a registration authority, associated with or attached to a message or file, stored with a third party which is separate from a KRA, in end user systems, in third party systems, at a CA, in a certificate, or in a requestor facility). Figure 1 presents a generalized model for a Key Recovery System, consisting of a KRI Generation Function, A KRI Management Function and a Key Recovery Function. The model addresses the creation of KRI for the recovery of the target key, the management of the KRI, and the recovery of the target key from that KRI. 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. 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, * Store-and-forward communications, and * Data storage. [TO BE MOVED TO SECTION 2.8] The key recovery model addresses both key escrowing (i.e., key backup) and encapsulated KRI techniques, as well as hybrids of these two techniques. A key escrowing technique employs one or more Key Recovery Agents (KRAs) who hold (i.e., escrow) keys or key components for their subscribers. In an encapsulated KRI technique, the KRA(s) do not hold keys belonging to their subscribers. Instead, a structure is created which contains information which will allow the Key Recovery Function to recover the subscriber's key. With both key escrowing and KRI encapsulation, a KRA may be operated by an organization as an integral part of its own security infrastructure, or a KRA may be operated by a third party organization. In the case of key escrowing by a third party organization, the key escrowing system is often called a key escrow system. 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 exchange mechanism is not inherently affected by any 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 components or 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 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. (Req. 1) There shall be a well-defined mapping from the key recovery functions of a product to the functions of the key recovery model. 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. 2.1 Key Recovery Information (KRI) Generation Function (Req. 2) The KRI Generation Function shall generate all or part of the KRI. 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 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 may 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.X), initialization and configuration may involve setting parameters which 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.Y), initialization may involve obtaining authentic copies of the KRA public key(s) for subsequent use in encapsulating the KRI by the cryptographic end system. These are critical aspects of the overall Key Recovery System, but their definition is beyond the scope of this document. (Req. 3) The KRI Generation Function shall assemble and format 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 availability may be 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 which 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, or (2) providing plaintext information pointing to the encrypted data within a structure containing the KRI, or (3) by a well- defined placement of the KRI and the encrypted data (e.g., within the same message), or (4) by acquiring information from another source (e.g., by examining a certificate to determine that a key is escrowed), or (5) by a combination of such techniques. The KRI Generation Function needs to determine that all information required to generate the KRI associated with given ciphertext is valid. This includes all information generated by 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. Verification by the KRI Validation Function may be supported, for example, by the generation of an integrity check value for the KRI. (Req. 4) The KRI Generation Function shall provide the generated KRI to the KRI Delivery Function. 2.2 KRI Delivery Function 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). (Req. 5) 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 which preserves the ability to communicate (see Section 2.7, Interoperability). (Req. 6) The KRI Delivery Function shall ensure that the persistance and availability of the KRI is commensurate with that of the corresponding transmitted or stored ciphertext data. For example, in a communication context, KRI need not be transmitted with every packet, but may have to be periodically retransmitted to facilitate requestor access for a very long lived communication session. (Note that the underlying communication or storage system is not considered to be part of the KRI Delivery Function.) 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. (Req. 7) The KRI Delivery Function shall make the KRI available to the key recovery function. The KRI Delivery Function shall make the KRI available to the key recovery function (requestors or KRAs or a combination of both). The term "make available" is system dependent and includes sending the KRI to the Key Recovery Requestor directly, or depositing the KRI in location(s) known to and accessible to the Key Recovery Requestor (i.e., the requestor(s)). (Req. 8) The KRI Delivery Function shall make the KRI available to the KRI Validation Function. The KRI Validation Function is responsible for verifying the validity of the KRI. The KRI Delivery Function must provide the KRI produced by the KRI Generation Function to the KRI Validation Function via the KRI Acquisition Function. The method of delivery may be via a communication channel, storage device or directly between modules within the same system. [MOVE TO SECTION 2.8?]For KRI encapsulation techniques, the target key (or portion of the target key) or key related information is encrypted by a key associated with a KRA. This key encrypting key is typically a public encryption key for the KRA. Additional KRI may accompany the data key, depending on the key recovery technique. [NOTE THAT A KEY EXCHANGE MECHANISM MAY CREATE ENCAPSULATED KRI]. When a key escrowing technique is employed for key recovery, the data key is typically encrypted by a key for which the corresponding decryption key (e.g., the private key exchange decryption key) has been stored (i.e., escrowed), in whole or in part, by one or more KRAs. 2.3 KRI Acquisition Function (Req. 9) The KRI Acquisition Function shall acquire the KRI needed for subsequent processing. The acquisition function may be in a receiving system which could, for example, be a cryptographic end system, a requestor system or a KRA. The KRI Acquisition Function could be distributed over multiple locations (e.g., systems, or hardware or software components). 2.4 KRI Validation Function (Req. 10) The KRI Validation Function shall provide a capability for ensuring the availability of KRI. The intent of this function is to provide assurance that a key requestor can successfully recover encrypted data using the KRI. Several degrees of validation may be performed, including: * Checking certificates for the presence of KRI (e.g., KRA identities, key recovery technique), * Checking that KRI is available for a KRA (e.g., in a recipient list or a key recovery block), * Authenticating the source of the KRI, * Validating the integrity of KRI associated with the encrypted data (e.g., received in the same message), and * Verifying that the KRI 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. In this case, a KRI Generation Function must be available. 2.5 Requestor Function The Requestor Function authenticates the entity making the request to the Key Recovery Agent. The Requestor Function consists of the requestor and a Requestor System (see Figure 3). The requestor is an entity who seeks to recover information that will allow the decryption of encrypted data. A request for a key recovery service, made by a requestor using a Requestor System to interact with one or more Key Recovery Agents, must be an authorized request -- the requestor and the Requestor System which issues a request for a key recovery service must have a legal and lawful right to access the data that can be decrypted using the recovered target key. Furthermore, the requestor and the Requestor System must establish their right to access that data. The authentication and authorization process is beyond the scope of this standard. (Req. 11) 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 can then be used to recover the data using a Data Recovery System which 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. 2.6 Key Recovery Agent(s) A Key Recovery Agent system, hereafter called a Key Recovery Agent (KRA), is a trusted entity who performs a key recovery service in response to an authorized request made by a Requestor System on behalf of a requestor. (Req. 12) A Key Recovery Agent shall have the ability to store the KRI provided by the KRI Delivery Function if such storage is required to satisfy a key recovery request. The KRA may need to store keys, key components or other information which will allow the recovery of a target key. A Key Recovery Agent needs to authenticate the entity requesting key recovery and verify the entity's authorization to access the encrypted data. Before honoring such a key recovery request, the KRA must authenticate the Requestor System's right to receive the requested key recovery service. (Req. 13) 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 (e.g., key or key component) required to decrypt data acquired by a requestor. The key recovery service performed by a KRA consists of processing all or part of the key recovery information provided to the KRA by the Requestor System, and returning an output value to the Requestor System. 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 This standard establishes interoperability requirements for several types of key recovery system components {products?}: cryptographic end systems (System A and System B), Key Recovery Agents and Key Recovery Requestors. No interoperability requirements are imposed on supporting (ancillary) components, nor are interoperability requirements imposed on communication between a cryptographic end system and a Key Recovery Agent (KRA). In both of these latter cases, the imposition of interoperability requirements is viewed as potentially too restrictive in light of the wide range of key recovery technologies that the standard attempts to embrace. This standard defines 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 XX defines the syntax for this communication syntax. 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 (i.e., System A and System B, where A and B are distinct), 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), 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. Vendors are encouraged to embody the key recovery technology in their products 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. When key recovery is introduced into a system using a standard (encryption) communication protocol, it must be done in a fashion that preserves interoperability. Interoperability is required when communicating with other key recovery capable systems, and when communicating with non-key recovery capable systems. (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 private key escrow scheme 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 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 supporting key/certificate management protocols, then it may or may not be possible for communicating systems to determine if key recovery is being employed. If a private 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 could be added to each certificate specifying the KRA(s) for the subject. If such an extension were employed and not marked "critical", this would comply 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 certificate extensions. If a KRI encapsulation scheme is employed, the key recovery information is 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 and X.411), an additional recipient, representing a KRA, could be added to the per-recipient token list to provide for key recovery on a per message basis. In ISAKMP, a participant in the key management exchange could generate and transmit a NOTIFY message with a payload containing per-session key recovery information. Even though no standard format for such a NOTIFY payload has been defined, a compliant implementation is required to silently discard an unrecognized payload, and this technique preserves interoperability. Both of these approaches to providing key recovery would be compliant with the interoperability requirements established here. If it is necessary to transport key recovery information 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. Thus, a vendor of a cryptographic end system in this category 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. Only then can a cryptographic end system with key recovery be considered compliant with this interoperability requirement. [ADDITIONAL MATERIAL TO BE PROVIDED FROM THE INTEROPERABILITY WORKING GROUP] 2.8 Mapping Components to the Key Recovery Model 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 examines how a cryptographic end system component can map to the Key Recovery Model. Cryptographic end systems encrypt and decrypt data. 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 necessary information needed to recover the data key may be made available, for example, as encapsulated information which may be stored or communicated with the encrypted data, or as cached data or both. The model does not specify which system or systems generate the KRI. When KRI is generated by 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. Figure 4 depicts a cryptographic end system application with an encryption/decryption capability. The application has a send/receive function for sending and receiving data, a key management function for generating and distributing keys, and an encrypt/decrypt function to encrypt and decrypt data. The Cryptographic End System Application processes cleartext and produces ciphertext and vice versa. Note that the communications end point which is generating and processing the cleartext need not be co-located with the Cryptographic End System Application. The key recovery functions within the cryptographic end system include a KRI Generation Function, a KRI Delivery Function, a KRI Acquisition Function, and a KRI Validation Function. Note that cryptographic end system products need not contain this 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 Acquisition and Validation Functions, rather than the receiver. 2.9 Key Recovery Techniques 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 keypair, directly accessible by a KRA. This section provides an overview of these two techniques. 2.9.1 KRI Encapsulation 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 A, hereinafter referred to as System A, first generates (or acquires) and encapsulates key recovery information (KRI) corresponding to the data key. Then, the KRI is provided to the KRI Delivery Function. Cryptographic End System B, hereinafter referred to as System B, may receive the KRI as well as the encrypted data and key exchange information. The KRI received by the KRI Acquisition Function may be provided to a 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. Validation may include checking that the key recovery technique used by System A is appropriate (e.g., by examining System A's certificate). 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. 2.9.2 Key Escrow 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, there are at least two mechanisms whereby System A can make the data key recoverable. First, 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 Acquisition and Validation Functions. In this case, System A's normal performance of the key exchange/negotiation protocol is sufficient to make the data key recoverable. Secondly, knowing that its own private key has been escrowed, System A could create encapsulate KRI which will allow itself to recover the data key (e.g., by wrapping (encrypting) the data key using its own key pair and placing it in a recipient list or key recovery block), in addition to the normal performance of the key exchange/negotiation protocol. System A would then transmit the wrapped data key with the communication or stored data. This method only works, however, in instances where the key exchange/negotiation mechanism permits such operations (e.g. RSA, but not Diffie-Hellman. If required to do so, System B may verify recoverability for either of the two mechanisms described above. In the first mechanism noted above, System B merely verifies 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. In the second mechanism noted above, System B may acquire information from some source (e.g., a certificate) using its KRI Acquisition and Validation Functions that System A's wrapped data key suitably provides for recoverability. 2.9.3 Interactions Between Systems Using Different Key Recovery Techniques Cryptographic end systems which interact with systems using different key recovery techniques may still provide for key recovery. Furthermore, compliant 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 In Figure 7 System A uses a KRI encapsulation technique to provide for key recovery, whereas System B uses a key escrow technique. System A can use its KRI Acquisition and Validation Functions 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. System B can use its KRI Acquisition and Validate Functions to determine the type of key recovery employed by System A (e.g., by examining System A's certificate) and check for the presence of encapsulated KRI. If System B must either validate or provide for the data key's recoverability, System B can itself generate and deliver encapsulated KRI in accordance with its key recovery technique provided that the key exchange/negotiation protocol allows. 2.9.3.2 Interactions Between KRI Encapsulation and Systems with No Key Recovery 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 attempt to verify its recoverability. The encapsulated KRI received from System A must not cause interoperability problems with System B, however. If the roles are reversed and System B initiates a communication, System A's KRI Acquisition and Validate functions 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 can itself generate and deliver encapsulated KRI provided that the key exchange/negotiation protocol allows. 2.9.3.3 Interaction Between Key Escrow and Systems with No Key Recovery In Figure 8, if System A uses Key Escrow and System B has no key recovery capability, System A can recover 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 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.1 Key Recovery Agent Requirements 3.1.1 Level 1 - Medium Assurance 3.1.1.1 Cryptographic Functions (Req. 14) All cryptographic modules shall be compliant with FIPS 140-1, Level 2 or higher. 3.1.1.2 Cryptographic Algorithms (Req. 15) 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. 3.1.1.3 Confidentiality These requirements are intended to protect against both the outsider and insider threats. The only insider threat addressed is the unauthorized user. The authorized insider threat is handled elsewhere using audit, role separation, and multi-person control. (Req. 16) The KRA shall protect all key recovery information stored against disclosure to unauthorized individuals. (Req. 17) The KRA shall protect key recovery information transmitted - electronically or physically communicated against disclosure to parties other than the requestor(s). (Req. 18) The strength of the algorithm used to protect the key recovery information shall be greater than or equal to the maximum strength of the encryption or key management algorithms employed for data encryption or for generation of the keys being recovered. (Req. 19) 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 (Req. 20) The product shall protect all KRI stored against modification. (Req. 21) The product shall apply source 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. (Req. 22) The product shall apply 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 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. (Req. 23) The product shall be capable of generating an audit record for the following events: * Start-up and shutdown of the audit functions, and * All auditable events as defined in the functional components included in this standard. (Req. 24) 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 (including emptying 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. (Req. 25) The following actions shall be audited. * The keys shall not be included in the audit; * Requests, responses, and other transactions generated by the product, including key recovery responses; and * Requests, responses, and other transactions received by the product, including key recovery requests. (Req. 26) The product shall record at least the following information within each audit record: * Date and time of the event, type of event, subject (user) identity, and success or failure of the event; and * Other information, as described in the functional component audit events. (Req. 27) The product shall be able to generate a human understandable presentation of any audit data stored in the permanent audit trail. (Req. 28) The audit trail shall not store the old or new authentication information (e.g., password). (Req. 29) The product shall be able to associate each auditable event with the identity of the user that caused the event. (Req. 30) The product shall provide the authorized administrator with the ability to empty the audit trail. (Note: emptying the audit trail means backup and delete) (Req. 31) 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 (i.e. optionally audited) events only. The mandatory audited events must never be excluded or excludable from the set of audited events.) (Req. 32) The product shall store generated audit records in a permanent audit trail. (Req. 33) The product shall restrict access to the audit trail to the authorized administrator. (Note: This requirement implies providing integrity to the audit trail.) 3.1.1.6 Identification and Authentication These requirements permit the unique identification of key recovery agent personnel. This facilitates individual accountability via audit functions and access controls. Requirements are levied on the strength of the authentication mechanism and the robustness of the authentication mechanism against attacks by rogue key recovery agent personnel. These requirements do not apply to electronic transactions (requests and responses). The electronic transactions may be identified and authenticated (if the scheme permits) using the access control policy. (Req. 34) The product shall provide functions for initializing and modifying KRA personnel authentication data. (Req. 35) The product shall restrict the use of these functions on the KRA personnel authentication data to the authorized administrator. (Note: These functions shall be assigned to the security administrator.) (Req. 36) The product shall allow authorized KRA personnel to use these functions to modify their own authentication. (Req. 37) The product shall protect authentication data that is stored in the product from unauthorized observation, modification, and destruction. (Req. 38) The product shall protect authentication information from unauthorized reuse, including replay. (Note: This and the previous requirement provide a capability for secure remote login.) (Req. 39) The product shall be able to terminate the KRA personnel session establishment process after five unsuccessful authentication attempts. (Note: If the product terminates the session after fewer than five unsuccessful attempts, the product meets this requirement.) (Req. 40) 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 an authorized administrator (i.e., security administrator).) (Req. 41) The product shall authenticate any KRA user's claimed identity prior to performing any functions on the user's behalf. (Req. 42) The product shall uniquely identify each KRA user before performing any actions requested by the user. (Req. 43) 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.) 3.1.1.7 Access Control 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 may be used to secure the transactions. These procedural and physical measures are beyond the scope the standard. (Req. 44) The product shall unambiguously associate the 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. (Req. 45) The product shall release the keys only to authorized users. (Req. 46) The product shall release a key only if the requester is authorized to receive the key associated with the user specified in the request and for the validity period (time interval). (Req. 47) The product shall ensure that security features are always invoked and cannot be bypassed. (Req. 48) The product shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. (Req. 49) The product shall enforce separation between the security domains of subjects in the system. (Req. 50) The product shall distinguish between security-relevant administrative functions from other functions. (Req. 51) The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the product; minimally, this set shall 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. (Req. 52) 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.) (Req. 53) The product shall be capable of distinguishing the set of KRA operators authorized for administrative functions from the set of all other users. (Req. 54) The product shall allow only specifically authorized KRA operators to assume the security administrative role (Req. 55) 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 (Req. 56) The product shall verify the source of received transactions. (Req. 57) The product shall verify the integrity of received transactions. (Req. 58) The product shall decrypt the received transactions which are encrypted. 3.1.1.9 Non-Repudiation These capabilities facilitate the use of a trusted time source to further support accountability. (Req. 59) The product shall be able to provide reliable time stamps for its own use. (Req. 60) The product shall be able to generate evidence of receipt for received transactions. (Note: The above 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 the registration or deposit of key recovery information from users, and requests from a requestor) 3.1.1.10 Protection of Trusted Security Functions (Req. 61) Before establishing a session with a KRA operator, the product shall display an advisory warning message regarding unauthorized use of the product. (Req. 62) 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". (Req. 63) The product shall restrict the capability to modify the warning message to the authorized administrator. (Req. 64) Upon successful session establishment, the product shall display the date, time, method, and port of the last successful session establishment to the KRA operator. (Req. 65) 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. (Req. 66) The data specified above shall not be removed without KRA operator intervention. 3.1.2 Level 2 - High Assurance 3.1.2.1 Cryptographic Functions (Req. 67) All cryptographic modules shall be compliant with FIPS 140-1, Level 3 or higher. 3.1.2.2 Cryptographic Algorithms Same as Level 1. 3.1.2.3 Confidentiality Level 2 requires additional protection against the insider threat of a rogue key recovery agent by requiring multi-party control on access to the key recovery information. All level 1 requirements and the following: (Req. 68) The system shall be designed for multiple KRAs. Two or more KRAs shall be required to obtain the key recovery information. 3.1.2.4 Integrity Same as Level 1. 3.1.2.5 Audit Level 2 adds a real time alarm to the security officer in the event of the audit trail becoming full to prevent audit data from being lost. It also requires the auditing of additional events consistent with the additional security requirements (i.e. trusted path) added at Level 2. Includes all the requirements of Level 1 and (Req. 69) 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. (Req. 70) The product shall provide the authorized administrator with the ability to manage the audit trail at any time during the operation of the product. (Req. 71) The following actions shall be auditable: * Execution of the tests of the underlying machine and the results of the tests; * All attempted uses of the trusted path functions; * Identification of the initiator and target of the trusted path; * Attempts to provide invalid inputs for administrative functions; and * 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. 3.1.2.6 Identification and Authentication Level 2 enhances assurance by supporting a hardware token. This provides an additional countermeasure to the threat of an attack on the authentication mechanism and the subsequent unauthorized access to key recovery information or critical functions. All Level 1 requirements and the following: (Req. 72) The product shall support a token based authentication. The token shall meet FIPS 140-1 Level 2 requirements. 3.1.2.7 Access Control 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: (Req. 73) The KRA shall embody a facility for multi-party (at least 2) authorization in support of the release of key material. The following requirements are to provide for strict role separation (Req. 74) The product shall distinguish security-relevant administrative functions from other functions. (Req. 75) The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the product; minimally, this set shall 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. (Req. 76) The product shall restrict the ability to perform a security-relevant administrative function to the security administrative role(s) authorized to use that function. (Req. 77) The product shall be capable of distinguishing the set of users authorized for administrative functions from the set of all other users. (Req. 78) The product shall allow only specifically authorized users to assume only those security administrative roles for which they have been authorized. (Req. 79) 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. (Req. 80) The product shall define a set of security administrative roles that minimally includes system administrator, system operator, crypto officer and audit administrator. (Req. 81) 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. (Req. 82) The system operator shall change the system configuration and run the system. (Req. 83) The crypto officer shall manage the cryptographic keys. (Req. 84) The audit administrator shall manage the audit log and audit profiles. (Req. 85) The product shall associate each security-relevant administrative function with at least one security administrative role. (Req. 86) The product shall enforce checks for valid input values for security- relevant administrative functions as described in the Administrative guidance. 3.1.2.8 Authentication of Received Transactions Same as Level 1. 3.1.2.9 Non Repudiation Level 2 requires additional capabilities to prove the origin of transmissions to allow recipients to counter the threat of an adversary spoofing as a Key Recovery Agent. All Level 1 requirements and the following: (Req. 87) The product shall generate evidence of origin for transmitted key recovery requests or responses. (Note: The above requirement shall also [include?] the reliable time stamp service to include the time in the evidence.) (Req. 88) The product shall provide a capability to verify the evidence of origin of information to the recipient. (Req. 89) 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). (Req. 90) The product shall provide the originator with the ability to request evidence of receipt on information. 3.1.2.10 Protection of Trusted Security Functions All Level 1 requirements and the following: (Req. 91) 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. (This communication path is generally called a trusted path.) (Req. 92) The local human users shall have the ability to initiate communication via the trusted path. (Req. 93) The product shall require the use of the trusted path for initial user (i.e., KRA operator) authentication. (Req. 94) 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. (Req. 95) The product shall preserve a secure state when the abstract machine tests fail. 3.2 Key Recovery Information Generator 3.2.1 Level 1 - Medium Assurance Key Recovery Information Generator 3.2.1.1 Cryptographic Functions (Req. 96) All cryptographic modules shall be FIPS 140-1, Level 1 compliant. 3.2.1.2 Cryptographic Algorithms (Req. 97) 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). 3.2.1.3 Confidentiality This requirement is intended to minimize the vulnerability created by the key recovery mechanism. The key recovery mechanism should not be weaker and thus easier to attack than the original encryption mechanism. (Req. 98) The strength of the algorithm used to protect the key recovery information shall be greater than or equal to the maximum strength of the encryption or key management algorithms employed for data encryption or for generation of the keys being recovered. 3.2.1.4 Integrity These requirements counter the threat of an outsider corrupting the key recovery information. (Req. 99) The KRI Generator shall generate an integrity value for the KRI. (Req. 100) The KRI Generator shall associate the key recovery information with the encrypted data. (Req. 101) The KRI Generator shall generate an integrity value for the association of the key recovery information to the data. As an example, a key recovery scheme that includes a keyed message digest computed on the KRI using the data encryption key meets all of the above three integrity requirements. Requirement 99 is met since the keyed message digest provides integrity. Requirement 100 is met by the unambiguous placement of KRI and encrypted data as defined by the protocol (e.g., fixed location, pointer, tagged information, etc.). Requirement 101 is met since the same key is used to calculate or verify the keyed message digest and to decrypt the data, which ensures the integrity of the association between the KRI and the encrypted data. 3.2.1.5 Identification and Authentication (Req. 102) All cryptographic modules shall implement role-based authentication. (Req. 103) One of the roles shall be the system administrator role. 3.2.1.6 Access Control (Req. 104) The KRI Generator shall allow only the system administrator to configure the key recovery mechanism. (Req. 105) At a minimum, the configurations shall include activation and deactivation of the key recovery mechanism. 3.2.2 Level 2 - High Assurance Key Recovery Information Generator 3.2.2.1 Cryptographic Functions (Req. 106) All cryptographic modules shall be FIPS 140-1, Level 2 compliant. 3.2.2.2 Cryptographic Algorithms Same as Level 1. 3.2.2.3 Confidentiality Same as Level 1. 3.2.2.4 Integrity All of Level 1 requirements and the following: (Req. 107) The product shall provide the capability for the decryptor to verify that the key recovery information can be successfully used to decrypt the data. 3.2.2.5 Identification and Authentication Same as Level 1. 3.2.2.6 Access Control Same as Level 1. 3.3 Key Recovery Information Delivery No Security requirements. 3.4 Key Recovery Information Acquisition No security requirements. 3.5 Key Recovery Information Validator 3.5.1 Level 1 - Medium Assurance Key Recovery Information Validator 3.5.1.1 Cryptographic Functions (Req. 108) All cryptographic modules shall be FIPS 140-1, Level 1 compliant. 3.5.1.2 Cryptographic Algorithms (Req. 109) 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). 3.5.1.3 Integrity 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. (Req. 110) Prior to decrypting the data, the KRI validator shall verify that the KRI acquired was that intended by the KRI generator. (Req. 111) 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. (Req. 112) 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 3.5.2.1 Cryptographic Functions (Req. 113) All cryptographic modules shall be FIPS 140-1, Level 2 compliant. 3.5.2.2 Cryptographic Algorithms Same as Level 1. 3.5.2.3 Integrity 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: (Req. 114) 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. (Req. 115) A KRI Generator Function in the receiving cryptographic end system shall generate accurate key recovery information for received encrypted data. (Req. 116) 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 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 3.6.1.1 Cryptographic Functions (Req. 117) All cryptographic modules shall be compliant with FIPS 140-1, Level 2 or higher. 3.6.1.2 Cryptographic Algorithms (Req. 118) The key recovery requests and responses shall be implemented so that only FIPS approved algorithms are required to use them. The implementation of these algorithms shall conform to the applicable FIPS standard(s). 3.6.1.3 Confidentiality (Req. 119) The requestor shall protect key recovery information received and/or stored against disclosure to unauthorized individuals. (Note: Storing the data encrypted and implementing access controls is one way to meet this requiremen.t) (Req. 120) 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.) (Req. 121) 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 (Req. 122) The product shall apply source 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. (Req. 123) 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 (Req. 124) The product shall be capable of generating an audit record for the following events: * Start-up and shutdown of the audit functions; and * All auditable events as defined in the functional components included in this standard. (Req. 125) 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. (Req. 126) The following actions shall be audited. The keys shall not be included in the audit: * Requests, responses, and other transactions generated by the product, including key recovery responses; and * Requests, responses, and other transactions received by the product, including key recovery requests. (Req. 127) 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 * Other information, as described in the functional component audit events (Req. 128) The product shall be able to generate a human understandable presentation of any audit data stored in the permanent audit trail. (Req. 129) The audit trail shall not store the old or new authentication information (e.g., password) (Req. 130) The product shall be able to associate each auditable event with the identity of the user that caused the event. (Req. 131) The product shall provide the authorized administrator with the ability to empty the audit trail. (Note: emptying the audit trail means backup and delete). (Req. 132) 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.) (Req. 133) The product shall store generated audit records in a permanent audit trail. (Req. 134) 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 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). (Req. 135) The product shall provide functions for initializing and modifying user authentication data. (Req. 136) The product shall restrict the use of these functions on the user personnel authentication data for any user to the authorized administrator. (Req. 137) 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.) (Req. 138) The product shall protect authentication data that is stored in the product from unauthorized observation, modification, and destruction. (Req. 139) 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.) (Req. 140) 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). (Req. 141) The product shall authenticate any user's claimed identity prior to performing any functions on the user's behalf. (Req. 142) The product shall uniquely identify each user before performing any actions requested by the user. (Req. 143) 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.) 3.6.1.7 Access Control 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. (Req. 144) The product shall verify the association of the response to an outstanding request. (Req. 145) 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. (Req. 146) The product shall ensure that security features are always invoked and cannot be bypassed. (Req. 147) The product shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. (Req. 148) The product shall enforce separation between the security domains of subjects in the system. 3.6.1.8 Authentication of Received Transactions (Req. 149) The product shall verify the source of received transactions. (Req. 150) The product shall verify the integrity of received transactions. (Req. 151) The product shall decrypt the received transactions which are encrypted. 3.6.1.9 Non-Repudiation (Req. 152) The product shall be able to provide reliable time stamps for its own use. (Note: We want to rely more on the KRA for time. But, having a requestor time stamp does not hurt.) (Req. 153) 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.) 3.6.1.10 Protection of Trusted Security Functions (Req. 154) Before establishing a session with a user, the product shall display an advisory warning message regarding unauthorized use of the product. (Req. 155) 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". (Req. 156) The product shall restrict the capability to modify the warning message to the authorized administrator. (Req. 157) Upon successful session establishment, the product shall display the date, time, method, and location of the last successful session establishment to the user. (Req. 158) 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. (Req. 159) The data specified above shall not be removed without user intervention. 3.6.2 Level 2 - High Assurance 3.6.2.1 Cryptographic Functions (Req. 160) All cryptographic modules shall be compliant with FIPS 140-1, Level 3 or higher. 3.6.2.2 Cryptographic Algorithms Same as Level 1. 3.6.2.3 Confidentiality Same as level 1. 3.6.2.4 Integrity Same as level 1. 3.6.2.5 Audit Includes all the requirements of Level 1 and the following: (Req. 161) 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. (Req. 162) The product shall provide the authorized administrator with the ability to manage the audit trail at any time during the operation of the product. (Req. 163) The following actions shall be auditable: * Execution of the tests of the underlying machine and the results of the tests; * All attempted uses of the trusted path functions; * Identification of the initiator and target of the trusted path; * Attempts to provide invalid inputs for administrative functions; and * 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 All Level 1 requirements and the following: (Req. 164) The product shall support and token based authentication. The token shall meet FIPS 140-1 Level 2 requirements. 3.6.2.7 Access Control All Level 1 requirements and the following: (Req. 165) Two or more users shall be required to request the recovery information from a KRA. (Req. 166) 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 Same as Level 1. 3.6.2.9 Non Repudiation Includes the Level 1 requirements and the following: (Req. 167) 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.) (Req. 168) The product shall provide a capability to verify the evidence of origin of information to the recipient. (Req. 169) 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). (Req. 170) 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 All Level 1 requirements and the following: (Req. 171) 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. (Req. 172) The local human users shall have the ability to initiate communication via the trusted path. (Req. 173) The product shall require the use of the trusted path for initial user authentication. (Req. 174) 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. (Req. 175) 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 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 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 Registration Agent 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. Integrity/Authenticity 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. The Registration Agent should verify authentication and integrity services for the received product information. The Registration Agent should apply authentication and integrity services to the product information it transmits. The Registration Agent should ensure that the product information it maintains is not modified by unauthorized parties. Licensing Agent Licensing Agents perform compliance audits of the KRAs to ensure that the KRAs operate in accordance with the KRA's stated policy. Authentic Public Key Source (APKS AKA Public Key Infrastructure (PKI)) Standards The APKS should carry out transactions in accordance with the Minimum Interoperability Specifications for PKI Components (MISPC) Security/Certificate Policy: The security of PKI and the degree to which the binding between an entity (subject or subscriber) and public key can be trusted, is determined by the Certificate Policy. Certificate Policy is defined and described in Certificate Policy Framework. Using this Framework, NIST has developed Baseline Security Requirements. NIST plans to enhance these for up to three more strictly superior policies. Thus, in order to define the security requirements for the APKS, we only need to select the proper certificate policy. Please note the certificate policy security requirements are quite comprehensive. For details, see IETF PKIX Part IV: Certificate Policy Framework. For Level 1, the APKS should meet the medium Certificate Policy. For Level 2, the APKS should meet the high Certificate Policy. 4 Assurance Requirements The assurance in a KRS compliant product can be achieved using the Common Criteria Evaluation Assurance Levels (EAL). The Common Criteria (CC) defines seven hierarchical assurance levels EAL1 through EAL7. The Common Criteria assurance levels may be overkill 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. (Req. 176) 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. (Req. 177) 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