Protection Profile for Enterprise Management

Version	Date	Comment
2.0	2025-07-18	Initial draft (version numbering chosen for alignment with the ESM family of modules)

Table 2: Auditable Events for Mandatory Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_ALT_EXT.1

Type of alert	Identity of system or agent that sent alert
FAU_GEN.1

No events specified	N/A
FAU_SAR_EXT.1

No events specified	N/A
FAU_SEL_EXT.1

TBD	No additional information
FAU_STG.1

No events specified	N/A
FAU_STG_EXT.1

No events specified	N/A
FCS_CKM.1/AKG

No events specified	N/A
FCS_CKM.1/SKG

No events specified	N/A
FCS_CKM.6

No events specified	N/A
FCS_COP.1/AEAD

No events specified	N/A
FCS_COP.1/Hash

No events specified	N/A
FCS_COP.1/KeyedHash

No events specified	N/A
FCS_COP.1/SigGen

No events specified	N/A
FCS_COP.1/SigVer

No events specified	N/A
FCS_RBG.1

No events specified	N/A
FCS_STG_EXT.1

No events specified	N/A
FDP_IFC.1

TBD	No additional information
FDP_IFF.1

TBD	No additional information
FDP_ITC.1

TBD	No additional information
FIA_ENR_EXT.2

No events specified	N/A
FIA_UAU.1

No events specified	N/A
FMT_MEC_EXT.1

Issuance of command to perform function	Command sent and identity external recipients
Change of policy settings	Policy changed and value or full policy
FMT_MOF.1

Issuance of command to perform function	Command sent and identity external recipients
Change of policy settings	Policy changed and value or full policy
FMT_SMF.1/INTERNAL

Success or failure of function	No additional information
FMT_SMF.1/MANAGED

No events specified	N/A
FMT_SMR.1

No events specified	N/A
FPT_API_EXT.1

No events specified	N/A
FPT_LIB_EXT.1

No events specified	N/A

FAU_ALT_EXT.1 Server Alerts

FAU_ALT_EXT.1.1

This SFR is written as if the TOE will always communicate with remote entities. If we are also considering a use case where it's a centralized server that manages the behavior of something locally, relevant changes may need to be made in both the SFR and EAs. The TSF shall alert the administrators in the event of any of the following:

Change in management status (i.e., adding system or agent to management, removing system or agent from management)
Failure to apply policy or configuration
Failure to respond to heartbeat or check in during designated reporting interval
[selection: [assignment: other events], no other events]

Application Note: An alert can be defined as anything providing straightaway notice to the administrator. An alert is different from an audit record, however the fact that an alert was sent should be audited per FAU_GEN.1. Email, pop-up notifications, or other methods are acceptable forms of alerts.

The expectation of this requirement is that the TOE has a mechanism to configure the heartbeat or reporting interval of systems or agents that are under its management. The inability of the system or agent to maintain this mechanism should be flagged by the TSF as anomalous behavior requiring further examination and potential corrective action. This necessarily includes a mechanism to identify the assets under management and when they are added or removed.

FAU_GEN.1 Audit Data Generation

FAU_GEN.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate audit data of the following auditable events:

Startup and shutdown of the audit functions

All auditable events for the [not specified] level of audit;

[

All administrative actions

Commands issued to managed [selection: system, agent]

Specifically defined auditable events listed in Table 2

[selection:
Auditable events defined in Table 15 for Implementation-Based SFRs,
Auditable events defined in Table 17 for Selection-Based SFRs,
Auditable events for Functional Package for Secure Shell (SSH), version 2.0,
Auditable events for Functional Package for Transport Layer Security (TLS), version 2.1,
Auditable events for Functional Package for X.509, version 1.0,
no other events
]

].

Application Note:

This requirement outlines the events for which audit data must be generated by either the TOE or by its underlying platform. It is acceptable for this requirement to be met through a combination of platform-provided and TOE-provided audit functions, so long as the full set of required events are generated and include the required data.

Item a above requires all administrative actions to be auditable. Administrative actions refer to any management functions specified by FMT_MOF.1. Thus no additional specification for the auditability of these actions is specified in Table 2 aside from those that require additional record content.

Item b above includes any commands that are performed against a managed system or agent. This need not go to the granularity of individual API calls, but it is expected that there is sufficient data to be clear to an administrator what actions the TOE may be performing against an external entity or what data it may be receiving from it.

Depending on the specific requirements selected by the ST author from SFR, optional requirements, selection-based requirements, and objective requirements, the ST author should include the appropriate auditable events from Table t-audit-optional, Table 17, and Table t-audit-objective in the ST for the requirements selected.

In item d above, "startup and shutdown of the audit functions" may refer to the independent startup and shutdown of audit functionality specifically, or it may refer to startup and shutdown of the TOE itself, if auditing cannot be disabled separately from the operation of the TOE. It is outside the scope of the TOE boundary to consider the need to audit the startup and shutdown of auditing functionality used by the TOE platform, as this would be an inherent function of the host operating system.

The following table contains the events enumerated in the auditable events tables for the TLS Functional Package. Inclusion of these events in the ST is subject to selection above, inclusion of the corresponding SFRs in the ST, and support in the FP as represented by a selection in the FP audit table. This list is included here for reference.

Table 3: Auditable Events for Functional Packages

Requirement	Auditable Events	Additional Audit Data Contents
FCS_TLSC_EXT.1	Failure to establish a TLS session.	Reason for failure.
FCS_TLSC_EXT.1	Failure to verify presented identifier.	Presented identifier and reference identifier.
FCS_TLSS_EXT.1	Failure to establish a TLS session.	Reason for failure.
FCS_DTLSC_EXT.1	Failure of the certificate validity check.	Issuer Name and Subject Name of certificate.
FCS_DTLSS_EXT.1	Failure of the certificate validity check.	Issuer Name and Subject Name of certificate.

FAU_GEN.1.2

The TSF shall record within the audit data at least the following information:

date and time of the event
type of event
subject identity (if applicable)
and the outcome (success or failure) of the event
additional information in Table 2
[selection:
- additional information defined in Table 15 for Objective SFRs,
- additional information defined in Table 17 for Selection-Based SFRs,
- Auditable events for Functional Package for Secure Shell (SSH), version 2.0,
- Auditable events for Functional Package for Transport Layer Security (TLS), version 2.1,
- Auditable events for Functional Package for X.509, version 1.0,
- no other additional information
]

Application Note: This requirement outlines the information to be included in audit data. All audits must contain at least the information mentioned in FAU_GEN.1.2, but may contain more information. The ST author must identify what audit data is generated by the TOE in its own audit mechanism versus audit data generated by the TOE platform based on the TOE's operation.

Evaluation Activities

FAU_GEN.1.1

TSS

The evaluator shall check the TSS and ensure that it lists all of the auditable events. The evaluator shall check to make sure that every audit event type mandated by the PP is described in the TSS. The evaluator shall verify that for every audit event described in the TSS, the description indicates where the audit event is generated (TSF, TOE platform).

If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the TSF; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).

Guidance

The evaluator shall check the administrative guide and ensure that it lists all of the auditable events. The evaluator shall check to make sure that every audit event type mandated by the PP is described.

The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP including those listed in the management section. The evaluator shall examine the administrative guide and make a determination of which administrative commands are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP.

The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements.

Tests

The evaluator shall test the TOE's ability to correctly generate audit data by having the TOE generate audit data for the events listed in the provided table and administrative actions. This should include all instances of an event. The evaluator shall test that audit data are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit data are generated as expected.

FAU_GEN.1.2

TSS

The evaluator shall check the TSS and ensure that it provides a format for audit data. Each audit data format type must be covered, along with a brief description of each field.

Guidance

The evaluator shall check the administrative guide and ensure that it provides a format for audit data. Each audit data format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that the description of the fields contains the information required in FAU_GEN.1.2.

Tests

When verifying the test results from FAU_GEN.1.1, the evaluator shall ensure the audit data generated during testing matches the format specified in the administrative guide, and that the fields for each audit data have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit data are generated as expected.

FAU_SAR_EXT.1 Monitored Event Review

FAU_SAR_EXT.1.1

The TSF shall provide [assignment: authorized users] with the capability to read [assignment: list or type of information] from the monitored data.

FAU_SAR_EXT.1.2

The TSF shall provide the monitored data in a manner suitable for the user to interpret the information.

FAU_SEL_EXT.1 Monitored Event Selection

FAU_SEL_EXT.1.1

The TSF shall be able to select the subset of monitored data to be recorded from the set of all monitored data based on the following attributes: [selection: monitored data is retained in its original format, [assignment: aggregation, summary, or other consolidated reporting format]].

Application Note: The purpose of this requirement is to allow the ST author to specify the monitored data that is retained by the TSF for subsequent review and reporting purposes. It may be the case that the TSF preserves all of the raw data that it collects, in which case "monitored data is retained in its original format" is selected. If only a subset of this data is retained (e.g. if compliance data is collected and only the violations are retained for review and reporting purposes), the ST author completes the assignment to describe this behavior, and whether it is configurable.

FAU_STG.1 Audit Data Storage Location

FAU_STG.1.1

The TSF shall be able to store generated audit data on [selection: the TOE itself, an external IT entity using a trusted channel according to FTP_ITC.1, local platform storage].

Application Note:

Per FAU_GEN.1.1, audit data may be generated by the TOE, the platform, or both. If audit data is generated by the TOE, the TSF must have the ability to securely transmit this data to a remote entity. It may additionally store this data within the TOE boundary, in which case "the TOE itself" is selected and FAU_STG.2 must be included in the ST. In cases where the TSF stores audit data within the TOE boundary or on local platform storage, it is expected that some mechanism exists in the TSF for an administrator to review the audit data, and FAU_SAR.1 must be included in the ST. Regardless of whether the TSF stores the audit data it generates within the TOE boundary, the TOE must always be able to securely transmit the audit data it generates to a remote entity. If audit data is generated by the platform, any secure local storage or secure remote transmission of this data is the responsibility of the platform.

Although the audit server is outside of the TOE, the TSF should still be able to support mutual authentication. There are no requirements levied on the audit server, but the TOE should be able to support TLS client certificate authentication. This way if the non-TOE audit server does support verifying client certs, the TSF is able to make use of that.

For distributed TOEs, each component must be able to export any audit data it generates across a protected channel. This may involve individual components independently transmitting audit data to the same environmental audit server via FTP_ITC.1, or it may involve one component of a distributed TOE aggregating audit data generated by other components prior to external transmission. In this case, the internal communication of audit data is protected via the mechanisms specified in FPT_ITT.1. The intent of this requirement in the context of a distributed TOE is that all audit data generated by all components of the TSF be transmitted to an environmental entity entirely through trusted channels, regardless of whether it is transmitted directly from the TSF to the operational environment or whether it is first transmitted to another part of the TOE.

Evaluation Activities

FAU_STG.1

TSS

The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided.

Guidance

The evaluator shall also examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and "cleared" periodically by sending the data to the audit server.

The evaluator shall also examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server.

Tests

Testing of the trusted channel mechanism will be performed as defined in the associated evaluation activities for the particular trusted channel mechanism.

The evaluator shall perform the following test for this requirement: :

Test FAU_STG.1:1: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator's choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.

FAU_STG_EXT.1 Monitored Data Storage Location

FAU_STG_EXT.1.1

The TSF shall shall be able to store [selection: all, [assignment: pre-defined or configurable subset of]] monitored data regarding managed [selection: systems, agents] on [selection: the TOE itself, an environmental system local to the TOE, an environmental system external to the TOE using a trusted channel according to FTP_ITC.1 for its secure transmission].

Evaluation Activities

FAU_STG_EXT.1

TSS

The evaluator shall examine the TSS to verify that it describes the monitored data that the TSF stores and whether this data is stored locally within the TOE boundary, locally on the TOE platform, or remotely. If monitored data is stored remotely, the evaluator shall examine the TSS to verify that it identifies the trusted channel used for these communications, and how the monitored data is handled if this connection is unavailable.

Guidance

If monitored data is stored remotely, the evaluator shall examine the operational guidance to ensure it describes how to establish the trusted channel to the remote server in terms of how to specify the destination as well as any specific configuration needed to ensure that a trusted channel is used for this transmission.

Tests

Testing of the trusted channel mechanism will be performed as defined in the associated evaluation activities for the particular trusted channel mechanism.

The evaluator shall perform the following tests: :

Test FAU_STG_EXT.1:1: The evaluator shall cause monitored data to be collected by the TOE and then review this data to verify that it includes the data that is specified in the TSS. This test may be performed in conjunction with FAU_SAR_EXT.1 to verify the ability to review this data and with FAU_SEL_EXT.1 to verify that configuring the suppression of any monitored data attributes has the intended effect and data with those attributes are not stored.
Test FAU_STG_EXT.1:2: [Conditional, the TOE stores monitored data remotely] If the TOE stores monitored data remotely, the evaluator shall establish a session between the TOE and the server used for storing monitored data according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the TOE and this server TOE during several activities of the evaluator's choice designed to generate monitored data to be transferred to the server. The evaluator shall observe that the monitored data is not able to be viewed in the clear during this transfer, and that it is successfully received by the server.
Test FAU_STG_EXT.1:3: [Conditional, the TOE stores monitored data remotely] If the TOE stores monitored data remotely, the evaluator shall establish a connection to the remote server as in the previous test and cause the server to become inaccessible by the TOE. The evaluator shall then cause monitored data to be collected and then re-establish the connection to the server to determine that the TOE handles the monitored data consistent with the TSS.

FCS_CKM.1/AKG Cryptographic Key Generation - Asymmetric Key

FCS_CKM.1.1/AKG

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [selection: Cryptographic Key Generation Algorithm] and specified cryptographic algorithm parameters ~~key sizes~~ [selection: Cryptographic Algorithm Parameters] that meet the following: [selection: List of Standards] .

Table 4 provides the allowable choices for completion of the selection operations of FCS_CKM.1/AKG.

Table 4: Allowable choices for FCS_CKM.1/AKG
Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
RSA	RSA	Modulus of size [selection: 3072, 4096, 6144, 8192] bits	NIST FIPS PUB 186-5 (Section A.1.1)
ECC-ERB	ECC-ERB - Extra Random Bits	Elliptic Curve [selection: P-384, P-521]	FIPS PUB 186-5 (Section A.2.1) NIST SP 800-186 (Section 3) [NIST Curves]
ECC-RS	ECC-RS - Rejection Sampling	Elliptic Curve [selection: P-384, P-521]	FIPS PUB 186-5 (Section A.2.2) NIST SP 800-186 (Section 3) [NIST Curves]
FFC-ERB	FFC-ERB - Extra Random Bits	Static domain parameters approved for [selection: IKE Groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192] TLS Groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] ]	NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]
FFC-RS	FFC-RS - Rejection Sampling	Static domain parameters approved for [selection: IKE Groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192] TLS Groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] ]	NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]
LMS	LMS	Private key size = [selection: 192 bits with[selection: SHA-256/192, SHAKE256/192] 256 bits with [selection: SHA-256, SHAKE256] ] Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25]	RFC 8554 [LMS] NIST SP 800-208 [parameters]
ML-KEM	ML-KEM KeyGen	Parameter set = ML-KEM-1024	NIST FIPS 203 (Section 7.1)
ML-DSA	ML-DSA KeyGen	Parameter set = ML-DSA-87	NIST FIPS 204 (Section 5.1)
XMSS	XMSS	Private key size = [selection: 192 bits with [selection: SHA-256/192, SHAKE256/192] 256 bits with [selection: SHA-256, SHAKE256] ] Tree height = [selection: 10, 16, 20]	RFC 8391 [XMSS] NIST SP 800-208 [parameters]

Application Note:

For RSA the choice of the modulus implies the resulting key sizes of the public and private keys generated using the specified standard methods. RSA key generation with modulus size 2048 bits is no longer permitted by CNSA.

For Finite Field Cryptography (FFC) DSA, ST authors should consult schemes for guidelines on use. FIPS PUB 186-5 does not approve DSA for digital signature generation but allows DSA for digital signature verification for legacy purposes. “FFC-ERB” or “FFC–RS” may be claimed only for generating private and public keys when “DH” is claimed in FCS_CKM_EXT.7.

When generating ECC keys pairs for key agreement and if “ECDH” is claimed in FCS_CKM_EXT.7, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.

When generating ECC key pairs for digital signature generation and if “ECDSA” is claimed in FCS_COP.1/SigGen, then “ECC–ERB” or “ECC–RS” must be claimed. The sizes of the private key, which is a scalar, and the public key, which is a point on the elliptic curve, are determined by the choice of the curve.

Evaluation Activities

FCS_CKM.1/AKG

TSS

The evaluator shall examine the TSS to verify that it describes how the TOE generates a key based on output from a random bit generator as defined in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1 is invoked.

The evaluator shall examine the TSS to verify that it identifies the usage and key lifecycle for keys generated using each selected algorithm.

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed in accordance with the relevant standards.

If the TOE uses the generated key in a key chain or hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of the key chain or hierarchy.

Guidance

The evaluator shall verify that the guidance instructs the administrator how to configure the TOE to generate keys for the selected key generation algorithms for all key types and uses identified in the TSS.

Tests

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

RSA Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
RSA	RSA	Modulus of size [selection: 3072, 4096, 6144, 8192] bits	NIST FIPS PUB 186-5 (Section A.1.1)

FIPS PUB 186-5 Key Pair generation specifies five methods for generating the primes p and q.

These are:

Random provable primes
Random probable primes
Provable primes with conditions based on auxiliary provable primes
Probable primes with conditions based on auxiliary provable primes
Probable primes with conditions based on auxiliary probable primes

In addition to the key generation method, the input parameters are:

Modulus [3072, 4096, 6144, 8192]
Hash algorithm [SHA-384, SHA-512] (methods 1, 3, 4 only)
Rabin-Miller prime test [2¹⁰⁰, 2^{Security String}] (methods 2, 4, 5 only)
p mod 8 value [0,1,3,5,7]
q mod 8 value [0,1,3,5,7]
Private key format [standard, Chinese Remainder Theorem]
Public exponent [fixed value, random]

The evaluator shall verify the ability of the TSF to correctly produce values for the RSA key components, including the public verification exponent e, the private prime factors p and q, the public modulus n, and the calculation of the private signature exponent d.

Testing for Random Provable Primes and Conditional Methods

To test the key generation method for the random provable primes method and for all the primes with conditions methods (methods 1, 3-5), the evaluator shall seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair.

For each supported combination of the above input parameters, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

Testing for Random Probable Primes Method

If the TOE generates random probable primes (method 2) then, if possible, the random probable primes method should also be verified against a known good implementation as described above. If verification against a known good implementation is not possible, the evaluator shall have the TSF generate 25 key pairs for each supported key length nlen and verify that all of the following are true.

n = p*q
p and q are probably prime according to Miller-Rabin tests with error probability <2^(-125)
2¹⁶ < e < 2²⁵⁶ and e is an odd integer
GCD(p-1,e) = 1
GCD(q-1,e) = 1
|p-q| > 2^{(nlen/2 – 100)}
p ≥ squareroot(2)*( 2^{(nlen/2 -1)} )
q ≥ squareroot(2)*( 2^{(nlen/2 -1)} )
2^(nlen/2) < d < LCM(p-1,q-1)
e*d = 1 mod LCM(p-1,q-1)

Elliptic Curve Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
ECC-ERB	ECC – Extra Random Bits	Elliptic Curve [selection: P-384, P-521]	NIST FIPS PUB 186-5 (Section A.2.1) NIST SP 800-186 (Section 3) [NIST Curves]
ECC-RS	ECC – Rejection Sampling	Elliptic Curve [selection: P-384, P-521]	NIST FIPS PUB 186-5 (Section A.2.2) NIST SP 800-186 (Section 3) [NIST Curves]

To test the TOE’s ability to generate asymmetric cryptographic keys using elliptic curves, the evaluator shall perform the ECC Key Generation Test and the ECC Key Validation Test using the following input parameters.

Elliptic curve [P-384, P-521]
Key pair generation method [extra random bits, rejection sampling]

ECC Key Generation Test
For each supported combination of the above input parameters the evaluator shall require the implementation under test to generate 10 private and public key pairs (d, Q). The private key, d, shall be generated using a random bit generator as defined in FCS_RBG.1. The private key, d, is used to compute the public key, Q'. The evaluator shall confirm that 0<d<n (where n is the order of the group), and the computed value Q' is then compared to the generated public and private key pairs’ public key, Q, to confirm that Q is equal to Q'.

ECC Key Validation Test
For each supported combination of the above parameters the evaluator shall generate 12 private and public key pairs using the key generation function of a known good implementation. For each set of 12 public keys, the evaluator shall modify four public key values by shifting x or y out of range by adding the order of the field and modify four other public key values by shifting x or y so that they are still in bounds, but not on the curve. The remaining public key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall submit the public keys to the public key validation (PKV) function of the TOE and confirm that the results correspond as expected for the modified and unmodified values.

Finite Field Cryptography Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
FFC-ERB	FFC – Extra Random Bits	Static domain parameters approved for [selection: IKE groups [selection:* MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]*]]	NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]
FFC-RS	FFC – Rejection Sampling	Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection:* ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]*]	NIST SP 800-56A Revision 3 (Section 5.6.1.1.4) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]

To test the TOE’s ability to generate asymmetric cryptographic keys using finite fields, the evaluator shall perform the Safe Primes Generation Test and the Safe Primes Validation Test using the following input parameter:

Fields/Groups [MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]

Safe Primes Generation Test
For each supported safe primes group, generate 10 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

Safe Primes Verification Test
For each supported safe primes group, use a known good implementation to generate 10 key pairs. For each set of 10, the evaluator shall modify three so they are incorrect. The remaining values are left unmodified (i.e., correct). To determine correctness, the evaluator shall submit the key pairs to the public key validation (PKV) function of the TOE and shall confirm that the results correspond as expected for the modified and unmodified values.

LMS Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
LMS	LMS Key Generation	Private key size = [selection: 192 bits with [selection: SHA-256/192, SHAKE256/192], 256 bits with [selection:* SHA-256, SHAKE256]]; Winternitz parameter = [selection:* 1, 2, 4, 8]; Tree height = [selection: 5, 10, 15, 20, 25]	RFC 8554 [LMS] NIST SP 800-208 [parameters]

To test the TOE’s ability to generate asymmetric cryptographic keys using LMS, the evaluator shall perform the LMS Key Generation Test using the following input parameters:

Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256]
Winternitz [1, 2, 4, 8]
Tree height [5, 10, 15, 20, 25]

LMS Key Generation Test
For each supported combination of the hash algorithm, Winternitz parameter, and tree height, the evaluator shall generate one public key for each of the test cases. The number of test cases depends on the tree height: Table 5: Number of LMS Test Cases

Height	Number of test cases
5	5
10	4
15	3
20	2
25	1

The evaluator shall verify the correctness of the TSF’s implementation by comparing the public key generated by the TSF with that generated by a known good implementation using the same input parameters.

