Comment: Comment-1-
Comment: Comment-2-
Comment: Comment-3-
Comment: Comment-4-
Comment: Comment-5-
Comment: Comment-6-
Comment: Comment-7-
Comment: Comment-8-

Protection Profile for Enterprise Management

NIAP Logo
Version: 2.0
2025-07-18
National Information Assurance Partnership

Revision History

VersionDateComment
2.02025-07-18Initial draft (version numbering chosen for alignment with the ESM family of modules)

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.3.2TOE Platform1.4Use Cases1.5Implementation-Based Features1.5.1Distributed TOE1.5.2Network Connectivity2Conformance Claims3Introduction to Distributed TOEs3.1Registration of Distributed TOE Components3.2Allocation of Requirements in Distributed TOEs4Security Problem Definition4.1Threats4.2Assumptions4.3Organizational Security Policies5Security Objectives5.1Security Objectives for the Operational Environment6Security Requirements6.1Security Functional Requirements6.1.1Auditable Events for Mandatory SFRs6.1.2Class FAU: Security Audit6.1.3Class FCS: Cryptographic Support6.1.4Class FDP: User Data Protection6.1.5Class FIA: Identification and Authentication6.1.6Class FMT: Management of the TSF6.1.7Protection of the TSF (FPT)6.1.8TOE Security Functional Requirements Rationale6.2Security Assurance Requirements6.2.1Class ASE: Security Target6.2.2Class ADV: Development6.2.3Class AGD: Guidance Documentation6.2.4Class ALC: Life-cycle Support6.2.5Class ATE: Tests6.2.6Class AVA: Vulnerability AnalysisAppendix A - Optional RequirementsA.1Strictly Optional Requirements A.1.1Class ALC: Life-cycle SupportA.2Objective Requirements A.3Implementation-dependent Requirements A.3.1Class FAU: Security AuditA.3.2Class FCO: CommunicationA.3.3Class FCS: Cryptographic SupportA.3.4Protection of the TSF (FPT)A.3.5Trusted Path/Channels (FTP)Appendix B - Selection-based Requirements B.1Class FAU: Security AuditB.2Class FCS: Cryptographic SupportB.3Class FIA: Identification and AuthenticationB.4Protection of the TSF (FPT)B.5TOE Access (FTA)B.6Trusted Path/Channels (FTP)Appendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Class FCO: CommunicationC.2.1.1FCO_CPC_EXT Component Registration Channel DefinitionC.2.2Class FCS: Cryptographic SupportC.2.2.1FCS_CKM_EXT Cryptographic Key ManagementC.2.2.2FCS_HTTPS_EXT HTTPS ProtocolC.2.2.3FCS_IV_EXT Initialization Vector GenerationC.2.2.4FCS_STG_EXT Cryptographic Key StorageC.2.3Class FDP: User Data ProtectionC.2.3.1FDP_DAR_EXT Data-at-Rest EncryptionC.2.3.2FDP_DEC_EXT Access to Platform ResourcesC.2.4Class FIA: Identification and AuthenticationC.2.4.1FIA_ENR_EXT EnrollmentC.2.4.2FIA_PMG_EXT Password ManagementC.2.4.3FIA_UIA_EXT User Identification and AuthenticationC.2.5Class FMT: Management of the TSFC.2.5.1FMT_CFG_EXT Secure by Default ConfigurationC.2.5.2FMT_MEC_EXT Supported Configuration MechanismC.2.6Protection of the TSF (FPT)C.2.6.1FPT_API_EXT Use of Supported Services and APIsC.2.6.2FPT_LIB_EXT Use of Third-Party LibrariesC.2.6.3FPT_TST_EXT Functionality TestingC.2.6.4FPT_TUD_EXT Trusted UpdateAppendix D - Inherently Satisfied RequirementsAppendix E - Entropy Documentation and AssessmentE.1Design DescriptionE.2Entropy JustificationE.3Operating ConditionsE.4Health TestingAppendix F - Evaluating Additional Components for a Distributed TOEF.1Evaluator Actions for Assessing the STF.2Evaluator Actions for Assessing the Guidance DocumentationF.3Evaluator Actions for Testing the TOEAppendix G - AcronymsAppendix H - Bibliography

1 Introduction

1.1 Overview

The scope of this Protection Profile (PP) is to describe the security functionality of an Enterprise-Management product (EM) in terms of [CC] and to define functional and assurance requirements for such products.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

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.

1.2.2 Technical Terms

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.

1.3 Compliant Targets of Evaluation

The PP for Enterprise-Management (EM) is intended to support Enterprise Security Management (ESM) products that are used to manage the configuration and behavior of endpoint systems in an enterprise setting, and providing monitoring and reporting capabilities for managed endpoints. EM supports ESM by applying policies that control the security-relevant behavior of systems. An EM product is specifically a type of software application.

An EM product may control the behavior of a system directly, or it may accomplish this by interacting with an agent that resides on that system. A conformant TOE may use different protocols to communicate with external entities. If IPsec is implemented for remote communications, the TOE boundary also includes the PP-Module for VPN Client.

1.3.1 TOE Boundary

