2.  Security Requirements
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 compliant. 

	2.1.1.2    Cryptographic Algorithms
2.1.1.2.1	The key recovery scheme shall be at least based on using only FIPS algorithms.  The implementation of these algorithms shall conform to the applicable FIPS standard(s).

2.1.1.3 Confidentiality
2.1.1.3.1  The KRA shall protect 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.4  Audit. 
2.1.1.4.1  The product/system shall be able to generate an audit record of the following auditable events: 
	a) Start-up and shutdown of the audit functions; and
b) 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:
a)	Any specific operation performed to process audit data stored in the audit trail. 
b)	All requests to use authentication data management mechanisms.
c)	All modifications to the audit configuration that occur while the audit collection functions are operating.
d)	All requests to access user authentication data
e)	Any use of the authentication mechanism.  The authentication information shall not be stored in the audit trail.
f)	All attempts to use the user identification mechanism, including the user identity provided. 
g)	Any attempt to perform an operation on the audit trail. 
h)	Use of a security-relevant administrative function;
i)	Explicit requests to assume the security administrative role;
j)	The allocation of a function to a security administrative role. 
k)	The addition or deletion of a user to/from a security administrative role. 
l)	The association of a security-relevant administrative function with a specific security administrative role.
	
2.1.1.4.3  The following actions shall be auditable, if applicable.  The keys shall not be included in the audit:
a) Requests, responses, and other transactions generated by the product/system
		b) Requests, responses, and other transactions received by the product/system

2.1.1.4.4 The product/system shall record within each audit record at least the following information: 
a) Date and time of the event, type of event, subject (user) identity, and success or failure of the event; and 
b) Other information, as described in the functional component audit events (FAU_GEN.1.2)

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

2.1.1.4.6  The product/system shall be able to associate any auditable event with the identity of the user that caused the event. (FAU_GEN.2.1)

2.1.1.4.7  The product/system shall provide the authorized administrator with the ability to empty the audit trail. (FAU_MGT.1.1)

2.1.1.4.8  The product/system 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.9  The product/system 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)

2.1.1.4.10  The product/system shall store generated audit records in a permanent audit trail. 
	2.1.1.5  Identification and Authentication
2.1.1.5.1  The product/system shall provide functions for initializing and modifying user authentication data. (FIA_ADA.3.1)

2.1.1.5.2  The product/system shall restrict the use of these functions on the user authentication data for any user to the authorized administrator. (FIA_ADA.3.2)

2.1.1.5.3  The product/system 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)

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

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

2.1.1.5.6  After the termination of a user session establishment process, the product/system 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/system shall authenticate any user's claimed identity prior to performing any functions for the user. (FIA_UAU.1.1)

2.1.1.5.8  The product/system shall uniquely identify each user before performing any actions requested by the user. (FIA_UID.2.1)

	2.1.1.6  Access Control
2.1.1.6.1  The product/system shall verify applicable authentication and integrity services for the received transactions as determined by the standard compliant protocol. (FPT_ACP.1.1)

2.1.1.6.2  The product/system 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/system shall apply applicable 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/system 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 specified in the request.

2.1.1.6.6  The product/system shall ensure that security policy enforcement functions are invoked and succeed before any security-related operation is allowed to proceed. 
(FPT_RVM.1.1)

2.1.1.6.7  The product/system 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/system shall enforce separation between the security domains of subjects in the system. (FPT_SEP.1.2)

2.1.1.6.9  The product/system shall distinguish 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/system; 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/system 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/system 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)

2.1.1.6.12  The product/system shall be capable of distinguishing the set of users authorized for administrative functions from the set of all other users. (FPT_TSA.2.4)

2.1.1.6.13 The product/system shall allow only specifically authorized users to assume the security administrative role. (FPT_TSA.2.5)

2.1.1.6.14  The product/system shall require an explicit request to be made in order for an authorized user to assume the security administrative role. (FPT_TSA.2.6)
		2.1.1.7  Non-Repudiation
2.1.1.7.1 The KRA shall be able to generate evidence of receipt for received transactions. (FCO_NRR.2.1)

2.1.1.7.2  The KRA shall be able to generate evidence of receipt of registration or deposit of key recovery information from users.

2.1.1.7.3  The KRA shall be able to generate evidence of receipt of requests from requestor.  

		2.1.1.8 Availability
2.1.1.8.1 The KRA shall provide a secure replication of any key recovery information stored. 

	2.1.1.9  Protection of Trusted Security Functions