ML-KEM Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
ML-KEM	ML-KEM Key Generation	Parameter set = [ML-KEM-1024]	NIST FIPS PUB 203 (Section 7.1)

To test the TOE’s ability to generate asymmetric cryptographic keys using ML-KEM, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Parameter set [ML-KEM-1024]
Random seed d [32 bytes]
Random seed z [32 bytes]

Algorithm Functional Test
For each supported parameter set the evaluator shall require the implementation under test to generate 25 key pairs using 25 different randomly generated pairs of 32-byte seed values (d, z). To determine correctness, the evaluator shall compare the resulting key pairs (ek, dk) with those generated using a known good implementation using the same inputs.

ML-DSA Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
ML-DSA	ML-DSA Key Generation	Parameter set = ML-DSA-87	NIST FIPS PUB 204 (Section 5.1)

To test the TOE’s ability to generate asymmetric cryptographic keys using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Parameter set [ML-DSA-87]
Random seed [32 bytes]

Algorithm Functional Test
For each supported parameter set the evaluator shall require the implementation under test to generate 25 key pairs using 25 different randomly generated 32-byte seed values. To determine correctness, the evaluator shall compare the resulting key pairs with those generated using a known good implementation using the same inputs.

XMSS Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
XMSS	XMSS	Private key size = [selection: 192 bits with [selection:* SHA-256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], tree height = [selection:* 10, 16, 20]	RFC 8391 [XMSS] NIST SP 800-208 [parameters]

To test the TOE’s ability to generate asymmetric cryptographic keys using XMSS, the evaluator shall perform the XMSS Key Generation Test using the following input parameters:

Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256]
Tree height [10, 16, 20] (XMSS only)

Table 6: Number of Test Cases for XMSS^MT

Height	Number of test cases
10	5
16	4
20	3
40	2
60	1

XMSS Key Generation Test
For each supported combination of hash algorithm and tree height, the evaluator shall generate one public key for each test case. The number of test cases depends on the tree height as defined in Table 6.

The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

Note: The number of test cases is limited due to the extreme amount of time it can take to generate XMSS trees.

FCS_CKM.1/SKG Cryptographic Key Generation - Symmetric Key

FCS_CKM.1.1/SKG

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate symmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [selection: Cryptographic Key Generation Algorithm] and specified cryptographic key sizes [selection: Cryptographic Key Sizes] that meet the following: [selection: List of standards] .

Table 7 provides the allowable choices for completion of the selection operations of FCS_CKM.1/SKG.

Table 7: Allowable Choices for FCS_CKM.1/SKG
Identifier	Cryptographic Key Generation Algorithm	Cryptographic Key Sizes	List of standards
RSK	Direct Generation from a Random Bit Generator as defined in FCS_RBG.1	[selection: 256, 384, 512] bits	NIST SP 800-133 Revision 2 (Section 6.1)[Direct generation of symmetric keys]

Evaluation Activities

FCS_CKM.1/SKG

TSS

The evaluator shall examine the TSS to verify that it describes how the TOE obtains a symmetric cryptographic key through direct generation from a random bit generator as defined in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1 is invoked.

The evaluator shall examine the TSS to verify that it identifies the usage, and key lifecycle for keys generated using each selected algorithm.

If the TOE uses the generated key in a key chain/hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of the key chain/hierarchy.

Guidance

The evaluator shall verify that the AGD instructs the administrator how to configure the TOE to use the DRBG to generate symmetric keys for all uses identified in the ST.

Tests

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

To test the TOE’s ability to generate symmetric cryptographic keys using a random bit generator, the evaluator shall configure the symmetric cryptographic key generation capability for each claimed key size. The evaluator shall use the description of the DRBG interface to verify that the TOE requests and receives an amount of DRBG output greater than or equal to the requested key size.

FCS_CKM.6 Timing and Event of Cryptographic Key Destruction

FCS_CKM.6.1

The TSF shall destroy [all plaintext keys and keying material] when [selection: no longer needed, [assignment: other circumstances for key or keying material destruction]].

FCS_CKM.6.2

The TSF shall destroy plaintext cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method [selection:

invoking platform-provided functionality with the following rules:
- For volatile memory, the destruction shall be executed by [selection:
  - a single direct overwrite consisting of [selection: a pseudo-random pattern using the TSF or platform DRBG (as defined in FCS_RBG.1), zeroes, ones, a new value of a key, [assignment: some value that does not contain any keying material]],
  - removal of power to the memory,
  - destruction of reference to the key directly followed by a request for garbage collection
  ]
- For non-volatile memory that consists of the invocation of an interface provided by the underlying platform that [selection:
  - logically addresses the storage location of the key and performs a [selection: single, [assignment: ST author defined multi-pass]] direct overwrite consisting of [selection: a pseudo-random pattern using the TSF or platform DRBG (as defined in FCS_RBG.1), zeroes, ones, a new value of a key, [assignment: some value that does not contain any keying material]],
  - instructs the underlying platform to destroy the abstraction that represents the key
  ]
implementing key destruction in accordance with the following rules:
- For volatile memory, the destruction shall be executed by a single direct overwrite consisting of [selection: a pseudo-random pattern using the TSF or platform DRBG (as defined in FCS_RBG.1), zeroes]
- For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo-random pattern using the TSF or platform DRBG (as defined in FCS_RBG.1), followed by a read-verify.
- For non-volatile flash memory, that is not wear-leveled, the destruction shall be executed by a [selection: single direct overwrite consisting of zeroes followed by a read-verify, block erase that erases the reference to memory that stores data as well as the data itself]
- For non-volatile flash memory that is wear-leveled, the destruction shall be executed by a [selection: single direct overwrite consisting of zeroes, block erase]
- For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write

] that meets the following: [no standard].

Application Note:

Even if "invoking platform-provided functionality with the following rules" is selected in FCS_CKM.6.2, the TSF must determine when the plaintext keys and keying material are no longer needed and thus should be destroyed.

For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc. “Plaintext keying material” may refer to a KEK that is used to encrypt other keying material. Destruction of encrypted keying material may be accomplished by destroying the KEK used to encrypt it. If different mechanisms are used for destroying different keying material, all relevant claims should be selected and the TSS should identify which keying material is destroyed by which mechanism.

Key storage areas in non-volatile storage can be overwritten with any value that renders the keys unrecoverable. The value used can be all zeroes, all ones, or any other pattern or combination of values significantly different than the value of the key itself. When ‘a value that does not contain any keying material’ is chosen, it means that the TOE uses some other specified data not drawn from a source that may contain keying material or reveal information about it or any other TSF-protected data. In other words, the data used for overwriting is carefully selected and not taken from a general ‘pool’ that might contain current or residual data that itself requires confidentiality protection. If multiple copies exist, all copies must be destroyed.

Since this is a software-only TOE, the hardware controllers that manage non-volatile storage media are necessarily outside the TOE boundary. Thus, the TOE developer is likely to have little control over—or insight into—the functioning of these storage devices. The TOE must make a “best-effort” to destroy disused cryptographic keys by invoking the appropriate hardware interfaces—recognizing that the specific actions taken by the hardware are out of the TOE’s control. But in cases where the TOE has insight into the non-volatile storage technologies used by the hardware, or where the TOE can specify a preference or method for destroying keys, the destruction should be executed by a single, direct overwrite consisting of pseudorandom data or a new key, by a repeating pattern of any static value, or by a block erase.

The interface referenced in the requirement could take different forms, the most likely of which is an API to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation that overwrites a key stored in non-volatile memory, the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation where an application instructs the underlying platform to destroy the representation of a key stored in non-volatile memory, the application may simply have a handle to a resource and can only ask the platform to delete the resource, as may be the case with a platforms secure key store. The latter implementation should only be used for the most restricted access. The level of detail to which the TOE has access should be described in the TSS.

Evaluation Activities

FCS_CKM.6

TSS

The evaluator shall verify that the TSS identifies all plaintext keys and keying material stored by the TOE, the type of memory in which it is stored, and when and how the keying material is erased. If the TOE uses one or more KEKs to protect stored keying material, the evaluator shall verify that the TSS describes the destruction of that keying material, either directly or by destruction of the KEK used to encrypt it.

If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting one time with a random pattern that is changed before each write"). For block erases, the evaluator shall also ensure that the TSS identifies the block erase command that is used and shall verify that the command used also addresses any copies of the plaintext key material that may be created, e.g., in order to optimize the use of Flash memory.

If platform-provided functionality is invoked for key destruction, the evaluator shall verify that the TSS identifies the platform functions used for this.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

Evaluation Activity Note: The following tests likely require the TOE developer to provide access to a test platform that provides the evaluator with tools that are typically not found on the end consumer version of the TOE.

The evaluator shall perform the following tests for all keys and key material subject to destruction by the TOE, whether the TSF destroys this key material itself or invokes the platform to do so.

For these tests, the evaluator shall utilize an appropriate development environment (e.g., a virtual machine) and development tools (debuggers, simulators, etc.) to test that keys are cleared, including all copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key.

:

Test FCS_CKM.6:1: Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of power, then this test is unnecessary. The evaluator shall:
1. Record the value of the key in the TOE subject to clearing.
2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
3. Cause the TOE to clear the key.
4. Cause the TOE to stop the execution but not exit.
5. Cause the TOE to dump the entire memory of the TOE into a binary file.
6. Search the content of the binary file created in Step #5 for instances of the known key value from Step #1.
7. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece.
Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails.

Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the test fails.
Test FCS_CKM.6:2: Applied to each key held in non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location:
1. Record the value of the key in the TOE subject to clearing.
2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
3. Cause the TOE to clear the key.
4. Search the non-volatile memory the key was stored in for instances of the known key value from Step #1. If a copy is found, then the test fails.
5. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. If a fragment is found then the test is repeated (as described for test 1 above), and if a fragment is found in the repeated test then the test fails.
Test FCS_CKM.6:3: Applied to each key held as non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location:
1. Record the storage location of the key in the TOE subject to clearing.
2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
3. Cause the TOE to clear the key.
4. Read the storage location in Step #1 of non-volatile memory to ensure the appropriate pattern is utilized.
The test succeeds if correct pattern is used to overwrite the key in the memory location. If the pattern is not found the test fails.

In cases where testing reveals that third-party software modules or programming language run-time environments do not properly overwrite keys, this fact must be documented. Likewise, it must be documented if there is no practical way to determine whether such modules or environments destroy keys properly.

In cases where it is impossible or impracticable to perform the above tests, the evaluator shall describe how keys are destroyed in such cases, to include:

Which keys are affected
The reasons why testing is impossible or impracticable
Evidence that keys are destroyed appropriately (e.g., citations to component documentation, component developer/vendor attestation, component vendor test results)
Aggravating and mitigating factors that may affect the timeliness or execution of key destruction (e.g., caching, garbage collection, operating system memory management)

FCS_COP.1/AEAD Cryptographic Operation – Authenticated Encryption with Associated Data

FCS_COP.1.1/AEAD

The TSF shall perform [authenticated encryption with associated data] in accordance with a specified cryptographic algorithm [selection: Cryptographic Algorithm] and cryptographic key sizes [selection: Cryptographic Key Sizes] that meet the following: [selection: List of Standards] .

Table 8 provides the allowable choices for completion of the selection operations of FCS_COP.1/AEAD.

Table 8: Allowable choices for FCS_COP.1/AEAD
Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CCM	AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM]
AES-GCM	AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based], IV construction; the tag must be of length [selection: 96, 104, 112, 120, 128] bits.	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM]

Application Note: The use of 256-bit keys for AES encryption is required by CNSA.

Evaluation Activities

FCS_COP.1/AEAD

TSS

The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, nonces, and tags in conformance with the relevant specifications.

If a CCM mode algorithm is selected, then the evaluator shall examine the TOE summary specification to confirm that it describes how the nonce is generated and that the same nonce is never reused to encrypt different plaintext pairs under the same key.

If a GCM mode algorithm is selected, then the evaluator shall examine the TOE summary specification to confirm that it describes how the IV is generated and that the same IV is never reused to encrypt different plaintext pairs under the same key. The evaluator shall also confirm that for each invocation of GCM, the length of the plaintext is at most (2³²)-2 blocks.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

AES-CCM

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CCM	AES in CCM mode with non-repeating nonce, minimum size of 64 bits	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM]

To test the TOE’s implementation of AES-CCM authenticated encryption functionality the evaluator shall perform the Algorithm Functional Tests described below using the following input parameters:

Key Size [256] bits
Associated data size [0-65536] bits in increments of 8
Payload size [0-256] bits in increments of 8
IV/Nonce size [64-104] bits in increments of 8
Tag size [32-128] bits in increments of 16

Algorithm Functional Tests

Unless otherwise specified, the following tests should use random data, a tag size of 128 bits, IV/Nonce size of 104 bits, payload size of 256 bits, and associated data size of 256 bits. If any of these values are not supported, any supported value may be used. The evaluator shall compare the output from each test case against results generated by a known-good implementation with the same input parameters.

Variable Associated Data Test

For each claimed key size, and for each supported associated data size from 0 through 256 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data. In addition, for each key size, the TOE must be tested by encrypting 10 cases with associated data lengths of 65536 bits, if supported.

Variable Payload Test

For each claimed key size, and for each supported payload size from 0 through 256 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.

Variable Nonce Test

For each claimed key size, and for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.

Variable Tag Test

For each claimed key size, and for each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be tested by encrypting 10 test cases using all random data.

Decryption Verification Test

For each claimed key size, for each supported associated data size from 0 through 256 bits in increments of 8 bits, for each supported payload size from 0 through 256 bits in increments of 8 bits, for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, and for each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be tested by decrypting 10 test cases using all random data.

AES-GCM

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-GCM	AES in GCM mode with non-repeating IVs using [selection: deterministic, DRBG-based] IV construction; the tag must be of length [selection: 96, 104, 112, 120, or 128] bits.	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM]

To test the TOE’s implementation of AES-GCM authenticated encryption functionality the evaluator shall perform the Encryption Algorithm Functional Tests and Decryption Algorithm Functional Tests as described below using the following input parameters:

Key Size [256] bits
Associated data size [0-65536] bits
Payload size [0-65536] bits
IV size [96] bits
Tag size [96, 104, 112, 120, 128] bits

Encryption Algorithm Functional Tests

The evaluator shall generate 15 test cases using random data for each combination of the above parameters as follows:

Each claimed key size,
Each supported tag size,
Four supported non-zero payload sizes, such that two are multiples of 128 bits and two are not multiples of 128 bits,
Four supported non-zero associated data sizes, such that two are multiples of 128 bits and two are not multiples of 128 bits, and
An associated data size of zero, if supported.

Note that the IV size is always 96 bits.

The evaluator shall compare the output from each test case against results generated by a known- good implementation with the same input parameters.

Decryption Algorithm Functional Tests

The evaluator shall test the authenticated decrypt functionality of AES-GCM by supplying 15 test cases for the supported combinations of the parameters as described above. For each parameter combination the evaluator shall introduce an error into either the Ciphertext or the Tag such that approximately half of the cases are correct and half the cases contain errors.

FCS_COP.1/Hash Cryptographic Operation - Hashing

FCS_COP.1.1/Hash

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to perform cryptographic hashing in accordance with specified cryptographic algorithm [selection: SHA-256, SHA-384, SHA-512, SHA3-384, SHA3-512] that meet the following: [selection: ISO/IEC 10118-3:2018 [SHA, SHA3], FIPS PUB 180-4 [SHA], FIPS PUB 202 [SHA3]].

Application Note: In accordance with CNSA:

SHA-1 hash is no longer permitted to be used as a hash function,
SHA3 hashes may be used only for internal hardware functionality such as boot integrity checks, and
SHA-256 is permitted only for use as part of LMS or XMSS.

The hash selection should be consistent with the overall strength of the algorithm used for signature generation. For example, the TOE should choose SHA-384 for 3072-bit RSA, 4096-bit RSA, or ECC with P-384; and SHA-512 for ECC with P-521.

Evaluation Activities

FCS_COP.1/Hash

TSS

The evaluator shall examine the TSS to verify that if SHA-256 is selected, that it is being used only as a PRF or MAC step in a key derivation function or as part of LMS, and not as a hash algorithm.

If "invoke platform-provided functionality" is selected:

The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the hash functionality is invoked for each digest size selected in the ST (it should be noted that this may be through a mechanism that is not implemented by the TOE; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).

If "implement functionality" is selected:

The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. The evaluator shall check the AGD documents to determine that any configuration that is required to be done to configure the functionality for the required hash sizes is present. The TSF hashing functions can be implemented in one of two modes.

The first mode is the byte-oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length (i.e., the length (in bits) of the message to be hashed is divisible by 8).

The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. byte-oriented TestMAC.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

SHA-256, SHA-384, SHA-512

To test the TOE’s ability to generate hash digests using SHA2 the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Test for each claimed SHA2 algorithm.

Algorithm Functional Test

The evaluator shall generate a number of test cases equal to the block size of the hash (512 for SHA2-256; 1024 for the other SHA2 algorithms).

Each test case is to consist of random data of a random length between 0 and 65536 bits, or the largest size supported.

Monte Carlo Test

Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation.

There are two versions of the Monte Carlo test for SHA-1 and SHA-2. Either one is acceptable. For the Standard Monte Carlo test the message hashed is always three times the length of the initial seed.

                  For j = 0 to 99
                  A = B = C = SEED
                  For i = 0 to 999
                  MSG = A || B || C
                  MD = SHA(MSG)
                  A = B
                  B = C
                  C = MD
                  Output MD
                  SEED = MD

For the alternate version of the Monte Carlo Test, the hashed message is always the same length as the seed.

                  INITIAL_SEED_LENGTH = LEN(SEED)
                  For j = 0 to 99
                  A = B = C = SEED
                  For i = 0 to 999
                  MSG = A || B || C
                  if LEN(MSG) >= INITIAL_SEED_LENGTH:
                  MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
                  else:
                  MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
                  MD = SHA(MSG)
                  A = B
                  B = C
                  C = MD
                  Output MD
                  SEED = MD

The evaluator shall compare the output against results generated by a known-good implementation with the same input.

Large Data Test

The implementation must be tested against one test case each on large data messages of 1GB, 2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example, consist of a repeated pattern of 64 bits.

The evaluator shall compare the output against results generated by a known-good implementation with the same input.

SHA3-384, SHA3-512 To test the TOE’s ability to generate hash digests using SHA3 the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Tests for each claimed SHA3 algorithm.
Algorithm Functional Test

Generate a test case consisting of random data for every message length from 0 bits (or the smallest supported message size) to rate bits, where rate equals

832 for SHA3-384 and
576 for SHA3-512.

Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits starting at length rate, and continuing until 65535 is exceeded.

The evaluator shall compare the output against results generated by a known-good implementation with the same input.

Monte Carlo Test

Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation.

For this Monte Carlo Test, the hashed message is always the same length as the seed.

                  MD[0] = SEED
                  INITIAL_SEED_LENGTH = LEN(SEED)
                  For 100 iterations
                  For i = 1 to 1000
                  MSG = MD[i-1];
                  if LEN(MSG) >= INITIAL_SEED_LENGTH:
                  MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
                  else:
                  MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
                  MD[i] = SHA3(MSG)
                  MD[0] = MD[1000]
                  Output MD[0]

The evaluator shall compare the output against results generated by a known-good implementation with the same input.

Large Data Test

The implementation must be tested against one test case each on large data messages of 1GB, 2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example, consist of a repeated pattern of 64 bits.

The evaluator shall compare the output against results generated by a known-good implementation with the same input.

FCS_COP.1/KeyedHash Cryptographic Operation - Keyed-Hash

FCS_COP.1.1/KeyedHash

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to perform [keyed-hash message authentication] in accordance with a specified cryptographic algorithm [selection: Keyed Hash Algorithm] and cryptographic key sizes [selection: Cryptographic Key Sizes] that meet the following: [selection: List of Standards] .

Table 9 provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyedHash.

Table 9: Allowable choices for FCS_COP.1/KeyedHash
Keyed Hash Algorithm	Cryptographic Key Sizes	List of Standards
HMAC-SHA-384	[selection: 384 (ISO, FIPS), 256 (FIPS)] bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
HMAC-SHA-512	[selection: 512 (ISO, FIPS), 384 (FIPS), 256 (FIPS)] bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]

Application Note: The intent of this requirement is to specify the keyed-hash message authentication function used when used for key establishment purposes for the various cryptographic protocols used by the TOE (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/Hash.

Evaluation Activities

FCS_COP.1/KeyedHash

TSS

The evaluator shall examine the TSS to ensure that the size of the key is sufficient for the desired security strength of the output.

If "invoke platform-provided functionality" is selected:

The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the keyed-hash functionality is invoked for each mode and key size selected in the ST (it should be noted that this may be through a mechanism that is not implemented by the TOE; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).

If "implement functionality" is selected:

The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

HMAC

Keyed Hash Algorithm	Cryptographic Key Sizes	List of Standards
HMAC-SHA-384	[selection: (ISO, FIPS) 384, (FIPS) 256] bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
HMAC-SHA-512	[selection: (ISO, FIPS) 512, (FIPS) 384, 256] bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]

To test the TOE’s ability to generate keyed hashes using HMAC the evaluator shall perform the Algorithm Functional Test for each combination of claimed HMAC algorithm the following parameters:

Hash function [SHA-256, SHA-384, SHA-512]
Key length [8-65536] bits by 8s
MAC length [32-[digest size of hash function (256, 384, 512)]] bits

Algorithm Functional Test

For each supported Hash function the evaluator shall generate 150 test cases using random input messages of 128 bits, random supported key lengths, random keys, and random supported MAC lengths such that across the 150 test cases:

The key length includes the minimum, the maximum, a key length equal to the block size, and key lengths that are both larger and smaller than the block size.
The MAC size includes the minimum, the maximum, and two other random values.

The evaluator shall compare the output against results generated by a known good implementation with the same input.

FCS_COP.1/SigGen Cryptographic Operation - Signature Generation

FCS_COP.1.1/SigGen

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to perform [digital signature generation] in accordance with a specified cryptographic algorithm [selection: Cryptographic Algorithm] and cryptographic key sizes [selection: Cryptographic Key Sizes] that meet the following: [selection: List of Standards] .

Table 10 provides the allowable choices for completion of the selection operations in FCS_COP.1/SigGen.