The boundary for EM includes all processes, all modules, and libraries bundled with the product, to be run on a single server or multiple servers in a load balancing or failover configuration. This includes any local or remote management interface that is used to access the TOE for the purpose of configuration (whether of itself or of endpoints under the TOE's control), audit review, or any other supported administrative function. The TOE boundary includes communications channels with external entities. The platform operating system or execution environment upon which the TOE is executing is outside the scope of an EM evaluation. The figure below shows a sample deployment of an EM product within its larger operational environment, including remote systems for which it is responsible for managing.

TBD.

A conformant TOE may include only EM functionality, or it may include agents within the logical boundary of the TOE. If agents are included in the logical boundary, the TOE also conforms to the PP-Module for Host Agent. Agents may also reside in the operational environment such that the TOE boundary only includes the EM functionality and its interface to remote agents is an external interface. If agents are supported by the product but are not included within the TOE boundary, appropriate justification must be provided for their exclusion from the TOE.

A conformant TOE may be isolated to a single system, or it may be distributed across multiple systems, either because the TOE's EM functionality is distributed across multiple servers, or because the TOE boundary includes agents that are remote to the server.

A conformant TOE will generally communicate with external systems (whether via agents or not) that are logically remote to the TOE. However, some use cases exist where an EM product only manages policy on a central server.

A conformant TOE may provide endpoint detection and response (EDR) capability in addition to its EM capability. If this is the case, the TOE may also

1.3.2 TOE Platform

The TOE platform consists of a general purpose OS or an Execution Environment on top of which the EM software executes.

1.4 Use Cases

Requirements in this PP are designed to address the security problem for the following use cases. These use cases are intentionally very broad, as many different types of EM products may exist. As this PP is revised to allow for more specific types of EM products, additional use cases may be devised.
[USE CASE 1] Interfacing with Endpoints
The TOE communicates with an endpoint system and issues commands to this system to push, edit, or retrieve data. This could include deployment or updates to system software, applying configuration settings, executing custom scripts against the system, or establishing interactive remote access to the system.
[USE CASE 2] System Inventory
The TOE collects data about endpoint systems that can be queried or browsed. This could include data about the system's hardware, software, or configuration
[USE CASE 3] System Monitoring
The TOE has a persistent connection to endpoint systems to monitor those systems for anomalous activity, such as disk utilization, memory usage, configuration of system permissions, or the starting and stopping of executable services or processes on the system.

1.5 Implementation-Based Features

A conformant TOE may implement certain features that are not strictly necessary in order to achieve the desired level of security, but if these features are implemented, they are required to be included within the TOE boundary.

1.5.1 Distributed TOE

The TOE is distributed across multiple systems (whether multiple server instances or a TOE that has a server component connected to one or more agents on remote systems). These instances must have the ability to communicate securely with one another and exchange authentication data so that sensitive data in transit between them is protected and only sent to the appropriate destination. Note that a distributed TOE by definition also includes the Network Connectivity feature; a TOE that operates on a single system is not distributed even if it includes both management and agent components.

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

1.5.2 Network Connectivity

The TOE uses networking functionality to transmit policy data, commands, or both. This data can be transmitted to logically remote entities that are in the operational environment, between separate components of a logically distributed TOE, or both. Specifically for this feature, if this is supported by the product, it must be claimed as part of the TSF.

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.
CC Conformance Claims

This PP is conformant to Part 2 (extended) and Part 3 (extended) of Common Criteria CC:2022, Revision 1.
PP Claim

This PP does not claim conformance to any Protection Profile.

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP:
Package Claim

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Introduction to Distributed TOEs

This PP includes support for distributed TOEs. EM products can sometimes be composed of multiple components operating as a logical whole. There are a number of different architectures; but fundamentally, they are variations of the following model where the SFRs of this PP can only be fulfilled if the components are deployed and operate together. To be considered a distributed TOE, a minimum of two interconnected components are required.

3.1 Registration of Distributed TOE Components

When dealing with a distributed TOE, a number of separate components need to be brought together in the operational environment in order to create the TOE. This requires that trusted communications channels are set up between certain pairs of components (it is assumed that all components need to communicate with at least one other component, but not that all components need to communicate with all other components). The underlying model for creation of the TOE is to have a "registration process" in which components "join" the TOE. The registration process starts with two components, one of which (the "joiner") is about to join an existing TOE by registering with the other (the "gatekeeper"). The two components will use one or more specified authentication and communication channel options so that the components authenticate each other and protect any sensitive data that is transmitted during the registration process (e.g., a key might be sent by a gatekeeper to the joiner as a result of the registration). The following figures illustrate the three supported registration models. Figure 1 illustrates a distributed TOE registration approach which uses an instance of FPT_ITT.1 or FTP_ITC.1 to protect the registration exchange.


Figure 1: Distributed TOE registration using channel satisfying FPT_ITT.1 or FTP_ITC.1.


The second approach (Figure 2) uses an alternative registration channel and supports use cases where the channel relies on environmental security constraints to provide the necessary protection of the registration exchange.


Figure 2: Distributed TOE registration using channel satisfying FTP_TRP.1/TRUSTPATH_JOIN


The final approach (Figure 3) supports use cases where registration is performed manually through direct configuration of both the Joiner and Gatekeeper devices. Once configured, the two components establish an internal TSF channel that satisfies FPT_ITT.1 or FTP_ITC.1.


Figure 3: Distributed TOE registration without a registration channel


In each case, during the registration process, the administrator must positively enable the joining components before it can act as part of the TSF. Figure 4 illustrates the approaches that this enablement step may take;


Figure 4: Joiner enablement options for Distributed TOEs


Note that in the case where no registration channel is required, that is the joiner and gatekeeper are directly configured (Figure 3), enablement is implied as part of this direct configuration process.

After registration, the components will communicate between themselves using a normal SSH, TLS, DTLS, IPsec, or HTTPS channel (which is specified in an ST as an instance of FPT_ITT.1 or FTP_ITC.1 in terms of Section 6 Security Requirements and Table t-audit-optional ). This channel for inter-component communications is specified at the top level with the new (extended) SFR FCO_CPC_EXT.1 and is in addition to the other communication channels required for communication with any entities outside the TOE specified in FTP_ITC.1 or FTP_TRP.1.

3.2 Allocation of Requirements in Distributed TOEs

For a distributed TOE, the security functional requirements in this PP need to be met by the TOE as a whole, but not all SFRs will necessarily be implemented by all components. The following categories are defined in order to specify when each SFR must be implemented by a component:
Table 1 specifies how each of the SFRs in this PP must be met, using the categories above.

Table 1: Security Functional Requirements for Distributed TOEs
Requirement Description Distributed TOE SFR Allocation

Only those SFRs included in the ST are required to be audited. The ST for a distributed TOE must include a mapping of SFRs to each of the components of the TOE. (Note that this deliverable is examined as part of the ASE_TSS.1 and AVA_VAN.1 Evaluation Activities.) The ST for a distributed TOE may also introduce a "minimum configuration" and identify components that may have instances added to an operational configuration without affecting the validity of the CC certification. Appendix F - Evaluating Additional Components for a Distributed TOE describes Evaluation Activities relating to these equivalency aspects of a distributed TOE (and hence what is expected in the ST).

4 Security Problem Definition

4.1 Threats

T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with parts of the EM system with the intent of compromise. Engagement may consist of altering existing legitimate communications.
T.NETWORK_EAVESDROP
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between parts of the EM system.
T.LOCAL_ATTACK
An attacker may compromise applications running on the same computing platform on which part of the EM system executes or on the same computing platform of a system the TOE otherwise manages.
T.LIMITED_PHYSICAL_ACCESS
An attacker may attempt to access EM system data at rest on the endpoint devices.

4.2 Assumptions

A.COMPONENTS_RUNNING
This assumption applies to distributed TOEs only. For distributed TOEs, it is assumed that the availability of all TOE components is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. It is also assumed that in addition to the availability of all components it is also checked as appropriate that the audit functionality is running properly on all TOE components.
A.CONNECTIVITY
The TOE relies on network connectivity to carry out its management activities. It is assumed that TOE is able to access managed endpoints.
A.SERVER_PLATFORM
The TOE relies on a trustworthy platform and local network from which it provides administrative capabilities.

The TOE may rely on this platform to provide a range of security-related services including reliable timestamps, user and group account management, logon and logout services via a local or network directory service, remote access control, and audit log management services to include offloading of audit logs to other servers. The platform is expected to be configured specifically to support services required for the proper function and protection of the TOE, employing features such as a host-based firewall, which limits its network role to providing the designated EM functionality.
A.PROPER_ADMIN
One or more competent, trusted personnel who are not careless, willfully negligent, or hostile, are assigned and authorized as the TOE Administrators, and do so using and abiding by guidance documentation.

4.3 Organizational Security Policies

P.ACCOUNTABILITY
Personnel operating the TOE shall be accountable for their actions within the TOE.
P.ADMIN
The TOE is configured in a manner that allows it to enforce existing organizational security policies, to the extent that such policies are enforceable by the TSF.
P.ENROLL
The TOE has a defined set of assets that it interacts with for the purpose of enterprise management. Administrators take care to ensure that these assets are specified as necessary through configuration of the TOE, including any mechanism that may exist for enrollment.

5 Security Objectives

5.1 Security Objectives for the Operational Environment

OE.AVAILABILITY
Administrators within the enterprise must take action to ensure the continuous availability of network resources to the extent that the TOE relies on the ability to access them in order to enforces its security requirements.
OE.COMPONENTS_RUNNING
For distributed TOEs, the administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly.
OE.IT_ENTERPRISE
The enterprise IT infrastructure provides security for a network that is available to the TOE and MDs that prevents unauthorized access.
OE.PROPER_ADMIN
TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner.
OE.TIMESTAMP
Reliable timestamps are provided by the operational environment for the TOE.

6 Security Requirements

This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations: For a distributed TOE, the ST author should reference Table 1 for guidance on how each SFR should be met. The table details whether SFRs should be met by all TOE components, by at least one TOE component or whether they are dependent on the feature being implemented by the TOE component. The ST for a distributed TOE must include a mapping of SFRs to each of the components of the TOE. (Note that this deliverable is examined as part of the ASE_TSS.1 and AVA_VAN.1 Evaluation Activities.)

Test Environment for Evaluation Activities

As described in the evaluation activities below, the ST for an EM system is required to list the types of systems or agents it can interface with in its evaluated configuration. The identified evaluation activities for testing that includes the use of an agent should be completed for each distinct type of agent if more than one are supported (e.g., the same agent but running on different OS platforms).

The evaluation activities for testing that include use of an agent will ensure that the TSF interacts appropriately with the agent (i.e., permits enrollment of the agent using the intended method, collects accurate data from the agent, and communicates policies or commands to the agent).

In addition to the above guidance, if the TOE is distributed across multiple distinct server components (e.g., due to network access limitations, fault tolerance, or a master/subordinate hierarchy relationship), then the ST is required to describe the nature of these interactions. All test evaluation activities that may be implemented by multiple server components within a distributed TOE shall be performed on each server that is capable of enforcing the action (e.g., if the TOE is distributed across multiple server components but is managed from a single component, it is expected that the evaluator will test the ability of these components to communicate by ensuring that a management activity performed on one component is replicated to all intended components).

6.1 Security Functional Requirements

6.1.1 Auditable Events for Mandatory SFRs


Table 2: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_ALT_EXT.1
Type of alertIdentity of system or agent that sent alert
FAU_GEN.1
No events specifiedN/A
FAU_SAR_EXT.1
No events specifiedN/A
FAU_SEL_EXT.1
TBD No additional information
FAU_STG.1
No events specifiedN/A
FAU_STG_EXT.1
No events specifiedN/A
FCS_CKM.1/AKG
No events specifiedN/A
FCS_CKM.1/SKG
No events specifiedN/A
FCS_CKM.6
No events specifiedN/A
FCS_COP.1/AEAD
No events specifiedN/A
FCS_COP.1/Hash
No events specifiedN/A
FCS_COP.1/KeyedHash
No events specifiedN/A
FCS_COP.1/SigGen
No events specifiedN/A
FCS_COP.1/SigVer
No events specifiedN/A
FCS_RBG.1
No events specifiedN/A
FCS_STG_EXT.1
No events specifiedN/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 specifiedN/A
FIA_UAU.1
No events specifiedN/A
FMT_MOF.1
Issuance of command to perform functionCommand sent and identity external recipients
Change of policy settingsPolicy changed and value or full policy
FMT_SMF.1/INTERNAL
Success or failure of function No additional information
FMT_SMF.1/MANAGED
No events specifiedN/A
FMT_SMR.1
No events specifiedN/A
FPT_API_EXT.1
No events specifiedN/A
FPT_LIB_EXT.1
No events specifiedN/A
FPT_TUD_EXT.1
Success or failure of signature verification No additional information

6.1.2 Class FAU: Security Audit

FAU_ALT_EXT.1 Server Alerts

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 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.
Evaluation Activities
FAU_ALT_EXT.1
TSS
The evaluator shall examine the TSS and verify that it describes the events that trigger the detection of an alert and the mechanism by which the alert is generated or transmitted (e.g., displayed in GUI, email notification). The evaluator shall also examine the TSS to verify that it identifies the reporting interval that the TSF uses to verify the availability of managed systems or agents.
Guidance
The evaluator shall examine the operational guidance to determine that it describes the process for configuring the behavior that triggers alerts and how the alerts are generated (e.g., if alerts are transmitted via email, the operational guidance would describe how to specify the recipients). If either aspect of this behavior operates in the evaluated configuration by default and no configuration of the functionality is performed, the evaluator shall examine the operational guidance to verify that it describes this.
Tests
The following tests are performed for each distinct type of entity with which the TSF communicates (if more than one such type is supported) and for each distinct alert mechanism (if more than one is supported):
  • Test FAU_ALT_EXT.1:1: The evaluator shall add a remote entity to management by the TSF through the process defined in FIA_ENR_EXT.2 and subsequently remove it from management. The evaluator shall verify in both cases that the expected alert mechanism is triggered.
  • Test FAU_ALT_EXT.1:2: The evaluator shall cause a managed entity to be inaccessible and verify that the expected alert mechanism is triggered for this entity's absence after no more than the maximum period of time specified in the TSS for the reporting interval.
  • Test FAU_ALT_EXT.1:3: For any other events that are described as triggering alerts, the evaluator shall cause the event to occur and verify that the expected alert mechanism is triggered.

FAU_GEN.1 Audit Data Generation

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate audit data of the following auditable events:
  1. All administrative actions
  2. Commands issued to managed [selection: system, agent]
  3. Specifically defined auditable events listed in Table 2
  4. [selection:
    • Startup and shutdown of the audit functions
    • Auditable events defined in for Implementation-Based SFRs
    • Auditable events defined in for Selection-Based SFRs
    • Auditable events defined in the audit table for the TLS Functional Package (see Table 3)
    • 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 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 t-audit-sel-based, 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
RequirementAuditable EventsAdditional 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.
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: ]
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

The TSF shall provide [assignment: authorized users] with the capability to read [assignment: list or type of information] from the monitored data.
The TSF shall provide the monitored data in a manner suitable for the user to interpret the information.
Evaluation Activities
FAU_SAR_EXT.1
TSS
The evaluator shall examine the TSS to verify that it describes how a user is authorized to read monitored data (e.g., through assignment of an administrative role) and how monitored data is presented (e.g., reporting mechanism).
Guidance
The evaluator shall check the operational guidance and ensure that it describes how the administrator accesses the monitored data and describes the format of this data (e.g., if the TSF presents monitored data in the form of reports on compliance scans, the evaluator shall verify that the operational guidance identifies how to view the results of a particular scan and what data is included in these results).
Tests
The evaluator shall attempt to view monitored data as an authorized administrator and verify that the monitored data is viewable and contains the information specified in the operational guidance.

FAU_SEL_EXT.1 Monitored Event Selection

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.
Evaluation Activities
FAU_SEL_EXT.1
TSS
The evaluator shall examine the TSS to verify that it identifies the monitored data that the TSF ensures is retained and whether this is configurable.
Guidance
If the functionality to retain monitored data is configurable, the evaluator shall examine the operational guidance to verify that instructions are provided for how to specify what monitored data is retained.
Tests
The evaluator shall also perform the following tests:
  • Test FAU_SEL_EXT.1:1: The evaluator shall perform actions that cause monitored data to be collected by the TOE and verify on review of this data that the information present is consistent with what the TSS identifies as being retained.
  • Test FAU_SEL_EXT.1:2: [Conditional, the TSF supports configuration of this function] If the TSF supports configuring the monitored data that is retained, the evaluator shall enable and disable these configuration elements, cause monitored data to be collected, and verify that the TSF suppresses the collection of any data that is configured to be suppressed.

FAU_STG.1 Audit Data Storage Location

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

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

6.1.3 Class FCS: Cryptographic Support

FCS_CKM.1/AKG Cryptographic Key Generation - Asymmetric Key

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:
  1. Random provable primes
  2. Random probable primes
  3. Provable primes with conditions based on auxiliary provable primes
  4. Probable primes with conditions based on auxiliary provable primes
  5. 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 [2100, 2Security 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)
  • 216 < e < 2256 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 XMSSMT
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

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

The TSF shall destroy [all plaintext keys and keying material] when [selection: no longer needed, [assignment: other circumstances for key or keying material destruction]].
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

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 (232)-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

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.

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

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

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

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)

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

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:

  1. Instantiate the DRBG.
  2. Generate a block of random bits.
  3. Generate a second block of random bits.
  4. 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:

  1. Instantiate the DRBG.
  2. Generate a block of random bits.
  3. Reseed.
  4. Generate a second block of random bits.
  5. 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

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.
Evaluation Activities
FCS_STG_EXT.1
TSS
Regardless of whether this requirement is met by the TSF or the TOE platform, the evaluator shall check the TSS to ensure that it lists each persistent secret (credential, secret key) and private key needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored. The evaluator then performs the following actions.