2.1.1.9.1 Before establishing a user session, the product/system shall display an advisory warning message regarding unauthorized use of the product/system. (FTA_TAB.2.1)

2.1.1.9.2  The default advisory warning message displayed by the product/system 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/system 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/system shall display the date, time, method, and location of the last successful session establishment to the user. (FTA_TAH.1.1)

2.1.1.9.5  Upon successful session establishment, the product/system 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 user intervention. (FTA_TAH.1.3)

		2.1.1.10 Policy
2.1.1.10.1 The KRA shall have a written policy based on the KRA Policy Framework.  It shall operate in accordance with this policy.
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 compliant. 

2.1.2.2  Cryptographic Algorithms
Same as Level 1

2.1.2.3 Confidentiality
	All level 1 requirements and;
2.1.2.3.1  The KRA shall prevent any single user or mechanism from compromising the confidentiality of the key recovery information. 

		2.1.2.4  Audit
Includes all the requirements of Level 1 and:

2.1.2.4.1  The product/system 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/system shall provide the authorized administrator with the ability to manage the audit trail at any time during the operation of the product/system. (FAU_MGT.4.2)

2.1.2.4.3  The following additional actions shall be auditable:
	a) Any specific operation performed to process audit data stored in the audit trail. 
		b) Any attempt to read, modify or destroy the audit trail.
	c) All modifications to the audit configuration that occur while the audit collection functions are operating.
		d) Execution of the tests of the underlying machine and the results of the tests. 
		e) All attempted uses of the trusted path functions.
		f) Identification of the initiator and target of the trusted path.
		g) Attempts to provide invalid inputs for administrative functions
	h) 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.4.5  The product/system shall restrict access to the audit trail to the authorized administrator. (FAU_PRO.1.1)
		2.1.2.5  Identification and Authentication
Same as Level 1

		2.1.2.6 Access Control 
2.1.2.6.1  The product/system shall distinguish security-relevant administrative functions from other functions. (FPT_TSA.3.1)

2.1.2.6.2  The set of security-relevant administrative functions shall include all functions necessary to install, configure, and manage the product/system; 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/system 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.3  The product/system 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.4  The product/system 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.5  The product/system 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.6  The product/system 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.7  The product/system 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.8  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.9  The system operator shall change system configuration and run the system.

2.1.2.6.10  The crypto officer shall manage the cryptographic keys.

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

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

2.1.2.6.13  The product/system 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
Includes the Level 1 requirements and;

2.1.2.7.1 The product/system shall generate evidence of origin for transmitted key recovery requests or responses. (FCO_NRO.1.1)

2.1.2.7.2 The product/system 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/system 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/system 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
2.1.2.9.1  The product/system 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/system shall require the use of the trusted path for initial user authentication. (FTP_TRP.1.3)

2.1.2.9.4  The product/system 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/system shall preserve a secure state when abstract machine tests fail. (FPT_FLS.1.1)
2.1.2.10  Policy
Same as Level 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 2 compliant. 

	2.1.1.2    Cryptographic Algorithms
2.1.1.2.2	The key recovery scheme shall be at least based on using only  FIPS algorithms.  The implementation of these algorithms shall conform to the applicable FIPS standard(s).
Note: Please note that making this level 2 will rule out Win95 type clients
	
2.2.1.3  Confidentiality
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
2.2.1.4.1  The key recovery information shall provide source authentication.

2.2.1.5  Key Recovery Functionality
2.2.1.5.1  The End User Products Key Recovery mechanism can be activated/deactivated by the system administrator.

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.1.1.2    Cryptographic Algorithms
2.1.1.2.1 The key recovery scheme shall be at least based on using only  FIPS algorithms.  The implementation of these algorithms shall conform to the applicable FIPS standard(s).

2.2.2.3  Confidentiality
2.2.2.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.2.4 Integrity/Authenticity
2.2.2.4.1  The key recovery information shall provide source authentication

2.2.2.5 Key Recovery Functionality
2.2.2.5.1  The End User Products Key Recovery mechanism is always activated.

2.3  Registration Agent.  Registration Agents should protect all sensitive information from modification. 

		2.3.1  Non- Repudiation
2.3.1.1 The RA shall be able to generate evidence of receipt for received transactions.

	2.3.2 Integrity
2.3.2.1	The RA shall be able to provide proof that information maintained has not been altered. 

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