Table 10: Allowable choices for FCS_COP.1/SigGen
Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
RSA-PKCS	RSASSA-PKCS1-v1_5	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5]
RSA-PSS	RSASSA-PSS	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512], Salt Length (sLen) such that [assignment: 0 ≤ sLen* ≤ hLen (Hash Output Length)*] and Mask Generation Function = MGF1	RFC 8017 (Section 8.1) [PKCS#1 v2.2] FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS]
ECDSA	ECDSA	Elliptic Curve [selection: P-384, P-521], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash function using [selection: SHA-384, SHA-512]	[selection: ISO/IEC 14888-3:2018 (Subclause 6.6), FIPS PUB 186-5 (Sections 6.3.1, 6.4.1][ECDSA] NIST SP-800 186 (Section 4) [NIST Curves]
ML-DSA	ML-DSA Signature Generation	Parameter set = ML-DSA-87	NIST FIPS 204 (Section 5.2)

Evaluation Activities

FCS_COP.1/SigGen

TSS

The evaluator shall examine the TSS and verify that any hash function is the appropriate security strength for the signing algorithm.

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards.

The evaluator shall examine the TSS to verify that the TOE has appropriate measures in place to ensure that hash-based signature algorithms do not reuse private keys.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

RSA-PKCS Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PKCS	RSASSA-PKCS1-v1_5	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5]

To test the TOE’s ability to perform RSA Digital Signature Generation using PKCS1-v1_5 signature type, the evaluator shall perform the Generated Data Test using the following input parameters:

Modulus size [3072, 4096, 6144, 8192] bits
Hash algorithm [SHA-384, SHA-512]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate three test cases using random data. The evaluator shall compare the results against those from a known good implementation.

RSA-PSS Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PSS	RSASSA-PSS	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512], Salt Length (sLen) such that [assignment: 0 ≤ sLen* ≤ hLen (Hash Output Length)*] and Mask Generation Function = MGF1	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS]

To test the TOE’s ability to perform RSA Digital Signature Generation using PSS signature type, the evaluator shall perform the Generated Data Test using the following input parameters:

Modulus size [3072, 4096, 6144, 8192] bits
Hash algorithm [SHA-384, SHA-512]
Salt length [Fixed based on implementation]
Mask function [MGF1]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate three test cases using random data. The evaluator shall compare the results against those from a known good implementation.

ECDSA Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ECDSA	ECDSA	Elliptic Curve [selection: P-384, P-521], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash function using [selection: SHA-384, SHA-512]	[selection: ISO/IEC 14888-3:2018 (Subclause 6.6), NIST FIPS PUB 186-5 (Sections 6.3.1, 6.4.1] [ECDSA] NIST SP-800 186 (Section 4) [NIST Curves]

To test the TOE’s ability to perform ECDSA Digital Signature Generation using extra random bits or rejection sampling for secret number generation, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Elliptic Curve [P-384, P-521]
Hash algorithm [SHA-384, SHA-512]

To test the TOE’s ability to perform ECDSA Digital Signature Generation using deterministic secret number generation, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Elliptic Curve [P-384, P-521]
Hash algorithm [SHA-384, SHA-512]

Algorithm Functional Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate 10 test cases using random data. The evaluator shall compare the results against those from a known good implementation.

ML-DSA Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ML-DSA	ML-DSA SigGen	Parameter set = ML-DSA-87	NIST FIPS PUB 204 (Section 5.2)

To test the TOE’s ability to generate digital signatures using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Parameter set [ML-DSA-87]
Seed [32 random bytes] (for non-deterministic signature testing), or
Seed [32 zero bytes] (for deterministic signature testing)
Message to sign [8-65535] bytes
Mu value (if generated externally)
Previously generated private key (sk)
Context (for external interface testing)

Algorithm Functional Test

For each combination of supported parameter set and capabilities, the evaluator shall require the implementation under test to generate 15 signatures pairs using 15 different randomly generated 32-byte seed values. To determine correctness, the evaluator shall compare the resulting key pairs with those generated using a known good implementation using the same inputs.

Known Answer Test for Rejection Cases

For each supported parameter set, the evaluator shall cause the TOE to generate signatures using the data below and a deterministic seed of all 0’s. Correctness is determined by comparing the hash of the resulting signature with the hash in the fourth row for each corresponding test case below.

The test values are defined as follows:

Seed is the seed to generate the key pair (pk, sk)
Hash of keys is computed by SHA-256(pk||sk)
Message is the message to be signed
Hash of sig is computed by SHA-256(sig)

ML-DSA-87 Test Cases for Rejection Cases

		Test case 87-RC-01
		Seed: 			E4F5AFCF697E0EC3C1BDEB66FAA903221E803902F9C3F716E1056A63D77DC250
		Hash of Keys: 	61618E8DDA6998072C8EB36974E03880D741CAF0BD523356DFC161E7C9E63934
		Message: 		F4F1C05004D5B946F69EAFE104C4020519086ADDB9582A20FDE887D13DFC36B1
		Hash of sig: 	B584E38FA442FC3C81A147D4BDBF058D73C822CAF5CA4C06B0110867F60A8001
						
		Test case 87-RC-02
		Seed: 			8B828D871254D6C57384A8E7025AA3F7160CAD1D2C754499DF3844426062C3DD
		Hash of Keys: 	BB64481317D6C0DBAD20C0C7EF11078AD54E5D574F4A07652115A95F77C655FA
		Message: 		0F9409C5A4930C25B83FC5B77FDB5BB49C75372DE724D9C1A77DB700CF0CF154
		Hash of sig: 	F86B49BE9DEB2B209BDEB4E922E5939E92D38E562C44BB09AFBD67323C345192
						
		Test case 87-RC-03
		Seed: 			E693D282CACB8CE65FD4D108DA7A373F097F0AA9713550BE242AAD5BD3E2E452
		Hash of Keys: 	B0BEAF56713A69BD4AB2CBEE006FA5001E7B41F3AE541E05F088933AA0CC78DF
		Message: 		24DABB9D57ADEBD560ED65D9451C5106D437061708F849BA53F3543CDF9AAAE0
		Hash of sig: 	DBF65CEFF9F96A74AAF6F3AB27B043231BE6AA04FBA2EEC987A24A00BDD6A08E
						
		Test case 87-RC-04
		Seed: 			4002163EB8EED01A8E0919BA8C07D291341EDCAE25B02B9779A2CFFE50561AF0
		Hash of Keys: 	FED1BE685C20ECB322FC40D41DEE7E0E98D0409FBF989CAE71B8AD2D58AD645E
		Message: 		EE316BB5EBED53325B4A55571C60657B53E353B51B831F4A0BBB28107EBA4BA8
		Hash of sig: 	3BE9B5545FDCED92547B3409C83B3312CCB5792A8EC3A4DA63BA692C79BEF17C
						
		Test case 87-RC-05
		Seed: 			9C7AD524F65854C27E565BCEDF8E86D650F13A40D0448F9AE10C05F10F777120
		Hash of Keys: 	0EA872CA5A4BEA94F4E8EF7ED31800727899A51059FDEE111E5CB15F0233B534
		Message: 		CE09831294AA96CAF684B9E667947B021C57B24C138EC7D4DA270694C82F2E08
		Hash of sig: 	3B9526CEE6587F2418BFE603ADB0F7DF0D69EBA31C9F9F005C60C993945EBD33
						
		Test case 87-RC-06
		Seed: 			2EB7676D4A28700DA7772A7A035EB495CAA6F842352A74824EF5FD891BC38B2A
		Hash of Keys: 	D5B73703A1DDC5BCB0D14AE39B193A25D6ADA6535827973181ADB0BE70435A5B
		Message: 		C2B3A0AC483A5517682285C205974B2A506946448A8F7D3E1934C155EFDFE922
		Hash of sig: 	375D598704B722C8A1FEF1626FD7738A532C06329AA4217357460E3B729660F8
						
		Test case 87-RC-07
		Seed: 			E4E80CCE8B26DF1B02B99949851EE2F907FE4F0CC34790352C76D5D91634D073
		Hash of Keys: 	84B7E61684A12698400B09EA332EA3C4FBCFA47FE37FD6AE725CBC5FA8A99D3F
		Message: 		89E6AB43C9CB1CC59C3986D53217A558357E62102A26F666F2B64CD1DBB7A536
		Hash of sig: 	7C4AABD163CAEF8F6EBFDA3E3EEBC0A9604675B0E991ABAFD284F1AE8BA07B2A
						
		Test case 87-RC-08
		Seed: 			5787262B803499223D4E5A8C1EE572E89F7A69B359B3F8505355B0BDEAB95E5C
		Hash of Keys: 	85AE1DE605A7B479C02730BF4B7DD6D0FD8FFE5C980893CA6DAD00BD8BD1CE68
		Message: 		D3230C4E061964BBFB17702432D5D36FC1EB3D1068F8CCAA84044776E3B5CC55
		Hash of sig: 	D3ABE460EE2DD9595F413CFE2780A319E4E4DFD6592995298A7AB0B82A5E2815
						
		Test case 87-RC-09
		Seed: 			CE099B99330537DD153052243FC32ACAD509A126AB982410258858567D410D79
		Hash of Keys: 	E04A9F15EDF8F078EB336CE624249EF2A8EDF2CDBF6A8276E9F5E92ED9B0BAE8
		Message: 		0035931762665F561A1B22176567E3B10FDE2441521F77030733A8E39312EEEE
		Hash of sig: 	3EEF413CB5EB179896ECA172D0DBFB9B251545DC561D61580BD5BBC8B6D734E1

		Test case 87-RC-10
		Seed: 			FC8F2929878CBD81E1CCC23913F290380120C043A4A8A251AEEBF09705B8E590
		Hash of Keys: 	7E2ECCA86F532E8E8092FEBB6E0007F92E7909AD2BCBE2E02AB375DAC9969E5E
		Message: 		D3C28875D2671C0EF23BFDC8869E8ECF8868D3F0561C3134D254F7479D0CE0E5
		Hash of sig: 	EB69A908EDCC04320A0B61AD57E21B044465F2037698636B64229CF2DB259789

Known Answer Test for Large Number of Rejection Cases (Total Rejection Count)

For each supported parameter set, the evaluator shall cause the TOE to generate signatures using the data below and a deterministic seed of all 0’s. Correctness is determined by comparing the hash of the resulting signature with the hash in the fourth row of the corresponding test case below.

ML-DSA-87 Test Cases for Total Rejection Count

		Test case 87-LN-01
		Seed: 			98B6298051D92BF37293C93C97370747BF527B87B71F6C4264182F45155ADE4C
		Hash of Keys: 	04A135B5C9B7020332C7B16E7108E8FF7FC1EAE1C23C5FA0B5D5CED0FEEE7424
		Message: 		D7B0341269259083ABF3C8DC47559A19D57669B4486E0224F376DC43E577A3D8
		Hash of sig: 	58D72D76EC0FB65BFB9893C4479366B79DD7B8B7577E4291D13514FCC76C26DD

		Test case 87-LN-02
		Seed: 			DFB5BDD90F58571DCA962426C623F13D046BBE814D183886AC90D143EAD725A7
		Hash of Keys: 	2B6AB8CFCCCC41F759CAF01932E9413F5DC6D949BC827F739866929683FB155E
		Message: 		21005DB2B583CC826A9684BFFD0EE00AB97E0479FE4A1D266699337540145778
		Hash of sig: 	C93EA34E00FFFFC3ECEA072D5FB038A83B5539CAF7B831AEDCFA785E50B3CA5E

		Test case 87-LN-03
		Seed: 			5AD414E0DD0EF2FE685F342871875FDF06F503717A86C3B3466565ADD2096417
		Hash of Keys: 	BD9C2D52F3FC78DB17E682DA2E78947ECFC0898333838D60C892700B2B0DDA9F
		Message: 		29139C279816B25F2D6BB52C8247D163544F7BA332C3CF63359B9E23FBC56515
		Hash of sig:	DB4BE2DE19FB40437BDB7E9B6578D665DB05B4E88C16907DF4546EBA9BE03AEA

		Test case 87-LN-04
		Seed: 			484DD2F406A4D15F49A91AD5FC3BDC1D0FF253622EB68F83D6E1C870D0E89E29
		Hash of Keys: 	A719DC9A77C91C46295555C2353BA0CBEA513DA9A92A5C34D2E949EFF46A12D8
		Message: 		6AD6E959F0EA60126364FB7C95FA71133F246A9265A11B4965EE78AB0CB5AF0E
		Hash of sig: 	5050D7A665074EC63D9F3966C1F01A1BFB18F9E83AE0B09F838BC1E2342ED6F4

		Test case 87-LN-05
		Seed: 			B25C1816F82D59940D5CB829BAC364AAD013C4C16415CE1CF6DCC2F15199B391
		Hash of Keys: 	ADBB2CD43F222640BD9FF4E61C80E63853E8DC1F759C581B7447C9C166EAA38E
		Message: 		824E47322895BFFE37B6B4AFC41CF6115C07EEC0C24EB81076C87A1B01AE8617
		Hash of sig: 	667ADA46073BC69D64DC47BB9A76DD0D78302E7415D87D5E816B05FB95F9E84D

		Test case 87-LN-06
		Seed: 			B2CE72B3560AF07E06465881F56ADA00262BA708D87B73F39E04E310F3B8A3E9
		Hash of Keys: 	FD9C4AC53AE803242A62DF933B8E8BAD6CE5207AC4A73683B6D9383B5E70B17A
		Message: 		A1501CC84C917E0D2D7C27C2AC382220BD8FFFE807DB38E37A9E429EC2781911
		Hash of sig: 	779553B195E11558EE59EF3942F5F6B446A2144600D1F4F50B300C6C56504760

		Test case 87-LN-07
		Seed: 			AB01D0E591B7DDCD3C03395AED808FA2763C0A486D44119D621BE0FD0B022B25
		Hash of Keys: 	93B6ADE34F78A4ADB36B2F6D2C51DB793E659E1243E80488AE1C03B65125D6D7
		Message: 		8DE8122D89D15FE84A4C34F6B59B2C4B11F33B6A053154D199B634F557FDF5F6
		Hash of sig: 	0483045999A79B583F403DB96A736F0F0B24E2DFBC4E5CFA9B50E3D910786F07

		Test case 87-LN-08
		Seed: 			15D60D3693762F82C9AC1DCB0576936651AC81D863842EDB91109C8EE83AE705
		Hash of Keys: 	2DF544E2E939AA717741C2437288FAEB308DEB8FF37A2652FAE34BAE8B84D779
		Message: 		F05946A6113905C34163AEF2246FD69016CE24A7BA40F8E7E42EDAC2D0A44605
		Hash of sig: 	F8383917AF79C8E540D2356AB05F08B465BF32DFEC444B787CE31BF48CC6C3DD

		Test case 87-LN-09
		Seed: 			21212285BED53B3411705DAF5F3BDDB6F0618EB571B36EE11A74053407A269F5
		Hash of Keys: 	737061155A9A03F11F9FEBBB940BED4DD54542C4A6212F89A5EB4EC2BE542782
		Message: 		FFE38246BF3DEFD9CAD15CC17CEA511C067D582E04227B479E32F9197CF91482
		Hash of sig: 	C4C12C58032052FB2D21F0C6A7388A63154FB85B74287D2859DE6C1C6F7F277B

		Test case 87-LN-10
		Seed: 			A2744470587C71BA43EC26DC390CE3531978F315993C653E5D3EFD2849D5D9F1
		Hash of Keys: 	B1BF37BFFB11531B6ADD697870D7DB2E2462D0A97A63F09C1D0038457C6D795A
		Message: 		9831A830231A160B9847203341A5F30BF3E87A2A482AEEA6886315C92B5C4E4C
		Hash of sig: 	46C669D2FEB643A38E54FF87B790CC33F44043A1B6B31DB9474D301328CA2A7F

FCS_COP.1/SigVer Cryptographic Operation - Signature Verification

FCS_COP.1.1/SigVer

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to perform [digital signature verification] in accordance with a specified cryptographic algorithm [selection: Cryptographic Algorithm] and cryptographic key sizes [selection: Cryptographic Key Sizes] that meet the following: [selection: List of Standards] .

Table 11 provides the allowable choices for completion of the selection operations in FCS_COP.1/SigVer.

Table 11: Allowable choices for FCS_COP.1/SigVer
Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
RSA-PKCS	RSASSA-PKCS1-v1_5	Modulus of size [selection: 3072, 4096, 6144, 8192] bits and hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5]
RSA-PSS	RSASSA-PSS	Modulus of size [selection: 3072, 4096, 6144, 8192] bits and hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.1) [PKCS#1 v2.2] FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS]
ECDSA	ECDSA	Elliptic Curve [selection: P-384, P-521] using hash [selection: SHA-384, SHA-512]	[selection: ISO/IEC 14888-3:2018 (Subclause 6.6), FIPS PUB 186-5 (Section 6.4.2)][ECDSA] NIST SP-800 186 (Section 4) [NIST Curves]
LMS	LMS	Private key size = [selection: 192 bits with [selection: SHA-256/192, SHAKE256/192] 256 bits with [selection: SHA-256, SHAKE256] ] Winternitz parameter = [selection: 1, 2, 4, 8] Tree height = [selection: 5, 10, 15, 20, 25]	RFC 8554 [LMS] NIST SP 800-208 [parameters]
XMSS	XMSS	Private key size = [selection: 192 bits with [selection: SHA-256/192, SHAKE256/192] 256 bits with [selection: SHA-256, SHAKE256] ] Tree height = [selection: 10, 16, 20]	RFC 8391 [XMSS] NIST SP 800-208 [parameters]
ML-DSA	ML-DSA Signature Verification	Parameter set = ML-DSA-87	NIST FIPS 204 (Section 5.3)

Evaluation Activities

FCS_COP.1/SigVer

TSS

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

RSA-PKCS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PKCS	RSASSA-PKCS1-v1_5	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5]

To test the TOE’s ability to perform RSA Digital Signature Verification using PKCS1-v1_5 signature type, the evaluator shall perform Generated Data Test using the following input parameters:

Modulus size [3072, 4096, 6144, 8192] bits
Hash algorithm [SHA-384, SHA-512]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate six test cases using a random message and its signature such that the test cases are modified as follows:

One test case is left unmodified
For one test case the Message is modified
For one test case the Signature is modified
For one test case the exponent (e) is modified
For one test case the IR is moved
For one test case the Trailer is moved

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

RSA-PSS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PSS	RSASSA-PSS	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS]

To test the TOE’s ability to perform RSA Digital Signature Verification using PSS signature type, the evaluator shall perform the Generated Data Test using the following input parameters:

Modulus size [3072, 4096, 6144, 8192] bits
Hash algorithm [SHA-384, SHA-512]
Salt length [0-hash length]
Mask function [MGF1]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate six test cases using random data such that the test cases are modified as follows:

One test case is left unmodified
For one test case the Message is modified
For one test case the Signature is modified
For one test case the exponent (e) is modified
For one test case the IR is moved
For one test case the Trailer is moved

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

ECDSA Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ECDSA	ECDSA	Elliptic Curve [selection: P-384, P-521] and hash function using [selection: SHA-384, SHA-512]	[selection: ISO/IEC 14888-3:2018 (Subclause 6.6), NIST FIPS PUB 186-5 (Sections 6.3.1, 6.4.1] [ECDSA] NIST SP-800 186 (Section 4) [NIST Curves]

To test the TOE’s ability to perform ECDSA Digital Signature Verification, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Elliptic Curve [P-384, P-521]
Hash algorithm [SHA-384, SHA-512]

Algorithm Functional Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate test cases consisting of messages and signatures such that the 21 test cases are modified as follows:

Three test cases are left unmodified
For three test cases the Message is modified
For three test cases the key is modified
For three test cases the r value is modified
For three test cases the s value is modified
For three test cases the value r is zeroed
For three test cases the value s is zeroed

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

LMS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
LMS	LMS	Private key size = [selection: 192 bits with [selection:* SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], Winternitz parameter = [selection:* 1, 2, 4, 8], and tree height = [selection: 5, 10, 15, 20, 25]	RFC 8554 [LMS] NIST SP 800-208 [parameters]

To test the TOE’s ability to verify cryptographic digital signature using LMS, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256]
Winternitz [1, 2, 4, 8]
Tree height [5, 10, 15, 20, 25]

Algorithm Functional Test

For each supported combination of the above parameters, the evaluator shall generate four test cases consisting of signed messages and keys, such that

One test case is unmodified (i.e., correct)
For one test case modify the message, i.e., the message is different
For one test case modify the signature, i.e., signature is different
For one test case modify the signature header so that it is a valid header for a different LMS parameter set.

The TOE must correctly verify the unmodified test case and fail to verify the modified test cases.

XMSS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
XMSS	XMSS	Private key size = [selection: 192 bits with [selection:* SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], and tree height = [selection:* 10, 16, 20]	RFC 8391 [XMSS] NIST SP 800-208 [parameters]

To test the TOE’s ability to verify digital signatures using XMSS or XMSS MT, the evaluator shall perform the XMSS digital signature verification test using the following input parameters:

Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256]
Tree height [10, 16, 20]

XMSS Digital Signature Verification Test

For each supported combination of the above parameters, the evaluator shall generate four test cases consisting of signed messages and keys, such that

One test case is unmodified (i.e., correct)
For one test case modify the message, i.e., the message is different
For one test case modify the signature, i.e., signature is different
For one test case modify the signature header so that it is a valid header for a different XMSS parameter set

The evaluator shall verify the correctness of the implementation by verifying that the TOE correctly verifies the unmodified test case and fails to verify the modified test cases.

ML-DSA Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ML-DSA	ML-DSA SigVer	Parameter set = ML-DSA-87	NIST FIPS PUB 204 (Section 5.2)

To test the TOE’s ability to validate digital signatures using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

Parameter set [ML-DSA-87]
Previously generated signed Message [8-65535] bytes
Mu value (if generated externally)
Context (for external interface testing)
Previously generated public key (pk)
Previously generated Signature

Algorithm Functional Test

For each combination of supported parameter set and capabilities, the evaluator shall require the implementation under test to validate 15 signatures. Each group of 15 test cases is modified as follows:

Three test cases are left unmodified
For three test cases the Signed message is modified
For three test cases the component of the signature that commits the signer to the message is modified
For three test cases the component of the signature that allows the verifier to construct the vector z is modified
For three test cases the component of the signature that allows the verifier to construct the hint array is modified

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

FCS_RBG.1 Random Bit Generation (RBG)

FCS_RBG.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to perform all deterministic random bit generation services using [selection: DRBG Algorithm] in accordance with [selection: List of standards] after initialization.

Table 12 provides the allowable choices for completion of the selection operations of FCS_RBG.1.

Table 12: Allowable choices for FCS_RBG.1.1
Identifier	DRBG Algorithm	List of standards
HASH_DRBG	Hash_DRBG with [selection: SHA-384, SHA-512]	[selection: ISO/IEC 18031: 2011 (Section C.2.2), NIST SP 800-90A Revision 1 Section 10.1.1]
HMAC_DRBG	HMAC_DRBG with [selection: SHA-384, SHA-512]	[selection: ISO/IEC 18031: 2011 (Section C.2.3), NIST SP 800-90A Revision 1 Section 10.1.2]
CTR_DRBG	CTR_DRBG with AES-CTR-256	[selection: ISO/IEC 18031: 2011 (Section C.3.2), NIST SP800-90A Revision 1 Section 10.2.1]

Application Note: If "implement functionality" is selected, FPT_FLS.1 and FPT_TST.1 are claimed.

FCS_RBG.1.2

The TSF shall use a [selection: TSF entropy source [assignment: name of entropy source], multiple independent TSF entropy sources [assignment: names of entropy sources], TSF interface for obtaining entropy] for initialization and reseeding.

Application Note:

Following the approach in SP800-90B/C, noise sources are required to be independent. Non-independent noise sources that share dependencies are treated as a single raw source requiring a single entropy source validation. If a TOE has multiple dependent noise sources, they should be grouped according to their dependencies for the purposes of these requirements. For the selection in this requirement, the ST author selects "TSF entropy source..." if a single entropy source is used as input to the DRBG. The ST author selects "multiple independent TSF entropy sources..." if a seed is formed from a combination of two or more independent entropy sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. If multiple distinct entropy sources exist such that each DRBG only uses one of them, then each iteration would select "TSF entropy source..."; "multiple independent TSF entropy sources..." is only selected if a single DRBG uses multiple independent entropy sources for its seed. The ST author selects "TSF interface for obtaining entropy" if entropy source data is generated outside the TOE boundary.

If "TSF entropy source..." is selected, FCS_RBG.3 must be claimed.

If "multiple independent TSF entropy sources..." is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.

If "TSF interface for obtaining entropy" is selected, FCS_RBG.2 must be claimed.

FCS_RBG.1.3

The TSF shall update the DRBG state by [selection: reseeding, uninstantiating and reinstantiating] using a [selection: TSF entropy source [assignment: name of entropy source], TSF interface for obtaining entropy [assignment: name of the interface]] in the following situations: [selection:

never,
on demand,
on the condition: [assignment: condition],
after [assignment: time]

] in accordance with [assignment: list of standards].

Evaluation Activities

FCS_RBG.1.1

Documentation will be produced - and the evaluator shall perform the activities - in accordance with and the Clarification to the Entropy Documentation and Assessment Annex.

TSS

The evaluator shall verify that the TSS identifies the DRBGs used by the TOE and whether they are implemented by the TSF or invoked from the underlying platform.

Guidance

If the DRBG functionality is configurable, the evaluator shall verify that the operational guidance includes instructions on how to configure this behavior.

Tests

[conditional: "implement functionality" is selected in FCS_RBG.1.1] The evaluator shall perform the following tests:

The evaluator shall perform 15 trials for the DRBG implementation. If the DRBG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the DRBG functionality.

If the DRBG has prediction resistance enabled, each trial consists of:

Instantiate the DRBG.
Generate a block of random bits.
Generate a second block of random bits.
Uninstantiate.

The evaluator shall verify that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. "generate one block of random bits" means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90A).