Persistent secrets and private keys manipulated by the TOE platform:

The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the key storage functionality is invoked for each persistent secret and private key described in the TSS (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).

Persistent secrets and private keys manipulated by the TSF:

The evaluator reviews the TSS to determine that it makes a case that, for each item listed as being manipulated by the TOE, it is not written unencrypted to persistent memory, and that the item is stored by the platform.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

6.1.4 Class FDP: User Data Protection

FDP_DAR_EXT.1 Encryption Of Sensitive Application Data

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 evaluator shall inspect the TSS and verify that it describes how files containing sensitive data are stored with the MODE_PRIVATE flag set.
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 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

The TSF shall enforce the [data monitoring SFP] on [assignment: types of systems, agents, or other entities from which the TSF can collect monitored data].
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.
Evaluation Activities
FDP_IFC.1
TSS
The evaluator shall examine the TSS to verify that it describes the types of agents or systems the TSF manages and the functions or data that is associated with these agents or system. For example, a conformant TOE may interact with agents installed on end user devices to manage the configuration of the behavior of these devices.
Guidance
There are no guidance EAs for this component.
Tests
There are no test EAs for this component.

FDP_IFF.1 Simple Security Attributes

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].
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.].
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 remote channel using an alternate protection mechanism of encryption of data prior to transmission.]
  • a secure local interface to a system or agent that is local to the TOE
]].
The TSF shall explicitly authorize an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorize information flows].
The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows].
Note: TBD
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)
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).
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.

FDP_NET_EXT.1 Network Communications

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.
Evaluation Activities
FDP_NET_EXT.1
TSS

None.

Guidance

The evaluator shall verify the guidance documents contain any instructions necessary to configure the restriction of network communications.

Tests
The evaluator shall perform the following tests:
  • Test FDP_NET_EXT.1:1: The evaluator shall run the application. While the application is running, the evaluator shall sniff network traffic ignoring all non-application associated traffic and verify that any network communications witnessed are documented in the TSS or are user-initiated.
  • Test FDP_NET_EXT.1:2: The evaluator shall run the application. After the application initializes, the evaluator shall run network port scans to verify that any ports opened by the application have been captured in the ST for the third selection and its assignment. This includes connection-based protocols (e.g. TCP, DCCP) as well as connectionless protocols (e.g. UDP).
    The following content should be included if:
    • the TOE implements ""
    If "no network communication" is selected, the evaluator shall ensure that the application's AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform the above Tests 1 and 2, as the platform will not allow the application to perform any network communication.

FDP_ITC.1 Import of User Data Without Security Attributes

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.
The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE.
The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [assignment: additional importation control rules].
Note: TBD
Evaluation Activities
FDP_ITC.1
TSS
The evaluator shall examine the TSS to verify that it describes the monitored data that the TSS collects on managed systems or agents (e.g., account settings, firewall rules, system configuration settings).
Guidance
The evaluator shall examine the operational guidance to verify that it describes how to specify what data is collected from managed systems or agents.
Tests
The evaluator shall exercise the functions of the TOE to collect data from managed systems or agents and verify the accuracy of this data by accessing the managed system directly (e.g., if the TSF reports a configuration setting on a managed system has a certain value, the evaluator would access that system and verify that this is the correct value).

6.1.5 Class FIA: Identification and Authentication

FIA_ENR_EXT.2 Method of Enrollment

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.
Evaluation Activities
FIA_ENR_EXT.2
TSS
TBD
Guidance
TBD
Tests
TBD

FIA_UAU.1 Timing of Authentication

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.
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.
Evaluation Activities
FIA_UAU.1
TSS
The evaluator shall examine the TSS to verify that it describes the process by which subjects accessing the TOE are authenticated (e.g., by running the TOE on a system that requires prior authentication or by providing its own authentication function on a remote management interface), and any functions that may be performed without authentication.
Guidance
The evaluator shall examine the operational guidance to verify that it describes any procedures used for configuring the authentication mechanism used to gain access to the TSF (e.g., if the TOE defines its own authentication mechanism and supports multiple administrators, the operational guidance should describe the process of creating a new administrator).
Tests
The evaluator shall perform the following tests:
  • Test FIA_UAU.1:1: The evaluator shall access the TOE without authentication and verify that only the functions specified in FIA_UAU.1.1 (if any) are accessible.
  • Test FIA_UAU.1:2: The evaluator shall verify that the TSF is accessible after the specified authentication mechanism is used (e.g. by ensuring that a valid username and password grants access to a management interface).

6.1.6 Class FMT: Management of the TSF

