2. Security Requirements The security requirements for the KRA and for the Requestor have been defined to allow a variety of product architectures. These include using a monolith product on which no other software/firmware can be loaded, using a monolith product on which other software/firmware can be loaded, using a layered product that has a distinct operating system, application, and cryptographic module. The requirements for the KRA and the Requestor have been defined so that all of these architectures can be evaluated. This is especially true of the requirements in the following areas: Audit, Identification and Authentication, some of the Access Control, and Protection of Trusted Security Functions. Furthermore, the product architecture may imply some of the requirements do not apply since the threat a requirement is supposed to mitigate does not exist. 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. 2.1. Key Recovery Agent Requirements 2.1.1. Level 1 - Medium Assurance 2.1.1.1. Cryptographic Functions 2.1.1.1.1. All cryptographic modules shall be FIPS 140-1, Level 2 or higher compliant. 2.1.1.2. Cryptographic Algorithms 2.1.1.2.1. The key recovery scheme shall be implemented so that only FIPS approved algorithms are required to use it. The implementation of these algorithms shall conform to the applicable FIPS standard(s). (Note: It was requested that the above section be moved under confidentiality. It is left here is since there are aspects to various schemes that are not related to confidentiality, e.g., source authentication, binding to encrypted data, integrity, etc. After the committee reviews this draft, this note will be deleted.) 2.1.1.3. Confidentiality: These requirements are intended to protect against both the outsider and insider threats. The only insider threat addressed is the unauthorized user. Authorized insider threat is handled elsewhere using audit, role separation, and multi-person control. 2.1.1.3.1. The KRA shall protect all key recovery information stored against disclosure to unauthorized individuals. 2.1.1.3.2. The KRA shall protect key recovery information transmitted against disclosure to parties other than the requestor(s). 2.1.1.3.3. The strength of the algorithm used to protect the key recovery information shall be greater than or equal to the maximum strength of the encryption or key management algorithms used for usage or generation of the keys being recovered. 2.1.1.4. Audit These requirements are used to create a log of information to allow oversight by a security officer to detect unauthorized operations by a key recovery agent. 2.1.1.4.1. The product shall be capable of generating an audit record for the following events: Start-up and shutdown of the audit functions; and All auditable events as defined in the functional components included in this standard; (FAU_GEN.1.1) 2.1.1.4.2. The following actions shall be auditable: Any specific operation performed to process audit data stored in the audit trail. (Note: This include backup and deletion of audit trail) Any attempt to read, modify or destroy the audit trail. All requests to use authentication data management mechanisms. All modifications to the audit configuration that occur while the audit collection functions are operating. All requests to access user authentication data Any use of an authentication mechanism. (e.g. login) The authentication information shall not be stored in the audit trail. All attempts to use the user identification mechanism, including the user identity provided. Any attempt to perform an operation on the audit trail. Use of a security-relevant administrative function; Explicit requests to assume the security administrative role; The allocation of a function to a security administrative role. The addition or deletion of a user to/from a security administrative role. The association of a security-relevant administrative function with a specific security administrative role. 2.1.1.4.3. The following actions shall be audited. The keys shall not be included in the audit: Requests, responses, and other transactions generated by the product, including key recovery responses. Requests, responses, and other transactions received by the product, including key recovery requests. 2.1.1.4.4. The product shall record within each audit record at least the following information: Date and time of the event, type of event, subject (user) identity, and success or failure of the event; and Other information, as described in the functional component audit events (FAU_GEN.1.2) 2.1.1.4.5. The product shall be able to generate a human understandable presentation of any audit data stored in the permanent audit trail. (FAU_POP.1.1) 2.1.1.4.6. The audit trail shall not store the old or new authentication information (e.g., password) 2.1.1.4.7. The product shall be able to associate each auditable event with the identity of the user that caused the event. (FAU_GEN.2.1) 2.1.1.4.8. The product shall provide the authorized administrator with the ability to empty the audit trail. (FAU_MGT.1.1) (Note: emptying the audit trail means backup and delete). 2.1.1.4.9. The product shall be able to include or exclude auditable events from the set of audited events based on the following attributes: User identity, and/or Event Type (FAU_SEL.1.1) (Note: The requirement applies to the auditable events only. The always audited events must never be excluded or excludable from the set of audited events.) 2.1.1.4.10. The product shall store generated audit records in a permanent audit trail. (FAU_STG.1.1) 2.1.1.4.11. The product shall restrict access to the audit trail to the authorized administrator. (FAU_PRO.1.1) (Note: This requirement implies providing integrity to the audit trail) 2.1.1.5. Identification and Authentication These requirements permit the unique identification of key recovery agent personnel. This facilitates individual accountability via audit functions and access controls. Requirements are levied on the strength of the authentication mechanism and the robustness of the authentication mechanism against attacks by rogue key recovery agent personnel. These requirements do not apply to electronic transactions (requests and responses). The electronic transactions may be identified and authenticated (if the scheme permits) using the access control policy. 2.1.1.5.1. The product shall provide functions for initializing and modifying KRA personnel authentication data. (FIA_ADA.3.1) 2.1.1.5.2. The product shall restrict the use of these functions on the KRA personnel authentication data for any user to the authorized administrator. (FIA_ADA.3.2) 2.1.1.5.3. The product shall allow authorized KRA personnel to use these functions to modify their own authentication data in accordance with the identification and authentication policy. (FIA_ADA.3.3) (Note: The identification and authentication policy is to permit each person to change his/her authentication information.) 2.1.1.5.4. The product shall protect from unauthorized observation, modification, and destruction authentication data that is stored in the product. 2.1.1.5.5. The product shall be able to terminate the KRA personnel session establishment process after five unsuccessful authentication attempts. (FIA_AFL.1.1) (Note: If the product terminates the session after less than five unsuccessful attempts, the product meets the above requirement) 2.1.1.5.6. After the termination of a KRA user session establishment process, the product shall be able to disable the user account until account is enabled by an authorized administrator (i.e., security administrator). (FIA_AFL.1.2) 2.1.1.5.7. The product shall authenticate any KRA user's claimed identity prior to performing any functions on the user's behalf. (FIA_UAU.1.1) 2.1.1.5.8. The product shall uniquely identify each KRA user before performing any actions requested by the user. (FIA_UID.2.1) 2.1.1.5.9. The product shall provide a mechanism to verify that secrets (i.e., authentication information such as passwords) meet the FIPS PUB 112 "Password Usage" and Department of Defense Password Management Guideline (CSC- STD-002-85). (Note: The above requirement implies that the product (as opposed to procedural means and management instructions) will enforce the password length, aging, etc. type requirements. If we do not want product to enforce the requirement, the above requirement should be deleted) 2.1.1.6. Access Control These requirements provide countermeasures against entities spoofing as an authorized requestor or end user. The requirements in this section ensure that the product implements and enforces the scheme claimed. In other words, before performing any key recovery related action, the product must validate security services (e.g., confidentiality, integrity, source authentication, etc.). Similarly, the product must apply the security services according to the scheme. 2.1.1.6.1. The product shall verify authentication and integrity services for the received transactions as determined by the standard compliant protocol (scheme). (FPT_ACP.1.1) 2.1.1.6.2. The product shall decrypt the received transactions if the standard compliant protocol requires the transaction to be encrypted. (FPT_ACP.1.2) 2.1.1.6.3. The product shall apply authentication, integrity, and confidentiality services to all transactions (i.e., requests and responses) as determined by the standard compliant protocol. (FPT_ACP.1.3) 2.1.1.6.4. The product shall release the keys only to authorized users. 2.1.1.6.5. The KRA shall release the 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), if applicable to the standard compliant protocol. 2.1.1.6.6. The product shall ensure that security policy enforcement functions are invoked and succeed before any security-related operation is allowed to proceed. (FPT_RVM.1.1) (Note: This requirement simply states that the product security features must be always invoked, and not bypassable) 2.1.1.6.7. The product shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. (FPT_SEP.1.1) 2.1.1.6.8. The product shall enforce separation between the security domains of subjects in the system. (FPT_SEP.1.2) 2.1.1.6.9. The product shall distinguish between security-relevant administrative functions from other functions. (FPT_TSA.2.1) 2.1.1.6.10. The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the product; minimally, this set shall include assignment/deletion of authorized users from security administrative roles, association of security-relevant administrative commands with security administrative roles, assignment/deletion of subjects whose keys are held, assignment/deletion of parties who may be provided the keys, product cryptographic key management, actions on the audit log, audit profile management, and changes to the system configuration. (FPT_TSA.2.2) 2.1.1.6.11. The product shall restrict the ability to perform security- relevant administrative functions to a security administrative role that has a specific set of authorized functions and responsibilities. (FPT_TSA.2.3) (Note: The term security administrative role refers to generic trusted administrative roles. Security administrator role is one, but not the only one, of these security administrative roles.) 2.1.1.6.12. The product shall be capable of distinguishing the set of KRA operators authorized for administrative functions from the set of all other users. (FPT_TSA.2.4) 2.1.1.6.13. The product shall allow only specifically authorized KRA operators to assume the security administrative role. (FPT_TSA.2.5) 2.1.1.6.14. The product shall require an explicit request to be made in order for an authorized KRA operator to assume the security administrative role. (FPT_TSA.2.6) 2.1.1.7. Non-Repudiation These capabilities facilitate trusted time source to further support accountability. 2.1.1.7.1. The product shall be able to provide reliable time stamps for its own use. (FPT_STM.1.1) 2.1.1.7.2. The product shall be able to generate evidence of receipt for received transactions. (FCO_NRR.2.1) (Note: The above requirement means using the reliable time stamp to requirement to put a trusted time stamp on the receipt. Furthermore, this requirement means that the product shall be able to generate evidence of receipt of: registration or deposit of key recovery information from users, and requests from requestor) 2.1.1.8. Availability These requirements are intended to provide the capability for a key recovery agent to recover in the event of a system failure or compromise. They act as a counter to the threat of the unauthorized destruction of the key recovery information or capabilities at the key recovery agent facility. 2.1.1.8.1. The KRA facility shall have the capability to securely replicate any key recovery information stored. (Note: The intent of the above requirement is for continued on-line access in case of a facility failure. In light of that, should this be a requirement on the component since it is a system architecture issue. Please note that the multiple KRAs requirement at Level 2 is to prevent one KRA from compromising key recovery information) 2.1.1.8.2. The KRA facility shall have a secure backup of the key recovery information stored. (Note: The intent of the above requirement is for ability to rebuild the key recovery database in case of KRA system failure. In light of that, should this be a requirement on the component since this a facility operations related issue) 2.1.1.9. Protection of Trusted Security Functions 2.1.1.9.1. Before establishing a session with KRA operator, the product shall display an advisory warning message regarding unauthorized use of the product. (FTA_TAB.2.1) 2.1.1.9.2. The default advisory warning message displayed by the product shall be as follows: "This system shall be used only by authorized personnel and only for authorized key recovery purposes. Violation shall result in criminal prosecution and civil penalties". (FTA_TAB.2.2) 2.1.1.9.3. The product shall restrict the capability to modify the warning message to the authorized administrator. (FTA_TAB.2.3) 2.1.1.9.4. Upon successful session establishment, the product shall display the date, time, method, and location of the last successful session establishment to the KRA operator. (FTA_TAH.1.1) 2.1.1.9.5. Upon successful session establishment, the product shall display the date, time, method, and location of the last unsuccessful attempt to session establishment and the number of unsuccessful attempts since the last successful session establishment. (FTA_TAH.1.2) 2.1.1.9.6. The data specified above shall not be removed without KRA operator intervention. (FTA_TAH.1.3) 2.1.2. Level 2 - High Assurance 2.1.2.1. Cryptographic Functions 2.1.2.1.1. All cryptographic modules shall be FIPS 140-1, Level 3 or higher compliant. 2.1.2.2. Cryptographic Algorithms Same as Level 1 2.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; 2.1.2.3.1. The system shall be designed for multiple KRAs. Two or more KRAs shall be required to obtain the key recovery information. 2.1.2.4. Audit: Level 2 adds a real time alarm to the security officer in the event of the audit trail becoming full to prevent audit data from being lost. It also requires the auditing of additional events consistent with the additional security requirements (i.e. trusted path) added at Level 2. Includes all the requirements of Level 1 and; 2.1.2.4.1. The product shall generate an alarm to the authorized administrator if the size of the audit data in the audit trail exceeds a pre- defined limit. (FAU_MGT.4.1) 2.1.2.4.2. The product shall provide the authorized administrator with the ability to manage the audit trail at any time during the operation of the product. (FAU_MGT.4.2) 2.1.2.4.3. The following actions shall be auditable: Execution of the tests of the underlying machine and the results of the tests. All attempted uses of the trusted path functions. Identification of the initiator and target of the trusted path. Attempts to provide invalid inputs for administrative functions The invocation of the non-repudiation service. The audit event shall include identification of the information, the destination, and a copy of the evidence provided. The event shall exclude all private and secret keys in encrypted or unencrypted form. 2.1.2.5. Identification and Authentication Level 2 enhances assurance by supporting a hardware token. This provides an additional countermeasure to the threat of an attack on the authentication mechanism and the subsequent unauthorized access to key recovery information or critical functions. All Level 1 requirements and the following; 2.1.2.5.1. The product shall support a token based authentication. The token shall meet FIPS 140-1 Level 2 requirements. 2.1.2.6. Access Control Level 2 requires multi-party access controls for release of key recovery information and establishes roles and responsibilities for key recovery facility personnel as additional countermeasures to the threat of a single rogue key recovery agent. All Level 1 requirements and the following; 2.1.2.6.1. The KRA shall embody a facility for multi-party (at least 2) authorization in support of the release of key material. (Note: The following requirements are to provide for strict role separation) 2.1.2.6.2. The product shall distinguish security-relevant administrative functions from other functions. (FPT_TSA.3.1) 2.1.2.6.3. The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the product; minimally, this set shall include assignment/deletion of authorized users from security administrative roles, association of security-relevant administrative commands with security administrative roles, assignment/deletion of subjects whose keys are held, assignment/deletion of parties who may be provided the keys, product cryptographic key management, actions on the audit log, audit profile management, and changes to the system configuration. (FPT_TSA.3.2) 2.1.2.6.4. The product shall restrict the ability to perform a security- relevant administrative function to the security administrative role(s) authorized to use that function. (FPT_TSA.3.3) 2.1.2.6.5. The product shall be capable of distinguishing the set of users authorized for administrative functions from the set of all other users. (FPT_TSA.3.4) 2.1.2.6.6. The product shall allow only specifically authorized users to assume only those security administrative roles for which they have been authorized. (FPT_TSA.3.5) 2.1.2.6.7. The product shall require an explicit request to assume a specific security administrative role to be made in order for an authorized user to assume that security administrative role. (FPT_TSA.3.6) 2.1.2.6.8. The product shall define a set of security administrative roles that minimally includes security administrator, system operator, crypto officer and audit administrator. (FPT_TSA.3.7) 2.1.2.6.9. The security administrator shall perform the following functions: assignment/deletion of authorized users from security administrative roles, association of security-relevant administrative commands with security administrative roles, assignment/deletion of subjects whose keys are held, and assignment/deletion of parties who may be provided the keys. 2.1.2.6.10. The system operator shall change system configuration and run the system. 2.1.2.6.11. The crypto officer shall manage the cryptographic keys. 2.1.2.6.12. The audit administrator shall manage audit log and audit profiles. 2.1.2.6.13. The product shall associate each security-relevant administrative function with at least one security administrative role. (FPT_TSA.3.8) 2.1.2.6.14. The product shall enforce checks for valid input values for security-relevant administrative functions as described in the Administrative guidance. (FPT_TSU.1.1) 2.1.2.7. Non Repudiation Level 2 requires additional capabilities to prove the origin of transmissions to allow recipients to counter the threat of an adversary spoofing as a Key Recovery Agent. All Level 1 requirements and the following; 2.1.2.7.1. The product shall generate evidence of origin for transmitted key recovery requests or responses. (FCO_NRO.1.1) (Note: The above requirement shall also the reliable time stamp service to include the time in the evidence) 2.1.2.7.2. The product shall provide a capability to verify the evidence of origin of information to the recipient. (FCO_NRO.1.3) 2.1.2.7.3. The product shall provide a capability to verify the evidence of receipt of proof of receipt to the originator of message (i.e., recipient of proof of receipt). (FCO_NRR.2.3) 2.1.2.7.4. The product shall provide the originator the ability to request evidence of receipt on information. (FCO_NRR.2.3) 2.1.2.8. Availability Same as Level 1. 2.1.2.9. Protection of Trusted Security Functions: Same as Level 1 and the following: 2.1.2.9.1. The product shall provide a communication path between itself and local human users that is logically distinct from other communication paths and provides assured identification of its endpoints. (FTP_TRP.1.1) 2.1.2.9.2. The local human users shall have the ability to initiate communication via the trusted path. (FTP_TRP.1.2) 2.1.2.9.3. The product shall require the use of the trusted path for initial user (i.e., KRA operator) authentication. (FTP_TRP.1.3) 2.1.2.9.4. The product shall provide the authorized administrator with the capability to demonstrate the correct operation of the security-relevant functions provided by the underlying abstract machine. (FPT_AMT.1.1) 2.1.2.9.5. The product shall preserve a secure state when abstract machine tests fail. (FPT_FLS.1.1) 2.2. End User Product 2.2.1. Level 1 - Key Recovery Capable End User Products 2.2.1.1. Cryptographic Functions 2.2.1.1.1. All cryptographic modules shall be FIPS 140-1, Level 1 compliant. 2.2.1.2. Cryptographic Algorithms 2.2.1.2.1. The key recovery scheme shall be implemented so that only FIPS approved algorithms are required to use it. The implementation of these algorithms shall conform to the applicable FIPS standard(s). 2.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. 2.2.1.3.1. The strength of the algorithm used to protect the key recovery information shall be greater than or equal to the maximum strength of the encryption or key management algorithms. 2.2.1.4. Integrity/Authenticity These requirements counter the threat of a single end user or an outsider corrupting the key recovery information. 2.2.1.4.1. The end user product shall be capable of generating key recovery information. 2.2.1.4.2. The key recovery information shall provide source authentication. 2.2.1.4.3. The end user product shall be capable of securely binding (i.e., with integrity) the key recovery information to the encrypted communications. 2.2.1.4.4. The end user product shall be capable of verifying the source and integrity of key recovery information 2.2.1.5. Key Recovery Functionality 2.2.1.5.1. The key recovery mechanism in the end user product shall be always activated/deactivated by the system administrator. (Note: The above requirement will be taken out if it appears some place else.) 2.2.2. Level 2 - Mandatory Enforcement of Key Recovery 2.2.2.1. Cryptographic Functions 2.2.2.1.1. All cryptographic modules shall be FIPS 140-1, Level 2 compliant. 2.2.2.2. Cryptographic Algorithms: Same as Level 1 2.2.2.3. Confidentiality: Same as Level 1 2.2.2.4. Integrity/Authenticity: Same as Level 1 2.2.2.5. Key Recovery Functionality 2.2.2.5.1. The key recovery mechanism shall be always activated in the end user product. (Note: The above requirement will be taken out if it appears some place else.) 2.3. Registration Agent. Registration Agents maintain the information on products and their key recovery protocol (scheme). Thus, the requirement on the registration agent is to maintain the integrity of the product information. 2.3.1. Integrity/Authenticity These requirements counter the threat of an adversary spoofing as the registration agent and of unauthorized access to the information and critical functions at the registration agent. 2.3.1.1. The Registration Agent shall verify authentication and integrity services for the received product information. 2.3.1.2. The Registration Agent shall apply authentication and integrity services to the product information it transmits. 2.3.1.3. The Registration Agent shall ensure that the product information it maintains is not modified by unauthorized parties. 2.4. Licensing Agent. Licensing Agents shall perform a compliance audit of the KRA to ensure that the KRA operates in accordance with the KRA's stated policy. 2.5. Requestor The requirements for the requestor are defined with strict operating system and user authentication controls in mind in order to ensure that the requestor system has good security controls for the key recovery information. Thus, the requestor system requires a true operating system (e.g., NT, UNIX, etc.) as opposed to Windows 95 type clients. 2.5.1. Level 1 - Medium Assurance 2.5.1.1. Cryptographic Functions 2.5.1.1.1. All cryptographic modules shall be FIPS 140-1, Level 2 or higher compliant. 2.5.1.2. Cryptographic Algorithms 2.5.1.2.1. The key recovery requests and responses shall be implemented so that only FIPS approved algorithms are required to use them. The implementation of these algorithms shall conform to the applicable FIPS standard(s). 2.5.1.3. Confidentiality 2.5.1.3.1. The requestor shall protect key recovery information received and/or stored against disclosure to unauthorized individuals. 2.5.1.3.2. The requestor shall protect key recovery request (specially the identities of subjects and time periods, if applicable) transmitted against disclosure to parties other than the KRA. 2.5.1.4. Audit 2.5.1.4.1. The product shall be capable of generating an audit record for the following events: Start-up and shutdown of the audit functions; and All auditable events as defined in the functional components included in this standard; (FAU_GEN.1.1) 2.5.1.4.2. The following actions shall be auditable: Any specific operation performed to process audit data stored in the audit trail. (Note: This include backup and deletion of audit trail) Any attempt to read, modify or destroy the audit trail. All requests to use authentication data management mechanisms. All modifications to the audit configuration that occur while the audit collection functions are operating. All requests to access user authentication data Any use of an authentication mechanism. (e.g. login) The authentication information shall not be stored in the audit trail. All attempts to use the user identification mechanism, including the user identity provided. Any attempt to perform an operation on the audit trail. Use of a security-relevant administrative function; Explicit requests to assume the security administrative role; The allocation of a function to a security administrative role. The addition or deletion of a user to/from a security administrative role. The association of a security-relevant administrative function with a specific security administrative role. 2.5.1.4.3. The following actions shall be audited. The keys shall not be included in the audit: Requests, responses, and other transactions generated by the product, including key recovery responses. Requests, responses, and other transactions received by the product, including key recovery requests. 2.5.1.4.4. The product shall record within each audit record at least the following information: Date and time of the event, type of event, subject (user) identity, and success or failure of the event; and Other information, as described in the functional component audit events (FAU_GEN.1.2) 2.5.1.4.5. The product shall be able to generate a human understandable presentation of any audit data stored in the permanent audit trail. (FAU_POP.1.1) 2.5.1.4.6. The audit trail shall not store the old or new authentication information (e.g., password) 2.5.1.4.7. The product shall be able to associate each auditable event with the identity of the user that caused the event. (FAU_GEN.2.1) 2.5.1.4.8. The product shall provide the authorized administrator with the ability to empty the audit trail. (FAU_MGT.1.1) (Note: emptying the audit trail means backup and delete). 2.5.1.4.9. The product shall be able to include or exclude auditable events from the set of audited events based on the following attributes: User identity, and/or Event Type (FAU_SEL.1.1) (Note: The requirement applies to the auditable events only. The always audited events must never be excluded or excludable from the set of audited events.) 2.5.1.4.10. The product shall store generated audit records in a permanent audit trail. (FAU_STG.1.1) 2.5.1.4.11. The product shall restrict access to the audit trail to the authorized administrator. (FAU_PRO.1.1) (Note: This requirement implies providing integrity to the audit trail) 2.5.1.5. Identification and Authentication The requirements in this section are for the identification and authentication of the various requestor personnel. These requirements do not apply to electronic transactions (requests and responses). The electronic transactions may be identified and authenticated (if the scheme permits) using the access control policy. 2.5.1.5.1. The product shall provide functions for initializing and modifying user authentication data. (FIA_ADA.3.1) 2.5.1.5.2. The product shall restrict the use of these functions on the user personnel authentication data for any user to the authorized administrator. (FIA_ADA.3.2) 2.5.1.5.3. The product shall allow authorized users to use these functions to modify their own authentication data in accordance with the identification and authentication policy. (FIA_ADA.3.3) (Note: The identification and authentication policy is to permit each person to change his/her authentication information.) 2.5.1.5.4. The product shall protect from unauthorized observation, modification, and destruction authentication data that is stored in the product. 2.5.1.5.5. The product shall be able to terminate the user session establishment process after five unsuccessful authentication attempts. (FIA_AFL.1.1) (Note: If the product terminates the session after less than five unsuccessful attempts, the product meets the above requirement) 2.5.1.5.6. After the termination of a user session establishment process, the product shall be able to disable the user account until account is enabled by an authorized administrator (i.e., security administrator). (FIA_AFL.1.2) 2.5.1.5.7. The product shall authenticate any user's claimed identity prior to performing any functions on the user's behalf. (FIA_UAU.1.1) 2.5.1.5.8. The product shall uniquely identify each user before performing any actions requested by the user. (FIA_UID.2.1) 2.5.1.5.9. The product shall provide a mechanism to verify that secrets (i.e., authentication information such as passwords) meet the FIPS PUB 112 "Password Usage" and Department of Defense Password Management Guideline (CSC- STD-002-85). (Note: The above requirement implies that the product (as opposed to procedural means and management instructions) will enforce the password length, aging, etc. type requirements. If we do not want the product to enforce the requirement, the above requirement should be deleted) 2.5.1.6. Access Control The requirements under this section are to ensure that the product implements and enforces the transaction security. 2.5.1.6.1. The product shall verify authentication and integrity services for the received transactions as determined by the standard compliant protocol (scheme). (FPT_ACP.1.1) 2.5.1.6.2. The product shall decrypt the received transactions if the standard compliant protocol requires the transaction to be encrypted. (FPT_ACP.1.2) 2.5.1.6.3. The product shall apply authentication, integrity, and confidentiality services to all transactions (i.e., requests) as determined by the standard compliant protocol. (FPT_ACP.1.3) 2.5.1.6.4. 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 right to it expires, whichever occurs earlier. 2.5.1.6.5. The product shall ensure that security policy enforcement functions are invoked and succeed before any security-related operation is allowed to proceed. (FPT_RVM.1.1) (Note: This requirement simply states that the product security features must be always invoked, and not bypassable) 2.5.1.6.6. The product shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. (FPT_SEP.1.1) 2.5.1.6.7. The product shall enforce separation between the security domains of subjects in the system. (FPT_SEP.1.2) 2.5.1.7. Non-Repudiation 2.5.1.7.1. The product shall be able to provide reliable time stamps for its own use. (FPT_STM.1.1) (Note: We want to reply more on the KRA for time. But, having requestor time stamp does not hurt) 2.5.1.7.2. The product shall be able to generate evidence of receipt for received transactions. (FCO_NRR.2.1) (Note: The above requirement means using the reliable time stamp to requirement to put a trusted time stamp on the receipt. Furthermore, this requirement means that the product shall be able to generate evidence of receipt of: registration or deposit of key recovery information from users, and requests from requestor) 2.5.1.8. Protection of Trusted Security Functions 2.5.1.8.1. Before establishing a session with a user, the product shall display an advisory warning message regarding unauthorized use of the product. (FTA_TAB.2.1) 2.5.1.8.2. The default advisory warning message displayed by the product shall be as follows: "This system shall be used only by authorized personnel and only for authorized key recovery purposes. Violation shall result in criminal prosecution and civil penalties". (FTA_TAB.2.2) 2.5.1.8.3. The product shall restrict the capability to modify the warning message to the authorized administrator. (FTA_TAB.2.3) 2.5.1.8.4. Upon successful session establishment, the product shall display the date, time, method, and location of the last successful session establishment to the user (FTA_TAH.1.1) 2.5.1.8.5. Upon successful session establishment, the product shall display the date, time, method, and location of the last unsuccessful attempt to session establishment and the number of unsuccessful attempts since the last successful session establishment. (FTA_TAH.1.2) 2.5.1.8.6. The data specified above shall not be removed without user intervention. (FTA_TAH.1.3) 2.5.2. Level 2 - High Assurance 2.5.2.1. Cryptographic Functions 2.5.2.1.1. All cryptographic modules shall be FIPS 140-1, Level 3 or higher compliant. 2.5.2.2. Cryptographic Algorithms Same as Level 1 2.5.2.3. Confidentiality Level 1 requirements and; 2.5.2.4. Audit: Includes all the requirements of Level 1 and; 2.5.2.4.1. The product shall generate an alarm to the authorized administrator if the size of the audit data in the audit trail exceeds a pre- defined limit. (FAU_MGT.4.1) 2.5.2.4.2. The product shall provide the authorized administrator with the ability to manage the audit trail at any time during the operation of the product. (FAU_MGT.4.2) 2.5.2.4.3. The following actions shall be auditable: Execution of the tests of the underlying machine and the results of the tests. All attempted uses of the trusted path functions. Identification of the initiator and target of the trusted path. Attempts to provide invalid inputs for administrative functions The invocation of the non-repudiation service. The audit event shall include identification of the information, the destination, and a copy of the evidence provided. The event shall exclude all private and secret keys in encrypted or unencrypted form. 2.5.2.5. Identification and Authentication Same as Level 1 and; 2.5.2.5.1. The product shall support and token based authentication. The token shall meet FIPS 140-1 Level 2 requirements. 2.5.2.6. Access Control Same as Level 1 and the following; 2.5.2.6.1. Two or more users shall be required to request the recovery information from a KRA. 2.5.2.6.2. The product shall enforce checks for valid input values for security-relevant administrative functions as described in the Administrative guidance. (FPT_TSU.1.1) 2.5.2.7. Non Repudiation Includes the Level 1 requirements and; 2.5.2.7.1. The product shall generate evidence of origin for transmitted key recovery requests or responses. (FCO_NRO.1.1) (Note: The above requirement shall also the reliable time stamp service to include the time in the evidence) 2.5.2.7.2. The product shall provide a capability to verify the evidence of origin of information to the recipient. (FCO_NRO.1.3) 2.5.2.7.3. The product shall provide a capability to verify the evidence of receipt of proof of receipt to the originator of message (i.e., recipient of proof of receipt). (FCO_NRR.2.3) 2.5.2.7.4. The product shall provide the originator the ability to request evidence of receipt on information. (FCO_NRR.2.3) 2.5.2.8. Protection of Trusted Security Functions: Same as Level 1 and the following: 2.5.2.8.1. The product shall provide a communication path between itself and local human users that is logically distinct from other communication paths and provides assured identification of its endpoints. (FTP_TRP.1.1) 2.5.2.8.2. The local human users shall have the ability to initiate communication via the trusted path. (FTP_TRP.1.2) 2.5.2.8.3. The product shall require the use of the trusted path for initial user authentication. (FTP_TRP.1.3) 2.5.2.8.4. The product shall provide the authorized administrator with the capability to demonstrate the correct operation of the security-relevant functions provided by the underlying abstract machine. (FPT_AMT.1.1) 2.5.2.8.5. The product shall preserve a secure state when abstract machine tests fail. (FPT_FLS.1.1) 2.6. Authentic Public Key Source (APKS AKA Public Key Infrastructure (PKI)) 2.6.1. Standards 2.6.1.1. The APKS shall carry out transactions in accordance with the Minimum Interoperability Specifications for PKI Components (MISPC) 2.6.2. Security/Certificate Policy: The security of PKI and the degree to which the binding between an entity (subject or subscriber) and public key can be trusted, is determined by the Certificate Policy. Certificate Policy is defined and described in Certificate Policy Framework. Using this Framework, NIST has developed Baseline Security Requirements. NIST plans to enhance these for up to three more strictly superior policies. Thus, in order to define the security requirements for the APKS, we only need to select the proper certificate policy. Please note the certificate policy security requirements are quite comprehensive. For details, see IETF PKIX Part IV: Certificate Policy Framework. 2.6.2.1. For Level 1, the APKS shall meet the medium Certificate Policy. For Level 2, the APKS shall meet the high Certificate Policy. ??