If the DRBG does not have prediction resistance, each trial consists of:

Instantiate the DRBG.
Generate a block of random bits.
Reseed.
Generate a second block of random bits.
Uninstantiate.

The evaluator shall verify that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call.

The following list contains more information on some of the input values to be generated/selected by the evaluator.

Entropy input: The length of the entropy input value must equal the seed length.
Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length.
Personalization string: The length of the personalization string must be less than or equal to seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied.
Additional input: The additional input bit lengths have the same defaults and restrictions as the personalization string lengths.

FCS_RBG.1.2

There are no additional EAs for this element.

FCS_RBG.1.3

TSS

The evaluator shall verify that the TSS identifies how the DRBG state is updated, and the situations under which this may occur.

Guidance

If the ST claims that the DRBG state can be updated on demand, the evaluator shall verify that the operational guidance has instructions for how to perform this operation.

Tests

There are no test activities for this element.

FCS_STG_EXT.1 Cryptographic Key Storage

FCS_STG_EXT.1.1

The TSF shall use [selection: platform-provided key storage, encryption as defined in FCS_STG_EXT.2] for all persistent secrets and private keys.

Application Note: This requirement ensures that persistent secrets (credentials, secret keys) and private keys are stored securely when not in use. If some secrets or keys are manipulated by the TOE and others are manipulated by the platform, then both of the selections can be specified by the ST author and the ST author must identify in the TSS those keys which are manipulated by the TOE and those by the platform.

If "encryption as defined in FCS_STG_EXT.2" is selected then FCS_STG_EXT.2 and FCS_IV_EXT.1 must be included in the ST.

If the TSF is an application, and not a dedicated server, then it should store its private keys in the platform-provided key storage.

The ST author is responsible for selecting the manner in which the keys are stored and where they are stored in the selections above.

FDP_DAR_EXT.1 Encryption Of Sensitive Application Data

FDP_DAR_EXT.1.1

The application shall [selection:

leverage platform-provided functionality to encrypt sensitive data
implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption
protect sensitive data in accordance with FCS_STO_EXT.1
not store any sensitive data

] in non-volatile memory.

Application Note:

If "implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption.

Any file that may potentially contain sensitive data (to include temporary files) shall be protected. The only exception is if the user intentionally exports the sensitive data to non-protected files. ST authors should select "protect sensitive data in accordance with FCS_STO_EXT.1" for the sensitive data that is covered by the FCS_STO_EXT.1 SFR.

Evaluation Activities

FDP_DAR_EXT.1

TSS

If any selection other than not store any sensitive data is selected the evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application. The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS.

If not store any sensitive data is selected, the evaluator shall inspect the TSS to ensure that it describes how sensitive data cannot be written to non-volatile memory. The evaluator shall also ensure that this is consistent with the file system test below.

If implement functionality to encrypt sensitive data is selected the evaluator shall confirm the TSS describes how the application ensures all sensitive data is protected by the file encryption functions.

If protect sensitive data in accordance with FCS_STO_EXT.1 is selected the evaluator shall confirm the TSS describes which data is protected via this mechanism and the selections within FCS_STO_EXT.1 that are leveraged. If multiple selections are included the evaluator shall ensure the TSS describes which sensitive data is captured by which selection.

If "leverage platform-provided functionality..." is selected, the evaluation activities will be performed as stated in the following requirements, which vary on a per-platform basis.

The following content should be included if:

the TOE implements ""

The Windows platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers.

The following content should be included if:

the TOE implements ""

The evaluator shall inspect the TSS and ensure that it describes how the application uses the Complete Protection, Protected Unless Open, or Protected Until First User Authentication Data Protection Class for each data file stored locally.

The following content should be included if:

the TOE implements ""

The Linux platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers.

The following content should be included if:

the TOE implements ""

The Solaris platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers.

The following content should be included if:

the TOE implements ""

The macOS platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers.

Guidance

The evaluator shall confirm the operational guidance contains any instructions necessary for configuring the storage and protection of any sensitive data.

If leverage platform-provided functionality to encrypt sensitive data is selected the evaluator shall confirm the operational guidance contains the list of supported operational environments and any steps necessary to ensure the platform captures any sensitive data that is stored.

Tests

If "implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption" or "protect sensitive data in accordance with FCS_STO_EXT.1" is selected, the evaluator shall inventory the file system locations where the application may write data. The evaluator shall run the application and attempt to store sensitive data. The evaluator shall then inspect those areas of the file system to note where data was stored (if any), and verify it has been encrypted.

If "leverage platform-provided functionality..." is selected no additional testing is required.

FDP_IFC.1 Subset Information Flow Control

FDP_IFC.1.1

The TSF shall enforce the [data monitoring SFP] on [assignment: types of systems, agents, or other entities from which the TSF can manage].

Application Note: The "data monitoring SFP" is a logical construct that references the TOE's ability to collect certain types of data from certain locations for the purpose of enterprise management. This SFR is intended for defining the objects the TSF interfaces with for data collection (e.g., its own local system, remote systems, agents running on remote systems) and the general types of data collected from these objects for monitoring and management purposes (e.g., user account data, system configuration data). FDP_IFF.1 and FDP_ITC.1 reference this policy and define the means by which it is enforced (e.g. what rules may exist for where to collect data, what data is collected, and by what means is this data collected). It is not necessary for the TSF to explicitly define a 'policy' for this behavior; if the TOE is inherently designed to collect certain types of data from certain objects, the existence of this SFP is implicit.

FDP_IFF.1 Simple Security Attributes

FDP_IFF.1.1

The TSF shall enforce the [assignment: data monitoring SFP] based on the following types of subject and information security attributes: [assignment: list of subjects and information controlled under the indicated SFP, and for each, the security attributes].

FDP_IFF.1.2

The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: rules for what data is collected, what sources that data is collected from, and what input validation if any is performed on that data to ensure that it is correctly formatted or that its content is consistent with what is expected.].

FDP_IFF.1.3

The TSF shall enforce the [data monitoring SFP to collect monitored data over the following interfaces: [selection:
secure remote [selection: internal, external] collection over [selection: [assignment: one or more remote trusted channels as defined in FPT_ITT.1], [assignment: one or more remote trusted channels as defined in FTP_ITC.1]]
a secure local interface to a system or agent that is local to the TOE
]].

FDP_IFF.1.4

The TSF shall explicitly authorize an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorize information flows].

FDP_IFF.1.5

The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows].

Evaluation Activities

FDP_IFF.1

TSS

The evaluator shall examine the TSS to verify that it describes how the TOE implements its enterprise management functionality, specifically in regards to the following:

The systems or agents that the TOE manages and the functions or data that it manages
The means by which the TOE is configured to bring these systems or agents under management (e.g., does a process exist by which agents are registered to the TOE via an enrollment process, is the TOE configured to interact with systems at administrator-defined network addresses).
How the TOE's interactions with managed systems or agents are protected (e.g., use of a trusted protocol or a local-only interface)
Any mechanisms the TSF uses to ensure that data transmitted from systems or agents is valid (e.g., must the data be formatted in accordance with a specific protocol such as SCAP)

If the ST defines any positive or negative exceptions to its enforced rules as defined in FDP_IFF.1.4 or FDP_IFF.1.5, the evaluator shall verify that the TSS identifies these exceptions.

Guidance

The evaluator shall examine the operational guidance to verify that it describes how to specify a system or agent to be managed (e.g., is there an enrollment process initiated from a remote agent, does an administrator on the TOE specify a remote endpoint to communicate with, etc.), and whether any configuration options exist for the act of management (e.g., a periodic scanning interval).

The evaluator shall also ensure that if any positive or negative exceptions to its enforced rules as defined in FDP_IFF.1.4 or FDP_IFF.1.5 exist, the operational guidance defines the behavior of these exceptions and describes how to configure them, to the extent that they are configurable versus existing by default.

Tests

The evaluator shall perform the following tests for each distinct type of system or agent that the TOE can communicate with (e.g. if the TOE supports both Windows and macOS agents, this would be two distinct types of agents): :

Test FDP_IFF.1:1: The evaluator shall follow the operational guidance to enter a system or agent into management. This may be performed in conjunction with FIA_ENR_EXT.1 (if claimed) and FIA_ENR_EXT.2.
Test FDP_IFF.1:2: The evaluator shall operate the TOE to exercise its management functions against the managed system or agent. The evaluator shall verify in doing so that the TOE is collecting accurate data about the managed system or agent, that any management functions being performed have the intended effect on the system or agent, and that data is transmitted in the expected format. This may be performed in conjunction with FMT_SMF.1/EXTERNAL and FDP_IFC.1.
Test FDP_IFF.1:3: If any positive exceptions to the enterprise management functionality exist as defined in FDP_IFF.1.4 (e.g., some data is always collected or some management activity always occurs regardless of configuration settings that would otherwise prohibit it), the evaluator shall configure the excepted behavior to be disallowed and then perform the associated action, observing that it was permitted per the exception.
Test FDP_IFF.1:4: If any negative exceptions to the enterprise management functionality exist as defined in FDP_IFF.1.5 (e.g., some action is always prohibited regardless of configuration settings that would otherwise permit it), the evaluator shall configure the excepted behavior to be allowed and then perform the associated action, observing that it was prohibited per the exception.

FDP_NET_EXT.1 Network Communications

FDP_NET_EXT.1.1

The application shall restrict network communication to [selection:

no network communication
user-initiated communication for [assignment: list of functions for which the user can initiate network communication]
respond to [assignment: list of remotely initiated communication]
[assignment: list of application-initiated network communication]

].

Application Note: This requirement is intended to restrict both inbound and outbound network communications to only those required, or to network communications that are user initiated. It does not apply to network communications in which the application may generically access the file system which may result in the platform accessing remotely mounted drives/shares.

FDP_ITC.1 Import of User Data Without Security Attributes

FDP_ITC.1.1

We could also use .2 if the "ignore any security attributes" wording is problematic (not actually clear from Part 2 what an example of that would be because 'security attributes' arguably are just an inherent part of the data that is collectedThe TSF shall enforce the [assignment: data monitoring SFP] when importing monitored data, controlled under the SFP, from outside of the TOE.

FDP_ITC.1.2

The TSF shall ignore any security attributes associated with the monitored data when imported from outside the TOE.

FDP_ITC.1.3

The TSF shall enforce the following rules when importing monitoreddata controlled under the SFP from outside the TOE: [assignment: additional importation control rules].

Note: TBD

FIA_ENR_EXT.2 Method of Enrollment

FIA_ENR_EXT.2.1

Registration shall occur through the following processes: [selection:

The TOE through FCO_CPC_EXT.1 adds another agent to the distributed TOE, which is considered inherently enrolled by the process of joining the TOE.
The TOE administrator accesses a remote agent or system as a sufficiently privileged user on the remote entity to enroll that remote agent or system directly.
An external agent or system requests to be enrolled or has sufficient privileges to initiate enrollment on their own.
The TOE interacts with some environmental process that causes a system or agent to be enrolled indirectly through environmental mechanisms.
The TOE interacts with remote systems solely through transactional sessions. No separate 'enrollment' activity occurs on the TSF because it is not a prerequisite to collecting data from these systems.
The TOE does not perform registration because the entire physical boundary of the TOE is limited to one system so this system is implicitly already registered to the TOE without separate actions.

]

Application Note: In all cases where agent enrollment explicitly or implicitly occurs (i.e., each of the first four selections), FIA_ENR_EXT.1 is claimed to further describe the enrollment process and FMT_MOF.1/MANAGEMENT_ENROLL is claimed to define the ability of the TSF to authorize this function.

FIA_UAU.1 Timing of Authentication

FIA_UAU.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated with the server.

FIA_UAU.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] that requires each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.

Application Note: This requirement ensures that any user attempting to access the TSF must be authenticated. The ST author is responsible for assigning the list of actions that can take place (if any) before this authentication. The TSF or TOE platform may use enterprise authentication to meet this requirement (e.g., integration with enterprise directory services for single sign-on). An application that is installed in the context of a particular OS user such that the authentication context is inherited from logging in to the TOE platform as that user is also an example of authentication being facilitated through invocation of platform-provided functionality.
If "implement functionality" is selected in FIA_UAU.1.2, the ST must include the selection-based SFRs FIA_UIA_EXT.1 and FTA_SSL.3.

FMT_CFG_EXT.1 Secure by Default Configuration

FMT_CFG_EXT.1.1

The application shall [selection: not use credentials, use platform-provided credentials, provide only enough functionality to set new credentials when configured with default credentials or no credentials for application provided credentials].

Application Note: Default credentials are credentials (e.g., passwords, keys) that are automatically (without user interaction) loaded onto the platform during application installation. Credentials that are generated during installation using requirements laid out in FCS_RBG_EXT.1 or established by leveraging platform accounts are not by definition default credentials.

FMT_CFG_EXT.1.2

The application shall be configured by default with file permissions which protect the application binaries and data files from modification by normal unprivileged users.

Application Note: The precise expectations for file permissions vary per platform but the general intention is that a trust boundary protects the application and its data.

Evaluation Activities

FMT_CFG_EXT.1.1

TSS

The evaluator shall check that the TSS describes whether the application requires any type of application provided credentials and whether the application is pre-configured with default values for these credentials. If credentials are required, the evaluator shall verify that the TSS details how use of the TOE is restricted until new credentials are set (which includes the replacement of default credentials if any are present).

Guidance

The evaluator shall verify the guidance documentation details regarding any default or null application provided credentials being used and how they would be updated.

Tests

If the application uses any default credentials the evaluator shall run the following tests. :

Test FMT_CFG_EXT.1.1:1: For any application provided credentials the evaluator shall install and run the application without generating or loading new credentials and verify that only the minimal application functionality required to set new credentials is available.
Test FMT_CFG_EXT.1.1:2: For any application provided credentials the evaluator shall attempt to clear all credentials and verify that only the minimal application functionality required to set new credentials is available.
Test FMT_CFG_EXT.1.1:3: For any application provided credentials the evaluator shall run the application, establish new credentials and verify that the original default credentials no longer provide access to the application.

FMT_CFG_EXT.1.2

TSS

None.

Guidance

None.

Tests

The evaluator shall install and run the application. The evaluator shall inspect the file system of the platform (to the extent possible) for any files created by the application and ensure that their permissions are adequate to protect them. The method of doing so varies per platform. :

The following content should be included if:

the TOE implements ""

The evaluator shall run the command find -L . -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files (for this test, directories are not considered to be files).

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the SysInternals tools Process Monitor and Access Check (or tools of equivalent capability, like icacls.exe) for Classic Desktop applications to verify that files written to disk during an application's installation have the correct file permissions, such that a standard user cannot modify the application or its data files. For Windows Universal Applications the evaluator shall consider the requirement met because of the AppContainer sandbox.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the command find -L . -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the command find . $ -perm -002 $ inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the command find . -perm +002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.

FMT_MEC_EXT.1 Supported Configuration Mechanism

FMT_MEC_EXT.1.1

The application shall [selection: invoke the mechanisms recommended by the platform vendor for storing and setting configuration options, implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption].

Application Note:

Configuration options that are stored remotely are not subject to this requirement. Sensitive Data is generally not considered part of configuration options and should be stored according to FDP_DAR_EXT.1 or FCS_STO_EXT.1.

If “implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption.

Evaluation Activities

FMT_MEC_EXT.1

TSS

The evaluator shall review the TSS to identify the application's configuration options (e.g., settings) and determine whether these are stored and set using the mechanisms supported by the platform or implemented by the application in accordance with the PP-Module for File Encryption. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR.

Conditional: If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the evaluator shall ensure that the TSS identifies those options, as well as indicates where the encrypted representation of these options is stored.

Guidance

The evaluator shall verify the guidance documentation contains any information necessary to configure the protection of configuration settings.

Tests

If " invoke the mechanisms recommended by the platform vendor for storing and setting configuration options" is selected, the method of testing varies per platform as follows: :

The following content should be included if:

the TOE implements ""

The evaluator shall determine and verify that Windows Universal Applications use either the Windows.Storage namespace, Windows.UI.ApplicationSettings namespace, or the IsolatedStorageSettings namespace for storing application specific settings. For .NET applications, the evaluator shall determine and verify that the application uses one of the locations listed in https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/ or https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/zzdt0e7f(v=vs.100) or https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/ or https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config for storing application specific (whether application-wide or user-specific) settings.

For Classic Desktop applications, the evaluator shall run the application while monitoring it with the SysInternals tool Process Monitor and make changes to its configuration. The evaluator shall verify that Process Monitor logs show corresponding changes to the Windows Registry or C:\ProgramData\ directory.

:

The following content should be included if:

the TOE implements ""

The evaluator shall verify that the app uses the user defaults system or key-value store for storing all settings.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the application while monitoring it with the utility strace. The evaluator shall make security-related changes to its configuration. The evaluator shall verify that strace logs corresponding changes to configuration files that reside in /etc (for system-specific configuration), in the user's home directory (for user-specific configuration), or /var/lib/ (for configurations controlled by UI and not intended to be directly modified by an administrator).

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the application while monitoring it with the utility dtrace. The evaluator shall make security-related changes to its configuration. The evaluator shall verify that dtrace logs corresponding changes to configuration files that reside in /etc (for system-specific configuration) or in the user's home directory (for user-specific configuration).

:

The following content should be included if:

the TOE implements ""

The evaluator shall verify that the application stores and retrieves settings using the NSUserDefaults class.

If " implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, for all configuration options listed in the TSS as being stored and protected using encryption, the evaluator shall examine the contents of the configuration option storage (identified in the TSS) to determine that the options have been encrypted.

FMT_MOF.1 Management of Security Functions Behavior

FMT_MOF.1.1

The TSF shall restrict the ability to perform the functions

listed in FMT_SMF.1/Managed
listed in FMT_SMF.1/Internal

to [assignment: authorized administrative roles for each function].

Application Note: This requirement defines the permissions necessary to execute or manage the behavior of functions used for both management of external entities (i.e., Enterprise-Management) as defined in FMT_SMF.1/Internal as well as the TOE itself. The ST author will define, for each claimed administrative function, any roles that are authorized to perform this function. Roles may be predefined by the TOE, inherited from an organizational directory, or custom based on privileges assigned to a role that the TOE has the ability to create.

Role assignment in and of itself may not be sufficient to authorize a function; it may be the case that scoping rules also define the specific set of objects that the function may be performed against. Examples could include a user having the ability to reset only their own password while an administrator has the ability to reset any user's password, or two different users being able to perform the same Enterprise-Management functions against two groups of external entities.

FMT_SMF.1/INTERNAL Specification of Management Functions (Server Configuration of Server)

FMT_SMF.1.1/INTERNAL

Incomplete/placeholder as the management functionality necessary for the server must be defined (e.g., configuration of cryptographic channels, configuration of X.509 certs/trust anchors, configuration of user accounts). Note that some of this may be selectable as being implemented by the TOE or by the platform (or not at all, depending on what is claimed).
The TSF shall be capable of performing the following management functions for configuration of the TSF:

specify systems to be managed