FMT_CFG_EXT.1 Secure by Default Configuration

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

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 inspect the TSS and verify that it describes what Android API is used (and provides a link to the documentation of the API) when storing configuration data. The evaluator shall run the application and verify that the behavior of the TOE is consistent with where and how the API documentation says the configuration data will be stored.

    For SharedPreferences, the evaluator shall examine the XML file to make sure it reflects the changes made to the configuration to verify that the application used SharedPreferences or PreferenceActivity to store the configuration data. For DataStore, the evaluator shall use a protocol buffer analyzer to examine the file to make sure it reflects the changes made to the configuration to verify that the application used DataStore to store the configuration data.
    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

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.
Evaluation Activities
FMT_MOF.1
TSS
The evaluator shall examine the TSS to ensure that it describes what security management functions are restricted to the administrator and what actions can be taken for each management function. The evaluator shall verify that the security management functions are restricted to authorized administrators.
Guidance
The evaluator shall examine the operational guidance to verify that it describes the management functions that are available to authorized administrators and how administrators are authorized to perform those particular functions (e.g., default for the account, role membership, group membership).
Tests
  • Test FMT_MOF.1:1: The evaluator shall attempt to access the functions and policies in FMT_SMF.1/INTERNAL and FMT_SMF.1/MANAGED as an unauthorized user and verify that the attempt fails. This may require the evaluator to use multiple different accounts with differing levels of privilege to interact with the TSF.

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

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)
Evaluation Activities
FMT_SMF.1/INTERNAL
TODO: You need to explain the lack of EAs for this component!!!!

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

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.
Evaluation Activities
FMT_SMF.1/MANAGED
TSS
The evaluator shall examine the TSS to ensure that it describes each management function claimed. The evaluator shall examine the TSS to ensure that it identifies the management functions implemented for each supported type of system or agent. If multiple systems or agents are supported, the evaluator shall examine the TSS to verify that any differences between management functions and policies for each supported system or agent are clearly indicated (e.g., a product that can manage endpoint systems with multiple operating systems may have OS-specified differences in the functions on those operating systems that can be managed).
Guidance
For each management function that can be performed against each type of managed system or agent, the evaluator shall examine the operational guidance to verify that it includes instructions on how to perform these actions, and what particular parameters or options can be specified for them.
Tests
For each type of managed agent or system claimed by the TOE:
  • Test FMT_SMF.1/MANAGED:1: The evaluator shall verify that for each supported management function, the TSF can collect data on the current status of that function to determine its configuration, and can execute function to change its behavior or data on the managed agent or system.

FMT_SMR.1 Security Roles

The TSF shall maintain the roles [assignment: the authorized identified roles].
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.
Evaluation Activities
FMT_SMR.1
TSS
The evaluator shall examine the TSS to ensure that it describes the management roles implemented by the TOE and how these roles are associated with users (e.g. is the role an intrinsic property of a user account, or can a user be reassigned different permissions).
Guidance
The evaluator shall examine the operational guidance to verify that it describes how to associate administrators with management roles, and the different privileges associated with each role.
Tests
The evaluator shall perform the following tests:
  • Test FMT_SMR.1:1: The evaluator shall follow the operational guidance to create administrator accounts or assign roles to administrators in order to demonstrate that each of the defined roles can be assumed.

6.1.7 Protection of the TSF (FPT)

FPT_API_EXT.1 Use of Supported Services and APIs

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.
Evaluation Activities
FPT_API_EXT.1
TSS

The evaluator shall verify that the TSS lists the platform APIs used by the TOE. The evaluator shall then compare the list with the supported APIs (available through e.g., developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported.

Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FPT_LIB_EXT.1 Use of Third-Party Libraries

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.
Evaluation Activities
FPT_LIB_EXT.1
TSS
The evaluator shall verify that the TSS lists the libraries used by the TOE or references a software bill of materials (SBOM) that serves as an authoritative definition for this.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall ensure that the TOE is built with the libraries claimed in the TSS.

FPT_TUD_EXT.1 Trusted Update

The TSF shall provide authorized administrators the ability to query the current version of the software.
Application Note: For a distributed TOE, the method of determining the installed versions on each component of the TOE is described in the operational guidance. In the requirement, "software" refers to the component of the distributed TOE to which the requirement is being applied.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide authorized administrators the ability to initiate updates to the TOE.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide a means to verify software updates to the TSF using a digital signature mechanism prior to installing those updates.
Application Note:

The software on the TSF will occasionally need to be updated. This requirement is intended to ensure that the TSF only installs updates provided by the vendor, as updates provided by another source may contain malicious code.

For distributed TOEs, all TOE components must support Trusted Update. The verification of the signature or hash on the update must either be done by each TOE component itself (signature verification) or for each TOE component (hash verification).

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. The TSS must detail the mechanisms that support the continuous proper functioning of the TOE during trusted update of distributed TOEs.

Evaluation Activities
FPT_TUD_EXT.1.1
TSS
The evaluator shall verify that the TSS identifies the mechanism by which the current version of the TOE can be identified.
Guidance
The evaluator shall ensure that the administrator guidance includes instructions for determining the current version of the TOE.
Tests
The evaluator shall query the TSF for the current version of the software according to the operational guidance and shall verify that the current version matches that of the documented and installed version.
FPT_TUD_EXT.1.2
TSS
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 verify that the operational guidance provides instructions for how to initiate an update to the TOE and any restrictions on this function such that only an authorized administrator can perform it.
Tests
There are no test activities for this element.

FPT_TUD_EXT.1.3
TSS
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).

If "implement functionality" is selected, the evaluator shall examine the TSS and verify that it describes the standards by which the updates are digitally signed and how the signature verification process is implemented.
Guidance
The evaluator shall examine the operational guidance to verify that it identifies how the TOE will verify the integrity of an update and how the administrator is made aware of a failure to verify the integrity of the update.
Tests
The evaluator shall perform the following tests:
  • Test FPT_TUD_EXT.1.3:1: The evaluator shall attempt to initiate an update digitally signed by the vendor and verify that the update is successfully installed.
  • Test FPT_TUD_EXT.1.3:2: The evaluator shall attempt to install an update not digitally signed by the vendor and verify that either the signature can be checked (allowing the update to be aborted) or the update is not installed.

6.1.8 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 13: SFR Rationale
ThreatAddressed byRationale

6.2 Security Assurance Requirements

The Security Objectives for the TOE in Section 6 Security Requirements were constructed to address threats identified in Section 4.1 Threats. The Security Functional Requirements (SFRs) in Section 6 Security Requirements are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual Evaluation Activities (AAs) to be performed are specified both in Section 6 Security Requirements as well as in this section.

The general model for evaluation of TOEs against STs written to conform to this PP is as follows:

After the ST has been approved for evaluation, the ITSEF will obtain the TOE, supporting environmental IT, and the administrative and user guides for the TOE. The ITSEF is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Evaluation Activities contained within Section 6 Security Requirements, which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The Evaluation Activities that are captured in Section 6 Security Requirements also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP.

The TOE Security Assurance Requirements are identified in Table 14.

Table 14: Security Assurance Requirements
Assurance ClassAssurance 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)
Preparative Procedures (AGD_PRE.1)
Life Cycle Support (ALC) Labeling of the TOE (ALC_CMC.1)
TOE CM Coverage (ALC_CMS.1)
Tests (ATE) Independent Testing – Conformance (ATE_IND.1)
Vulnerability Assessment (AVA) Vulnerability Survey (AVA_VAN.1)

6.2.1 Class ASE: Security Target

The ST is evaluated as per ASE activities defined in the CEM. In addition, there may be Evaluation Activities specified within Section 6 Security Requirements and relevant appendices that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type.

ASE_TSS.1 TOE summary specification

Developer action elements:

Content and presentation elements:

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

Evaluator action elements:

6.2.2 Class ADV: Development

The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST, and any additional information required by this PP that is not to be made public (e.g., Entropy Essay).

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:

The developer shall provide a functional specification.
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:

The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI.
The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI.
The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering.
The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.
Evaluation Activities
ADV_FSP.1
There are no specific evaluation activities associated with these SARs, except ensuring the information is provided. The functional specification documentation is provided to support the evaluation activities described in Section 5 and the relevant appendices, and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.

6.2.3 Class AGD: Guidance Documentation

The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel.

Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes:

Guidance pertaining to particular security functionality must also be provided; requirements on such guidance are contained in the evaluation activities specified with each requirement.

AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

Developer action elements:

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:

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.
The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner.
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.
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.
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.
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.
The operational user guidance shall be clear and reasonable.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
AGD_OPE.1
Some of the contents of the operational guidance will be verified by the evaluation activities in Sections 4.2, 4.3, and 4.4, and evaluation of the TOE according to the CEM. The following additional information is also required.

If cryptographic functions are provided by the TOE, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.

The documentation must describe the process for verifying updates to the TOE by verifying a digital signature - this may be done by the TOE or the underlying platform. The evaluator shall verify that this process includes the following steps:

Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory).

Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash or digital signature.

The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities.

AGD_PRE.1 Preparative Procedures (AGD_PRE.1)

Developer action elements:

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:

The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures.
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:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation.
Evaluation Activities
AGD_PRE.1
As indicated in the introduction above, there are significant expectations with respect to the documentation, especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the TOE in the ST.

6.2.4 Class ALC: Life-cycle Support