and [selection: configuration of remote channels for collection of monitored data, configuration of the contents and formatting for transmission of monitored data, configuration of remote trusted channel for transmission of monitored data, [assignment: list of management functions]TBD: we'll want to avoid open-ended assignments like this so we should define everything we want to have be selectable as selections, no other functions]

Application Note: This requirement addresses the management functions the TOE provides to manage its own behavior (as opposed to managing the behavior of external entities)

FMT_SMF.1/MANAGED Specification of Management Functions (Server configuration of Managed Systems)

FMT_SMF.1.1/MANAGED

The TSF shall be capable of performing the following management functions against managed systems:

query configuration

apply configuration

[selection:
agent functions:

query installed agent software version

update the agent software

query agent connectivity status

configure agent reporting interval

unenroll agent from management

password policy [selection:
minimum password length
minimum password complexity
maximum password lifetime
authentication factors
authentication failures, maximum before lockout
authentication failures, lockout duration
authentication failures, reset interval
]
audit policy [selection:
audit rules
name and address of audit or logging server to which to send audit or logging records
local audit storage and retention policy
]
access banners policy
session locking policy [selection:
screen-lock enabled or disabled
screen lock timeout
display notifications
]
host-based firewall policy
removable media policy
software update policy
network time server policy
cryptographic policy
].

Application Note: This requirement captures all the configuration functionality that the TSF provides to interact with managed systems, whether that is through direct interaction with those systems or with agents running on those systems. Note that the "managed system" may also be the local system on which the TOE resides if the purpose of the TOE is to manage a centralized system.

If the TOE interacts with agents, the selection for "agent functions" must be claimed.

FMT_SMR.1 Security Roles

FMT_SMR.1.1

The TSF shall maintain the roles [assignment: the authorized identified roles].

FMT_SMR.1.2

The TSF shall be able to associate users with roles.

Application Note: This PP does not require a fixed set of arbitrarily-named roles. The purpose of this requirement is for the ST author to document how users are organized for the purpose of determining the authorizations they have to interact with the TSF, as specified in FMT_MOF.1.

FPT_AEX_EXT.1 Anti-Exploitation Capabilities

FPT_AEX_EXT.1.1

The application shall not request to map memory at an explicit address except for [assignment: list of explicit exceptions].

Application Note: Requesting a memory mapping at an explicit address subverts address space layout randomization (ASLR).

FPT_AEX_EXT.1.2

The application shall [selection, choose one of:

not allocate any memory region with both write and execute permissions
allocate memory regions with write and execute permissions for only [assignment: list of functions performing just-in-time compilation]

].

Application Note: Requesting a memory mapping with both write and execute permissions subverts the platform protection provided by DEP. If the application performs no just-in-time compiling, then the first selection must be chosen.

FPT_AEX_EXT.1.3

The application shall be compatible with security features provided by the platform vendor.

Application Note: This requirement is designed to ensure that platform security features do not need to be disabled in order for the application to run.

FPT_AEX_EXT.1.4

The application shall not write user-modifiable files to directories that contain executable files unless explicitly directed by the user to do so.

Application Note:

The purpose of this requirement is to help ensure the integrity of application binaries by supporting file protection mechanisms such as directory-level file permissions and application allowlisting.

A user-modifiable file for purposes of this requirement is a file that is writable by an unprivileged user of the application -- either directly through application execution or independently of the application. If the application runs in the context of the application user, then the application should not be able to write to the directory containing the application binaries -- regardless of whether the files are configuration data, audit data, or temporary files.

Executables and user-modifiable files may not share the same parent directory, but may share directories above the parent.

FPT_AEX_EXT.1.5

The application shall be built with stack-based buffer overflow protection enabled.

Evaluation Activities

FPT_AEX_EXT.1.1

TSS

The evaluator shall ensure that the TSS describes the compiler flags used to enable ASLR when the application is compiled. If any explicitly-mapped exceptions are claimed, the evaluator shall check that the TSS identifies these exceptions, describes the static memory mapping that is used, and provides justification for why static memory mapping is appropriate in this case.

Guidance

None.

Tests

The evaluator shall perform either a static or dynamic analysis to determine that no memory mappings are placed at an explicit and consistent address except for any exceptions claimed in the SFR. For these exceptions, the evaluator shall verify that this analysis shows explicit mappings that are consistent with what is claimed in the TSS. The method of doing so varies per platform. For those platforms requiring the same application running on two different systems, the evaluator may alternatively use the same device. After collecting the first instance of mappings, the evaluator must uninstall the application, reboot the device, and reinstall the application to collect the second instance of mappings. :

The following content should be included if:

the TOE implements ""

The evaluator shall run the same application on two different Windows systems and run a tool that will list all memory mapped addresses for the application. The evaluator shall then verify the two different instances share no mapping locations. The Microsoft SysInternals tool, VMMap, could be used to view memory addresses of a running application. The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the application has ASLR enabled.

:

The following content should be included if:

the TOE implements ""

The evaluator shall perform a static analysis to search for any mmap calls (or API calls that call mmap), and ensure that no arguments are provided that request a mapping at a fixed address.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the same application on two different Linux systems. The evaluator shall then compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the same application on two different Solaris systems. The evaluator shall then compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the same application on two different Mac systems. The evaluator shall then compare their memory maps using vmmap PID to ensure the two different instances share no mapping locations.

FPT_AEX_EXT.1.2

TSS

None.

Guidance

None.

Tests

The evaluator shall verify that no memory mapping requests are made with write and execute permissions. The method of doing so varies per platform. :

The following content should be included if:

the TOE implements ""

The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the application passes the NXCheck. The evaluator may also ensure that the /NXCOMPAT flag was used during compilation to verify that DEP protections are enabled for the application.

:

The following content should be included if:

the TOE implements ""

The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with the PROT_EXEC permission.

:

The following content should be included if:

the TOE implements ""

The evaluator shall perform static analysis on the application to verify that both

mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, and
mprotect is never invoked with the PROT_EXEC permission.

:

The following content should be included if:

the TOE implements ""

The evaluator shall perform static analysis on the application to verify that both

mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, and
mprotect is never invoked with the PROT_EXEC permission.

:

The following content should be included if:

the TOE implements ""

The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with the PROT_EXEC permission.

FPT_AEX_EXT.1.3

TSS

None.

Guidance

None.

Tests

The evaluator shall configure the platform in the necessary manner and carry out one of the prescribed tests: :

The following content should be included if:

the TOE implements ""

If the OS platform supports Windows Defender Exploit Guard, then the evaluator shall ensure that the application can run successfully with Windows Defender Exploit Guard Exploit Protection configured with the following minimum mitigations enabled; Control Flow Guard (CFG), Randomize memory allocations (Bottom-Up ASLR), Export address filtering (EAF), Import address filtering (IAF), and Data Execution Prevention (DEP). The following link describes how to enable Exploit Protection, https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/enable-exploit-protection?view=o365-worldwide.

:

The following content should be included if:

the TOE implements ""

Applications running on iOS cannot disable security features, therefore this requirement is met and no evaluation activity is required.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application can successfully run on a system with either SELinux or AppArmor enabled and in enforce mode.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application can run with Solaris Trusted Extensions enabled and enforcing.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application can successfully run on macOS without disabling any security features.

FPT_AEX_EXT.1.4

TSS

None.

Guidance

None.

Tests

The evaluator shall run the application and determine where it writes its files. For files where the user does not choose the destination, the evaluator shall check whether the destination directory contains executable files. This varies per platform: :

The following content should be included if:

the TOE implements ""

For Windows Universal Applications the evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). For Windows Desktop Applications the evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.

:

The following content should be included if:

the TOE implements ""

The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.

FPT_AEX_EXT.1.5

TSS

(Conditional: The PE or ELF automated tests fail) The evaluator shall ensure that the TSS describes the stack-based buffer overflow compiler flags.

Guidance

None.

Tests

The evaluator will inspect every native executable included in the TOE to ensure that stack-based buffer overflow protection is present. :

The following content should be included if:

the TOE implements ""

Applications that run as Managed Code in the .NET Framework do not require these stack protections. Applications developed in Object Pascal using the Delphi IDE compiled with RangeChecking enabled comply with this element. For other code, the evaluator shall review the TSS and verify that the /GS flag was used during compilation. The evaluator shall run a tool like, BinSkim, that can verify the correct usage of /GS.

:

Test FPT_AEX_EXT.1.5:1:
For PE, the evaluator will disassemble each and ensure the following sequence appears:
mov rcx, QWORD PTR [rsp+(...)]
xor rcx, (...)
call (...)

:

Test FPT_AEX_EXT.1.5:2:
For ELF executables, the evaluator will ensure that each contains references to the symbol __stack_chk_fail.
If these automated tests fail, the evaluator shall perform the above, conditional TSS activity.

Tools such as Canary Detector may help automate these activities.

FPT_API_EXT.1 Use of Supported Services and APIs

FPT_API_EXT.1.1

The TSF shall use only documented platform APIs.

Application Note: This requirement applies to the APIs used when "invoke platform-provided functionality" is selected in an SFR.

FPT_LIB_EXT.1 Use of Third-Party Libraries

FPT_LIB_EXT.1.1

The TOE software shall be packaged with only [assignment: list of third-party libraries].

Application Note: The intention of this requirement is for the ST author to document which software libraries (including version numbers) the TOE includes in case vulnerabilities are later discovered with those libraries.

FPT_TUD_EXT.1 Support for Trusted Updates

FPT_TUD_EXT.1.1

The application shall [selection: provide the ability, use platform-provided services] to check for updates and patches to the TOE.

Application Note:

This requirement is about the ability to "check" for updates. The actual installation of any updates should be done by the platform. This requirement is intended to ensure that the TOE can check for updates provided by the vendor (either directly through a function on the TOE itself or distribution through a platform's official application store), as updates provided by another source may contain malicious code.

Updates for different components of a distributed TOE may be checked in different ways. The means must exist for each component to be checked individually.

FPT_TUD_EXT.1.2

The application shall [selection: provide the ability, use platform-provided services] to query the current version of the application software.

Application Note: Different components in a distributed TOE may have different application versions and different means of checking the current version. It is expected that all TOE components support some mechanism for implementing this requirement, even if that mechanism differs between components.

FPT_TUD_EXT.1.3

The application shall [selection:

perform trusted updates
not download, modify, replace or update its own binary code

].

Application Note:

This requirement applies to the code of the application; it does not apply to mobile code technologies that are designed for download and execution by the application.

If "perform trusted updates" is selected then FPT_TUD_EXT.2 must be included in the ST.

FPT_TUD_EXT.1.4

Application updates shall be digitally signed such that the application platform can cryptographically verify them prior to installation.

Application Note: The specifics of the verification of updates involves requirements on the platform (and not the application), so these are not fully specified here.

FPT_TUD_EXT.1.5

The application is distributed [selection: with the platform OS, as an additional software package to the platform OS].

Application Note: Application software that is distributed as part of the platform operating system is not required to be packaged for installation or uninstallation. If "as an additional software package to the platform OS" is selected, the requirements from FPT_TUD_EXT.2 must be included in the ST.

Evaluation Activities

FPT_TUD_EXT.1.1

TSS

The evaluator shall verify the TSS contains a description of the update mechanism leveraged, how new updates are checked for, how the current version is checked for, and how the updates are signed.

Guidance

The evaluator shall check to ensure the guidance includes a description of how to check for and apply new updates.

Tests

The evaluator shall check for an update using procedures described in either the application documentation or the platform documentation and verify that the application does not issue an error. If it is updated or if it reports that no update is available this requirement is considered to be met.

FPT_TUD_EXT.1.2

TSS

If the TOE is distributed, the evaluator shall examine the TSS to verify that it describes the mechanisms that support the continuous proper functioning of the TOE during the update process update. Updating a distributed TOE might lead to the situation where different TOE components are running different software versions. Depending on the differences between the different software versions the impact of a mixture of different software versions might be no problem at all or critical to the proper functioning of the TOE.

Guidance

The evaluator shall verify guidance includes a description of how to query the current version of the application.

Tests

The evaluator shall query the application for the current version of the software according to the operational user guidance. The evaluator shall then verify that the current version matches that of the documented and installed version. This operation may be performed alongside the act of checking for updates, i.e., updating the TOE to a newer version would require awareness of what version was running prior to the update.

FPT_TUD_EXT.1.3

TSS

There are no additional TSS evaluation activities for this element.

Guidance

There are no additional Guidance evaluation activities for this element.

Tests

Conditional: If "not download, modify, replace or update its own binary code" is selected the evaluator shall verify that the application's executable files are not changed by the application with the following tests: :

The following content should be included if:

the TOE implements ""

The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox).

:

The following content should be included if:

the TOE implements ""
the TOE implements ""
the TOE implements ""
the TOE implements ""

The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the ST. The evaluator shall then compare each executable file with either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical.

FPT_TUD_EXT.1.4

TSS

The evaluator shall verify that the TSS identifies how updates to the application are signed by an authorized source. The definition of an authorized source must be contained in the TSS. The evaluator shall also ensure that the TSS (or the operational guidance) describes how candidate updates are obtained.

Guidance

There are no additional Guidance evaluation activities for this element.

Tests

There are no test activities for this element.

FPT_TUD_EXT.1.5

TSS

The evaluator shall verify that the TSS identifies how the application is distributed. If "as an additional package..." is selected, the evaluator shall perform the tests in FPT_TUD_EXT.2.

Guidance

None.

Tests

If " with the platform OS" is selected, the evaluator shall perform a clean installation or factory reset to confirm that TOE software is included as part of the platform OS.

ASE_TSS.1 TOE summary specification

Developer action elements:

Content and presentation elements:

ASE_TSS.1.1C

The TOE summary specification shall describe how the TOE meets each SFR.

Evaluator action elements:

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

The functional specification describes the Target Security Functions Interfaces (TSFIs). It is not necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs conforming to this PP will necessarily have interfaces to the Operational Environment that are not directly invokable by TOE users, there is little point specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this PP, the activities for this family should focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional "functional specification" documentation is necessary to satisfy the evaluation activities specified.

The interfaces that need to be evaluated are characterized through the information needed to perform the evaluation activities listed, rather than as an independent, abstract list.

Developer action elements:

ADV_FSP.1.1D

The developer shall provide a functional specification.

ADV_FSP.1.2D

The developer shall provide a tracing from the functional specification to the SFRs.

Application Note: As indicated in the introduction to this section, the functional specification is comprised of the information contained in the AGD_OPE and AGD_PRE documentation. The developer may reference a website accessible to application developers and the evaluator. The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.

Content and presentation elements:

ADV_FSP.1.1C

The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI.

ADV_FSP.1.2C

The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI.

ADV_FSP.1.3C

The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering.

ADV_FSP.1.4C

The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

Evaluator action elements:

ADV_FSP.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ADV_FSP.1.2E

The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.

AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

Developer action elements:

AGD_OPE.1.1D

The developer shall provide operational user guidance.

Application Note: The operational user guidance does not have to be contained in a single document. Guidance to users, administrators and application developers can be spread among documents or web pages. Where appropriate, the guidance documentation is expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to support security automation.

Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance.

Content and presentation elements:

AGD_OPE.1.1C

The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.

Application Note: User and administrator are to be considered in the definition of user role.

AGD_OPE.1.2C

The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner.

AGD_OPE.1.3C

The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.

AGD_OPE.1.4C

The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.

AGD_OPE.1.5C

The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences, and implications for maintaining secure operation.

AGD_OPE.1.6C

The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.

AGD_OPE.1.7C

The operational user guidance shall be clear and reasonable.

Evaluator action elements:

AGD_OPE.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AGD_PRE.1 Preparative Procedures (AGD_PRE.1)

Developer action elements:

AGD_PRE.1.1D

The developer shall provide the TOE, including its preparative procedures.

Application Note: As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.

Content and presentation elements:

AGD_PRE.1.1C

The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures.

AGD_PRE.1.2C

The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.

Application Note: It is recognized that the application of these requirements will vary depending on aspects such as whether the TOE is delivered in an operational state, or whether it has to be installed at the TOE owner's site, etc.

Evaluator action elements:

AGD_PRE.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AGD_PRE.1.2E

The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.

ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)

This component is targeted at identifying the TOE such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user.

Developer action elements:

ALC_CMC.1.1D

The developer shall provide the TOE and a reference for the TOE.

Content and presentation elements:

ALC_CMC.1.1C

The TOE shall be labeled with its unique reference.

Evaluator action elements:

ALC_CMC.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)

Given the scope of the TOE and its associated evaluation evidence requirements, this component's evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.

Developer action elements:

ALC_CMS.1.1D

The developer shall provide a configuration list for the TOE.

Content and presentation elements:

ALC_CMS.1.1C

The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs.

ALC_CMS.1.2C

The configuration list shall uniquely identify the configuration items.

Evaluator action elements:

ALC_CMS.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ATE_IND.1 Independent Testing - Conformance (ATE_IND.1)

Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operational) documentation provided. The focus of the testing is to confirm that the requirements specified in Sections 5.3 and 5.4 are being met, although some additional testing is specified for SARs in Section 6. The Evaluation Activities identify the additional testing activities associated with these components. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the TOE or platform combinations that are claiming conformance to this PP.

Developer action elements:

ATE_IND.1.1D

The developer shall provide the TOE for testing.

Content and presentation elements:

ATE_IND.1.1C

The TOE shall be suitable for testing.

Evaluator action elements:

ATE_IND.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ATE_IND.1.2E

The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.

Evaluation Activities

ATE_IND.1

The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the CEM and the body of this PP's Evaluation Activities. While it is not necessary to have one test case per test listed in an evaluation activity, the evaluator shall document in the test plan that each applicable testing requirement in the ST is covered.

The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary.

The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (IPsec, TLS/HTTPS, SSH).

The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a "fail" and "pass" result (and the supporting details), and not just the "pass" result.

AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)

Developer action elements:

AVA_VAN.1.1D

The developer shall provide the TOE for testing.

Content and presentation elements:

AVA_VAN.1.1C

The TOE shall be suitable for testing.

Evaluator action elements:

AVA_VAN.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AVA_VAN.1.2E

The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE.

AVA_VAN.1.3E

The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential.

ALC_FLR.1 Basic Flaw Remediation (ALC_FLR.1)

This SAR is optional and may be claimed at the ST-Author's discretion.

Developer action elements:

ALC_FLR.1.1D

The developer shall document and provide flaw remediation procedures addressed to TOE developers.

Content and presentation elements:

ALC_FLR.1.1C

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.

ALC_FLR.1.2C

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

ALC_FLR.1.3C

The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.

ALC_FLR.1.4C

The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.

Evaluator action elements:

ALC_FLR.1.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ALC_FLR.2 Flaw Reporting Procedures (ALC_FLR.2)

This SAR is optional and may be claimed at the ST-Author's discretion.

Developer action elements:

ALC_FLR.2.1D

The developer shall document and provide flaw remediation procedures addressed to TOE developers.

ALC_FLR.2.2D

The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws.

ALC_FLR.2.3D

The developer shall provide flaw remediation guidance addressed to TOE users.

Content and presentation elements:

ALC_FLR.2.1C

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.

ALC_FLR.2.2C

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

ALC_FLR.2.3C

The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.

ALC_FLR.2.4C

The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.

ALC_FLR.2.5C

The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and inquiries of suspected security flaws in the TOE.

ALC_FLR.2.6C

The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users.

ALC_FLR.2.7C

The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.

ALC_FLR.2.8C

The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE.

Evaluator action elements:

ALC_FLR.2.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

ALC_FLR.3 Systematic Flaw Remediation (ALC_FLR.3)

This SAR is optional and may be claimed at the ST-Author's discretion.

Developer action elements:

ALC_FLR.3.1D

The developer shall document and provide flaw remediation procedures addressed to TOE developers.

ALC_FLR.3.2D

The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws.

ALC_FLR.3.3D

The developer shall provide flaw remediation guidance addressed to TOE users.

Content and presentation elements:

ALC_FLR.3.1C

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.

ALC_FLR.3.2C

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

ALC_FLR.3.3C

The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.

ALC_FLR.3.4C

The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.

ALC_FLR.3.5C

The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE.

ALC_FLR.3.6C

The flaw remediation procedures shall include a procedure requiring timely response and the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw.

ALC_FLR.3.7C

The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users.

ALC_FLR.3.8C

The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.

ALC_FLR.3.9C

The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE.

ALC_FLR.3.10C

The flaw remediation guidance shall describe a means by which TOE users may register with the developer, to be eligible to receive security flaw reports and corrections.

ALC_FLR.3.11C

The flaw remediation guidance shall identify the specific points of contact for all reports and enquiries about security issues involving the TOE.

Evaluator action elements:

ALC_FLR.3.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Table 15: Auditable Events for Implementation-dependent Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_NET_EXT.1

No events specified	N/A
FCO_CPC_EXT.1

Enabling or disabling communications between a pair of components.	Identities of the endpoint's pairs enabled or disabled.
FCS_CKM.2

No events specified	N/A
FCS_CKM_EXT.7

No events specified	N/A
FTP_ITC.1

Initiation and termination of the trusted channel	Trusted channel protocol Non-TOE endpoint of connection
FTP_TRP.1

Initiation and termination of the trusted channel	Trusted channel protocol Identity of administrator

FAU_NET_EXT.1 Network Reachability Review

This component must be included in the ST if the TOE implements any of the following features:

Network Connectivity

FAU_NET_EXT.1.1

The TSF shall provide authorized administrators with the capability to read the network connectivity status of an external entity.

Application Note: Depending on whether the external entity is a system or a specific agent residing on the system, the network connectivity status may be registered with an ICMP ping or other generic mechanism, or through an API or other function that is specific to the agent or interface the TOE interacts with to perform management functions.

FCO_CPC_EXT.1 Component Registration Channel Definition

This component must be included in the ST if the TOE implements any of the following features:

Distributed TOE

FCO_CPC_EXT.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require an Administrator to enable communications between any pair of TOE components before such communication can take place.

FCO_CPC_EXT.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to implement a registration process in which components establish and use a communications channel that uses [selection: A channel that meets the secure channel requirements in FPT_ITT.1 , A channel that meets the secure registration channel requirements in FTP_TRP.1/Join, No channel] for at least TSF data.

FCO_CPC_EXT.1.3

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to enable an administrator to disable communications between any pair of TOE components.

Application Note: This SFR is only applicable if the TOE is distributed and therefore has multiple components that need to communicate via an internal TSF channel. When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR.

Registration of the distributed TOE components may be accomplished either using the same trusted channel that subsequent communications occur on (FPT_ITT.1), a separate channel that exists for the purpose of facilitating this registration, i.e. a joining channel (FTP_TRP.1/Join), or no channel. In the case of the latter, registration would be accomplished by independent administrative configuration of each component.

Evaluation Activities

FCO_CPC_EXT.1

TSS

The evaluator shall examine the TSS to verify that it describes the mechanism for registering distributed TOE components using a secure channel, whether this is a dedicated registration channel or the same channel that is used for protected communications once registered, and whether the functionality is implemented by the TSF or invoked from its platform.

Guidance

The evaluator shall examine the guidance documentation to confirm that it contains instructions for enabling and disabling communications with any individual component of a distributed TOE. The evaluator shall confirm that the method of disabling is such that all other components can be prevented from communicating with the component that is being removed from the TOE (preventing the remaining components from either attempting to initiate communications to the disabled component, or from responding to communications from the disabled component).

Tests

:

Test FCO_CPC_EXT.1:1: The evaluator shall confirm that an IT entity that is not currently a member of the distributed TOE cannot communicate with any component of the TOE until the non-member entity is enabled by an administrator for each of the non-equivalent TOE components that it is required to communicate with (non-equivalent TOE components are as defined in the minimum configuration for the distributed TOE).
Test FCO_CPC_EXT.1:2: The evaluator shall confirm that after enablement, an IT entity can communicate only with the components that it has been enabled for. This includes testing that the enabled communication is successful for the enabled component pair, and that communication remains unsuccessful with any other component for which communication is possible but has not been explicitly enabled.
Some TOEs may set up the registration channel before the enablement step is carried out, but in such a case the channel must not allow communications until after the enablement step has been completed.
Test FCO_CPC_EXT.1:3: The evaluator shall separately disable each TOE component in turn and ensure that the other TOE components cannot then communicate with the disabled component, whether by attempting to initiate communications with the disabled component or by responding to communication attempts from the disabled component. In situations where one component acts as the 'Gatekeeper' for all other components, the test would involve disabling the components in turn on the Gatekeeper and ensuring that the TOE no longer communicates with disabled components.