At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user visible aspects of the life-cycle, rather than an examination of the TOE vendor's development and configuration management process. This is not meant to diminish the critical role that a developer's practices play in contributing to the overall trustworthiness of a product; rather, it's a reflection on the information to be made available for evaluation at this assurance level.

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:

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

Content and presentation elements:

The TOE shall be labeled with its unique reference.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_CMC.1
The evaluator shall check the ST to ensure that it contains an identifier (such as a product name and version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the operational guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that the information in the ST is sufficient to distinguish the product.

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:

The developer shall provide a configuration list for the TOE.

Content and presentation elements:

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

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_CMS.1
The "evaluation evidence required by the SARs" in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the operational guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component.

Life-cycle support is targeted aspects of the developer's life-cycle and instructions to providers of applications for the developer's devices, rather than an in-depth examination of the TSF manufacturer's development and configuration management process. This is not meant to diminish the critical role that a developer's practices play in contributing to the overall trustworthiness of a product; rather, it's a reflection on the information to be made available for evaluation.

The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification.

6.2.5 Class ATE: Tests

Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as defined in the following requirements.

Since many of the APIs are not exposed at the user interface (e.g., touch screen), the ability to stimulate the necessary interfaces requires a developer's test environment. This test environment will allow the evaluator, for example, to access APIs and view file system information that is not available on consumer devices.

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:

The developer shall provide the TOE for testing.

Content and presentation elements:

The TOE shall be suitable for testing.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
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.

6.2.6 Class AVA: Vulnerability Analysis

For the first generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future protection profiles.

AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)

Developer action elements:

The developer shall provide the TOE for testing.

Content and presentation elements:

The TOE shall be suitable for testing.

Evaluator action elements:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE.
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.
Evaluation Activities
AVA_VAN.1
As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to determine the vulnerabilities that have been found in network infrastructure devices and the implemented communication protocols in general, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated.

Appendix A - Optional Requirements

As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements:

The first type, defined in Appendix A.1 Strictly Optional Requirements, are strictly optional requirements. If the TOE meets any of these requirements the vendor is encouraged to claim the associated SFRs in the ST, but doing so is not required in order to conform to this PP.

The second type, defined in Appendix A.2 Objective Requirements, are objective requirements. These describe security functionality that is not yet widely available in commercial technology. Objective requirements are not currently mandated by this PP, but will be mandated in the future. Adoption by vendors is encouraged, but claiming these SFRs is not required in order to conform to this PP.

The third type, defined in Appendix A.3 Implementation-dependent Requirements, are Implementation-dependent requirements. If the TOE implements the product features associated with the listed SFRs, either the SFRs must be claimed or the product features must be disabled in the evaluated configuration.

A.1 Strictly Optional Requirements

A.1.1 Class ALC: Life-cycle Support

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:

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

Content and presentation elements:

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.
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.
The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.
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:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_FLR.1
Evaluated as specified by [CEM].

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:

The developer shall document and provide flaw remediation procedures addressed to TOE developers.
The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws.
The developer shall provide flaw remediation guidance addressed to TOE users.

Content and presentation elements:

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.
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.
The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.
The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.
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.
The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users.
The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.
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:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_FLR.2
Evaluated as specified by [CEM].

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:

The developer shall document and provide flaw remediation procedures addressed to TOE developers.
The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws.
The developer shall provide flaw remediation guidance addressed to TOE users.

Content and presentation elements:

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.
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.
The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.
The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.
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.
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.
The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users.
The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.
The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE.
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.
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:

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Evaluation Activities
ALC_FLR.3
Evaluated as specified by [CEM].

A.2 Objective Requirements

This PP does not define any Objective requirements.

A.3 Implementation-dependent Requirements

A.3.1 Class FAU: Security Audit

FAU_NET_EXT.1 Network Reachability Review

This component must be included in the ST if the TOE implements any of the following features:
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.
Evaluation Activities
FAU_NET_EXT.1
TSS
The evaluator shall examine the TSS to verify that it describes the mechanism by which the TSF can query the connectivity status of any managed systems or agents.
Guidance
The evaluator shall examine the operational guidance to verify that it includes instructions for how to query the connectivity status of managed systems or agents (e.g., this may be shown as a status indicator on a table entry).
Tests
The evaluator shall follow the steps in the operational guidance to identify the connectivity status of a system or agent managed by the TOE. The evaluator shall change the state of that connection (e.g. by powering down the managed system or the system a managed agent runs on) and verify that the connectivity status accurately reflects the change.

A.3.2 Class FCO: Communication

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

A.3.3 Class FCS: Cryptographic Support

FCS_CKM.2 Cryptographic Key Distribution

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.

Evaluation Activities
FCS_CKM.2
TSS
The evaluator shall ensure that the TSS documents that the security strength supported by the selected key distribution methods is sufficient for the security strength of the keys distributed through those methods.

It is not necessary to identify the services that use each key distribution method here. That information should be documented in the requirements for the individual services and protocols that invoke key distribution.
Guidance
The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key distribution methods.
Tests
Specific testing for this component is covered by testing for the claimed components in FCS_COP.1/KeyEncap or FCS_COP.1/KeyWrap, depending on selections made.

FCS_CKM_EXT.7 Cryptographic Key Agreement

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 15 provides the allowable choices for completion of the selection operations of FCS_CKM_EXT.7.
Table 15: 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.

A.3.4 Protection of the TSF (FPT)

FPT_ITT.1 Internal TOE TSF Data Transfer

This component must be included in the ST if the TOE implements any of the following features:
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 the PP-Module for VPN Client
    • 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
    • SSH as defined in the Functional Package for Secure Shell
    ]
] to protect all data from [disclosure and modification] when it is transferred between separate parts of the TOE.
Application Note: This requirement ensures all communications between components of a distributed TOE are protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined in the protocol chosen in the second selection.

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. 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
Protocol, RBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

Evaluation Activities
FPT_ITT.1
TSS
The evaluator shall examine the TSS to determine that the methods and protocols used to protect distributed TOE components are described. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration 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 TOE; 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 establishing the communication paths for each supported method.
Tests
  • Test FPT_ITT.1:1: The evaluator shall ensure that communications using each specified (in the operational guidance) communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.
  • Test FPT_ITT.1:2: The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext.
 Further evaluation activities are associated with the specific protocols.

A.3.5 Trusted Path/Channels (FTP)

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

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.
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.
Evaluation Activities
FTP_ITC.1
TSS
The evaluator shall examine the TSS to determine that the methods of communication with authorized IT entities are indicated, along with how those communications are protected.

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 configuring the communication channel between the TSF and authorized IT entities for each supported method.
Tests
  • Test FTP_ITC.1:1: The evaluator shall ensure that communications using each specified (in the operational guidance) communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.
  • Test FTP_ITC.1:2: The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext.
  • Test FTP_ITC.1:3: The evaluator shall ensure, for each communication channel with the TSF, that a protocol analyzer identifies the traffic as the protocol under testing.
 Further evaluation activities are associated with the specific protocols.

FTP_TRP.1 Trusted Path

This component must be included in the ST if the TOE implements any of the following features:
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].
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [remote administrators] to initiate communication via the trusted path.
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.
Evaluation Activities
FTP_TRP.1
TSS
The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration 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 establishing the remote administrative sessions for each supported method.
Tests
The evaluator shall also perform the following tests:
  • Test FTP_TRP.1:1: The evaluator shall ensure that communications using each specified (in the operational guidance) remote administration method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.
  • Test FTP_TRP.1:2: For each method of remote administration supported, the evaluator shall follow the operational guidance to ensure that there is no available interface that can be used by a remote user to establish remote administrative sessions without invoking the trusted path.
  • Test FTP_TRP.1:3: The evaluator shall ensure, for each method of remote administration, the channel data is not sent in plaintext.
 Further evaluation activities are associated with the specific protocols.

Appendix B - Selection-based Requirements

As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.

B.1 Class FAU: Security Audit

FAU_SAR.1 Audit Review

The inclusion of this selection-based component depends upon selection in FAU_STG.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.
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.
Evaluation Activities
FAU_SAR.1
TSS
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 operational guidance and ensure that it describes how the administrator accesses the audit data and describes the format of audit data.
Tests
The evaluator shall attempt to view the audit data as the authorized administrator and verify that the action succeeds. The evaluator shall ensure the audit data generated during testing match the format specified in the administrative guide.

FAU_STG.2 Audit Event Storage

The inclusion of this selection-based component depends upon selection in FAU_STG.1.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.
The TSF shall be able to [selection, choose one of: prevent, detect] unauthorized modifications to the stored audit data in the audit trail.
Evaluation Activities
FAU_STG.2
TSS
If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how the audit data protection 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).

If "implement functionality" is selected, the evaluator shall ensure that the TSS describes how the audit data are protected from unauthorized modification or deletion. The evaluator shall ensure that the TOE uses audit trail specific protection mechanisms.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests:
  • Test FAU_STG.2:1: The evaluator shall access the audit trail as an unauthorized user and attempt to modify and delete the audit data. The evaluator shall verify that these attempts fail.
  • Test FAU_STG.2:2: The evaluator shall access the audit trail as an authorized user and attempt to modify and delete the audit data. The evaluator shall verify that these attempts succeed. The evaluator shall verify that only the records intended for modification and deletion are modified and deleted.