FCS_CKM.2 Cryptographic Key Distribution

FCS_CKM.2.1

The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [selection: key encapsulation as defined in FCS_COP.1/KeyEncap, key wrapping as defined in FCS_COP.1/KeyWrap] that meets the following: [none].

Application Note:

If "key encapsulation..." is selected, FCS_COP.1/KeyEncap is claimed. If "key wrapping..." is selected, FCS_COP.1/KeyWrap must be claimed.

FCS_CKM_EXT.7 Cryptographic Key Agreement

FCS_CKM_EXT.7.1

The TSF shall derive shared cryptographic keys with input from multiple parties in accordance with specified cryptographic key agreement algorithms [selection: Cryptographic algorithm] and specified cryptographic parameters [selection: Cryptographic parameters] that meet the following: [selection: List of standards] .

Table 16 provides the allowable choices for completion of the selection operations of FCS_CKM_EXT.7.

Table 16: Allowable choices for FCS_CKM_EXT.7
Identifier	Cryptographic algorithm	Cryptographic parameters	List of standards
KAS2	RSA	Modulus size [selection: 3072, 4096, 6144, 8192] bits	NIST SP 800-56B Revision 2 (Section 8.3) [KAS2]
DH	Finite Field Cryptography Diffie-Hellman	Static domain parameters approved for [selection: IKE Groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192] TLS Groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] ]	NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]
ECDH	Elliptic Curve Diffie-Hellman	Elliptic Curve [selection: P-384, P-521]	NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH] NIST SP 800-186 (Section 3.2.1) [NIST Curves]

Application Note: This SFR is claimed if the TSF supports key agreement schemes as a method of key establishment for trusted channels. This will generally apply to all conformant TOEs, except in the rare (but possible) case where only key encapsulation is used.

All of the above algorithms with the selectable parameters are CNSA compliant.

Evaluation Activities

FCS_CKM_EXT.7

TSS

The evaluator shall ensure that the TSS documents that the security strength of the material contributed by the TOE is sufficient for the security strength of the key and the agreement method.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

KAS2

Identifier	Cryptographic Algorithm	Cryptographic Parameters	List of Standards
KAS2	RSA	Modulus Size [selection: 3072, 4096, 6144, 8192] bits	NIST SP 800-56B Revision 2 (Section 8.3) [KAS2]

To test the TOE’s implementation of the of the KAS2 RSA Key Agreement scheme, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters:

RSA Private key format [Basic, Prime Factor, Chinese Remainder Theorem]
Modulo value [3072, 4096, 6144, 8192]
Role [initiator, responder]

The evaluator shall generate a test group (i.e., set of tests) for each parameter value of the above parameter type with the largest number of supported values. For example, if the TOE supports all five Modulo values, then the evaluator shall generate five test groups. Each of the above supported parameter values must be included in at least one test group.

Regardless of how many parameter values are supported, there must be at least two test groups.

Half of the test groups are designated as Algorithm Functional Tests (AFT) and the remainder are designated as Validation Tests (VAT). If there is an odd number of groups, then the extra group is designated randomly as either AFT or VAT.

Algorithm Functional Test
For each test group designated as AFT, the evaluator shall generate 10 test cases using random data (except for a fixed public exponent, if supported). The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs.

Validation Test
For each test group designated as VAT, the evaluator shall generate 25 test cases are using random data (except for a fixed public exponent, if supported). Of the 25 test cases:

Two test cases must have a shared secret with a leading nibble of 0s,
Two test cases have modified derived key material,
Two test cases have modified tags, if key confirmation is supported,
Two test cases have modified MACs, if key confirmation is supported, and
The remaining test cases are not modified.

To determine correctness, the evaluator shall confirm that the resulting 25 shared secrets correspond as expected for both the modified and unmodified values.

FFC Diffie-Hellman Key Agreement

Identifier	Cryptographic Algorithm	Cryptographic Parameters	List of Standards
DH	Finite Field Cryptography Diffie-Hellman	Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]	NIST SP 800-56A Revision 3 (Section 5.7.1.1) [DH] [selection: RFC 3526 [IKE Groups], RFC 7919 [TLS Groups]]

To test the TOE’s implementation of FFC Diffie-Hellman Key Agreement, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters:

Domain Parameter Group [MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]

Algorithm Functional Test
For each supported domain parameter group, the evaluator shall generate 10 test cases by generating the initiator and responder secret keys using random data, calculating the responder public key, and creating the shared secret. The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs.

Validation Test
For each supported combination of the above parameters the evaluator shall generate 15 Diffie Hellman initiator/responder key pairs using the key generation function of a known-good implementation. For each set of key pairs, the evaluator shall modify five initiator private key values. The remaining key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall confirm that the 15 shared secrets correspond as expected for both the modified and unmodified inputs.

Elliptic Curve Diffie-Hellman Key Agreement

Identifier	Cryptographic Algorithm	Cryptographic Parameters	List of Standards
ECDH	Elliptic Curve Diffie-Hellman	Elliptic Curve [selection: P-384, P-521]	NIST SP 800-56A Revision 3 (Section 5.7.1.2) [ECDH] NIST SP 800-186 (Section 3.2.1) [NIST Curves]

To test the TOE’s implementation of Elliptic Curve Diffie-Hellman Key Agreement, the evaluator shall perform the Algorithm Functional Test and Validation Test using the following input parameters:

Elliptic Curve [P-384, P-521]

Algorithm Functional Test
For each supported Elliptic Curve the evaluator shall generate 10 test cases by generating the initiator and responder secret keys using random data, calculating the responder public key, and creating the shared secret. The resulting shared secrets shall be compared with those generated by a known-good implementation using the same inputs.

Validation Test
For each supported Elliptic Curve the evaluator shall generate 15 Diffie Hellman initiator/responder key pairs using the key generation function of a known-good implementation. For each set of key pairs, the evaluator shall modify five initiator private key values. The remaining key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall confirm that the 15 shared secrets correspond as expected for the modified and unmodified values.

FTP_ITC.1 Inter-TSF Trusted Channel (Authorized IT Entities)

This component must be included in the ST if the TOE implements any of the following features:

Network Connectivity

FTP_ITC.1.1

The TSF shall [selection:

invoke platform-provided functionality to use [selection:
IPsec
SSH
mutually authenticated TLS
mutually authenticated DTLS
HTTPS
]
implement functionality using [selection:
IPsec as defined in the PP-Module for VPN Client
SSH as defined in the Functional Package for Secure Shell
mutually authenticated TLS as defined in the Package for Transport Layer Security
mutually authenticated DTLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1
]

] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: connectivity to remote [selection: systems, agents], audit server, [selection: authentication server, remote destination for monitored data, [assignment: other capabilities]] that is logically distinct from other communication channels and provides assured identification of its endpoints and protection of the channel data from modification or disclosure.

Application Note: The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel with authorized IT entities that the TOE interacts with to perform its functions.

Protection (by one of the listed protocols) is required at least for communications with the IT entities managed by the TOE (whether those are systems that are managed using APIs provided by those systems by default, specialized agents running on systems that are designed for the purpose of interacting with the TOE, or both) and with the server that collects the audit information. If it communicates with an authentication server (e.g., RADIUS), then the ST author chooses "authentication server" in FTP_ITC.1.1 and this connection must be protected by one of the listed protocols. The TSF collects data from remote systems or agents and it may or may not transmit this data further to another remote entity. For example, the TSF may generate reports of the monitored data and transmit these reports to an external system for archival purposes. If such an interface exists, then the ST author chooses "remote destination for monitored data" in the selection and this connection must similarly be protected by one of the listed protocols. If other authorized IT entities (e.g., NTP server) are protected, the ST author makes the appropriate assignments (for those entities) and selections (for the protocols that are used to protect those connections).

To summarize, all communications with external entities that require protection of data in transit must be defined and must use one of the protocols specified in the requirement. At minimum, the TSF must communicate with external entities for the purpose of performing Enterprise-Management functions against them, and with a remote audit server for external storage of audit data. Additional channels are not required in order for the TOE to achieve its minimum required functionality, but if any such channels are implemented, appropriate protections must be provided for them.

The trusted channel uses IPsec, TLS, DTLS, or HTTPS as the protocol that preserves the confidentiality and integrity of external communications. The ST author chooses the mechanism or mechanisms supported by the TOE.

If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If HTTPS is chosen, FCS_HTTPS_EXT.1 must be included in the ST.

If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell. It should be noted that due to constraints imposed by this PP that SHA-1 cannot be used.

If the ST author selects "mutually authenticated TLS as defined in the Package for Transport Layer Security" or "mutually authenticated DTLS as defined in the Package for Transport Layer Security," the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:

FCS_TLS_EXT.1:
- either TLS or DTLS is selected depending on the selection made in FTP_ITC.1.1
- either client or server is selected as appropriate
FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate):
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected
FCS_DTLSC_EXT.1.1 or FCS_DTLSS_EXT.1.1 (as appropriate):
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected

Protocol, RBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection.

FTP_ITC.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [selection: the TSF, another trusted IT product] to initiate communication via the trusted channel.

FTP_ITC.1.3

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to initiate communication via the trusted channel for [assignment: list of functions for which a trusted channel is required].

Application Note: While there are no requirements on the party initiating the communication, the ST author lists in the assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the authorized IT entity.

FTP_TRP.1 Trusted Path

This component must be included in the ST if the TOE implements any of the following features:

Network Connectivity

FTP_TRP.1.1

The TSF shall [selection:

invoke platform-provided functionality to use [selection:
IPsec
TLS
HTTPS
SSH
]
implement functionality using [selection:
IPsec as defined in the PP-Module for VPN Client
TLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1
SSH as defined in the Functional Package for Secure Shell
]

] to provide a trusted communication path between itself as a [selection: server, peer] and [remote] administrators that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from [modification, disclosure].

FTP_TRP.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [remote administrators] to initiate communication via the trusted path.

FTP_TRP.1.3

The TSF shall require the use of the trusted path for [initial administrator authentication, [remote administration]].

Application Note: This requirement ensures that authorized remote administrators initiate all communication with the TOE via a trusted path, and that all communications with the TOE by remote administrators is performed over this path. The data passed in this trusted communication channel are encrypted as defined in the protocol chosen in the first selection. The ST author chooses the mechanism or mechanisms supported by the TOE.

If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell.

If the ST author selects "TLS as defined in the Package for Transport Layer Security" the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:

FCS_TLS_EXT.1:
- TLS must be selected
- Server must be selected
FCS_TLSS_EXT.1.1:
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.

Protocol, RBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

If HTTPS is chosen, FCS_HTTPS_EXT.1 must be included in the ST.

Table 17: Auditable Events for Selection-based Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_SAR.1

No events specified	N/A
FAU_STG.2

No events specified	N/A
FCS_COP.1/KeyEncap

No events specified	N/A
FCS_COP.1/KeyWrap

No events specified	N/A
FCS_COP.1/SKC

No events specified	N/A
FCS_COP.1/XOF

No events specified	N/A
FCS_HTTPS_EXT.1

Failure of the certificate validity check	Issuer Name and Subject Name of certificate [selection: User's authorization decision, No additional information]
FCS_IV_EXT.1

No events specified	N/A
FCS_RBG.2

No events specified	N/A
FCS_RBG.3

No events specified	N/A
FCS_RBG.4

No events specified	N/A
FCS_RBG.5

No events specified	N/A
FCS_STG_EXT.2

No events specified	N/A
FIA_AFL.1

Unsuccessful login attempts limit is met or exceeded.	Origin of the attempt (e.g., IP address).
FIA_ENR_EXT.1

Failure of user authentication	Presented username
FIA_PMG_EXT.1

No events specified	N/A
FIA_UIA_EXT.1

All use of identification and authentication mechanisms.	Origin of the attempt (e.g., IP address).
FMT_MOF.1/MANAGEMENT_ENROLL

Enrollment by a user	Identity of user
FPT_FLS.1

Failure of the TSF.	None.
FPT_ITT.1

Initiation and termination of the trusted channel	Trusted channel protocol Identity of initiator and recipient
FPT_TST.1

Execution of self-tests.	None.
FTA_SSL.3

The termination of a remote session by the session locking mechanism.	None.
FTA_TAB.1

No events specified	N/A
FTP_TRP.1/Join

Initiation and termination of the trusted channel.	Trusted channel protocol.

FAU_SAR.1 Audit Review

The inclusion of this selection-based component depends upon selection in:

FAU_STG.1.1

FAU_SAR.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide [authorized administrators] with the capability to read [all audit information] from the audit data.

FAU_SAR.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide the audit data in a manner suitable for the authorized administrators to interpret the information.

Application Note: The intent of this requirement is to ensure that the administrator can view and interpret the audit data and to prevent unauthorized users from accessing the logs.

This SFR is claimed if "the TOE itself" or "local platform storage" is selected in FAU_STG.1.1.

FAU_STG.2 Audit Event Storage

The inclusion of this selection-based component depends upon selection in:

FAU_STG.1.1

FAU_STG.2.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to protect the stored audit data in the audit trail from unauthorized deletion.

Application Note: If "store audit data locally" is selected in FAU_STG.1.1, this SFR must be included in the ST.

The purpose of this requirement is to ensure that audit data are stored securely. The ST author is responsible for selecting whether audit data are maintained when audit storage or failure occurs. The ST author must choose a means by which audit data are saved and select the events during which the data will be saved. The TSF may rely on the underlying operating system for this functionality, and the first selection should be made appropriately.

FAU_STG.2.2

The TSF shall be able to [prevent] unauthorized modifications to the stored audit data in the audit trail.

FCS_COP.1/KeyEncap Cryptographic Operation - Key Encapsulation

The inclusion of this selection-based component depends upon selection in:

FCS_CKM.2.1

FCS_COP.1.1/KeyEncap

The TSF shall perform [key encapsulation] in accordance with a specified cryptographic algorithm [selection: Cryptographic algorithm] and cryptographic key sizes [selection: Cryptographic key sizes] that meet the following: [selection: List of standards] .

Table 18 provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyEncap.

Table 18: Allowable choices for FCS_COP.1/KeyEncap
Identifier	Cryptographic algorithm	Cryptographic key sizes	List of standards
ML-KEM	ML-KEM	Parameter set = ML-KEM-1024	NIST FIPS 203

Application Note: This SFR is claimed when "key encapsulation" is selected in FCS_CKM.2.1. For this PP, the only anticipated use of key encapsulation is the use of ML-KEM as part of key establishment for trusted communications.

Evaluation Activities

FCS_COP.1/KeyEncap

TSS

The evaluator shall ensure that the TSS documents that the selection of the key size is sufficient for the security strength of the key encapsulated.

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following test may require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

ML-KEM Key Encapsulation

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
ML-KEM	ML-KEM	Parameter set = ML-KEM-1024	NIST FIPS PUB 203

To test the TOE’s implementation of ML-KEM key encapsulation/decapsulation, the evaluator shall perform the Encapsulation Test and the Decapsulation Test using the following input parameters:

Encapsulation Parameters:
- Parameter set [ML-KEM-1024]
- Previously generated encapsulation key (ek)
- Random value (m) [32 bytes]
Decapsulation Parameters:
- Parameter set [ML-KEM-1024]
- Previously generated decapsulation key (dk)
- Previously generated ciphertext (c) [32 bytes]

Encapsulation Test

For each supported parameter set the evaluator shall generate 25 test cases consisting of an encapsulation key ek and random value m. For each test case the valuator shall require the implementation under test to generate the corresponding shared secret k and ciphertext c. To determine correctness, the evaluator shall compare the resulting values with those generated using a known-good implementation using the same inputs.

Encapsulation Key Check (if supported)

The evaluator shall generate 10 encapsulation keys such that:

Five of the encapsulation keys are valid, and
Five of the encapsulation keys are modified such that a value in the noisy linear system is encoded into the key as a value greater than Q.

The evaluator shall invoke the TOE’s Encapsulation Key Check functionality to determine the validity of the 10 keys. The unmodified keys should be determined valid, and the modified keys should be determined invalid.

Decapsulation Key Check (if supported)

The evaluator shall generate 10 decapsulation keys such that:

Five of the decapsulation keys are valid, and
Five of the decapsulation keys are modified such that the concatenated values ek||H(ek) will no longer match by modifying H(ek) to be a different value.

The evaluator shall invoke the TOE’s Decapsulation Key Check functionality to determine the validity of the 10 keys. The unmodified keys should be determined valid, and the modified keys should be determined invalid.

Decapsulation Test

For each supported parameter set the evaluator shall use a single previously generated decapsulation key dk and generate 10 test cases consisting of valid and invalid ciphertexts c. For each test case the evaluator shall require the implementation under test to generate the corresponding shared secret k whether or not the ciphertext is valid. To determine correctness, the evaluator shall compare the resulting values with those generated using a known-good implementation using the same inputs.

FCS_COP.1/KeyWrap Cryptographic Operation - Key Wrapping

The inclusion of this selection-based component depends upon selection in:

FCS_CKM.2.1

FCS_COP.1.1/KeyWrap

The TSF shall perform [key wrapping] in accordance with a specified cryptographic algorithm [selection: Cryptographic algorithm] and cryptographic key sizes [selection: Cryptographic key sizes] that meet the following: [selection: List of standards] .

Table 19 provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyWrap.

Table 19: Allowable choices for FCS_COP.1/KeyWrap
Identifier	Cryptographic algorithm	Cryptographic key sizes	List of standards
AES-KW	AES in KW mode	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (clause 6), NIST SP 800-38F (Section 6.2)] [KW mode]
AES-KWP	AES in KWP mode	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] NIST SP 800-38F (Section 6.3) [KWP mode]
AES-CCM	AES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM]
AES-GCM	AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based], IV construction; the tag must be of length [selection: 96, 104, 112, 120, 128] bits.	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM]

Application Note: This SFR is claimed when "key wrapping" is selected in FCS_CKM.2.1. NIST 800-57p1rev5 sec. 5.6.2 specifies that the size of key used to protect the key being transported should be at least the security strength of the key it is protecting.

Evaluation Activities

FCS_COP.1/KeyWrap

TSS

The evaluator shall ensure that the TSS documents that the selection of the key size is sufficient for the security strength of the key wrapped.

The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, nonces, and MACs in conformance with the relevant specifications.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

For tests of AES-GCM and AES-CCM, see testing for FCS_COP.1/AEAD.

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

AES-KW

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-KW	AES in KW mode	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (clause 6), NIST SP 800-38F (Section 6.2)] [KW mode]

To test the TOE’s ability to wrap keys using AES in Key Wrap mode the evaluator shall perform the Algorithm Functional Tests using the following input parameters:

Key size [256] bits
Keyword cipher type [cipher, inverse]
Payload sizes [128-4096] bits by 64s

Algorithm Functional Test

The evaluator shall generate 100 encryption test cases using random data for each combination of claimed key size, keyword cipher type, and six supported payload sizes such that the payload sizes include the minimum, the maximum, two that are divisible by 128, and two that are not divisible by 128.

The results shall be compared with those generated by a known-good implementation using the same inputs.

The evaluator shall generate 100 decryption test cases using the same parameters as above, but with 20 of each 100 test cases having modified ciphertext to produce an incorrect result. To determine correctness, the evaluator shall confirm that the results correspond as expected for both the modified and unmodified values.

AES-KWP

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-KWP	AES in KWP mode	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] NIST SP 800-38F (Section 6.3) [KWP mode]

To test the TOE’s ability to wrap keys using AES in Key Wrap with Padding mode with padding the evaluator shall perform the Algorithm Functional Tests using the following input parameters:

Key size [256] bits
Keyword cipher type [cipher, inverse]
Payload sizes [8-4096] bits by 8s

Algorithm Functional Test

The evaluator shall generate 100 encryption test cases using random data for each combination of claimed key size, keyword cipher type, and six supported payload sizes such that the payload sizes include the minimum, the maximum, two that are divisible by 128, and two that are not divisible by 128.

The results shall be compared with those generated by a known-good implementation using the same inputs.

The evaluator shall generate 100 decryption test cases using the same parameters as above, but with 20 of each 100 test cases having modified ciphertext to produce an incorrect result. To determine correctness, the evaluator shall confirm that the results correspond as expected for both the modified and unmodified values.

FCS_COP.1/SKC Cryptographic Operation - Encryption/Decryption

The inclusion of this selection-based component depends upon selection in:

FCS_DTLSC_EXT.1.2, FCS_TLSC_EXT.1.2 from Functional Package for Transport Layer Security (TLS), version 2.1

FCS_COP.1.1/SKC

The TSF shall perform [symmetric-key encryption/decryption] in accordance with a specified cryptographic algorithm [selection: Cryptographic Algorithm] and cryptographic key sizes [selection: Cryptographic Key Sizes] that meet the following: [selection: List of Standards] .

Table 20 provides the allowable choices for completion of the selection operations of FCS_COP.1/SKC.

Table 20: Allowable choices for FCS_COP.1/SKC
Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CBC	AES in CBC mode with non-repeating and unpredictable IVs	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC]
XTS-AES	AES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer	512 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS]
AES-CTR	AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR]

Evaluation Activities

FCS_COP.1/SKC

TSS

The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, tweak values, and counters in conformance with the relevant specifications.

If XTS-AES is claimed then the evaluator shall examine the TSS to verify that the TOE creates full-length keys by methods that ensure that the two key halves are different and independent.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

AES-CBC

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CBC	AES in CBC mode with non-repeating and unpredictable IVs	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC]

To test the TOE’s ability to encrypt/decrypt data using AES in CBC mode, the evaluator shall perform Algorithm Functional Tests and Monte Carlo Tests using the following input parameters:

Key size [256] bits
Direction [encryption, decryption]

Algorithm Functional Tests

Algorithm Functional Tests are designed to verify the correct operation of the logical components of the algorithm implementation under normal operation using different block sizes. For AES-CBC, there are two types of AFTs:

Known-Answer Tests

For each combination of direction and claimed key size, the TOE must be tested using the GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002.

Multi-Block Message Tests

For each combination of direction and claimed key size, the TOE must be tested against 10 test cases consisting of a random IV, random key, and random plaintext/ciphertext. The plaintext/ciphertext starts with a length of 16 bytes and increases by 16 bytes for each test case until reaching 160 bytes.

Monte Carlo Tests

Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE must process the test cases according to the following algorithm once for each combination of direction and key size:

                    Key[0] = Key
                    IV[0] = IV
                    PT[0] = PT
                    for i = 0 to 99 {
                    Output Key[i], IV[i], PT[0]
                    for j = 0 to 999 {
                    if (j == 0) {
                    CT[j] = AES-CBC-Encrypt(Key[i], IV[i], PT[j])
                    PT[j+1] = IV[i]
                    } else {
                    CT[j] = AES-CBC-Encrypt(Key[i], PT[j])
                    PT[j+1] = CT[j-1]
                    }
                    }
                    Output CT[j]
                    AES_KEY_SHUFFLE(Key, CT)
                    IV[i+1] = CT[j]
                    PT[0] = CT[j-1]
                    }