B.2 Class FCS: Cryptographic Support

FCS_COP.1/KeyEncap Cryptographic Operation - Key Encapsulation

The inclusion of this selection-based component depends upon selection in FCS_CKM.2.1.
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 16 provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyEncap.
Table 16: 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.
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 17 provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyWrap.
Table 17: 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 .
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 18 provides the allowable choices for completion of the selection operations of FCS_COP.1/SKC.
Table 18: 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.
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 19 provides the allowable choices for completion of the selection operations of FCS_COP.1/XOF.
Table 19: 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, FPT_ITT.1.1, FTP_ITC.1.1, FTP_TRP.1.1.
The TSF shall [selection: invoke platform-provided functionality to implement, implement] the HTTPS protocol that complies with RFC 2818.
The TSF shall [selection: invoke platform-provided functionality to implement, implement] HTTPS using TLS in accordance with .
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.
Evaluation Activities
FCS_HTTPS_EXT.1
TSS
The evaluator shall verify that the TSS describes whether the TOE's HTTPS functionality is implemented by the TOE or invoked from the TOE platform. If the TOE implements HTTPS, the evaluator shall verify that the corresponding claims from the TLS Functional Package (client, server, or both) are present.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
  • Test FCS_HTTPS_EXT.1:1: The evaluator shall attempt to establish an HTTPS connection with a web server, web a client, or both (depending on whether the TOE acts as a web client, a web server, or both), observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.
 Other tests are performed in conjunction with the TLS evaluation activities.

FCS_IV_EXT.1 Initialization Vector Generation

The inclusion of this selection-based component depends upon selection in FCS_STG_EXT.1.1.
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate IVs in accordance with Table 20.
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 20 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 20: 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).
Evaluation Activities
FCS_IV_EXT.1
TSS
If "invoke platform-provided functionality" is selected:

The evaluator shall examine the TSS to verify that it describes (for each supported platform) how the IV generation is invoked for each mode 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 details the encryption of user credentials, persistent secrets, and private keys and the generation of the IVs used for that encryption.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall ensure that the generation of IVs for each key encrypted by the same KEK meets Table 20.

FCS_RBG.2 Random Bit Generation (External Seeding)

The inclusion of this selection-based component depends upon selection in FCS_RBG.1.2.
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.

Evaluation Activities
FCS_RBG.2

The evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF external interface that is used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be determined that the TSF can derive a seed from it that has the claimed amount of min-entropy. If the TSF uses an entropy source that can be assumed to have full entropy, the seed is the output data from the entropy source. If the TSF uses an entropy source where the min-entropy of the data is less than 1:1, the evaluator shall verify that the entropy documentation identifies how large the collected data sample is and how TSF derives this data into a seed that has the claimed min-entropy.

TSS
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

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

Evaluation Activities
FCS_RBG.3

The evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF entropy source that is used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be determined that the TSF can derive a seed from it that has the claimed amount of min-entropy. If the TSF uses an entropy source that can be assumed to have full entropy, the seed is the output data from the entropy source. If the TSF uses an entropy source where the min-entropy of the data is less than 1:1, the evaluator shall verify that the entropy documentation identifies how large the collected data sample is and how TSF derives this data into a seed that has the claimed min-entropy.

TSS
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

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

Evaluation Activities
FCS_RBG.4

The evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it identifies, for each DRBG function implemented by the TOE, each TSF entropy source used to seed the TOE's DRBG.

TSS
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FCS_RBG.5 Random Bit Generation (Combining Entropy Sources)

The inclusion of this selection-based component depends upon selection in FCS_RBG.1.2.
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.

Evaluation Activities
FCS_RBG.5

Using the entropy sources specified in FCS_RBG.4, the evaluator shall examine the entropy documentation required by FCS_RBG.1 to verify that it describes the method by which data from these sources are combined into a single seed. This should include an estimation of the rate at which each entropy source outputs data and whether this is dependent on any system-specific factors so that each source's relative contribution to the overall entropy is understood. The evaluator shall verify that the amount of sampled data, the min-entropy rate of the sampled data, and the method by which the multiple sampled data sources are combined can be used to determine that the TSF can derive a seed from it that has the claimed amount of min-entropy. This includes any description of how the TSF derives data larger than the seed value into a seed that has the claimed min-entropy.

TSS
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

The inclusion of this selection-based component depends upon selection in FCS_STG_EXT.1.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.

Evaluation Activities
FCS_STG_EXT.2
TSS
The evaluator shall examine the TSS to ensure it describes in detail how user credentials, persistent secret and private keys are stored and encrypted. The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to persistent memory and that it identifies the mode of encryption.

If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how the key encryption functionality is invoked (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).
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

B.3 Class FIA: Identification and Authentication

FIA_AFL.1 Authentication Failure Handling

The inclusion of this selection-based component depends upon selection in FIA_UIA_EXT.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].
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.
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].
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.
The TSF shall provide the following password management capabilities for administrative passwords:
  1. 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]]
  2. 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:
  1. lists the supported special character(s) for the composition of administrator passwords.
  2. states that the minimum password length is configurable by an administrator.
  3. 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:
  1. identifies the characters that may be used in passwords and provides guidance to security administrators on the composition of strong passwords, and
  2. 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.
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.
Evaluation Activities
FIA_UIA_EXT.1
TSS
The evaluator shall examine the TSS to determine that it describes the logon process for remote authentication mechanism (e.g., SSH public key, Web GUI password, etc.) and optional local authentication mechanisms supported by the TOE. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”.
Guidance
The evaluator shall examine the guidance documentation to determine that any necessary preparatory steps (e.g., establishing credential material such as pre- shared keys, tunnels, certificates, etc.) to logging in are described. For each supported the login method, the evaluator shall ensure the guidance documentation provides clear instructions for successfully logging on.
Tests
The evaluator shall perform the following test for each method by which administrators access the TOE, as well as for each type of credential supported by the login method:
  • Test FIA_UIA_EXT.1:1: The evaluator shall use the guidance documentation to configure the appropriate credential supported for the login method. For all combinations of supported credentials and login methods, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access.

B.4 Protection of the TSF (FPT)

FPT_FLS.1 Failure with Preservation of Secure State

The inclusion of this selection-based component depends upon selection in FCS_RBG.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.
Evaluation Activities
FPT_FLS.1
TSS
The evaluator shall verify that the TSF describes how the TOE enters an error state in the event of a DRBG self-test failure.
Guidance
The evaluator shall verify that the guidance documentation describes the error state that results from a DRBG self-test failure and the actions that a user or administrator should take in response to attempt to resolve the error state.
Tests
There are no test activities for this component.

FPT_ITT.1 Internal TOE TSF Data Transfer

The inclusion of this selection-based component depends upon selection in FDP_IFF.1.3.
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 ,
    • mutually authenticated DTLS as defined in ,
    • HTTPS in accordance with FCS_HTTPS_EXT.1,
    • SSH as defined in
    ]
] 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), 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 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 ," the TSF must be validated against .

If the ST author selects that the TSF implements "mutually authenticated TLS as defined in " or "mutually authenticated DTLS as defined in ," the TSF must be validated against requirements from , 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.
Evaluation Activities
FPT_ITT.1
TSS
The evaluator shall examine the TSS to determine that the methods and protocols used to protect distributed TOE components are described. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration 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 establishing the communication paths for each supported method.
Tests
  • Test FPT_ITT.1:1: The evaluator shall ensure that communications using each specified (in the operational guidance) communication method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.
  • Test FPT_ITT.1:2: The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext.
 Further evaluation activities are associated with the specific protocols.

FPT_TST.1 TSF Self-Testing

The inclusion of this selection-based component depends upon selection in FCS_RBG.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].
The TSF shall provide authorized users with the capability to verify the integrity of [[DRBG seed and output data]].
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.
Evaluation Activities
FPT_TST.1
TSS

The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF along with how they are run. This description should include an outline of what the tests are actually doing. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the DRBG is operating correctly.

Note that this information may also be placed in the entropy documentation specified by Appendix E - Entropy Documentation and Assessment.

Guidance

If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance provides instructions on how to execute that self-test.

Tests

For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1.

If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in the operational guidance to perform the self-test will result in execution of the self-test.

B.5 TOE Access (FTA)

FTA_SSL.3 TSF-initiated termination

The inclusion of this selection-based component depends upon selection in FIA_UAU.1.2.
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.
Evaluation Activities
FTA_SSL.3
TSS
The evaluator shall examine the TSS to determine that it details the session termination and the related inactivity time period.
Guidance
The evaluator shall confirm that the guidance documentation includes instructions for configuring the inactivity time period for session termination.
Tests
For each method of establishing an interactive session with the TOE, the evaluator shall perform the following test:
  • Test FTA_SSL.3:1: The evaluator shall follow the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator shall establish an interactive session with the TOE. The evaluator shall then observe that the session is terminated after the configured time period.

FTA_TAB.1 Default TOE access banners