where

AES_KEY_SHUFFLE

is defined as:

                    If ( keylen = 128 )
                    Key[i+1] = Key[i] xor MSB(CT[j], 128)
                    If ( keylen = 192 )
                    Key[i+1] = Key[i] xor (LSB(CT[j-1], 64) || MSB(CT[j], 128))
                    If ( keylen = 256 )
                    Key[i+1] = Key[i] xor (MSB(CT[j-1], 128) || MSB(CT[j], 128))

The above pseudocode is for encryption. For decryption, swap all instances of CT and PT.

The initial IV, key, and plaintext/ciphertext should be random.

The evaluator shall test the decrypt functionality using the same test as above, exchanging CT and PT, and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.

XTS-AES

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
XTS-AES	AES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer	512 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS]

To test the TOE’s ability to encrypt/decrypt data using AES in XTS mode, the evaluator shall perform the Single Data Unit Test and the Multiple Data Unit Test using the following input parameters:

Direction [encryption, decryption]
Key size [512] bits
Tweak value format [128-bit hex string, data unit sequence number]

Single Data Unit Test

For each combination of claimed key size, direction, and supported tweak value format, the evaluator shall generate 50 test cases consisting of random payload data. The payload data size is determined randomly for each test case from supported values within the range [128-65536] bits. The payload size and data unit size must be equal.

Multiple Data Unit Test

For each combination of claimed key size, direction, and supported tweak value format, the evaluator shall generate 50 test cases consisting of random payload data. The payload data size is determined randomly for each test case from supported values within the range [128-65536] bits. Likewise, the data unit size is determined randomly for each test case from supported values within the range [128-65535] bits. The payload size and data unit size must not be equal.

The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

AES-CTR

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CTR	AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key.	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR]

To test the TOE’s ability to encrypt/decrypt data using AES in CTR mode, the evaluator shall perform the Algorithm Functional Test and the Counter Test using the following input parameters:

Direction [encryption, decryption]
Key size [256] bits

Algorithm Functional Tests

Algorithm Functional Tests are designed to verify the correct operation of the logical components of the algorithm implementation under normal operation using different block sizes. For AES-CTR, there are three types of AFTs:

Known-Answer Tests

For each combination of direction and claimed key size, the TOE must be tested using the GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002.

Single Block Message Tests

For each combination of direction and claimed key, the evaluator shall generate 10 test cases with a data size of 128 bits.

Partial Block Message Tests

Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE must process the test cases according to the following algorithm once for each combination of direction and key size:

For each combination of direction and claimed key, the evaluator shall generate five test cases such that the data size is not a multiple of 128 bits.

The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.
Counter Test

The evaluator shall generate a single message of 1000 blocks (128000 bits) and either encrypt or decrypt it. Back-compute the IVs used. Verify that they are unique and increasing (encryption) or decreasing (decryption).

FCS_COP.1/XOF Cryptographic Operation - Extendable-Output Function

The inclusion of this selection-based component depends upon selection in:

FCS_CKM.1.1/AKG,
FCS_COP.1.1/SigVer

FCS_COP.1.1/XOF

The TSF shall perform [extendable-output function] in accordance with a specified cryptographic algorithm [selection: Cryptographic Algorithm] and parameters [selection: Parameters] that meet the following: [selection: List of Standards] .

Table 21 provides the allowable choices for completion of the selection operations of FCS_COP.1/XOF.

Table 21: Allowable choices for FCS_COP.1/XOF
Cryptographic Algorithm	Parameters	List of Standards
SHAKE	Functions = [SHAKE256]	NIST FIPS PUB 202 Section 6.2 [SHAKE]

Application Note: In accordance with CNSA, SHAKE is permitted to be used only as a component of LMS or XMSS. Therefore this component is claimed only if LMS or XMSS is claimed in FCS_COP.1/SigVer.

Evaluation Activities

FCS_COP.1/XOF

TSS

There are no additional TSS evaluation activities for this component.

Guidance

There are no additional Guidance evaluation activities for this component.

Tests

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

SHAKE

Cryptographic Algorithm	Parameters	List of Standards
SHAKE	Function = [SHAKE256]	NIST FIPS PUB 202 Section 6.2 [SHAKE]

To test the TOE’s implementation of the SHAKE Extendable Output Function the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Variable Output Test using the following input parameters:

Function [SHAKE256]
Output length [16-65536] bits

Algorithm Functional Test

For each supported function, generate test cases consisting of random data for every message length from 0 bits (if supported) to rate-1 bits, where rate equals

1088.

Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits starting at length rate, and continuing until 65535 is exceeded.

Monte Carlo Test

The Monte Carlo test takes in a single 128-bit message (SEED) and desired output length in bits, and runs 100 iterations of the chained computation. MaxOutBytes and MinOutBytes are the largest and smallest supported input and output sizes in bytes, respectively.

                  Range = maxOutBytes - minOutBytes + 1
                  OutputLen = maxOutBytes
                  For j = 0 to 99
                  MD[0] = SEED
                  For i = 1 to 1000
                  MSG[i] = 128 leftmost bits of MD[i-1]
                  if (MSG[i] < 128 bits)
                  Append 0 bits on rightmost side of MSG[i] til MSG[i] is 128 bits
                  MD[i] = SHAKE(MSG[i], OutputLen * 8)
                  
                  RightmostOutputBits = 16 rightmost bits of MD[i] as an integer
                  OutputLen = minOutBytes + (RightmostOutputBits % Range)
                  Output MD[1000], OutputLen
                  SEED = MD[1000]

Variable Output Test

This test measures the ability of the TOE to generate output digests of varying sizes.

The evaluator shall generate 512 test cases such that the input for each test case consists of 128- bits of random data, and the output length includes the minimum supported value, the maximum supported value, and 510 random values between the minimum and maximum digest sizes supported by the implementation.

FCS_HTTPS_EXT.1 HTTPS Protocol

The inclusion of this selection-based component depends upon selection in:

FPT_ITT.1.1,
FTP_ITC.1.1,
FTP_TRP.1.1

FCS_HTTPS_EXT.1.1

The TSF shall [selection: invoke platform-provided functionality to implement, implement] the HTTPS protocol that complies with RFC 2818.

FCS_HTTPS_EXT.1.2

The TSF shall [selection: invoke platform-provided functionality to implement, implement] HTTPS using TLS in accordance with Functional Package for Transport Layer Security (TLS), version 2.1.

Application Note: The requirement is claimed if the TSF selects HTTPS in any iteration of FPT_ITT.1, FTP_ITC.1, or FTP_TRP.1. It is expected that if the TOE invokes platform-provided functionality to perform HTTPS, that the platform implementation of HTTPS is conformant to the functional package.

FCS_IV_EXT.1 Initialization Vector Generation

The inclusion of this selection-based component depends upon selection in:

FCS_STG_EXT.1.1

FCS_IV_EXT.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate IVs in accordance with Table 22.

Application Note: This requirement must be included in the ST if the selection in FCS_STG_EXT.1 indicates that the TSF is protecting private keys and persistent secrets with encryption rather than the platform-provided key storage.

Table 22 lists the requirements for composition of IVs according to the corresponding NIST Special Publications for each cipher mode. The composition of IVs generated for encryption according to a cryptographic protocol is addressed by the protocol. Thus, this requirement addresses only IVs generated for key storage encryption.

Table 22: References and IV Requirements for NIST-approved Cipher Modes

Cipher Mode	Reference	IV Requirement
Electronic Codebook (ECB)	SP800-38A	No IV
Counter (CTR)	SP800-38A	"Initial Counter" shall be non-repeating. No counter value shall be repeated across multiple messages with the same secret key.
Cipher Block Chaining (CBC)	SP800-38A	IVs shall be unpredictable. Repeating IVs leak information about whether the first one or more blocks are shared between two messages, so IVs should be non-repeating in such situations.
Output Feedback (OFB)	SP800-38A	IVs shall be non-repeating and shall not be generated by invoking the cipher on another IV.
Cipher Feedback (CFB)	SP800-38A	IVs should be non-repeating as repeating IVs leak information about the first plaintext block and about common shared prefixes in messages.
XOR Encrypt XOR (XEX) Tweakable Block Cipher with Ciphertext Stealing (XTS)	SP800-38E	No IV. Tweak values shall be non-negative integers, assigned consecutively, and starting at an arbitrary non-negative integer.
Cipher-based Message Authentication Code (CMAC)	SP800-38B	No IV
Key Wrap and Key Wrap with Padding	SP800-38F	No IV
Counter with CBC-Message Authentication Code (CCM)	SP800-38C	No IV. Nonces shall be non-repeating.
Galois Counter Mode (GCM)	SP800-38D	IV shall be non-repeating. The number of invocations of GCM shall not exceed 2^32 for a given secret key unless an implementation only uses 96-bit IVs (default length).

FCS_RBG.2 Random Bit Generation (External Seeding)

The inclusion of this selection-based component depends upon selection in:

FCS_RBG.1.2

FCS_RBG.2.1

The TSF shall be able to accept a minimum input of [384 bits of min-entropy] from a TSF interface for obtaining entropy.

Application Note:

This SFR is claimed if "TSF interface for obtaining entropy" is selected in FCS_RBG.1.2, i.e., the TOE's entropy source is outside the TOE boundary.

If the environmental entropy source produces full entropy, the amount of entropy data collected is equal to the amount specified in the selection. If the entropy source does not assure full entropy (i.e., the ratio of min-entropy to collected data is less than 1:1), then the TSF must collect sufficient additional entropy data and perform a derivation function on it to reduce the collected data to a seed with the claimed min-entropy. In this case, the entropy documentation is expected to identify the min-entropy rate of the source data, how much data the TSF collects, and what derivation function is performed on this collected data to ensure that it has the claimed min-entropy.

One should not apply NIST SP 800-90B (or AIS-31) statistical tests against an external entropy source since the TSF is unable to enforce entropy requirements or conditioning requirements against something outside of its logical boundary. However, the TSS may include estimates for min-entropy from external sources that contribute to the overall entropy requirements for the DRBG.

FCS_RBG.3 Random Bit Generation (Internal Seeding - Single Source)

The inclusion of this selection-based component depends upon selection in:

FCS_RBG.1.2

FCS_RBG.3.1

The TSF shall be able to seed the DRBG using a [selection, choose one of: TSF software-based entropy source, TSF hardware-based entropy source] [assignment: name of entropy source] with [a minimum of 384] bits of min-entropy.

Application Note:

This SFR is claimed if "TSF entropy source..." is selected in FCS_RBG.1.2, i.e., the TOE has a single entropy source that is inside the TOE boundary. If the TOE obtains seed material from an environmental component, this is specified using FCS_RBG.2.

If the TSF entropy source produces full entropy, the amount of entropy data collected is equal to the amount specified in the selection. If the entropy source does not assure full entropy (i.e., the ratio of min-entropy to collected data is less than 1:1), then the TSF must collect sufficient additional entropy data and perform a derivation function on it to reduce the collected data to a seed with the claimed min-entropy. In this case, the entropy documentation is expected to identify the min-entropy rate of the source data, how much data the TSF collects, and what derivation function is performed on this collected data to ensure that it has the claimed min-entropy.

One can apply NIST SP 800-90B (or AIS-31) statistical tests against internal entropy sources (aka raw entropy) to confirm the min-entropy of the entropy source.

FCS_RBG.4 Random Bit Generation (Internal Seeding - Multiple Sources)

The inclusion of this selection-based component depends upon selection in:

FCS_RBG.1.2

FCS_RBG.4.1

The TSF shall be able to seed the DRBG using [selection: [assignment: number] independent TSF software-based entropy source(s), [assignment: number] independent TSF hardware-based entropy source(s)].

Application Note:

This SFR is claimed if "multiple independent TSF entropy sources..." is selected in FCS_RBG.1.2, i.e., the TSF performs some sort of operation to combine data from multiple distinct sources into a value that is used to derive a seed. If the TOE has only a single entropy source, this is specified using FCS_RBG.3. FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy.

FCS_RBG.5 Random Bit Generation (Combining Entropy Sources)

The inclusion of this selection-based component depends upon selection in:

FCS_RBG.1.2

FCS_RBG.5.1

The TSF shall [assignment: combining operation] [selection: output from TSF entropy source(s), input from TSF interface(s) for obtaining entropy] resulting in a minimum of [384] bits of min-entropy to create the entropy input into the derivation function as defined in [assignment: list of standards].

Application Note:

This SFR is claimed if "multiple TSF entropy sources..." is selected in FCS_RBG.1.2, i.e., the TSF performs some sort of operation to combine data from multiple distinct sources into a value that is used to derive a seed. If the TOE has only a single entropy source, this is specified using FCS_RBG.3.

If the environmental entropy source produces full entropy, the amount of entropy data collected is equal to the amount specified in the selection. If the entropy source does not assure full entropy (i.e., the ratio of min-entropy to collected data is less than 1:1), then the TSF must collect sufficient additional entropy data and perform a derivation function on it to reduce the collected data to a seed with the claimed min-entropy. In this case, the entropy documentation is expected to identify the min-entropy rate of the source data, how much data the TSF collects, and what derivation function is performed on this collected data to ensure that it has the claimed min-entropy.

One can apply NIST SP 800-90B (or AIS-31) statistical tests against internal entropy sources (aka raw entropy) to confirm the min-entropy of the entropy sources either in aggregate or individually.

FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

The inclusion of this selection-based component depends upon selection in:

FCS_STG_EXT.1.1

FCS_STG_EXT.2.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to encrypt all keys using AES in the [selection: Key Wrap (KW) mode, Key Wrap with Padding (KWP) mode, GCM, CCM, CBC mode].

Application Note: This requirement states that keys used by the TSF shall not be kept in plaintext. The intent of this requirement is to ensure that the private keys, credentials, and persistent secrets cannot be accessed in the TOE in an unencrypted state, allowing an attacker to access keys without having to exhaust the AES key space.

This requirement must be included in the ST if the selection in FCS_STG_EXT.1 indicates that the TSF is protecting private keys and persistent secrets with encryption rather than the platform-provided key storage.

FIA_AFL.1 Authentication Failure Handling

The inclusion of this selection-based component depends upon selection in:

FIA_UIA_EXT.1.1

FIA_AFL.1.1

The TSF shall detect when an administrator configurable positive integer within [assignment: range of acceptable values] unsuccessful authentication attempts occur related to [administrator login using passwords].

FIA_AFL.1.2

When the defined number of unsuccessful authentication attempts has been [selection: met, surpassed], the TSF shall [selection: prevent the offending administrator from successfully establishing a remote session using any authentication method that involves a password until [assignment: action to unlock] is taken by an administrator, prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until an administrator defined time period has elapsed]

Application Note: This SFR is included in the ST if "Web GUI Password" or "SSH password" are selected in FIA_UIA_EXT.1.1. Note that if password-based authentication is the sole mechanism used to access the TOE, it is necessary to provide a means to access the TOE locally in order to ensure that triggering the lockout mechanism cannot be used as a denial of service to the TSF.

Evaluation Activities

FIA_AFL.1

TSS

The evaluator shall examine the TSS to verify that it describes the existence of a lockout function for password-based administrator authentication and the action that is taken when it is triggered, and the mechanism by which a locked account is restored.

Guidance

The evaluator shall examine the operational guidance to verify that it describes how to configure the number of authentication failures that trigger a lockout, and the allowed range of values for this parameter. If the means for a locked account to be unlocked is time-based, the evaluator shall examine the operational guidance to verify that it describes how to configure the time period for the lockout, and the allowed values for this parameter. If the means for a locked account to be unlocked is based on administrative action, the evaluator shall examine the operational guidance to ensure that it identifies how an administrator may unlock a locked account.

Tests

The evaluator shall perform the following tests for each TSF management interface that supports password-based authentication: :

Test FIA_AFL.1:1: The evaluator shall configure the lockout behavior to lock an account after some number of invalid authentication attempts. The evaluator shall then deliberately enter invalid credentials on an administrator account and verify that further attempts are prevented when the configured value is met or exceeded, per the ST.
Test FIA_AFL.1:2: The evaluator shall repeat the previous test with a different configured value to ensure that the TSF enforces the new value.
Test FIA_AFL.1:3: [Conditional, a time-based unlock is supported] If a locked account is restored after a configurable time period, the evaluator shall configure the lockout period to be a certain amount of time, cause an account to be locked, and verify that the account is unlocked once the configured time period has elapsed.
Test FIA_AFL.1:4: [Conditional, a time-based unlock is supported] If a locked account is restored after a configurable time period, the evaluator shall repeat the previous test with a different configured time value and verify that the TSF enforces the new value.
Test FIA_AFL.1:5: [Conditional, an administrative unlock is supported] If a locked account is restored in response to some administrator action, the evaluator shall cause an account to be locked and then use a different account to restore it using the manner specified in the operational guidance.

FIA_ENR_EXT.1 Enrollment

The inclusion of this selection-based component depends upon selection in:

FIA_ENR_EXT.2.1

FIA_ENR_EXT.1.1

Three things to consider here:
1. Right now it just talks about "user" enrollment which is an MDM specific framing. Should think about other ways that enrollment could occur (e.g., based on individual device, group of devices) and what authentication is used for those (certificate on device? Key distributed by EM during the setup process?)
2. Right now this only applies to systems with agents but enrollment could potentially apply in an agentless scenario too. Might need a separate iteration for non-agent scenarios (but selection/feature-based, not mandatory)
3. FIA_ENR_EXT.1.2 talks about limitation on enrollment because it covers the MDM case where a user has to enroll a specific device that's associated with them. Not sure if we care about any such limitations in the context of EM and if we do what all those limitations would be. If we don't want any limitations we may need to define a new extended SFR because we probably can't have 1.2 say "The TSF shall do nothing related to this function".
The TSF shall authenticate the remote subjects over a trusted channel during the enrollment of a [selection: Host Agent, Agentless System].

FIA_ENR_EXT.1.2

pretty big departure from this SFR was originally written, we might need to get it a new name. Ideas for "eligibility features" from the call include characteristics of the system or agent being enrolled (compatibility? Minimum version?) or administrative action from FMT (administrator must specifically authorize something to be enrolled?) The TSF shall limit the ~~user's~~ enrollment of [selection: agents, systems] to those specified by [assignment: features that determine the eligibility of a system or agent for enrollment].

Application Note: This requirement is designed to permit the enterprise to restrict enrollment of systems or agents. There may be certain cases where the TSF does not want to unconditionally permit the registration of a system or agent to occur. For example, there may be maximum number of devices a user is allowed to have and attempts to register additional devices beyond this should fail.

Evaluation Activities

FIA_ENR_EXT.1.1

TSS

The evaluator shall examine the TSS and verify that it describes the process of enrollment for each agent or platform listed as supported in the ST. This description shall include the trusted path used for enrollment (FTP_TRP.1/TRUSTPATH_ENROLL), the method of user authentication (username or password, token, etc.), the method of authentication decision (local or remote authentication services), and the actions performed on the TOE upon successful authentication.

Guidance

The evaluator shall examine the operational guidance to verify that it describes the process by which the TOE enrolls endpoints into management.

Tests

:

Test FIA_ENR_EXT.1.1:1: The evaluator shall attempt to enroll a device without providing correct credentials. The evaluator shall verify that the device is not enrolled and that the described enrollment actions are not taken.
Test FIA_ENR_EXT.1.1:2: The evaluator shall attempt to enroll the device providing correct credentials. The evaluator shall verify that the device is enrolled and that the described enrollment actions are taken.

FIA_ENR_EXT.1.2

TSS

todo update these The evaluator shall examine the TSS and verify that it implements a policy to limit the user's enrollment of devices.

Guidance

The evaluator shall ensure that the administrative guidance describes the methods of restricting user enrollment and that it instructs the administrator how to configure the restrictions.

Tests

For each type of policy selected, the evaluator shall perform the following: :

Test FIA_ENR_EXT.1.2:1: The evaluator shall attempt to configure the TOE according to the administrative guidance in order to prevent enrollment. The evaluator shall verify that the user cannot enroll a device outside of the configured limitation. (For example, the evaluator may try to enroll a disallowed device, or may try to enroll additional devices beyond the number allowed.)

FIA_PMG_EXT.1 Password Management

The inclusion of this selection-based component depends upon selection in:

FIA_UIA_EXT.1.1

FIA_PMG_EXT.1.1

The TSF shall provide the following password management capabilities for administrative passwords:

Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, [assignment: other characters]]
Minimum password length shall be [configurable to between [assignment: minimum number of characters supported by the TOE] and [assignment: number of characters greater than or equal to 15] characters].

.

Application Note: This SFR is included in the ST if "Web GUI Password" or "SSH password" are selected in FIA_UIA_EXT.1.1.

Evaluation Activities

FIA_PMG_EXT.1

TSS

The evaluator shall check that the TSS:

lists the supported special character(s) for the composition of administrator passwords.
states that the minimum password length is configurable by an administrator.
lists the range of values supported for the minimum password length. The listed range shall include the value of 15.

Guidance

The evaluator shall examine the guidance documentation to determine that it:

identifies the characters that may be used in passwords and provides guidance to security administrators on the composition of strong passwords, and
provides instructions on setting the minimum password length and describes the valid minimum password lengths supported.

Tests

The evaluator shall perform the following tests: :

Test FIA_PMG_EXT.1:1: The evaluator shall compose passwords that meet the requirements in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, and a minimum length listed in the requirement are supported and justify the subset of those characters chosen for testing.
Test FIA_PMG_EXT.1:2: The evaluator shall compose passwords that do not meet the requirements in some way. For each password, the evaluator shall verify that the TOE does not support the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that the TOE enforces the allowed characters and the minimum length listed in the requirement and justify the subset of those characters chosen for testing.

FIA_UIA_EXT.1 User Identification and Authentication

The inclusion of this selection-based component depends upon selection in:

FIA_UAU.1.2

FIA_UIA_EXT.1.1

The TSF shall provide the following authentication mechanisms: [selection: Web GUI password, SSH password, SSH public key, X.509 certificate, [assignment: other authentication mechanism]]

Application Note: This SFR is included in the ST if "implement functionality" is selected in FIA_UAU.1.2.
If either "password" option is selected, or the assignment is used for any other password-based authentication mechanism, the ST must include the selection-based SFRs FIA_AFL.1 and FIA_PMG_EXT.1.

FMT_MOF.1/MANAGEMENT_ENROLL Management of Security Functions Behavior (Enrollment)

The inclusion of this selection-based component depends upon selection in:

FIA_ENR_EXT.2.1

FMT_MOF.1.1/MANAGEMENT_ENROLL

The TSF shall restrict the ability to [initiate the enrollment process] to [authorized administrators].