The inclusion of this selection-based component depends upon selection in FIA_UAU.1.2.
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.
Evaluation Activities
FTA_TAB.1
TSS
The evaluator shall check the TSS to ensure that it details each administrative method of access (local and/or remote) available on the TOE (e.g., serial port, SSH, HTTPS). The evaluator shall check the TSS to ensure that all administrative methods of access available to the administrator are listed and that the TSS states that the TOE is displaying an advisory notice and a consent warning message for each administrative method of access. The advisory notice and the consent warning message might be different for different administrative methods of access and might be configured during initial configuration (e.g., via configuration file).
Guidance
The evaluator shall check the guidance documentation to ensure that it describes how to configure the banner message.
Tests
The evaluator shall perform the following test:
  • Test FTA_TAB.1:1: The evaluator shall follow the guidance documentation to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in each instance.

B.6 Trusted Path/Channels (FTP)

FTP_TRP.1/Join Trusted Path (for Joining)

The inclusion of this selection-based component depends upon selection in FCO_CPC_EXT.1.2.
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].
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.
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.

Appendix C - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP.

C.1 Extended Components Table

All extended components specified in the PP are listed in this table:
Table 21: Extended Component Definitions
Functional ClassFunctional Components
Class FCO: CommunicationFCO_CPC_EXT Component Registration Channel Definition
Class FCS: Cryptographic SupportFCS_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 ProtectionFDP_DAR_EXT Data-at-Rest Encryption
FDP_DEC_EXT Access to Platform Resources
Class FIA: Identification and AuthenticationFIA_ENR_EXT Enrollment
FIA_PMG_EXT Password Management
FIA_UIA_EXT User Identification and Authentication
Class FMT: Management of the TSFFMT_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

C.2 Extended Component Definitions

C.2.1 Class FCO: Communication

This PP defines the following extended components as part of the class originally defined by CC Part 2:

C.2.1.1 FCO_CPC_EXT Component Registration Channel Definition

Family Behavior

This family describes the registration process, including the capability for the administrator to enable or disable communications between a distributed TOE and other components of the TOE.

Component Leveling

FCO_CPC_EXT1

FCO_CPC_EXT.1, Component Registration Channel Definition, defines requirements for the registration process for distributed TOEs.

Management: FCO_CPC_EXT.1

There are no management activities foreseen.

Audit: FCO_CPC_EXT.1

The following actions should be auditable if FAU_GEN security audit data generation is included in the PP or ST.

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

FCO_CPC_EXT.1 Component Registration Channel Definition

Hierarchical to:No other components.
Dependencies to: FPT_ITT.1 TSF Data Transfer
FTP_TRP.1 Trusted Path

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.

C.2.2 Class FCS: Cryptographic Support

This PP defines the following extended components as part of the class originally defined by CC Part 2:

C.2.2.1 FCS_CKM_EXT Cryptographic Key Management

Family Behavior

This family defines requirements for management of cryptographic keys using mechanisms beyond what are specified in CC Part 2.

Component Leveling

FCS_CKM_EXT7

FCS_CKM_EXT.7, Cryptographic Key Agreement, requires that cryptographic key agreement be performed in accordance with specified standards.

Management: FCS_CKM_EXT.7

There are no management functions foreseen.

Audit: FCS_CKM_EXT.7

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST:

  • minimal: Success and failure of the activity;
  • basic: The object attribute(s), and object value(s) excluding any sensitive information.

FCS_CKM_EXT.7 Cryptographic Key Agreement

Hierarchical to:No other components.
Dependencies to:

[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation, or
FCS_CKM.5 Cryptographic key derivation, or
FCS_CKM_EXT.8 Password-based key derivation],
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.6 Timing and event of cryptographic key destruction
FCS_COP.1 Cryptographic operation

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 [assignment: cryptographic algorithm] and specified cryptographic parameters [assignment: cryptographic parameters] that meet the following: [assignment: list of standards]

C.2.2.2 FCS_HTTPS_EXT HTTPS Protocol

Family Behavior

This family defines requirements for protecting HTTP communications between the TOE and an external IT entity.

Component Leveling

FCS_HTTPS_EXT1

FCS_HTTPS_EXT.1, HTTPS Protocol, defines requirements for the implementation of the HTTPS protocol.

Management: FCS_HTTPS_EXT.1

There are no management activities foreseen.

Audit: FCS_HTTPS_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST:

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

FCS_HTTPS_EXT.1 HTTPS Protocol