Application Note: This requirement outlines the enrollment functions that both administrators and users may perform. The enrollment actions are identified in the TSS as a part of FIA_ENR_EXT.1.

FPT_FLS.1 Failure with Preservation of Secure State

The inclusion of this selection-based component depends upon selection in:

FCS_RBG.1.1

FPT_FLS.1.1

The TSF shall preserve a secure state when the following types of failures occur: [DRBG self-test failure].

Application Note: This SFR is claimed when "implement functionality" is selected in FCS_RBG.1.1. The intent of this requirement is to ensure that cryptographic services requiring random bit generation cannot be performed if a failure of a self-test defined in FPT_TST.1 occurs.

FPT_ITT.1 Internal TOE TSF Data Transfer

The inclusion of this selection-based component depends upon selection in:

FDP_IFF.1.3

FPT_ITT.1.1

The TSF shall [selection:

invoke platform-provided functionality to use [selection:
IPsec,
mutually authenticated TLS,
mutually authenticated DTLS,
HTTPS,
SSH
]
implement functionality using [selection:
IPsec as defined in ,
mutually authenticated TLS as defined in Functional Package for Transport Layer Security (TLS), version 2.1,
mutually authenticated DTLS as defined in Functional Package for Transport Layer Security (TLS), version 2.1,
HTTPS in accordance with FCS_HTTPS_EXT.1,
SSH as defined in Functional Package for Secure Shell (SSH), version 2.0
]

] to protect all data from [disclosure and modification] when it is transferred between separate parts of the TOE.

Application Note: This requirement ensures that all communications between components of a distributed TOE are protected through the use of an encrypted communications channel.

The trusted channel uses secure protocols that preserve the confidentiality and integrity of communications. For this particular use, any of IPsec, TLS, DTLS, HTTPS, or SSH can be used. If TLS or DTLS is used, mutual authentication must be supported regardless of whether the TOE acts as the client or the server in this connection. Where X.509 validation is needed (e.g., if the TOE acts as a TLS server that supports mutual authentication), Functional Package for X.509, version 1.0 must be claimed. To distinguish X.509 validation for internal communications from validation for external communications (e.g., communication between TOE components versus communication to a remote IT entity in the operational environment), FIA_X509_EXT.1 from Functional Package for X.509, version 1.0 must be iterated for this use as "FIA_X509_EXT.1/Internal" per the guidance in . This channel may also be used as the registration channel for the registration process, as described in section 3.1 and FCO_CPC_EXT.1.2.

If the ST author selects that the TSF implements "IPsec as defined in ," the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If the ST author selects that the TSF implements "SSH as defined in Functional Package for Secure Shell (SSH), version 2.0," the TSF must be validated against Functional Package for Secure Shell (SSH), version 2.0.

If the ST author selects that the TSF implements "mutually authenticated TLS as defined in Functional Package for Transport Layer Security (TLS), version 2.1" or "mutually authenticated DTLS as defined in Functional Package for Transport Layer Security (TLS), version 2.1," the TSF must be validated against requirements from Functional Package for Transport Layer Security (TLS), version 2.1, with the following selections made:

FCS_TLS_EXT.1:
- either TLS or DTLS is selected depending on the selection made in FPT_ITT.1.1
- either client or server is selected as appropriate
FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate):
- The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected
FCS_DTLSC_EXT.1.1 or FCS_DTLSS_EXT.1.1 (as appropriate):
- The ciphersuites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected

Protocol, DRBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

This requirement is claimed if "FPT_ITT.1" is selected in FDP_IFF.1.

If HTTPS is selected, FCS_HTTPS_EXT.1 must be included in the ST. FCS_HTTPS_EXT.1 includes selections for both TSF and platform-provided HTTPS functionality, so this must be claimed if either of the HTTPS selections above are made.

FPT_TST.1 TSF Self-Testing

The inclusion of this selection-based component depends upon selection in:

FCS_RBG.1.1

FPT_TST.1.1

The TSF shall run a suite of the following self-tests [during initial start-up, [selection: periodically during normal operation, at the request of the authorized user, at the conditions [assignment: conditions under which self-test should occur], at no other time]] to demonstrate the correct operation of [TSF DRBG specified in FCS_RBG.1]: [assignment: DRBG health tests].

FPT_TST.1.2

The TSF shall provide authorized users with the capability to verify the integrity of [[DRBG seed and output data]].

FPT_TST.1.3

The TSF shall provide authorized users with the capability to verify the integrity of [[TSF DRBG specified in FCS_RBG.1]].

Application Note: This SFR is claimed when "implement functionality" is selected in FCS_RBG.1.1. It is intended to require that any DRBG implemented by the TOE undergo health testing at startup (and optionally in other circumstances) to ensure that the random bit generation functionality has not been degraded. If the TSF supports multiple DRBGs, this SFR should be iterated to describe the self-test behavior for each. The TSF's response to a DRBG health test failure is addressed by in FPT_FLS.1.

FPT_TUD_EXT.2 Integrity for Installation and Update

The inclusion of this selection-based component depends upon selection in:

FPT_TUD_EXT.1.3,
FPT_TUD_EXT.1.5

FPT_TUD_EXT.2.1

The application shall be distributed using [selection: the format of the platform-supported package manager, a container image].

FPT_TUD_EXT.2.2

The application shall be packaged such that its removal results in the deletion of all traces of the application, with the exception of configuration settings, output files, and audit/log events.

Application Note: Application software bundled with the system/firmware image are not subject to this requirement if the user is unable to remove the application through means provided by the OS.

FPT_TUD_EXT.2.3

The application installation package shall be digitally signed such that [selection:

its platform can cryptographically verify them prior to installation.
the application can verify them using [selection: Leighton-Micali Signature., eXtended Merkle Signature Scheme]

].

Application Note:

The specifics of the verification of installation packages involves requirements on the platform (and not the application), so these are not fully specified here.

If "Leighton-Micali Signature" or "eXtended Merkle Signature Scheme" is selected, the corresponding selection must be made in FCS_COP.1/SigVer.

Evaluation Activities

FPT_TUD_EXT.2.1

TSS

The evaluator shall verify that the TSS describes how the application is distributed and verify that description aligns with the selections in the ST.

Guidance

None.

Tests

If a container image is claimed, the evaluator shall verify that application updates are distributed as container images. If the format of the platform-supported package manager is claimed, the evaluator shall verify that application updates are distributed in the format supported by the platform. This varies per platform: :

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application is packaged in the standard Windows Installer (.MSI) format, the Windows Application Software (.EXE) format signed using the Microsoft Authenticode process, or the Windows Universal Application package (.APPX) format. See https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx for details regarding Authenticode signing.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application is packaged in the IPA format.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application is packaged in the format of the package management infrastructure of the chosen distribution. For example, applications running on Red Hat and Red Hat derivatives shall be packaged in RPM format. Applications running on Debian and Debian derivatives shall be packaged in DEB format.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application is packaged in the PKG format.

:

The following content should be included if:

the TOE implements ""

The evaluator shall ensure that the application is packaged in the DMG format, the PKG format, or the MPKG format.

FPT_TUD_EXT.2.2

TSS

None.

Guidance

The evaluator shall verify the guidance documentation details how uninstallation of the application is performed.

Tests

:

The following content should be included if:

the TOE implements ""

The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox).

For all other platforms, the evaluator shall record the path of every file on the entire file system prior to installation of the application, and then install and run the application. Afterward, the evaluator shall uninstall the application, and compare the resulting file system to the initial record to verify that no files, other than configuration, output, and audit or log files, have been added to the file system.

FPT_TUD_EXT.2.3

TSS

The evaluator shall verify that the TSS identifies how the application installation package is signed by an authorized source. The definition of an authorized source must be contained in the TSS.

Guidance

None.

Tests

Conditional: if "the application can verify them using" is selected the evaluator shall perform the following tests: :

Test FPT_TUD_EXT.2.3:1: The evaluator shall ensure that the update has a digital signature belonging to the vendor prior to its installation. The evaluator shall modify the downloaded update in such a way that the digital signature is no longer valid. The evaluator will then attempt to install the modified update. The evaluator shall ensure that the modified update fails to install.
Test FPT_TUD_EXT.2.3:2: The evaluator shall ensure that the update has a digital signature belonging to the vendor. The evaluator shall then attempt to install the update (or permit installation to continue). The evaluator shall ensure that the update successfully installs.

FTA_SSL.3 TSF-initiated termination

The inclusion of this selection-based component depends upon selection in:

FIA_UAU.1.2

FTA_SSL.3.1

The TSF shall terminate an interactive session after a [administrator-configurable time interval of session inactivity].

Application Note: This SFR is included in the ST if "implement functionality" is selected in FIA_UAU.1.2.

FTA_TAB.1 Default TOE access banners

The inclusion of this selection-based component depends upon selection in:

FIA_UAU.1.2

FTA_TAB.1.1

Before establishing a user session, the [selection: TSF, TOE platform] shall display an [administrator-specified advisory notice and consent warning] message.

Application Note: This SFR is claimed if "implement functionality" is selected in FIA_UAU.1.2. A conformant TOE may rely on its underlying platform for authentication (e.g. if the TSF is accessed through being launched in the context of a remote OS session rather than through a web server that it provides for that purpose). If the TSF relies on platform-provided functionality to authenticate users, there is no "pre-authentication" scenario where it would have the ability to display a banner, so this SFR is only required if it provides its own mechanism to do so.

FTP_TRP.1/Join Trusted Path (for Joining)

The inclusion of this selection-based component depends upon selection in:

FCO_CPC_EXT.1.2

FTP_TRP.1.1/Join

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide a communication path between itself and a joining component that is logically distinct from other communication paths and provides assured identification of [selection: the TSF endpoint, both joining component and TSF endpoint] and protection of the communicated data from [modification] and [selection: disclosure, none].

FTP_TRP.1.2/Join

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [selection: the TSF, the joining component] to initiate communication via the trusted path.

FTP_TRP.1.3/Join

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require the use of the trusted path for [joining components to the TSF under environmental constraints identified in [assignment: reference to operational guidance]].

Application Note: This SFR implements one of the types of channel identified in the main selection for FCO_CPC_EXT.1.2. The "joining component" in FTP_TRP.1/Join is the IT entity that is attempting to join the distributed TOE by using the registration process.

The effect of this SFR is to require the ability for components to communicate in a secure manner while the distributed TSF is being created (or when adding components to an existing distributed TSF). When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR.

The selection at the end of FTP_TRP.1/Join recognises that in some cases confidentiality (i.e., protection of the data from disclosure) may not be provided by the channel. The ST author distinguishes in the TSS whether in this case the TOE relies on the environment to provide confidentiality (as part of the constraints referenced in FTP_TRP.1.3/Join) or whether the registration data exchanged does not require confidentiality (in which case this assertion must be justified). If "none" is selected, then this word may be omitted in the ST to improve readability.

The assignment in FTP_TRP.1.3/Join ensures that the ST highlights any specific details needed to protect the registration environment. Note that when the ST uses FTP_TRP.1/Join for the registration channel, then this channel cannot be reused as the normal inter-component communication channel defined in FPT_ITT.1.

Evaluation Activities

FTP_TRP.1/Join

TSS

The evaluator shall examine the TSS to determine that the methods of joining TOE components are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of joining are consistent with those specified in the requirement, and are included in the requirements in the ST.

If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the TSF; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).

Guidance

The evaluator shall confirm that the operational guidance contains instructions for joining TOE components for each supported method.

Tests

The evaluator shall also perform the following tests: :

Test FTP_TRP.1/Join:1: The evaluator shall ensure that the communications path for joining components to the TSF is tested for each distinct (nonequivalent) component type, setting up the connections as described in the guidance documentation and ensuring that communication is successful. In particular the evaluator shall confirm that requirements on environment protection for the registration process are consistent with observations made on the test configuration (for example, a requirement to isolate the components from the Internet during registration might be inconsistent with the need for a component to contact a license server). If no requirements on the registration environment are identified as necessary to protect confidentiality, then the evaluator shall confirm that the key used for registration can be configured (following the instructions in the guidance documentation) to be at least the same length as the key used for the internal TSF channel that is being enabled. The evaluator shall confirm that the key used for the channel is unique to the pair of components (this is done by identifying the relevant key during the registration test: it is not necessary to examine the key value).
Test FTP_TRP.1/Join:2: The evaluator shall follow the guidance documentation to ensure that in fact the communication channel can be enabled by an administrator for all the TOE components identified in the guidance documentation as capable of initiation.
Test FTP_TRP.1/Join:3: The evaluator shall ensure that if the guidance documentation states that the channel data is encrypted then the data observed on the channel is not plaintext.
Test FTP_TRP.1/Join:4: The evaluator shall ensure that, for each different pair of nonequivalent component types that can use the registration channel, the connection is physically interrupted during a joining attempt. The evaluator shall ensure that when physical connectivity is restored, communications are appropriately protected.

Further evaluation activities are associated with the specific protocols.

Assurance	Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (base PP)	Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)	A Protection Profile developed by international technical communities and approved by multiple schemes.
Common Criteria (CC)	Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory	Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)	Common Evaluation Methodology for Information Technology Security Evaluation.
Direct Rationale	A type of Protection Profile, PP-Module, or Security Target in which the security problem definition (SPD) elements are mapped directly to the SFRs and possibly to the security objectives for the operational environment. There are no security objectives for the TOE.
Distributed TOE	A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)	A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages.
Functional Package (FP)	A document that collects SFRs for a particular protocol, technology, or functionality.
Operational Environment (OE)	Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)	An implementation-independent set of security requirements for a category of products.
Protection Profile Configuration (PP-Configuration)	A comprehensive set of security requirements for a product type that consists of at least one base PP and at least one PP-Module.
Protection Profile Module (PP-Module)	An implementation-independent statement of security needs for a TOE type complementary to one or more base PPs.
Security Assurance Requirement (SAR)	A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)	A requirement for security enforcement by the TOE.
Security Target (ST)	A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)	The product under evaluation.
TOE Security Functionality (TSF)	The security functionality of the product under evaluation.
TOE Summary Specification (TSS)	A description of how a TOE satisfies the SFRs in an ST.

Endpoint	A computing device that runs a general purpose OS, mobile device OS, or network device OS. Endpoints can include desktops, servers, and mobile devices.
Endpoint Detection and Response (EDR)	A system that analyzes collected EDR Host Agent data for detecting, investigating, and remediating unauthorized activities on endpoints.
Enrolled State	The state in which an endpoint with a running Host Agent is managed by an EM.
Enrollment	The process of transitioning an endpoint from an unenrolled to an enrolled state.
Enterprise Security Management (ESM)	A type of application hosted on one or more servers that provides support for security management, information flows, reporting, policy, and data analytics in complex enterprise environments.
Host Agent	A logical piece of software that executes on endpoints to collect data about the endpoint and executes commands sent to the endpoint from an EM server or service. An example command sent to an endpoint could be to enforce a policy from an EM, to collect some files, or to run an OS command.
Monitored Data	Information that the TSF collects from the enterprise for the purpose of reporting or using as a basis for exercising management functions. Depending on the design and architecture of the TOE, this may be collected through an agent or directly from a system.
Operating System (OS)	Software that manages physical and logical resources and provides services for applications.
Unenrolled State	The state in which an endpoint, with or without a Host Agent, is not managed by an EM.

Assurance Class	Assurance Components
Security Target (ASE)	Conformance Claims (ASE_CCL.1)
	Extended Components Definition (ASE_ECD.1)
	ST Introduction (ASE_INT.1)
	Security Objectives for the Operational Environment (ASE_OBJ.1)
	Direct Rationale Security Requirements (ASE_REQ.1)
	Security Problem Definition (ASE_SPD.1)
	TOE Summary Specification (ASE_TSS.1)
Development (ADV)	Basic Functional Specification (ADV_FSP.1)
Guidance Documents (AGD)	Operational User Guidance (AGD_OPE.1)
Guidance Documents (AGD)	Preparative Procedures (AGD_PRE.1)
Life Cycle Support (ALC)	Labeling of the TOE (ALC_CMC.1)
Life Cycle Support (ALC)	TOE CM Coverage (ALC_CMS.1)
Tests (ATE)	Independent Testing – Conformance (ATE_IND.1)
Vulnerability Assessment (AVA)	Vulnerability Survey (AVA_VAN.1)

Functional Class	Functional Components
Class FCO: Communication	FCO_CPC_EXT Component Registration Channel Definition
Class FCS: Cryptographic Support	FCS_CKM_EXT Cryptographic Key Management FCS_HTTPS_EXT HTTPS Protocol FCS_IV_EXT Initialization Vector Generation FCS_STG_EXT Cryptographic Key Storage
Class FDP: User Data Protection	FDP_DAR_EXT Data-at-Rest Encryption FDP_DEC_EXT Access to Platform Resources
Class FIA: Identification and Authentication	FIA_ENR_EXT Enrollment FIA_PMG_EXT Password Management FIA_UIA_EXT User Identification and Authentication
Class FMT: Management of the TSF	FMT_CFG_EXT Secure by Default Configuration FMT_MEC_EXT Supported Configuration Mechanism
Protection of the TSF (FPT)	FPT_API_EXT Use of Supported Services and APIs FPT_LIB_EXT Use of Third-Party Libraries FPT_TST_EXT Functionality Testing FPT_TUD_EXT Trusted Update

Hierarchical to:	No other components.
Dependencies to:	FPT_ITT.1 TSF Data Transfer FTP_TRP.1 Trusted Path

Acronym	Meaning
API	Application Programming Interface
base PP	Base Protection Profile
CC	Common Criteria
CEM	Common Evaluation Methodology
cPP	Collaborative Protection Profile
EA	Evaluation Activity
ECDSA	Elliptic Curve Digital Signature Algorithm
EDR	Endpoint Detection and Response
EP	Extended Package
ESM	Enterprise Security Management
FIPS	Federal Information Processing Standards
FP	Functional Package
IP	Internet Protocol
ISO	International Organization for Standardization
IT	Information Technology
NIAP	National Information Assurance Partnership
NIST	National Institute of Standards and Technology
OE	Operational Environment
OS	Operating System
PP	Protection Profile
PP-Configuration	Protection Profile Configuration
PP-Module	Protection Profile Module
RSA	Rivest, Shamir, Adleman (digital signature algorithm)
SAR	Security Assurance Requirement
SFR	Security Functional Requirement
ST	Security Target
TOE	Target of Evaluation
TSF	TOE Security Functionality
TSFI	TSF Interface
TSS	TOE Summary Specification

Identifier	Title
[CC]	Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and general model, CCMB-2022-11-001, CC:2022, Revision 1, November 2022. Part 2: Security functional requirements, CCMB-2022-11-002, CC:2022, Revision 1, November 2022. Part 3: Security assurance requirements, CCMB-2022-11-003, CC:2022, Revision 1, November 2022. Part 4: Framework for the specification of evaluation methods and activities, CCMB-2022-11-004, CC:2022, Revision 1, November 2022. Part 5: Pre-defined packages of security requirements, CCMB-2022-11-005, CC:2022, Revision 1, November 2022.
[CEM]	Common Methodology for Information Technology Security Evaluation - Evaluation methodology, CCMB-2022-11-006, CC:2022, Revision 1, November 2022.
[ERR]	Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1), Version 1.2, CCMB-2025-02-001, 15 October 2025.

Protection Profile for Enterprise Management

Revision History

Contents

1 Introduction

1.1 Overview

1.2 Terms

1.2.1 Common Criteria Terms

1.2.2 Technical Terms

1.3 Compliant Targets of Evaluation

1.3.1 TOE Boundary

1.3.2 TOE Platform

1.4 Use Cases

1.5 Implementation-Based Features

1.5.1 Distributed TOE

1.5.2 Network Connectivity

2 Conformance Claims

3 Introduction to Distributed TOEs

3.1 Registration of Distributed TOE Components

3.2 Allocation of Requirements in Distributed TOEs

4 Security Problem Definition

4.1 Threats

4.2 Assumptions

4.3 Organizational Security Policies

5 Security Objectives

5.1 Security Objectives for the Operational Environment

6 Security Requirements

6.1 Security Functional Requirements

6.1.1 Auditable Events for Mandatory SFRs

6.1.2 Class FAU: Security Audit

FAU_ALT_EXT.1 Server Alerts

FAU_GEN.1 Audit Data Generation

FAU_SAR_EXT.1 Monitored Event Review

FAU_SEL_EXT.1 Monitored Event Selection

FAU_STG.1 Audit Data Storage Location

FAU_STG_EXT.1 Monitored Data Storage Location

6.1.3 Class FCS: Cryptographic Support

FCS_CKM.1/AKG Cryptographic Key Generation - Asymmetric Key

FCS_CKM.1/SKG Cryptographic Key Generation - Symmetric Key

FCS_CKM.6 Timing and Event of Cryptographic Key Destruction

FCS_COP.1/AEAD Cryptographic Operation – Authenticated Encryption with Associated Data

FCS_COP.1/Hash Cryptographic Operation - Hashing

FCS_COP.1/KeyedHash Cryptographic Operation - Keyed-Hash

FCS_COP.1/SigGen Cryptographic Operation - Signature Generation

FCS_COP.1/SigVer Cryptographic Operation - Signature Verification

FCS_RBG.1 Random Bit Generation (RBG)

FCS_STG_EXT.1 Cryptographic Key Storage

6.1.4 Class FDP: User Data Protection

FDP_DAR_EXT.1 Encryption Of Sensitive Application Data

FDP_IFC.1 Subset Information Flow Control

FDP_IFF.1 Simple Security Attributes

FDP_NET_EXT.1 Network Communications

FDP_ITC.1 Import of User Data Without Security Attributes

6.1.5 Class FIA: Identification and Authentication

FIA_ENR_EXT.2 Method of Enrollment

FIA_UAU.1 Timing of Authentication

6.1.6 Class FMT: Management of the TSF

FMT_CFG_EXT.1 Secure by Default Configuration

FMT_MEC_EXT.1 Supported Configuration Mechanism

FMT_MOF.1 Management of Security Functions Behavior

FMT_SMF.1/INTERNAL Specification of Management Functions (Server Configuration of Server)

FMT_SMF.1/MANAGED Specification of Management Functions (Server configuration of Managed Systems)

FMT_SMR.1 Security Roles

6.1.7 Protection of the TSF (FPT)

FPT_AEX_EXT.1 Anti-Exploitation Capabilities

FPT_API_EXT.1 Use of Supported Services and APIs

FPT_LIB_EXT.1 Use of Third-Party Libraries

FPT_TUD_EXT.1 Support for Trusted Updates

6.1.8 TOE Security Functional Requirements Rationale

6.2 Security Assurance Requirements

6.2.1 Class ASE: Security Target

ASE_TSS.1 TOE summary specification

Developer action elements:

Content and presentation elements:

Evaluator action elements:

6.2.2 Class ADV: Development

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

Developer action elements:

Content and presentation elements:

Evaluator action elements:

6.2.3 Class AGD: Guidance Documentation