Hierarchical to:No other components.
Dependencies to: FCS_TLS_EXT.1 TLS Protocol
[FCS_TLSC_EXT.1 TLS Client Protocol or
FCS_TLSS_EXT.1 TLS Server Protocol

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 .

C.2.2.3 FCS_IV_EXT Initialization Vector Generation

Family Behavior

This family defines requirements for generating IVs in accordance with NIST-approved cipher modes.

Component Leveling

FCS_IV_EXT1

FCS_IV_EXT.1, Initialization Vector Generation, defines requirements for generating IVs.

Management: FCS_IV_EXT.1

There are no management activities foreseen.

Audit: FCS_IV_EXT.1

There are no auditable events foreseen.

FCS_IV_EXT.1 Initialization Vector Generation

Hierarchical to:No other components.
Dependencies to:No dependencies.

FCS_IV_EXT.1.1

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

C.2.2.4 FCS_STG_EXT Cryptographic Key Storage

Family Behavior

This family defines requirements for ensuring the protection of keys and secrets.

Component Leveling

FCS_STG_EXT12

FCS_STG_EXT.1, Cryptographic Key Storage, defines requirements for the security of persistent secrets and private keys.

FCS_STG_EXT.2, Encrypted Cryptographic Key Storage, defines requirements for preventing access to private keys and persistent secrets.

Management: FCS_STG_EXT.1

The following actions could be considered for the management functions in FMT.

  • Import keys or secrets into the secure key storage

Audit: FCS_STG_EXT.1

There are no auditable events foreseen.

FCS_STG_EXT.1 Cryptographic Key Storage

Hierarchical to:No other components.
Dependencies to:No dependencies.

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.

Management: FCS_STG_EXT.2

There are no management activities foreseen.

Audit: FCS_STG_EXT.2

There are no auditable events foreseen.

FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

Hierarchical to:No other components.
Dependencies to:No dependencies.

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

C.2.3 Class FDP: User Data Protection

This PP defines the following extended components as part of the class originally defined by CC Part 2:

C.2.3.1 FDP_DAR_EXT Data-at-Rest Encryption

Family Behavior

This family defines requirements for implementation of data-at-rest protection.

Component Leveling

FDP_DAR_EXT1

FDP_DAR_EXT.1, Encryption Of Sensitive Application Data, requires the application to be able to protect all data with a chosen method of encryption.

Management: FDP_DAR_EXT.1

No specific management functions are identified.

Audit: FDP_DAR_EXT.1

There are no auditable events foreseen.

FDP_DAR_EXT.1 Encryption Of Sensitive Application Data

Hierarchical to:No other components.
Dependencies to:No dependencies.

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.

C.2.3.2 FDP_DEC_EXT Access to Platform Resources

Family Behavior

This family defines requirements for accessing platform resources.

Component Leveling

FDP_DEC_EXT

C.2.4 Class FIA: Identification and Authentication

This PP defines the following extended components as part of the class originally defined by CC Part 2:

C.2.4.1 FIA_ENR_EXT Enrollment

Family Behavior

This family defines requirements for the TSF to perform enrollment of external entities so that the TSF has authorization to transmit data to or receive data from these entities.

Component Leveling

FIA_ENR_EXT1

FIA_ENR_EXT.1, Enrollment, defines requirements for authenticating and limiting user actions.

Management: FIA_ENR_EXT.1

The following actions could be considered for the management functions in FMT.

  • Configure the specific device models.
  • Configure the specific time period.

Audit: FIA_ENR_EXT.1

The following actions should be auditable if FAU_GEN security audit data generation is included in the PP or ST.

  • Failure of user authentication.
  • Presented username.

FIA_ENR_EXT.1 Enrollment

Hierarchical to:No other components.
Dependencies to: FIA_UAU.4 Single-Use Authentication Mechanisms
FMT_SMF.1 Specification of Management Functions

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

C.2.4.2 FIA_PMG_EXT Password Management

Family Behavior

The TOE defines the attributes of passwords used by administrative users to ensure that strong passwords and passphrases can be chosen and maintained. This is a new family defined for the FIA class.

Component Leveling

FIA_PMG_EXT1

FIA_PMG_EXT.1, Password Management, requires the TSF to support passwords with varying composition requirements, minimum lengths, maximum lifetime, and similarity constraints.

Management: FIA_PMG_EXT.1

There are no management functions foreseen.

Audit: FIA_PMG_EXT.1

There are no auditable events foreseen.

FIA_PMG_EXT.1 Password Management

Hierarchical to:No other components.
Dependencies to:No dependencies.

FIA_PMG_EXT.1.1

The TSF shall provide the following password management capabilities for administrative passwords:
  1. Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [assignment: allowable special characters]
  2. Minimum password length shall be [assignment: minimum password character length].

C.2.4.3 FIA_UIA_EXT User Identification and Authentication

Family Behavior

The TSF requires a non-TOE entity to be authenticated before any TSF-mediated actions may be taken. This is a new family defined for the FIA class.

Component Leveling

FIA_UIA_EXT1

FIA_UIA_EXT.1, User Identification and Authentication, requires Administrators to be identified and authenticated by the TOE before the TOE performs any mediated functions.

Management: FIA_UIA_EXT.1

The following actions could be considered for the management functions in FIA_UIA_EXT.1.

  • Ability to configure the list of TOE services available before an entity is identified and authenticated.

Audit: FIA_UIA_EXT.1

The following actions should be auditable if FAU_GEN security audit data generation is included in the PP or ST.

  • All use of the identification and authentication mechanism
  • Provided user identity, origin of the attempt (e.g., IP address)

FIA_UIA_EXT.1 User Identification and Authentication

Hierarchical to:No other components.
Dependencies to:No dependencies.

FIA_UIA_EXT.1.1

The TSF shall provide the following authentication mechanisms: [assignment: allowable authentication mechanisms]

C.2.5 Class FMT: Management of the TSF

This PP defines the following extended components as part of the class originally defined by CC Part 2:

C.2.5.1 FMT_CFG_EXT Secure by Default Configuration

Family Behavior

This family defines requirements for authorization to manage the behavior of the application.

Component Leveling

FMT_CFG_EXT1

FMT_CFG_EXT.1, Secure by Default Configuration, requires the application to define how to set new credentials and protect the application from modification by unprivileged users.

Management: FMT_CFG_EXT.1

No specific management functions are identified.

Audit: FMT_CFG_EXT.1

There are no auditable events foreseen.

FMT_CFG_EXT.1 Secure by Default Configuration

Hierarchical to:No other components.
Dependencies to:No dependencies.

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

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.

C.2.5.2 FMT_MEC_EXT Supported Configuration Mechanism

Family Behavior

This family defines requirements for the TOE’s use of mechanisms for the storage of configuration data.

Component Leveling

FMT_MEC_EXT1

FMT_MEC_EXT.1, Supported Configuration Mechanism, requires the application to store configuration data either through the use of an appropriate environmental mechanism or through its own file encryption capability.

Management: FMT_MEC_EXT.1

No specific management functions are identified.

Audit: FMT_MEC_EXT.1

There are no auditable events foreseen.

FMT_MEC_EXT.1 Supported Configuration Mechanism

Hierarchical to:No other components.
Dependencies to:No dependencies.

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

C.2.6 Protection of the TSF (FPT)

This PP defines the following extended components as part of the FPT class originally defined by CC Part 2:

C.2.6.1 FPT_API_EXT Use of Supported Services and APIs

Family Behavior

This family describes document platform APIs when selecting "invoke platform-provided functionality."

Component Leveling

FPT_API_EXT1

FPT_API_EXT.1, Use of Supported Services and APIs, defines requirements for API usage.

Management: FPT_API_EXT.1

There are no management activities foreseen.

Audit: FPT_API_EXT.1

There are no auditable events foreseen.

FPT_API_EXT.1 Use of Supported Services and APIs

Hierarchical to:No other components.
Dependencies to:No dependencies.

FPT_API_EXT.1.1

The TSF shall use only documented platform APIs.

C.2.6.2 FPT_LIB_EXT Use of Third-Party Libraries

Family Behavior

This family describes packaging third-party libraries when selecting "implement functionality."

Component Leveling

FPT_LIB_EXT1

FPT_LIB_EXT.1, Use of Third-Party Libraries, defines requirements for third-party libraries.

Management: FPT_LIB_EXT.1

There are no management activities foreseen.

Audit: FPT_LIB_EXT.1

There are no auditable events foreseen.

FPT_LIB_EXT.1 Use of Third-Party Libraries

Hierarchical to:No other components.
Dependencies to:No dependencies.

FPT_LIB_EXT.1.1

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

C.2.6.3 FPT_TST_EXT Functionality Testing

Family Behavior

This family defines requirements for running self-tests and verifying integrity or executable code.

Component Leveling

FPT_TST_EXT

C.2.6.4 FPT_TUD_EXT Trusted Update

Family Behavior

This family defines requirements for allowing authorized administrators to query software versions, initiate updates, and verify software updates prior to installation.

Component Leveling

FPT_TUD_EXT1

FPT_TUD_EXT.1, Trusted Update, defines requirements for authorized administrators to manage software versions and updates.

Management: FPT_TUD_EXT.1

The following actions could be considered for the management functions in FMT.

  • Query the current version of system software.
  • Update system software.

Audit: FPT_TUD_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST:

  • Success or failure of signature verification

FPT_TUD_EXT.1 Trusted Update

Hierarchical to:No other components.
Dependencies to:No dependencies.

FPT_TUD_EXT.1.1

The TSF shall provide authorized administrators the ability to query the current version of the software.

FPT_TUD_EXT.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide authorized administrators the ability to initiate updates to the TOE.

FPT_TUD_EXT.1.3

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide a means to verify software updates to the TSF using a digital signature mechanism prior to installing those updates.

Appendix D - Inherently Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this Protection Profile. However, these requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the Protection Profile provides evidence that these controls are present and have been evaluated.

Appendix E - Entropy Documentation and Assessment

This appendix describes the required supplementary information for each entropy source used by the TOE.

The documentation of the entropy sources should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied on to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.

E.1 Design Description

Documentation shall include the design of each entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.

The documentation will describe the operation of the entropy source to include, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if or where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.

This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.

If implemented, the design description shall include a description of how third-party applications can add entropy to the DRBG. A description of any DRBG state saving between power-off and power-on shall be included.

E.2 Entropy Justification

There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the DRBG output (by this particular TOE). This argument will include a description of the expected min-entropy rate (i.e., the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied on to produce bits with entropy.

The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product.

For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.

For third-party provided entropy sources, in which the TOE vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to "assume" an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.

Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.

The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.

E.3 Operating Conditions

The entropy rate may be affected by conditions outside the control of the entropy source itself. For example, voltage, frequency, temperature, and elapsed time after power-on are just a few of the factors that may affect the operation of the entropy source. As such, documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. Similarly, documentation shall describe the conditions under which the entropy source is no longer guaranteed to provide sufficient entropy. Methods used to detect failure or degradation of the source shall be included.

E.4 Health Testing

More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, TOE behavior upon entropy source failure, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.

Appendix F - Evaluating Additional Components for a Distributed TOE

In the case of a distributed TOE the ST will identify an evaluated configuration that consists of a number of separate components chosen by the ST author, which collectively satisfy the requirements of the PP. This evaluated configuration need not be the minimum set of components that could possibly meet the PP (e.g., if the TOE is intended for large enterprise deployments then the evaluated configuration might include some redundancy in components in order to support expected connectivity and loads), but because this is the main configuration referred to in the ST and the evaluation, it is treated in this section as the minimum configuration of interest and is referred to here as the 'minimum configuration' as well as the 'evaluated configuration'.

In addition to the minimum configuration above, the ST may also identify (at the author's discretion, and subject to verification as described in this section) which TOE components can have instances added to an operational configuration without affecting the validity of the CC certification. The ST description may include constraints on how such components are added, including required or prohibited configurations of the components.

Extra instances of a TOE component must have the same hardware and software as the original component included in the evaluated configuration.

F.1 Evaluator Actions for Assessing the ST

TSS The evaluator shall examine the TSS to identify any extra instances of TOE components allowed in the ST and shall examine the description of how the additional components maintain the SFRs to confirm that it is consistent with the role that the component plays in the evaluated configuration. For example: the secure channels used by the extra component for intra-TOE communications (FPT_ITT) and external communications (FTP_ITC) must be consistent, the audit information generated by the extra component must be maintained, and the management of the extra component must be consistent with that used for the original instance of the component in the minimum configuration.

F.2 Evaluator Actions for Assessing the Guidance Documentation

Guidance The evaluator shall examine the description of the extra instances of TOE components in the guidance documentation to confirm that they are consistent with those identified as allowed in the ST. This includes confirmation that the result of applying the guidance documentation to configure the extra component will leave the TOE in a state such that the claims for SFR support in each component are as described in the ST and therefore that all SFRs continue to be met when the extra components are present.

The evaluator shall examine the secure communications described for the extra components to confirm that they are the same as described for the components in the minimum configuration (additional connections between allowed extra components and the components in the minimum configuration are allowed of course).

F.3 Evaluator Actions for Testing the TOE

Tests The evaluator tests the TOE in the minimum configuration as defined in the ST (and the guidance documentation).

If the description of the use of extra components in the ST and guidance documentation identifies any difference in the SFRs allocated to a component, or the scope of the SFRs involved (e.g., if different selections apply to different instances of the component) then the evaluator tests these additional SFR cases that were not included in the minimum configuration.

In addition, the evaluator tests the following aspects for each extra component that is identified as allowed in the distributed TOE:

Appendix G - Acronyms

Table 22: Acronyms
AcronymMeaning
APIApplication Programming Interface
Base-PPBase Protection Profile
CCCommon Criteria
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
EAEvaluation Activity
ECDSAElliptic Curve Digital Signature Algorithm
EDREndpoint Detection and Response
EPExtended Package
ESMEnterprise Security Management
FIPSFederal Information Processing Standards
FPFunctional Package
IPInternet Protocol
ISOInternational Organization for Standardization
ITInformation Technology
NIAPNational Information Assurance Partnership
NISTNational Institute of Standards and Technology
OEOperational Environment
OSOperating System
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
RSARivest, Shamir, Adleman (digital signature algorithm)
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
STSecurity Target
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification

Appendix H - Bibliography

Table 23: Bibliography
IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -