Comment: Comment-1-
Comment: Comment-2-
Comment: Comment-3-
Comment: Comment-4-

Protection Profile for Retransmission Device

NIAP Logo
Version: 1.0
2025-05-15
National Information Assurance Partnership

Revision History

VersionDateComment
v 1.02024-12-30Initial release

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Overview1.3.2TOE Configurations1.3.2.1CU-Only Configuration1.3.2.2EU-Only Configuration1.3.2.3HWS-ERD Configuration1.3.3TOE Logical Boundary1.3.3.1Security Isolation1.3.3.2Traffic Forwarding and Routing - CU-Only and HWS-ERD1.3.3.3Cryptographic Processing - EU-Only and HWS-ERD1.3.3.4Security Management1.3.4TOE Physical Boundary1.3.4.1CU-Only Physical Boundary1.3.4.2EU-Only Physical Boundary1.3.4.3HWS-ERD Physical Boundary1.4Use Cases1.5Product Features Mapped to Implementation-Dependent Requirements1.5.1IPsec1.5.2MACsec1.5.3PFED1.5.4WLAN1.5.5CU Functionality1.5.6Hardware-Separated Encrypting Retransmission Device (HWS-ERD)1.6SFR Applicability2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions4Security Objectives4.1Security Objectives for the Operational Environment4.2Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Auditable Events for Mandatory SFRs5.1.2Auditable Events for Objective SFRs5.1.3Auditable Events for Implementation-Dependent SFRs5.1.4Auditable Events for Selection-Based SFRs5.1.5Class FAU: Security Audit5.1.6Class FCO: Communications5.1.7Class FCS: Cryptographic Support5.1.8Class FDP: User Data Protection5.1.9Class FIA: Identification and Authentication5.1.10Class FMT: Security Management5.1.11Class FPF: Packet Filtering5.1.12Class FPT: Protection of the TSF5.1.13Class FTA: TOE Access5.1.14Class FTP: Trusted Path/Channel5.1.15TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documentation5.2.4Class ALC: Life-cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements A.1.1Class ALC: Life-cycle SupportA.2Objective Requirements A.2.1Class FPT: Protection of the TSFA.3Implementation-dependent Requirements A.3.1Class FAU: Security AuditA.3.2Class FCS: Cryptographic SupportA.3.3Class FDP: User Data ProtectionA.3.4Class FIA: Identification and AuthenticationA.3.5Class FMT: Security ManagementA.3.6Class FPT: Protection of the TSFA.3.7Class FTP: Trusted Path/ChannelAppendix B - Selection-based Requirements B.1Class FCS: Cryptographic SupportB.2Class FDP: User Data ProtectionB.3Class FIA: Identification and AuthenticationB.4Class FPT: Protection of the TSFB.5Class FTP: Trusted Path/ChannelAppendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Class FCS: Cryptographic SupportC.2.1.1FCS_CKM_EXT Cryptographic Key ManagementC.2.1.2FCS_HTTPS_EXT HTTPS ProtocolC.2.1.3FCS_REC_EXT Key RecoveryC.2.1.4FCS_REKEY_EXT Periodic RekeyC.2.1.5FCS_STG_EXT Key Storage and ProtectionC.2.2Class FDP: User Data ProtectionC.2.2.1FDP_BRINGUP_EXT Secure Bring-UpC.2.2.2FDP_ITC_EXT Key/Credential ImportC.2.2.3FDP_PBR_EXT Protocol Break EnforcementC.2.2.4FDP_STG_EXT User Data StorageC.2.3Class FIA: Identification and AuthenticationC.2.3.1FIA_AFL_EXT Authentication Failure HandlingC.2.3.2FIA_PMG_EXT Password ManagementC.2.3.3FIA_PSK_EXT Pre-Shared Key CompositionC.2.3.4FIA_TRT_EXT Authentication ThrottlingC.2.3.5FIA_UAU_EXT User AuthenticationC.2.3.6FIA_UIA_EXT Administrator AuthenticationC.2.4Class FPF: Packet FilteringC.2.4.1FPF_RUL_EXT Packet FilteringC.2.5Class FPT: Protection of the TSFC.2.5.1FPT_APW_EXT Protection of Administrator PasswordC.2.5.2FPT_BBD_EXT Baseband ProcessingC.2.5.3FPT_DPD_EXT Baseband ProcessingC.2.5.4FPT_ISO_EXT EU and CU IsolationC.2.5.5FPT_JTA_EXT JTAG DisablementC.2.5.6FPT_KST_EXT Key StorageC.2.5.7FPT_NOT_EXT Self-Test NotificationC.2.5.8FPT_PPF_EXT Protection of Platform FirmwareC.2.5.9FPT_RBP_EXT Rollback ProtectionC.2.5.10FPT_ROT_EXT Platform IntegrityC.2.5.11FPT_RVR_EXT Platform Firmware RecoveryC.2.5.12FPT_SEP_EXT Hardware-Enforced Separation Between TOE SubsystemsC.2.5.13FPT_SKP_EXT Protection of TSF DataC.2.5.14FPT_TRAN_EXT Transaction ControlC.2.5.15FPT_TST_EXT TSF TestingC.2.5.16FPT_TUD_EXT Trusted UpdatesC.2.6Class FTA: TOE AccessC.2.6.1FTA_SSL_EXT Session Locking and TerminationC.2.7Class FTP: Trusted Path/ChannelC.2.7.1FTP_ITC_EXT Trusted Channel CommunicationsC.2.7.2FTP_ITP_EXT Physically Protected ChannelAppendix D - Entropy Documentation and AssessmentD.1Design DescriptionD.2Entropy JustificationD.3Operating ConditionsD.4Health TestingAppendix E - Validation GuidelinesAppendix F - Implicitly Satisfied RequirementsAppendix G - Use Case TemplatesAppendix H - PFED SpecificationH.1TOE Cryptographic Boundary and OverviewH.2Cryptographic Algorithms and ParametersH.3ERD Pair Provisioning and Cryptographic BondingH.3.1Tunnel-0 Establishment Using a Pre-Shared KeyH.3.2Transition to Tunnel-1 and PSK DestructionH.4Provisioning Completion and Key Material GenerationZH.5Key Derivation and Key StorageH.5.1Key DerivationH.5.2Hardware Root of TrustH.6Session Setup and Mutual AuthenticationH.7Rekey OperationsH.7.1Rekey SchedulingH.7.2Rekey ModesH.8Session Key RecoveryH.9Traffic Isolation and Interface FilteringH.10Dead Peer Detection and Persona EnforcementH.11Logging and AuditH.12Platform and Operational Environment EnforcementH.13Bring-Up and Multi-Factor ActivationAppendix I - AcronymsAppendix J - Bibliography

1 Introduction

1.1 Overview

The scope of this Protection Profile (PP) is to describe the security functionality of retransmission devices in terms of the Common Criteria and to define functional and assurance requirements for such products.

The form factors may vary according to the needs of the mission and the specific supported End User Devices (EUD) and are intended to provide isolation, authentication, and confidentiality for an EUD that must interoperate with an untrusted domain.

This PP covers devices which meet one of the following use cases: Communication Unit (CU), Encryption Unit (EU), or a combined EU+CU. The main goal of the CU use case is to provide network transport and simple isolation of the EUD. The EU use case is intended to provide an independent layer of encryption for an EUD on top of the existing network transport.

This PP can be met in one of three ways. The first is to claim conformance only to the CU requirements; the conformant Target of Evaluation (TOE) claims only that it is a CU. The second is to claim conformance to only the EU requirements; the conformant TOE claims only that it is an EU. The third is to claim conformance to both EU+CU, which must include a physical and logical separation between the EU and CU components in the enclosure or solution.

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

Address Space Layout Randomization (ASLR)
 An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of an application process.
Application (app)
 Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. The terms TOE and application are interchangeable in this document.
Application Programming Interface (API)
 A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform.
Communication Unit (CU)
 A retransmission device (RD) component whose primary purpose is to provide network transport and simple isolation for an End User Device (EUD) or Encryption Unit (EU) when communicating with an untrusted transport network. The interconnect between the EUD or EU and the CU is always over a dedicated wired interconnect.
Credential
 Data that establishes the identity of a user, (e.g., a cryptographic key or password).
Data Execution Prevention (DEP)
 An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code.
Developer
 An entity that writes application software. For the purposes of this document, vendors and developers are the same.
Encryption Unit (EU)
 A retransmission device component whose primary purpose is to provide an independent layer of encryption for an EUD on top of the existing network transport.
Hardware Separated Encrypting Retransmission Device (HWS-ERD)
 An HWS-ERD will encrypt traffic between two endpoints while maintaining a defined physical and logical protocol break between the trusted and the untrusted trusted domains. The protocol break will be both physically and logically enforced.
Mobile Code
 Software transmitted from a remote system for execution within a limited execution environment on the local system. Typically, there is no persistent installation and execution begins without the user's consent or even notification. Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash, and Microsoft Silverlight.
Operating System (OS)
 Software that manages hardware resources and provides services for applications.
Personally Identifiable Information (PII)
 Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. [OMB]
Platform
 The environment in which application software runs. The platform can be an operating system, hardware environment, a software based execution environment, or some combination of these. These types of platforms may also run atop other platforms.
Sensitive Data
 Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include PII, credentials, and keys. Sensitive data shall be identified in the application’s TSS by the ST author.
An anti-exploitation feature that places a value on the stack at the start of a function call, and checks that the value is the same at the end of the function call. This is also referred to as Stack Guard, or Stack Canaries.
Vendor
 An entity that sells application software. For purposes of this document, vendors and developers are the same. Vendors are responsible for maintaining and updating application software.

1.3 Compliant Targets of Evaluation

1.3.1 TOE Overview

The primary TOE for this PP is a retransmission device, herein referred to as a CU, that is designed to provide hardware isolation and other security features to protect communication between trusted EUDs or networks and unrestricted (black) transport networks.

In addition, this PP supports the specification, evaluation, and certification of other related components, either independently or in combination, as described in more detail below. Beyond the primary TOE (i.e., CU), conformance under this PP can be claimed for an EU, including the special use cases for supporting Wireless Local Area Network (WLAN) or other black network interface configurations, or a combination of a CU and EU, referred to herein as a Hardware Separated Encrypting Retransmission Device (HWS-ERD), including the special use case for Protocol Free Encrypting Device (PFED)-based implementations.

Depending on the evaluated configuration, the TOE may provide any of the following.

The TOE is deployed between an EUD or trusted network and an untrusted network environment. Its primary security objectives are to do the following.

The TOE supports the following evaluated configurations.

Each evaluated configuration constitutes a distinct TOE instance.

Figure 1: Communications Unit (CU) TOE

Figure 2: Encryption Unite (EU) TOE

Figure 3: CU+EU Hardware-Separated Encrypting Retransmission Device (HWS-ERD) TOE

Figure 4: CU+EU Hardware-Separated Encrypting Retransmission Device (HWS-ERD) TOE Environment Configuration

1.3.2 TOE Configurations

1.3.2.1 CU-Only Configuration

In the CU-Only configuration, the TOE performs the following.

The CU provides isolation between trusted components and untrusted black transport networks and represents the minimum TOE configuration supported by the PP.

CU Characteristics

Encryption Option Specific CU Behavior

1.3.2.2 EU-Only Configuration

In the EU-Only configuration, the TOE does the following. As noted, this configuration supports EUs that require connections to untrusted black networks, such as WLAN and tactical radio encryption implementations and functions as a dedicated encryption component for those applications. For these special use cases, some or all of the CU requirements may be applicable. All traffic transmitted over the untrusted interface, either wired or wirelessly, is cryptographically protected.

1.3.2.3 HWS-ERD Configuration

In the HWS-ERD configuration, the TOE consists of the following. The EU and CU are as follows. The EU is solely responsible for: The CU is solely responsible for the following. Plaintext traffic does not traverse the CU or any black interface, i.e., there may be no cryptographic bypass capability between the EUD or trusted network and EU or between the EU and CU.

1.3.3 TOE Logical Boundary

The logical boundary of the TOE includes the security functionality implemented by hardware, firmware, and software components within the evaluated configuration.

Depending on the configuration, the TOE logical boundary includes the following security functions.

1.3.3.1 Security Isolation

For all configurations, the TOE does the following. In the HWS-ERD configuration, this includes enforced separation between the EU and CU roles.

1.3.3.2 Traffic Forwarding and Routing - CU-Only and HWS-ERD

Where applicable, the TOE does the following.

1.3.3.3 Cryptographic Processing - EU-Only and HWS-ERD

Where applicable, the TOE does the following. In these configurations, all cryptographic processing is confined to the EU component.

1.3.3.4 Security Management

The TOE provides administrative functionality to do the following. In these configurations, all cryptographic processing is confined to the EU component.

1.3.4 TOE Physical Boundary

The TOE physical boundary encompasses all hardware, firmware, and software components that implement the security functionality described in the TOE logical boundary. The physical boundary must also be protected by passive anti-tamper methods.

1.3.4.1 CU-Only Physical Boundary

The TOE includes the following. The following are excluded from the TOE.

1.3.4.2 EU-Only Physical Boundary

The TOE includes the following. The following are excluded from the TOE

1.3.4.3 HWS-ERD Physical Boundary

The TOE includes both of the following.

Encryption Unite (EU) Communications Unit (CU) The dedicated wired interface between the EU and CU is included within the TOE boundary. The following are excluded from the TOE.

1.4 Use Cases

[USE CASE 1] Dedicated CU Retransmission Device (CU-Only)
The TOE is a retransmission device that provides network transport and routing functionality, as well as hardware isolation between trusted components and untrusted black transport networks.
[USE CASE 2] Dedicated EU Retransmission Device (EU-Only)
The TOE is a retransmission device that provides hardware isolation between the EUD and untrusted black transport networks, as well as capability to encrypt all traffic from the EUD to form an encrypted tunnel to another encryption endpoint.
[USE CASE 3] Hardware-Separated Encrypting Retransmission Device (HWS-ERD) (i.e., CU + EU)
The TOE is a retransmission device composed of a hardware-separated EU and CU.
  • The EU and CU are implemented as distinct hardware components with independent processors and memory.
  • Communication between the EU and CU occurs only via a dedicated wired interface.
  • The EU is solely responsible for cryptographic processing of the EUD payload.
  • The CU is solely responsible for routing or transport of encrypted traffic and isolation from untrusted networks.

1.5 Product Features Mapped to Implementation-Dependent Requirements

The features enumerated below, if implemented by the TOE, require that additional SFRs be claimed in the ST.

1.5.1 IPsec

A conformant TOE claims to be an EU and implements IPsec for data-in-transit encryption in the EU.

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

1.5.2 MACsec

A conformant TOE claims to be an EU and implements MACsec for data-in-transit encryption in the EU.

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

1.5.3 PFED

A conformant TOE claims to be an EU and implements PFED for data-in-transit encryption in the EU.

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

1.5.4 WLAN

A conformant TOE claims to be an EU and implements WLAN for data-in-transit encryption in the EU.

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

1.5.5 CU Functionality

A conformant TOE claims to be a CU. This includes the TOE claiming to be only a CU or claiming to be a CU as part of an HWS-ERD configuration.

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

1.5.6 Hardware-Separated Encrypting Retransmission Device (HWS-ERD)

A conformant TOE claims to be both a CU and an EU, and includes physical and logical separation between the EU and CU components in the enclosure or solution.

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

1.6 SFR Applicability

The following table depicts how each SFR is applicable to CU and EU. f
SFR CU EU Mandatory (M), Objective (Ob), Optional (Op), Selection-Based (SB)
FAU_GEN.1 Audit Data Generation X X M
FAU_SAR.1 Audit Review X X M
FAU_STG.1 Audit Data Storage Location
FAU_STG.2 Protected Audit Trail Storage X X M
FAU_STG.5 Prevention of Audit Data Loss X X M
FCO_NRO.1 Selective Proof of Origin X O
FCO_NRR.1 Selective Proof of Receipt X X O
FCS_CKM.1/AKG Cryptographic Key Generation - Asymmetric Key X SB
FCS_CKM.1/SKG Cryptographic Key Generation - Symmetric Key X X SB
FCS_CKM.2 Cryptographic Key Distribution X SB
FCS_CKM.6 Timing and Event for Cryptographic Key Destruction X X M
FCS_CKM_EXT.7 Cryptographic Key Agreement X SB
FCS_COP.1/AEAD Cryptographic Operation - Authenticated Encryption with Associated Data X X SB
FCS_COP.1/CMAC Cryptographic Operation - CMAC X SB (FCS_CKM.5.1, FCS_STG_EXT.3.1)
FCS_COP.1/Hash Cryptographic Operation - Hashing X X SB
FCS_COP.1/KeyedHash Cryptographic Operation - Keyed Hash X X SB
FCS_COP.1/KeyEncap Cryptographic Operation - Key Encapsulation X SB
FCS_COP.1/KeyWrap Cryptographic Operation - Hashing X X SB
FCS_COP.1/SigGen Cryptographic Operation - Signature Generation X SB
FCS_COP.1/SigVer Cryptographic Operation - Signature Verification X X SB
FCS_COP.1/SKC Cryptographic Operation - Symmetric Key Encryption and Decryption X X SB
FCS_COP.1/XOF Cryptographic Operation - Extendable-Output Function X X SB
FCS_HTTPS_EXT.1 HTTPS Protocol X X SB
FCS_RBG.1 Random Bit Generation (RBG)
FCS_RBG.2 Random Bit Generation (External Seeding) X X SB
FCS_RBG.3 Random Bit Generation (Internal Seeding - Single Source X X SB
FCS_RBG.4 Random Bit Generation (Internal Seeding - Multiple Sources) X X SB
FCS_RBG.5 Random Bit Generation (Combining Entropy Sources) X X SB
FCS_RBG.6 Random Bit Generation Service X X SB
FCS_STG_EXT.1 Protected Storage X X M
FCS_STG_EXT.2 Encrypted Cryptographic Key Storage X X SB (FCS_STG_EXT.1.1)
FCS_STG_EXT.3 Key Integrity Protection X X SB (FCS_STG_EXT.1.1)
FDP_IFC.1/CU Subset Information Flow Control X X O
FDP_IFC.1/HWS Subset Information Flow Control X X O
FDP_IFC.2 Complete Information Flow Control X X M - EUs, O - CUs
FDP_IFF.1 Information Flow Control Functions X X M - EUs, O - CUs
FDP_ITC_EXT.1 Key/Credential Import X X SB (FCS_STG_EXT.1.2
FDP_STG_EXT.1 User Data Storage X X M
FIA_AFL_EXT.1 Authentication Failure Handling X X SB
FIA_PMG_EXT.1 Password Management X X M
FIA_PSK_EXT.1 Pre-Shared Key Composition X X SB (IPsec only)
FIA_TRT_EXT.1 Authentication Throttling X X M
FIA_UAU.5 Multiple Authentication Mechanisms X X SB
FIA_UAU.7 Protected Authentication Feedback X X SB
FIA_UAU_EXT.1 Authentication for Cryptographic Operation X X SB
FIA_UAU_EXT.2 Timing of Authentication X X M
FMT_MOF Management of Security FUnctions Behavior X X M
FMT_SMF.1 Specification of Management Functions X X M
FMT_SMR.1 Security Roles X X M
FPF_RUL_EXT.1 Packet Filtering Rules X X M
FPF_RUL_EXT.1 Packet Filtering Rules X X M
FPT_APW_EXT.1 Protection of Administrator Password X X M
FPT_BBD_EXT.1 Application Processor Mediation X M
FPT_FLS.1 Failure with Preservation of Secure State X X SB
FPT_INI.1 TSF Initialization X X M
FPT_JTA_EXT.1 JTAG Disablement X X M
FPT_KST_EXT.1 Key Storage X X M
FPT_KST_EXT.2 No Key Transmission X X M
FPT_KST_EXT.3 No Plaintext Key Export X X M
FPT_NOT_EXT.1 Self-Test Notification X X M
FPT_PHP.1 Passive Detection of Physical Attack X X M
FPT_PHP.2 Notification of Physical Attack X X Ob
FPT_PHP.3 Resistance to Physical Attack X X Ob
FPT_PPF_EXT.1 Protection of Platform Firmware and Critical Data X X M
FPT_RBP_EXT.1 Rollback Protection X X M
FPT_RCV.2 Automated Recovery X X M
FPT_ROT_EXT.1 Platform Integrity Root X X M
FPT_ROT_EXT.2 Platform Integrity Extension X X M
FPT_RVR_EXT.1 Platform Firmware Recovery X X SB
FPT_SEP_EXT.1 TSF Domain Separation XX M
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) X X M
FPT_STM.1 Reliable Time Stamps X X M
FPT_TST.1 TSF Self-Test X M
FPT_TST_EXT.1 TSF Testing X X M
FPT_TUD_EXT.1 TOE Firmware Update X X M
FPT_TUD_EXT.2 Platform Firmware Authenticated Update Mechanism X X SB
FPT_TUD_EXT.3 Platform Firmware Delayed - Authentication Update Mechanism X X SB
FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism X X SB
FTA_SSL.3 TSF-Initiated Termination X X M
FTA_SSL.4 User-Initiated Termination X X M
FTA_SSL_EXT.1 TSF- and TSF-Initiated Session Blocking X X M
FTA_TAB.1 Default TOE Access Banners X X M
FTP_ITC.1 Inter-TSF Trusted Channel X
FTP_ITC.1/MACsec Trusted Channel Communication - MACsec X (MACsec) SB
FTP_ITC_EXT.1/Admin Physically Protected Channel SB
FTP_ITC_EXT.1/IPsec Trusted Channel Communication X (IPsec) SB
FTP_ITC_EXT.1/WLAN Trusted Channel Communication (Wireless LAN) X (WLAN, EU-only) SB
FTP_ITP_EXT.1 Physically Protected Channel X X
FTP_TRP.1 Trusted Path SB (FMT_SMF.1.1)

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 Security Problem Definition

The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce.

3.1 Threats

T.BASEBAND_PROCESSOR_COMPROMISE
The Baseband Processor (BP), which processes untrusted radio-frequency inputs (e.g., cellular, Wi-Fi, Bluetooth), may be exploited by an attacker through malformed or malicious wireless signals. A successful compromise of the BP could allow an attacker to execute arbitrary code within the BP domain. An attacker controlling the BP may attempt to access or manipulate Application Processor (AP) resources without authorization.
T.DATA_INTEGRITY
Devices on a protected network may be exposed to threats presented by devices located outside the protected network that may attempt to modify the data without authorization or determine the contents of secure communication. If known malicious external devices are able to communicate with devices on the protected network or if devices on the protected network can communicate with those external devices, then the data contained in the communications may be susceptible to a loss of integrity or confidentiality.
T.NETWORK_ACCESS
Devices located outside the protected network may seek to exercise services located on the protected network that are intended to only be accessed from inside the protected network or only accessed by entities using an authenticated path into the protected network.
T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may initiate communications with the TOE or alter communications between the TOE and other endpoints in order to compromise the TOE. An attacker from off the TOE can attempt to compromise the TOE through a network interface connected to an active TOE component, such as a management subsystem. These attacks include malicious software update of any applications or system software on the device. An attacker is actively interacting with or altering network traffic to compromise the TOE.
T.NETWORK_DISCLOSURE
Devices on a protected network may be exposed to threats presented by devices located outside the protected network, which may attempt to conduct unauthorized activities. If malicious external devices are able to communicate with devices on the protected network, or if devices on the protected network can establish communications with those external devices (e.g., as a result of nonexistent or insufficient data encryption that exposes the data in transit to rogue elements), then those internal devices may be susceptible to the unauthorized disclosure of information.
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 the TOE and other endpoints, resulting in modification or disclosure of sensitive communications. An attacker is listening to communications to extract sensitive information.
T.PERSISTENT_PRESENCE
Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it. The device has likely lost this integrity due to some other threat vector, yet the continued access by an attacker constitutes an ongoing threat in itself. In this case, the device and its data may be controlled by an adversary as well as by its legitimate owner.
T.PHYSICAL_ACCESS
An attacker with physical access may attempt to access user data on the mobile device, including credentials. These physical access threats may involve attacks that attempt to access the device through external hardware ports, to impersonate the user authentication mechanisms through its user interface, or through direct and possibly destructive access to its storage media. An attacker with physical access might also be able to compromise TOE integrity, subvert TOE protections, or access tenant data through hardware attacks such as probing, physical manipulation, fault-injection, side-channel analysis, environmental stress, or activating disabled features or pre-delivery services.
T.REPLAY_ATTACK
If an unauthorized individual successfully gains access to the system, the adversary may have the opportunity to conduct a replay attack. This method of attack allows the individual to capture packets traversing the network and send the packets later, possibly unknown by the intended receiver.
T.SECURITY_FUNCTIONALITY_FAILURE
An attacker could leverage failed or compromised security functionality to access, change, or modify tenant data, TOE data, or other security functionality of the device.
T.SIDE_CHANNEL_LEAKAGE
An attacker running in a tenant context might be able to leverage physical effects caused by the operation of the TOE to derive sensitive information about other tenants or the TOE.
T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR
An attacker might be able to attain platform administrator status by defeating or bypassing authentication measures.
T.UNAUTHORIZED_RECONFIGURATION
An attacker might be able to modify the configuration of the TOE and alter its functionality. This might include activating dormant subsystems, disabling hardware assists, or altering boot-time behaviors.
T.UPDATE_COMPROMISE
An attacker may attempt to provide a compromised update of TOE firmware. Such updates can undermine the security functionality of the device if they are unauthorized, unauthenticated, or are improperly validated using non-secure or weak cryptography.

3.2 Assumptions

A.CONFIG
It is assumed that the TOE’s security functions are configured correctly in a manner to ensure that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks.
A.NOTIFY
It is assumed that the mobile user will immediately notify the administrator if the TOE is lost or stolen.
A.PRECAUTION
It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the TOE.
A.PROPER_USER
TOE users are not willfully negligent or hostile and use the device in compliance with a reasonable enterprise security policy.
A.REGULAR_UPDATES
It is assumed that the manufacturer provides updates to TOE firmware in a timely manner in response to known vulnerabilities, and that administrators apply these updates when they are received.
A.SUPPLY_CHAIN_SECURITY
The hardware components that comprise the TOE are assumed to be non-hostile and not compromised at the time of TOE construction. Likewise, the TOE is assumed to retain its integrity throughout transportation until delivery to its operational site.
A.TRUSTED_ADMIN
TOE security administrators are assumed to be trusted and to act in the best interest of security for the organization. The TOE is not expected to be capable of defending against a malicious administrator that actively works to bypass or compromise the security of the platform.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

The following security objectives for the operational environment assist the TOE in correctly providing its security functionality. These track with the assumptions about the environment.
OE.CONFIG
TOE administrators will configure the mobile device security functions correctly to create the intended security policy.
OE.NOTIFY
The TOE user will immediately notify the administrator if the TOE is lost or stolen.
OE.PRECAUTION
he TOE user exercises precautions to reduce the risk of loss or theft of the TOE.
OE.PROPER_USER
Administrators take measures to ensure that TOE users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device.
OE.SUPPLY_CHAIN
The manufacturer is expected to implement processes to ensure that TOE hardware and firmware are not compromised between time of TOE manufacture and delivery to its operational site.
OE.TRUSTED_ADMIN
The administrator of the TOE is not careless, willfully negligent or hostile, and administers the platform in compliance with enterprise security policy.

4.2 Security Objectives Rationale

This section describes how the assumptions and organizational security policies map to operational environment security objectives.
Table 1: Security Objectives Rationale
Assumption or OSPSecurity ObjectivesRationale
A.CONFIGOE.CONFIGThe operational environment objective OE.CONFIG is realized through A.CONFIG.
A.NOTIFYOE.NOTIFYThe operational environment objective OE.NOTIFY is realized through A.NOTIFY.
A.PRECAUTIONOE.PRECAUTIONThe operational environment objective OE.PRECAUTION is realized through A.PRECAUTION.
A.PROPER_​USEROE.PROPER_​USERThe operational environment objective OE.PROPER_USER is realized through A.PROPER_USER.
A.REGULAR_​UPDATESOE.TRUSTED_​ADMINThe operational environment objective A.REGULAR_UPDATES is realized through OE.TRUSTED_ADMIN.
A.SUPPLY_​CHAIN_​SECURITYOE.SUPPLY_​CHAINThe operational environment objective A.SUPPLY_CHAIN_SECURITY is realized through OE.SUPPLY_CHAIN.
A.TRUSTED_​ADMINOE.TRUSTED_​ADMINThe operational environment objective A.TRUSTED_ADMIN is realized through OE.TRUSTED_ADMIN.

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

5.1 Security Functional Requirements

5.1.1 Auditable Events for Mandatory SFRs

Table 2: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_GEN.1
No events specifiedN/A
FAU_SAR.1
No events specifiedN/A
FAU_STG.1
On failure of logging function, capture record of failure and record upon restart of logging function. None
FAU_STG.2
No events specifiedN/A
FAU_STG.5
Audit trail full. Overwrite of audit records is commencing. None
FCO_NRO.1
No events specifiedN/A
FCO_NRR.1
No events specifiedN/A
FCS_STG_EXT.1
No events specifiedN/A
FDP_IFC.2
No events specifiedN/A
FDP_IFF.1
No events specifiedN/A
FDP_STG_EXT.1
Addition or removal of certificate from Trust Anchor DatabaseSubject name of certificate
FIA_PMG_EXT.1
No events specifiedN/A
FIA_PSK_EXT.1
No events specifiedN/A
FIA_TRT_EXT.1
No events specifiedN/A
FIA_UAU_EXT.2
Action performed before authentication. No additional information
FMT_MOF.1
No events specifiedN/A
FMT_SMF.1
No events specifiedN/A
FMT_SMR.1
No events specifiedN/A
FPF_RUL_EXT.1
No events specifiedN/A
FPT_APW_EXT.1
No events specifiedN/A
FPT_BBD_EXT.1
No events specifiedN/A
FPT_INI.1
  • Detection of an initialization error or failure
  • Entry into halted, reduced-functionality, or error-signaling state due to initialization failure
  • Successful initialization, if audited by the TOE
Result, state entered, affected property or element if available, and reason for failure if available
FPT_JTA_EXT.1
No events specifiedN/A
FPT_KST_EXT.1
No events specifiedN/A
FPT_KST_EXT.2
No events specifiedN/A
FPT_KST_EXT.3
No events specifiedN/A
FPT_NOT_EXT.1
[selection, choose one of: Measurement of TSF software, none][selection, choose one of: Integrity verification value, No additional information]
FPT_PHP.1
[selection: Detection of intrusion., None]None.
FPT_PPF_EXT.1
No events specifiedN/A
FPT_RBP_EXT.1
No events specifiedN/A
FPT_RCV.2
  • Entry into maintenance mode due to a failure or service discontinuity from which automated recovery is not possible
  • If audited by the TOE, attempt to return the TOE to a secure state from maintenance mode
  • If audited by the TOE, successful return to a secure state
Failure/discontinuity type if available, recovery action if available, state entered, and result
FPT_ROT_EXT.1
No events specifiedN/A
FPT_ROT_EXT.2
[selection: Failure of integrity verification, None]None
FPT_SKP_EXT.1
No events specifiedN/A
FPT_STM.1
No events specifiedN/A
FPT_TST.1
Execution of self-tests No additional information
FPT_TST_EXT.1
Initiation of self-test No additional information
Failure of self-test[selection, choose one of: Algorithm that caused the failure, No additional information]
FPT_TUD_EXT.1
No events specifiedN/A
FTA_SSL.3
TSF-initiated termination of a remote interactive session due to inactivity No additional information
FTA_SSL.4
Administrator-initiated termination of an interactive session No additional information
FTA_SSL_EXT.1
No events specifiedN/A
FTA_TAB.1
No events specifiedN/A
FTP_ITC.1
  • Establishment of a trusted channel
  • Failure to establish or use a trusted channel for a claimed capability of service
  • TOE-initiated communication over a trusted channel for a claimed service
Trusted-channel mechanism, peer or endpoint identity if available, claimed capability or initiated service, result, and reason for failure if available

5.1.2 Auditable Events for Objective SFRs

Table 3: Auditable Events for Objective Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FPT_PHP.2
[selection: Detection of intrusion, None]None
FPT_PHP.3
Detection of attempted intrusion. None

5.1.3 Auditable Events for Implementation-Dependent SFRs

Table 4: Auditable Events for Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_GEN.1/PFED
No events specifiedN/A
FAU_GEN.2/PFED
No events specifiedN/A
FAU_STG.1/PFED
No events specifiedN/A
FCS_CKM.1/PFEDAKG
No events specifiedN/A
FCS_CKM.2/PFED
No events specifiedN/A
FCS_CKM.5/PFED
No events specifiedN/A
FCS_CKM.6
No events specifiedN/A
FCS_CKM.6/PFED
No events specifiedN/A
FCS_CKM_EXT.7
No events specifiedN/A
FCS_COP.1/PFEDAES
TBD No additional information
FCS_COP.1/PFEDHash
No events specifiedN/A
FCS_COP.1/PFEDKeyEncap
No events specifiedN/A
FCS_COP.1/PFEDSigGen
No events specifiedN/A
FCS_COP.1/PFEDSigVer
No events specifiedN/A
FCS_REC_EXT.1/PFED
No events specifiedN/A
FCS_REKEY_EXT.1/PFED
  • PFED rekey initiation, if audited
  • Successful PFED rekey, if audited;
  • Failure of PFED rekey0
 No additional information
FDP_BRINGUP_EXT.1
  • Secure bring-up credential provision, if audited
  • Successful secure bring-up
  • Failed secure bring-up
 No additional information
FDP_IFC.1/CU
  • Denial of a covered CU packet flow by policy, if audited
  • Permitting of a covered CU packet flow by policy, if audited
 No additional information
FDP_IFC.1/HWS
No events specifiedN/A
FDP_IFC.1/PFED
No events specifiedN/A
FDP_IFF.1/CU
Denial of a CU packet flow because it does not match an explicitly configured allow rule No additional information
FDP_IFF.1/HWS
No events specifiedN/A
FDP_IFF.1/PFED
No events specifiedN/A
FIA_AFL.1/PFED
No events specifiedN/A
FIA_PSK_EXT.1/PFED
No events specifiedN/A
FIA_UAU.2/PFED
  • Successful PFED mutual authentication, if audited
  • failed PFED mutual authentication
 No additional information
FIA_UAU.3/PFED
  • Successful or failed PFED mutual authentication
  • Successful of failed PFED user activation, if claimed and audited
 No additional information
FMT_SMF.1/PFED
No events specifiedN/A
FPT_DPD_EXT.1
  • Detection of peer failure or disconnect
  • Triggering of session reconnect
  • Failure of reconnect attempt, if audited
 No additional information
FPT_FLS.1/PFED
Session termination due to dead peer detection, recovery failure, or provisioning failure No additional information
FPT_HRT.1/PFED
No events specifiedN/A
FPT_ISO_EXT.1/PFED
No events specifiedN/A
FPT_RCV.1/PFED
Entry into secure recovery state due to dead peer detection, session key divergence, failed rekey, or failed recovery No additional information
FPT_SEP_EXT.1
No events specifiedN/A
FPT_TRAN_EXT.1/PFED
No events specifiedN/A
FPT_TST.1/PFED
  • Successful completion of initialization self-test
  • Failure of initialization self-test of a PFED cryptographic function
  • Failure of initialization self-test or verification of the hardware root of trust
 No additional information
FTP_ITC.1/MACsec
Initiation and termination of trusted channelTrusted channel protocol, non-TOE endpoint of connection
FTP_ITC.1/PFED
No additional information

5.1.4 Auditable Events for Selection-Based SFRs

Table 5: Auditable Events for Selection-based Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FCS_CKM.1/AKG
Needs to be completed. No additional information
FCS_CKM.1/SKG
Needs to be completed. No additional information
FCS_CKM.2
Needs to be completed. No additional information
FCS_COP.1/AEAD
No events specifiedN/A
FCS_COP.1/CMAC
No events specifiedN/A
FCS_COP.1/Hash
No events specifiedN/A
FCS_COP.1/KeyEncap
No events specifiedN/A
FCS_COP.1/KeyWrap
No events specifiedN/A
FCS_COP.1/KeyedHash
No events specifiedN/A
FCS_COP.1/SKC
No events specifiedN/A
FCS_COP.1/SigGen
No events specifiedN/A
FCS_COP.1/SigVer
No events specifiedN/A
FCS_COP.1/XOF
No events specifiedN/A
FCS_HTTPS_EXT.1
Failure to establish an HTTPS session
  • Reason for failure
  • Non-TOE endpoint of connection (IP address) for failures
Establishment or Termination of an IPsec SANon-TOE endpoint of connection (IP address)
FCS_RBG.1
Failure of the randomization processNone
FCS_RBG.2
No events specifiedN/A
FCS_RBG.3
No events specifiedN/A
FCS_RBG.4
No events specifiedN/A
FCS_RBG.5
No events specifiedN/A
FCS_RBG.6
No events specifiedN/A
FCS_STG_EXT.2
No events specifiedN/A
FCS_STG_EXT.3
No events specifiedN/A
FDP_ITC_EXT.1
No events specifiedN/A
FDP_PBR_EXT.1
No events specifiedN/A
FIA_AFL_EXT.1
Failed attempt at administrator authenticationNone
FIA_UAU.5
No events specifiedN/A
FIA_UAU.7
No events specifiedN/A
FIA_UAU_EXT.1
No events specifiedN/A
FIA_UIA_EXT.1
All use of the authentication mechanismProvided user identity, origin of the attempt (e.g., console, remote IP address)
FPT_FLS.1
Failure of the TSF None
FPT_RVR_EXT.1
No events specifiedN/A
FPT_TUD_EXT.2
[selection: Failure of update authentication/integrity check/rollback, None]Version numbers of the current firmware and of the attempted update
[selection: Failure of update operation, None]Version numbers of the current firmware and of the attempted update
[selection: Success of update operation, None]Version numbers of the new and old firmware images
FPT_TUD_EXT.3
[selection: Failure of update authentication/integrity/rollback check, None]Version numbers of the current firmware and of the attempted update
[selection: Failure of update operation, None]Version numbers of the current firmware and of the attempted update
[selection: Success of update operation, None]Version numbers of the new and old firmware images
FPT_TUD_EXT.4
No events specifiedN/A
FTP_ITC_EXT.1/Admin
Initiation of the trusted channelUser ID and remote source (IP Address) if feasible
Termination of the trusted channelUser ID and remote source (IP Address) if feasible
Failures of the trusted path functionsUser ID and remote source (IP Address) if feasible
FTP_ITC_EXT.1/IPsec
Initiation and termination of trusted channelTrusted channel protocol, non-TOE endpoint of connection
FTP_ITC_EXT.1/WLAN
Initiation and termination of trusted channelTrusted channel protocol, non-TOE endpoint of connection
FTP_ITP_EXT.1
No events specifiedN/A
FTP_TRP.1
Initiation of the trusted channelAdministrator ID and remote source (IP Address), if feasible
Termination of the trusted channelAdministrator ID and remote source (IP Address), if feasible
Failures of the trusted path functionsUser ID and remote source (IP Address), if feasible

5.1.5 Class FAU: Security Audit

FAU_GEN.1 Audit Data Generation

The TSF shall be able to generate audit data of the following auditable events:
  1. Start-up and shutdown of the audit functions
  2. All administrative actions
  3. Start-up, shutdown, and reboot of the platform
  4. Specifically defined auditable events in Table 2
  5. [selection: ].
The TSF shall record within the audit data at least the following information:
  1. Date and time of the event
  2. Type of event
  3. Subject and object identity (if applicable)
  4. The outcome (success or failure) of the event
  5. [Additional information defined in Table 2]
  6. [selection: ].
Application Note: The ST author should include this SFR in the ST if the TOE generates audit events for integrity verification or boot failures as indicated by the appropriate selections in FPT_ROT_EXT.2, FPT_ROT_EXT.3, FPT_TUD_EXT.2, or FPT_TUD_EXT.3.4.

If this SFR is included in the ST, then all the other FAU SFRs must also be claimed.

Appropriate entries from Table t-audit-optional, Table t-audit-objective, and Table t-audit-sel-based should be included in the ST if the associated SFRs and selections are included.

Specific auditable events required for SFRs from the functional packages are defined in the respective packages.

Evaluation Activities
FAU_GEN.1
TSS
The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type shall be covered, along with a brief description of each field.
Guidance
The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP. The evaluator shall examine the AGD and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements claimed in the ST. The evaluator shall document the methodology or approach taken while determining which actions in the AGD are security-relevant with respect to this PP.
Tests
The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed and administrative actions. 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. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly.

FAU_SAR.1 Audit Review

The TSF shall provide the administrator with the capability to read all audited events and record contents from the audit data.
The TSF shall provide the audit data in a manner suitable for the administrator to interpret the information.
Evaluation Activities
FAU_SAR.1
TSS
There are no additional TSS evaluation activities for this component.
Guidance
The evaluator shall review the AGD for the procedure on how to review the audit records.
Tests
The evaluator shall verify that the audit records provide all of the information specified in FAU_GEN.1 and that this information is suitable for human interpretation. The evaluation activity for this requirement is performed in conjunction with the evaluation activity for FAU_GEN.1.

FAU_STG.1 Audit Data Storage Location

The TSF shall be able to[selection: store audit data on the TOE itself, transmit audit data to an external IT entity using a trusted channel in accordance with FTP_ITC_EXT.1/Admin]
Application Note: The ST author selects "trusted channel" and includes FTP_ITC_EXT.1/Admin in the ST if the TOE offloads audit data to external IT entity over a network connection. Protocols used for implementing the trusted channel must be selected in FTP_ITC_EXT.1/Admin.
Evaluation Activities
FAU_STG.1.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.
Guidance
If "trusted channel" is selected above, the evaluator shall examine the AGD 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. Furthermore, it must describe whether the transfer mechanism is periodic or continuous, and what happens in the event of a loss of connectivity.
Tests
If "trusted channel" is selected above, testing of the trusted channel mechanism itself is to be performed as specified in the evaluation activities for FTP_ITC_EXT.1/Admin. In addition, the evaluator must perform the following test:

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.2 Protected Audit Trail Storage

The TSF shall protect the stored audit data in the audit trail from unauthorized deletion.
The TSF shall be able to [prevent] unauthorized modifications to the stored audit data in the audit trail.
Application Note: Deletion of audit data within the TOE is "authorized" if the deletion is initiated or performed by an administrator.

Notwithstanding this requirement, audit records may be overwritten if local audit record storage is full in accordance with FAU_STG.5.

Evaluation Activities
FAU_STG.2
TSS
The evaluator shall ensure that the TSS lists the locations of all logs and the access controls of those files such that unauthorized modification and deletion are prevented.
Guidance
The evaluator shall ensure that the Guidance describes the steps necessary for an authorized administrator to delete audit records, if such a capability is implemented.
Tests
The evaluator shall perform the following tests:
  • Test FAU_STG.2:1: [conditional] If the TOE implements an audit record deletion capability, then the evaluator shall attempt to delete the audit trail in a manner that the access controls should prevent (as an unauthorized user) and shall verify that the attempt fails.

  • Test FAU_STG.2:2: The evaluator shall attempt to modify the audit trail in a manner that the access controls should prevent (as an unauthorized application) and shall verify that the attempt fails.

FAU_STG.5 Prevention of Audit Data Loss

The TSF shall optionally notify the administrator or user that storage is full and [overwrite the oldest stored audit records] if the audit data storage is full.
Evaluation Activities
FAU_STG.5
TSS
The evaluator shall examine the TSS to ensure that it describes the size limits on the audit records, the detection of a full audit trail, and the actions taken by the TSF when the audit trail is full. The evaluator shall ensure that the actions results in the deletion or overwrite of the oldest stored record.
Guidance
The evaluator shall examine the AGD to ensure that it describes the means used by the TOE to indicate that the audit trail is full and overwrite is about to commence.
Tests
The evaluator shall cause audit records to be written until the size limits are met and exceeded. The evaluator shall verify that the overwrite function works as described in the TSS and that the indication of full audit trail is evident as described in the AGD.

5.1.6 Class FCO: Communications

FCO_NRO.1 Selective Proof of Origin

The TSF shall be able to generate evidence of origin for transmitted [assignment: list of information types] at the request of the [selection: originator, recipient, [assignment: list of third parties]].
The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies.
The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of origin].
Application Note: The intent of this requirement is for the TOE to provide verifiable evidence that specified transmitted information originated from the claimed source and was generated by the TOE acting on behalf of that source. The ST author identifies the types of data for which proof of origin is provided (e.g., control messages, management communications, or selected user data flows).

Typical implementations rely on digital signatures or message authentication codes (MACs) bound to the originator. The mechanism is expected to prevent forgery and replay.
Evaluation Activities
FCO_NRO.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies each transmitted information type for which the TOE generates evidence of origin.
  • Describes the specific mechanism used to generate the evidence of origin for each claimed information type.
  • Identifies the originator attributes and information fields that are bound to the evidence of origin.
  • Describes how the TOE ensures the integrity of the binding between the originator-related attributes, the identified information fields, and the resulting evidence of origin.
  • Identifies the entities that are able to request generation of the evidence and the entities that are able to verify it.
  • Describes all claimed limitations on verification, including any dependence on trusted channels, cryptographic keys, certificates, time, retained state, or message freshness information.
  • Describes how the TOE handles failed verification, missing required attributes or fields, unsupported information types, and attempts to verify evidence outside the stated limitations.
  • If the TOE supports multiple protocols or message formats for this requirement, describes the behavior for each claimed protocol or format.
The evaluator shall also examine the TSS to ensure that the claimed evidence of origin is based on TOE-controlled data and TOE-enforced security functionality, and not solely on unauthenticated or externally asserted metadata that the TOE does not validate.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FCO_NRR.1 Selective Proof of Receipt

The TSF shall be able to generate evidence of receipt for received [assignment: list of information types] at the request of the [selection: originator, recipient, [assignment: list of third parties]].
The TSF shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the [assignment: list of information fields] of the information to which the evidence applies.
The TSF shall provide a capability to verify the evidence of receipt of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of receipt].
Application Note: The intent of this requirement is for the TOE to provide verifiable evidence that specified information was received by the claimed recipient and that the evidence was generated by the TOE acting on behalf of that recipient. The ST author defines the conditions under which proof of receipt is generated.

Proof of receipt is commonly realized through authenticated acknowledgements. These acknowledgements are expected to include integrity protection and resistance to replay.
Evaluation Activities
FCO_NRR.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies each received information type for which the TOE generates evidence of receipt.
  • Describes the specific mechanism used to generate the evidence of receipt for each claimed information type.
  • Identifies the recipient attributes and information fields that are bound to the evidence of receipt.
  • Describes how the TOE ensures the integrity of the binding between the recipient-related attributes, the identified information fields, and the resulting evidence of receipt.
  • Identifies the entities that are able to request generation of the evidence and the entities that are able to verify it.
  • Describes all claimed limitations on verification, including any dependence on trusted channels, cryptographic keys, certificates, time, retained state, or message freshness information.
  • Describes how the TOE handles failed verification, missing required attributes or fields, unsupported information types, and attempts to verify evidence outside the stated limitations.
  • If the TOE supports multiple protocols or message formats for this requirement, describes the behavior for each claimed protocol or format.
The evaluator shall also examine the TSS to ensure that the claimed evidence of receipt is based on TOE-controlled data and TOE-enforced security functionality, and not solely on unauthenticated or externally asserted metadata that the TOE does not validate.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

5.1.7 Class FCS: Cryptographic Support

FCS_STG_EXT.1 Protected Storage

The TSF shall provide [selection: mutable hardware-based, immutable hardware-based, software-based] protected storage for asymmetric private keys, [symmetric keys, and persistent secrets].
Application Note: If the protected storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST author is expected to select "software-based." If "software-based" is selected, the ST author is expected to select "software-based key storage" in FCS_STG_EXT.2 and also claim FCS_STG_EXT.3.

If this SFR is included in the ST, then FCS_CKM.6 must also be claimed.
The TSF shall support the capability of [selection:
  • importing keys and secrets into the TOE
  • causing the TOE to generate [selection: asymmetric, symmetric] keys and secrets
] upon request of [selection: a client application, an administrator].
Application Note: If "causing the TOE to generate keys and secrets" is selected in FCS_STG_EXT.1.2, then the ST must include at least one of FCS_CKM.1/AKG or FCS_CKM.1/SKG depending on the value of the internal selection.
The TSF shall be capable of destroying keys and secrets in the protected storage upon request of [selection: a client application, an administrator].
The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be explicitly authorized by [selection: the user, the administrator, a common application developer].
The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by [selection: the user, the administrator, a common application developer].
Evaluation Activities
FCS_STG_EXT.1
TSS
The evaluator shall review the TSS to determine that the TOE implements the required protected storage. The evaluator shall ensure that the TSS contains a description of the protected storage mechanism that justifies the selection of mutable hardware-based or software-based.
Guidance
The evaluator shall examine the AGD to ensure that it describes the process for generating keys, importing keys, or both, based on what is claimed by the ST. The evaluator shall also examine the AGD to ensure that it describes the process for destroying keys that have been imported or generated.
Tests
The evaluator shall test the functionality of each security function as described below. If the TOE supports both import and generation of keys, the evaluator shall repeat the testing as needed to demonstrate that the keys resulting from both operations are treated in the same manner. The devices used with the tooling may need to be non-production devices in order to enable the execution of testing and gathering of evidence.

  • Test FCS_STG_EXT.1:1: The evaluator shall import or generate keys and secrets of each supported type according to the operational guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key and secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur during import.

  • Test FCS_STG_EXT.1:2: The evaluator shall write, or the developer shall provide access to, tenant software that uses a generated or imported key/secret:
    • For RSA, the secret shall be used to sign data.
    • For ECDSA, the secret shall be used to sign data.
    The evaluator shall verify that the tenant software is able to access and use the key/secret as described.

  • Test FCS_STG_EXT.1:3: The evaluator shall destroy keys and secrets of each supported type according to the operational guidance. The evaluator shall write, or the developer shall provide access to, tenant software that destroys an imported or generated key and secret. The evaluator shall verify that the tenant software is able to cause the deletion of only keys that were created or imported on its behalf.

5.1.8 Class FDP: User Data Protection

FDP_IFC.2 Complete Information Flow Control

The TSF shall enforce the [assignment: information flow control SFP] on [assignment: list of subjects and information] and all operations that cause that information to flow to and from subjects covered by the SFP.
The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP.
The TSF shall enforce the [assignment: additional information flow control SFP rules].
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].
Application Note: The intent of this requirement is for the TOE to ensure that every operation that causes information to flow to or from a TOE subject is governed by one or more TOE-enforced information flow control Security Function Policies (SFPs), and that no information flow occurs outside that control. For a retransmission device, this requirement is intended to ensure that all traffic forwarding, relaying, routing, protocol handling, retransmission, and other TOE-mediated data movement are subject to explicit flow control policies rather than ad hoc or bypass behavior.

The TOE’s design is expected to ensure that no data path bypasses enforcement, including user data, control traffic, and management communications.

The ST author also describes how all interfaces and communication paths are brought under policy control.
Evaluation Activities
FDP_IFC.2
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the information flow control SFP or SFPs enforced by the TOE.
  • Identifies the subjects, information, and operations covered by each SFP.
  • Describes how the TOE ensures that all operations causing information to flow to or from TOE subjects are covered by one or more SFPs.
  • Describes the complete set of operational information flows within the claimed TOE configuration and maps those flows to the applicable SFPs.
  • Identifies the security attributes used by the TOE to make authorization and denial decisions for information flow.
  • Describes the additional SFP rules enforced by the TOE under FDP_IFC.2.3.
  • Describes the explicit authorization rules enforced by the TOE under FDP_IFC.2.4.
  • Describes the explicit denial rules enforced by the TOE under FDP_IFC.2.5.
The evaluator shall also verify that the authorization and denial rules are based on attributes that are available to the TOE and can be enforced by the TOE.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FDP_IFF.1 Information Flow Control Functions

The TSF shall enforce the [assignment: information flow control 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: for each operation, the security attribute-based relationship that hold between subject and information security attributes].
The TSF shall enforce the [assignment: additional information flow control SFP rules].
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: based on security attributes, that explicitly deny information flows].
Application Note: The intent of this requirement is for the TOE to enforce an information flow control Security Function Policy (SFP) by making permit or deny decisions based on defined security attributes of subjects and information. For a retransmission device, this requirement focuses on the decision function itself: the TOE is expected to evaluate security-relevant attributes associated with TOE-controlled subjects, information, and operations, and to permit or deny information flow only in accordance with the configured or defined policy rules. The ST author specifies security attributes associated with subjects and information (e.g., interfaces, VLAN identifiers, session state, cryptographic context), and the conditions governing whether flows are permitted or denied. Flow evaluation is expected to occur prior to transmission, with behavior typically following a default-deny model unless explicitly permitted.
Evaluation Activities
FDP_IFF.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the information flow control SFP enforced by the TOE.
  • Identifies the controlled subjects, information, and operations to which the SFP applies.
  • Identifies the subject security attributes and information security attributes used by the TOE to make information flow decisions.
  • Describes how the TOE obtains, maintains, or derives those attributes for use in policy enforcement.
  • Describes the attribute-based relationships required for a flow to be permitted for each claimed controlled operation.
  • Describes the additional information flow control rules enforced by the TOE under FDP_IFF.1.3.
  • Describes the explicit authorization rules enforced by the TOE under FDP_IFF.1.4.
  • Describes the explicit denial rules enforced by the TOE under FDP_IFF.1.5.
The evaluator shall examine the TSS to ensure that the security attributes named in the ST are attributes the TOE can actually evaluate and enforce, and that the described permit and deny logic is specific enough to support repeatable testing.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FDP_STG_EXT.1 User Data Storage

The TSF shall provide protected storage for the Trust Anchor Database.
Evaluation Activities
FDP_STG_EXT.1
TSS
The evaluator shall ensure the TSS describes the Trust Anchor Database implemented that contain certificates used to meet the requirements of this PP. This description shall contain information pertaining to how certificates are loaded into the store, and how the store is protected from unauthorized access (for example, UNIX permissions) in accordance with the permissions established in FMT_SMF_EXT.1 and FMT_MOF_EXT.1.1.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

5.1.9 Class FIA: Identification and Authentication

FIA_PMG_EXT.1 Password Management

The TSF shall support the following for the Password Authentication Factor:
  1. Passwords shall be able to be composed of any combination of [selection: upper and lower case letters, [assignment: a character set of at least 52 characters]], numbers, and special characters: [selection: "!", "@", "#", "$", "%", "^", "&", "*", "(", ")", [assignment: other characters]]
  2. Password length up to [assignment: an integer greater than or equal to 14] characters shall be supported.
Application Note: While some corporate policies require passwords of 14 characters or better, the use of a Root Encryption Key for DAR protection and key storage protection and the anti-hammer requirement (FIA_TRT_EXT.1) addresses the threat of attackers with physical access using much smaller and less complex passwords.

The ST author selects the character set: either the upper and lower case Basic Latin letters or another assigned character set containing at least 52 characters. The assigned character set must be well defined: either according to an international encoding standard (such as Unicode) or defined in the assignment by the ST author. The ST author also selects the special characters that are supported by TOE; they may optionally list additional special characters supported using the assignment.
Evaluation Activities
FIA_PMG_EXT.1
TSS
There are no additional TSS evaluation activities for this component.
Guidance
The evaluator shall examine the operational guidance to determine that it provides guidance to security administrators on the composition of strong passwords, and that it provides instructions on setting the minimum password length. The evaluator shall also perform the following tests. Note that one or more of these tests can be performed with a single test case.
Tests
The evaluator shall compose passwords that either meet the requirements, or fail to 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, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.

FIA_PSK_EXT.1 Pre-Shared Key Composition

The TSF shall be able to use pre-shared keys that conform to RFC 8784 for IPsec
The TSF shall be able to [selection: accept externally generated pre-shared keys, generate 256 bit-based pre-shared keys via FCS_RBG.1].
Application Note: Generated PSKs are expected to be shared between components via an out-of-band mechanism.
Evaluation Activities
FIA_PSK_EXT.1
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.

FIA_TRT_EXT.1 Authentication Throttling

The TSF shall limit automated user authentication attempts by [selection: preventing authentication via an external port, enforcing a delay between incorrect authentication attempts] for all authentication mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500 milliseconds.
Application Note: The authentication throttling applies to all authentication mechanisms selected in FIA_UAU.5.1. The user authentication attempts in this requirement are attempts to guess the Authentication Factor. The developer can implement the timing of the delays in the requirements using unequal or equal timing of delays. The minimum delay specified in this requirement provides defense against brute forcing.
Evaluation Activities
FIA_TRT_EXT.1
TSS
The evaluator shall verify that the TSS describes the method by which authentication attempts are not able to be automated. The evaluator shall ensure that the TSS describes either how the TSF disables authentication via external interfaces (other than the ordinary user interface) or how authentication attempts are delayed in order to slow automated entry and shall ensure that this delay totals at least 500 milliseconds over 10 attempts for all authentication mechanisms selected in FIA_UAU.5.1.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FIA_UAU_EXT.2 Timing of Authentication

The TSF shall allow [selection: [assignment: list of actions], no actions] on behalf of the user to be performed before the user is authenticated.
The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.
Application Note: The security relevant actions allowed by unauthorized users in locked state must be listed. At a minimum the actions that correspond to the functions available to the user in FMT_SMF_EXT.1 and are allowed by unauthorized users in locked state should be listed. For example, if the user can enable/disable the camera per function of FMT_SMF_EXT.1 and unauthorized users can take a picture when the device is in locked state, this action must be listed.
Evaluation Activities
FIA_UAU_EXT.2
TSS
The evaluator shall verify that the TSS describes the actions allowed by unauthorized users in the locked state.
Guidance
There are no guidance evaluation activities for this component.
Tests
The evaluator shall attempt to perform some actions not listed in the selection while the device is in the locked state and verify that those actions do not succeed.

5.1.10 Class FMT: Security Management

FMT_MOF.1 Management of Security Functions Behavior

The TSF shall restrict the ability to [determine the behaviour of] the functions [listed in Table 6] to [the roles indicated in Table 6].
Application Note: There are two roles defined in this PP: Administrator and user (see FIA_SMR.1). Administrators can perform most management functions on the platform, and only administrators are required to authenticate themselves to the platform.

Users have a limited ability to select responses to certain events as specified in the Management Functions table in FMT_SMF.1.

Evaluation Activities
FMT_MOF.1
TSS
The evaluator shall verify that the TSS describes those management functions that may be performed by the administrator, and those that can be performed by ordinary users. The TSS also describes any functionality that is affected by administrator-configured policy and how. This activity will be performed in conjunction with FMT_SMF.1.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Testing of this SFR is covered in the tests for FMT_SMF.1.

FMT_SMF.1 Specification of Management Functions

The TSF shall be capable of performing the following management functions: [

Table 6: Management Functions

Status Markers:
M - Mandatory
O - Optional/Selectable/Conditional
X - Not permitted

#Management FunctionAdminUserApplication Notes
1 Ability to administer the platform [selection: locally, remotely].
OOptional/Conditional
XNot permitted

Administration is considered “local” if the administrator is physically present at the TOE.

Administration is considered “remote” if communications between the administrator and TOE is over a network.

If "locally" is selected, then function 6 is mandatory.

If "remotely" is selected, then FTP_TRP.1 must be claimed in the ST and functions 5, 6, and 13 are mandatory.

2 Ability to configure and manage the audit functionality and audit data.
OOptional/Conditional
XNot permitted

Management of audit data includes the ability to delete it.

This function must be claimed if FAU_GEN.1 is claimed in the ST.

3 Ability to configure name/address of audit/logging server to which to send audit/logging records.
OOptional/Conditional
XNot permitted

This function must be claimed if FAU_STG.1 is claimed in the ST.

4 Ability to review audit records.
OOptional/Conditional
XNot permitted

This function must be claimed if FAU_SAR.1 is claimed in the ST.

5Ability to initiate a trusted channel or accept an incoming channel for remote administration.
OOptional/Conditional
XNot permitted

This function must be claimed if FTP_TRP.1 is claimed in the ST.

This function is mandatory when function 1 remote administrator is selected.

6 Ability to manage authentication credentials for administrators.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_UIA_EXT.1 is claimed in the ST.

This function is mandatory when function 1 is selected (local or remote).

7 Ability to set parameters for allowable number of authentication failures.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_AFL_EXT.1 is claimed in the ST.

8 Ability to configure password length and complexity.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_PMG_EXT.1 is claimed in the ST.

If password length and complexity are not configurable, then the administrator option should be denied.

9 Ability to configure authentication throttling policy.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_TRT_EXT.1 is claimed in the ST.

If authentication throttling policy is not configurable, then the administrator option should be denied.

10 Ability to manage authentication methods and change default authorization factors.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_UAU.5 is claimed in the ST.

If authentication methods are not configurable, then the administrator option should be denied.

11 Ability to configure certificate revocation checking methods.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_X509_EXT.1 is claimed in the ST (i.e., the TOE claims conformance to .

If TOE does not support configuration of certificate revocation checking methods, then the administrator option should be denied.

12 Ability to configure TSF behavior when certificate revocation status cannot be determined.
OOptional/Conditional
XNot permitted

This function must be claimed if FIA_X509_EXT.2 is claimed in the ST (i.e., the TOE claims conformance to and the claims made in the SFR indicate that the administrator is allowed to configure how the TSF treats a certificate with undetermined revocation status.

13 Ability to manage the IPsec reference identifier.
OOptional/Conditional
XNot permitted

This function must be claimed if FCS_IPSEC_EXT.1 is claimed in the ST.

This function is mandatory when function 1 remote administrator is selected.

14 Ability to configure default action to take on boot integrity failure.
OOptional/Conditional
XNot permitted

This function must be claimed if "in accordance with administrator-configurable policy" is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.

15 Ability to configure default action to take on update failure.
OOptional/Conditional
XNot permitted

This function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 is claimed in the ST and "in accordance with administrator-configurable policy" is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4.

16 Ability to initiate the update process.
OOptional/Conditional
OOptional/Conditional

This function must be claimed if something other than "no mechanism for platform firmware update" is selected in FPT_TUD_EXT.1.1.

17 Ability to determine the action to take on update failure.
OOptional/Conditional
OOptional/Conditional

This function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 are claimed in the ST.

18 Ability to determine the action to take on integrity check failure.
OOptional/Conditional
OOptional/Conditional

This function must be claimed if FPT_ROT_EXT.2 or FPT_ROT_EXT.3 is claimed in the ST.

The administrator option must be selected if "by express determination of an [administrator]" is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.

The user option must be selected if "by express determination of an [user]" is selected in FPT_ROT_EXT.2.2 or FPT_ROT_EXT.3.2.

19 Ability to manage import and export of keys/secrets to and from protected storage.
OOptional/Conditional
XNot permitted

This function must be claimed if FCS_STG_EXT.1 is claimed in the ST.

Application Note: These functions become Mandatory or Selectable as indicated in the Notes.

If function 1 is not selected, then no other administrative functions may be selected.
Evaluation Activities
FMT_SMF.1
TSS
The evaluator shall examine the TSS to ensure that it describes each management function and its associated actions.
Guidance
The evaluator shall examine the AGD to ensure that it describes how the administrator performs each management function that the ST claims the TOE supports.

The evaluator shall verify for each claimed management function that the guidance is sufficiently detailed to allow the function to be performed.
Tests
The evaluator shall test each management function included in the ST to demonstrate that the function can be performed only by the roles indicated in Table 6 and the result of the function is demonstrated.

FMT_SMR.1 Security Roles

The TSF shall maintain the roles [user and [selection: administrator, no other roles]].
The TSF shall be able to associate users with roles.
Application Note: If "administrator" is selected, then the user authentication SFRs in FIA must be claimed.

A user is a human who interacts with the TOE through a user interface. Users do not authenticate themselves to the TOE, though they may be authenticated by tenant software. The user role is considered to exist even if no humans normally interact with a TOE.

An administrator is a privileged user that must be authenticated by the TOE in order to administer the TOE. This role is distinct from OS or VS administrators, who are may are authenticated to tenant software and are considered to be users in the context of the TOE.
Evaluation Activities
FMT_SMR.1
TSS
There are no additional TSS evaluation activities for this component.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Documentation and testing for roles is covered in the Evaluation Activities for FMT_SMF.1

5.1.11 Class FPF: Packet Filtering

FPF_RUL_EXT.1 Packet Filtering Rules

The TSF shall perform packet filtering on network packets processed by the TOE.
The TSF shall allow the definition of packet filtering rules using the following network protocols and protocol fields: [
  • IPv4 (RFC 791)
    • source address
    • destination address
    • protocol
  • IPv6 (RFC 8200)
    • source address
    • destination address
    • next header (protocol)
  • TCP (RFC 793)
    • source port
    • destination port
  • UDP (RFC 768)
    • source port
    • destination port
]
Application Note: This element identifies the protocols and references the protocol definitions that serve to define to what extent the network traffic can be interpreted by the TOE when importing (receiving network traffic or ingress) and exporting (sending–or forming to be sent–network traffic or egress).

While the protocol formatting specified in the RFCs is still used, many RFCs define behaviors which are no longer considered safe to follow. For example, RFC 792 defined the “Redirect” Internet Control Message Protocol (ICMP) type, which is not considered safe to honor when it might come from an adversary; the “source quench” message, which is insecure because its source cannot be validated. It also identifies the various attributes that are applicable when constructing rules to be enforced by this requirement – the applicable interface is a property of the TOE and the rest of the identified attributes are defined in the associated RFCs. Note that the Protocol is the IPv4 field (in IPv6 this field is called the “next header”) that identifies the applicable protocol, such as TCP, UDP, ICMP, etc. Also, ‘Interface’ identified above is the external port where the applicable network traffic was received or alternately will be sent.
The TSF shall allow the following operations to be associated with packet filtering rules: permit and drop with the capability to log the operation.
Application Note: This element defines the operations that can be associated with rules used to match network traffic.
The TSF shall allow the packet filtering rules to be assigned to each distinct network interface.
Application Note: This element identifies where rules can be assigned. Specifically, a conforming TOE must be able to assign filtering rules specific to each of its available and identifiable distinct network interfaces that handle layer 3 and 4 network traffic. Identifiable means the interface is unique and identifiable within the TOE, and does not necessarily require the interface to be visible from the network perspective (e.g., does not need to have an IP address assigned to it). A distinct network interface is one or more physical connections that share a common logical path into the TOE. For example, the TOE might have a small form-factor pluggable (SFP) port supporting SFP modules that expose a number of physical network ports, but since a common driver is used for all external ports they can be treated as a single distinct network interface.

Note that there could be a separate ruleset for each interface or alternately a shared ruleset that somehow associates rules with specific interfaces.
The TSF shall process the applicable packet filtering rules (as determined in accordance with FPF_RUL_EXT.1.4) in the following order: [administrator-defined].
Application Note: This element requires that an administrator is able to define the order in which configured filtering rules are precessed for matches.
The TSF shall drop traffic if a matching rule is not identified.
Application Note: This element requires that the behavior is always to deny network traffic when no rules apply.
Evaluation Activities
FPF_RUL_EXT.1.1
TSS
The evaluator shall verify that the TSS provide a description of the TOE’s initialization and start-up process, which clearly indicates where processing of network packets begins to take place, and provides a discussion that supports the assertion that packets cannot flow during this process.

The evaluator shall verify that the TSS also includes a narrative that identifies the components (e.g., active entity such as a process or task) involved in processing the network packets and describes the safeguards that would prevent packets flowing through the TOE without applying the ruleset in the event of a component failure. This could include the failure of a component, such as a process being terminated, or a failure within a component, such as memory buffers full and cannot process packets.
Guidance
The operational guidance associated with this requirement is assessed in the subsequent test EAs.
Tests
  • Test FPF_RUL_EXT.1.1:1: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would otherwise be denied by the ruleset should be sourced and directed to a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization.

  • Test FPF_RUL_EXT.1.1:2: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would be permitted by the ruleset should be sourced and directed to a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization and is only permitted once initialization is complete.

    • Note: The remaining testing associated with application of the ruleset is addressed in the subsequent test EAs.
FPF_RUL_EXT.1.2
There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4.

FPF_RUL_EXT.1.3
There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4.

FPF_RUL_EXT.1.4
TSS
The evaluator shall verify that the TSS describes a packet filtering policy that can use the following fields for each identified protocol, and that the RFCs identified for each protocol are supported:
  • IPv4 (RFC 791)
    • source address
    • destination address
    • protocol
  • IPv6 (RFC 8200)
    • source address
    • destination address
    • next header (protocol)
  • TCP (RFC 793)
    • source port
    • destination port
  • UDP (RFC 768)
    • source port
    • destination port
The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by the TOE developer (e.g., third party interoperability testing, protocol compliance testing).

The evaluator shall verify that each rule can identify the following actions: permit, discard, and log.

The evaluator shall verify that the TSS identifies all interface types subject to the packet filtering policy and explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used), they can be treated collectively as a distinct network interface.
Guidance
The evaluator shall verify that the operational guidance identifies the following protocols as being supported and the following attributes as being configurable within packet filtering rules for the associated protocols:
  • IPv4 (RFC 791)
    • destination address
    • protocol
  • IPv6 (RFC 8200)
    • source address
    • destination address
    • next header (protocol)
  • TCP (RFC 793)
    • source port
    • destination port
  • UDP (RFC 768)
    • source port
    • destination port
The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions: permit, discard, and log.

The evaluator shall verify that the operational guidance explains how rules are associated with distinct network interfaces.

The guidance may describe the other protocols contained within the ST (e.g., IPsec, IKE, potentially HTTPS, SSH, and TLS) that are processed by the TOE. The evaluator shall ensure that it is made clear what protocols were not considered as part of the TOE evaluation.
Tests
  • Test FPF_RUL_EXT.1.4:1: The evaluator shall use the instructions in the operational guidance to test that packet filter rules can be created that permit, discard, and log packets for each of the following attributes:
    • IPv4 (RFC 791)
      • destination address
      • protocol
    • IPv6 (RFC 8200)
      • source address
      • destination address
      • next header (protocol)
    • TCP (RFC 793)
      • source port
      • destination port
    • UDP (RFC 768)
      • source port
      • destination port

  • Test FPF_RUL_EXT.1.4:2: The evaluator shall repeat Test 1 above for each distinct network interface type supported by the TOE to ensure that packet filtering rules can be defined for all supported types.

    Note that these test activities should be performed in conjunction with those of FPF_RUL_EXT.1.6 where the effectiveness of the rules is tested; here the evaluator is just ensuring the guidance is sufficient and the TOE supports the administrator creating a ruleset based on the above attributes. The test activities for FPF_RUL_EXT.1.6 define the combinations of protocols and attributes required to be tested. If those combinations are configured manually, that will fulfill the objective of these test activities, but if those combinations are configured otherwise (e.g., using automation), these test activities may be necessary in order to ensure the guidance is correct and the full range of configurations can be achieved by a TOE administrator.

FPF_RUL_EXT.1.5
TSS
The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the processing of default rules, determination of whether a packet is part of an established session, and application of administrator defined and ordered ruleset.
Guidance
The evaluator shall verify that the operational guidance describes how the order of packet filtering rules is determined and provides the necessary instructions so that an administrator can configure the order of rule processing.
Tests
  • Test FPF_RUL_EXT.1.5:1: The evaluator shall devise two equal packet filtering rules with alternate operations – permit and discard. The rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is enforced in both cases by generating applicable packets and using packet capture and logs for

  • Test FPF_RUL_EXT.1.5:2: The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator shall test both orders to ensure that the first is enforced regardless of the specificity of the rule.

FPF_RUL_EXT.1.6
TSS
The evaluator shall verify that the TSS describes the process for applying packet filtering rules and also that the behavior (either by default, or as configured by the administrator) is to discard packets when there is no rule match. The evaluator shall verify the TSS describes when the IPv4 and IPv6 protocols supported by the TOE differ from the full list provided in the RFC Values for IPv4 and IPv6 table.
Guidance
The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance provides the appropriate instructions to configure the behavior to discard packets with no matching rules. The evaluator shall verify that the operational guidance describes the range of IPv4 and IPv6 protocols supported by the TOE.
Tests
  • Test FPF_RUL_EXT.1.6:1: The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.

  • Test FPF_RUL_EXT.1.6:2: The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must also be denied but are not required to be logged.

  • Test FPF_RUL_EXT.1.6:3: The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different (than those permitted above) combinations of a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.

  • Test FPF_RUL_EXT.1.6:4: The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.

  • Test FPF_RUL_EXT.1.6:5: The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must also be denied but are not required to be logged.

  • Test FPF_RUL_EXT.1.6:6: The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different (than those permitted above) combinations of a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are dropped (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.

  • Test FPF_RUL_EXT.1.6:7: The evaluator shall configure the TOE to permit and log protocol 6 (TCP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination TCP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged.

  • Test FPF_RUL_EXT.1.6:8: The evaluator shall configure the TOE to discard and log protocol 6 (TCP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination TCP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and logged.

  • Test FPF_RUL_EXT.1.6:9: The evaluator shall configure the TOE to permit and log protocol 17 (UDP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination UDP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Here the evaluator shall ensure that the UDP port 500 (IKE) is included in the set of tests.

  • Test FPF_RUL_EXT.1.6:10: The evaluator shall configure the TOE to discard and log protocol 17 (UDP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination UDP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Again, the evaluator shall ensure that UDP port 500 is included in the set of tests.

The following table identifies the RFC defined values for the protocol fields for IPv4 and IPv6 to be used in configuring and otherwise testing packet filtering rule definition and enforcement:

ProtocolDefined Attributes
IPv4
  • Transport Layer Protocol 1 - Internet Control Message
  • Transport Layer Protocol 2 - Internet Group Management
  • Transport Layer Protocol 3 - Gateway-to-Gateway
  • Transport Layer Protocol 4 - IP in IP (encapsulation)
  • Transport Layer Protocol 5 - Stream
  • Transport Layer Protocol 6 - Transmission Control
  • Transport Layer Protocol 7 - UCL
  • Transport Layer Protocol 8 - Exterior Gateway Protocol
  • Transport Layer Protocol 9 - Any private interior gateway
  • Transport Layer Protocol 10 - BBN RCC Monitoring
  • Transport Layer Protocol 11 - Network Voice Protocol
  • Transport Layer Protocol 12 - PUP
  • Transport Layer Protocol 13 - ARGUS
  • Transport Layer Protocol 14 - EMCON
  • Transport Layer Protocol 15 - Cross Net Debugger
  • Transport Layer Protocol 16 - Chaos
  • Transport Layer Protocol 17 - User Datagram
  • Transport Layer Protocol 18 - Multiplexing
  • Transport Layer Protocol 19 - DCN Measurement Subsystems
  • Transport Layer Protocol 20 - Host Monitoring
  • Transport Layer Protocol 21 - Packet Radio Measurement
  • Transport Layer Protocol 22 - XEROX NS IDP
  • Transport Layer Protocol 23 - Trunk-1
  • Transport Layer Protocol 24 - Trunk-2
  • Transport Layer Protocol 25 - Leaf-1
  • Transport Layer Protocol 26 - Leaf-2
  • Transport Layer Protocol 27 - Reliable Data Protocol
  • Transport Layer Protocol 28 - Internet Reliable Transaction
  • Transport Layer Protocol 29 - ISO Transport Protocol Class 4
  • Transport Layer Protocol 30 - Bulk Data Transfer Protocol
  • Transport Layer Protocol 31 - MFE Network Services Protocol
  • Transport Layer Protocol 32 - MERIT Internodal Protocol
  • Transport Layer Protocol 33 - Sequential Exchange Protocol
  • Transport Layer Protocol 34 - Third Party Connect Protocol
  • Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol
  • Transport Layer Protocol 36 - XTP
  • Transport Layer Protocol 37 - Datagram Delivery Protocol
  • Transport Layer Protocol 38 - IDPR Control Message Transport Protocol
  • Transport Layer Protocol 39 - TP++ Transport Protocol
  • Transport Layer Protocol 40 - IL Transport Protocol
  • Transport Layer Protocol 41 - Simple Internet Protocol
  • Transport Layer Protocol 42 - Source Demand Routing Protocol
  • Transport Layer Protocol 43 - SIP Source Route
  • Transport Layer Protocol 44 - SIP Fragment
  • Transport Layer Protocol 45 - Inter-Domain Routing Protocol
  • Transport Layer Protocol 46 - Reservation Protocol
  • Transport Layer Protocol 47 - General Routing Encapsulation
  • Transport Layer Protocol 48 - Mobile Host Routing Protocol
  • Transport Layer Protocol 49 - BNA
  • Transport Layer Protocol 50 - SIPP Encap Security Payload
  • Transport Layer Protocol 51 - SIPP Authentication Header
  • Transport Layer Protocol 52 - Integrated Net Layer Security TUBA
  • Transport Layer Protocol 53 - IP with Encryption
  • Transport Layer Protocol 54 - NBMA Next Hop Resolution Protocol
  • Transport Layer Protocol 61 - Any host internal protocol
  • Transport Layer Protocol 62 - CFTP
  • Transport Layer Protocol 63 - Any local network
  • Transport Layer Protocol 64 - SATNET and Backroom EXPAK
  • Transport Layer Protocol 65 - Kryptolan
  • Transport Layer Protocol 66 - MIT Remote Virtual Disk Protocol
  • Transport Layer Protocol 67 - Internet Pluribus Packet Core
  • Transport Layer Protocol 68 - Any distributed file system
  • Transport Layer Protocol 69 - SATNET Monitoring
  • Transport Layer Protocol 70 - VISA Protocol
  • Transport Layer Protocol 71 - Internet Packet Core Utility
  • Transport Layer Protocol 72 - Computer Protocol Network Executive
  • Transport Layer Protocol 73 - Computer Protocol Heart Beat
  • Transport Layer Protocol 74 - Wang Span Network
  • Transport Layer Protocol 75 - Packet Video Protocol
  • Transport Layer Protocol 76 - Backroom SATNET Monitoring
  • Transport Layer Protocol 77 - SUN ND PROTOCOL-Temporary
  • Transport Layer Protocol 78 - WIDEBAND Monitoring
  • Transport Layer Protocol 79 - WIDEBAND EXPAK
  • Transport Layer Protocol 80 - ISO Internet Protocol
  • Transport Layer Protocol 81 - VMTP
  • Transport Layer Protocol 82 - SECURE-VMTP
  • Transport Layer Protocol 83 - VINES
  • Transport Layer Protocol 84 - TTP
  • Transport Layer Protocol 85 - NSFNET-IGP
  • Transport Layer Protocol 86 - Dissimilar Gateway Protocol
  • Transport Layer Protocol 87 - TCF
  • Transport Layer Protocol 88 - IGRP
  • Transport Layer Protocol 89 - OSPFIGP
  • Transport Layer Protocol 90 - Sprite RPC Protocol
  • Transport Layer Protocol 91 - Locus Address Resolution Protocol
  • Transport Layer Protocol 92 - Multicast Transport Protocol
  • Transport Layer Protocol 93 - AX.25 Frames
  • Transport Layer Protocol 94 - IP-within-IP Encapsulation Protocol
  • Transport Layer Protocol 95 - Mobile Internetworking Control Protocol
  • Transport Layer Protocol 96 - Semaphore Communications Security Protocol
  • Transport Layer Protocol 97 - Ethernet-within-IP Encapsulation
  • Transport Layer Protocol 98 - Encapsulation Header
  • Transport Layer Protocol 99 - Any private encryption scheme
  • Transport Layer Protocol 100 - GMTP
IPv6
  • Transport Layer Protocol 1 - Internet Control Message
  • Transport Layer Protocol 2 - Internet Group Management
  • Transport Layer Protocol 3 - Gateway-to-Gateway
  • Transport Layer Protocol 4 - IPv4 encapsulation
  • Transport Layer Protocol 5 - Stream
  • Transport Layer Protocol 6 - Transmission Control
  • Transport Layer Protocol 7 - CBT
  • Transport Layer Protocol 8 - Exterior Gateway Protocol
  • Transport Layer Protocol 9 - Any private interior gateway
  • Transport Layer Protocol 10 - BBN RCC Monitoring
  • Transport Layer Protocol 11 - Network Voice Protocol
  • Transport Layer Protocol 12 - PUP
  • Transport Layer Protocol 13 - ARGUS
  • Transport Layer Protocol 14 - EMCON
  • Transport Layer Protocol 15 - Cross Net Debugger
  • Transport Layer Protocol 16 - Chaos
  • Transport Layer Protocol 17 - User Datagram
  • Transport Layer Protocol 18 - Multiplexing
  • Transport Layer Protocol 19 - DCN Measurement Subsystems
  • Transport Layer Protocol 20 - Host Monitoring
  • Transport Layer Protocol 21 - Packet Radio Measurement
  • Transport Layer Protocol 22 - XEROX NS IDP
  • Transport Layer Protocol 23 - Trunk-1
  • Transport Layer Protocol 24 - Trunk-2
  • Transport Layer Protocol 25 - Leaf-1
  • Transport Layer Protocol 26 - Leaf-2
  • Transport Layer Protocol 27 - Reliable Data Protocol
  • Transport Layer Protocol 28 - Internet Reliable Transaction
  • Transport Layer Protocol 29 - Transport Protocol Class 4
  • Transport Layer Protocol 30 - Bulk Data Transfer Protocol
  • Transport Layer Protocol 31 - MFE Network Services Protocol
  • Transport Layer Protocol 32 - MERIT Internodal Protocol
  • Transport Layer Protocol 33 - Datagram Congestion Control Protocol
  • Transport Layer Protocol 34 - Third Party Connect Protocol
  • Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol
  • Transport Layer Protocol 36 - XTP
  • Transport Layer Protocol 37 - Datagram Delivery Protocol
  • Transport Layer Protocol 38 - IDPR Control Message Transport Protocol
  • Transport Layer Protocol 39 - TP++ Transport Protocol
  • Transport Layer Protocol 40 - IL Transport Protocol
  • Transport Layer Protocol 41 - IPv6 encapsulation
  • Transport Layer Protocol 42 - Source Demand Routing Protocol
  • Transport Layer Protocol 43 - Intentionally blank
  • Transport Layer Protocol 44 - Intentionally blank
  • Transport Layer Protocol 45 - Inter-Domain Routing Protocol
  • Transport Layer Protocol 46 - Reservation Protocol
  • Transport Layer Protocol 47 - General Routing Encapsulation
  • Transport Layer Protocol 48 - Dynamic Source Routing Protocol
  • Transport Layer Protocol 49 - BNA
  • Transport Layer Protocol 50 - Intentionally Blank
  • Transport Layer Protocol 51 - Intentionally Blank
  • Transport Layer Protocol 52 - Integrated Net Layer Security
  • Transport Layer Protocol 53 - IP with Encryption
  • Transport Layer Protocol 54 - NBMA Address Resolution Protocol
  • Transport Layer Protocol 55 - Mobility
  • Transport Layer Protocol 56 - Transport Layer Security Protocol using Kryptonet key management
  • Transport Layer Protocol 57 - SKIP
  • Transport Layer Protocol 58 - ICMP for IPv6
  • Transport Layer Protocol 59 - No Next Header for IPv6
  • Transport Layer Protocol 60 - Intentionally Blank
  • Transport Layer Protocol 61 - Any host internal protocol
  • Transport Layer Protocol 62 - CFTP
  • Transport Layer Protocol 63 - Any local network
  • Transport Layer Protocol 64 - SATNET and Backroom EXPAK
  • Transport Layer Protocol 65 - Kryptolan
  • Transport Layer Protocol 66 - MIT Remote Virtual Disk Protocol
  • Transport Layer Protocol 67 - Internet Pluribus Packet Core
  • Transport Layer Protocol 68 - Any distributed file system
  • Transport Layer Protocol 69 - SATNET Monitoring
  • Transport Layer Protocol 70 - VISA Protocol
  • Transport Layer Protocol 71 - Internet Packet Core Utility
  • Transport Layer Protocol 72 - Computer Protocol Network Executive
  • Transport Layer Protocol 73 - Computer Protocol Heart Beat
  • Transport Layer Protocol 74 - Wang Span Network
  • Transport Layer Protocol 75 - Packet Video Protocol
  • Transport Layer Protocol 76 - Backroom SATNET Monitoring
  • Transport Layer Protocol 77 - SUN ND PROTOCOL-Temporary
  • Transport Layer Protocol 78 - WIDEBAND Monitoring
  • Transport Layer Protocol 79 - WIDEBAND EXPAK
  • Transport Layer Protocol 80 - ISO Internet Protocol
  • Transport Layer Protocol 81 - VMTP
  • Transport Layer Protocol 82 - SECURE-VMTP
  • Transport Layer Protocol 83 - VINES
  • Transport Layer Protocol 84 - TTP
  • Transport Layer Protocol 85 - Internet Protocol Traffic Manager
  • Transport Layer Protocol 86 - NSFNET-IGP
  • Transport Layer Protocol 87 - Dissimilar Gateway Protocol
  • Transport Layer Protocol 88 - TCF
  • Transport Layer Protocol 89 - EIGRP
  • Transport Layer Protocol 90 - OSPFIGP
  • Transport Layer Protocol 91 - Sprite RPC Protocol
  • Transport Layer Protocol 92 - Locus Address Resolution Protocol
  • Transport Layer Protocol 93 - Multicast Transport Protocol
  • Transport Layer Protocol 94 - AX.25 Frames
  • Transport Layer Protocol 95 - IP-within-IP Encapsulation Protocol
  • Transport Layer Protocol 96 - Mobile Internetworking Control Pro.
  • Transport Layer Protocol 97 - Semaphore Communications Sec. Pro.
  • Transport Layer Protocol 98 - Ethernet-within-IP Encapsulation
  • Transport Layer Protocol 99 - Encapsulation Header
  • Transport Layer Protocol 100 - GMTP
  • Transport Layer Protocol 101 - Ipsilon Flow Management Protocol
  • Transport Layer Protocol 102 - PNNI over IP
  • Transport Layer Protocol 103 - Protocol Independent Multicast
  • Transport Layer Protocol 104 - ARIS
  • Transport Layer Protocol 105 - SCPS Transport Layer Protocol
  • Transport Layer Protocol 106 - QNX
  • Transport Layer Protocol 107 - Active Networks
  • Transport Layer Protocol 108 - Payload Compression Protocol
  • Transport Layer Protocol 109 - Sitara Networks Protocol
  • Transport Layer Protocol 110 - Compaq Peer Protocol
  • Transport Layer Protocol 111 - IPX in IP
  • Transport Layer Protocol 112 - Virtual Router Redundancy Protocol
  • Transport Layer Protocol 113 - PGM Reliable Transport Protocol
  • Transport Layer Protocol 114 - Any 0-hop protocol
  • Transport Layer Protocol 115 - Layer Two Tunneling Protocol
  • Transport Layer Protocol 116 - D-II Data Exchange (DDX)
  • Transport Layer Protocol 117 - Interactive Agent Transfer Protocol
  • Transport Layer Protocol 118 - Schedule Transfer Protocol
  • Transport Layer Protocol 119 - SpectraLink Radio Protocol
  • Transport Layer Protocol 120 - UTI
  • Transport Layer Protocol 121 - Simple Message Protocol
  • Transport Layer Protocol 122 - SM
  • Transport Layer Protocol 123 - Performance Transparency Protocol
  • Transport Layer Protocol 124 - ISIS over IPv4
  • Transport Layer Protocol 125 - FIRE
  • Transport Layer Protocol 126 - Combat Radio Transport Protocol
  • Transport Layer Protocol 127 - Combat Radio User Datagram
  • Transport Layer Protocol 128 - SSCOPMCE
  • Transport Layer Protocol 129 - IPLT
  • Transport Layer Protocol 130 - Secure Packet Shield
  • Transport Layer Protocol 131 - Private IP Encapsulation within IP
  • Transport Layer Protocol 132 - Stream Control Transmission Protocol
  • Transport Layer Protocol 133 - Fibre Channel
  • Transport Layer Protocol 134 - RSVP-E2E-IGNORE
  • Transport Layer Protocol 135 - Mobility Header
  • Transport Layer Protocol 136 - UDPLite
  • Transport Layer Protocol 137 - MPLS-in-IP
  • Transport Layer Protocol 138 - MANET Protocols
  • Transport Layer Protocol 139 - Host Identity Protocol
  • Transport Layer Protocol 140 - Shim6 Protocol
  • Transport Layer Protocol 141 - Wrapped Encapsulating Security Payload
  • Transport Layer Protocol 142 - Robust Header Compression

5.1.12 Class FPT: Protection of the TSF

FPT_APW_EXT.1 Protection of Administrator Password

The TSF shall store administrative passwords in non-plaintext form.
The TSF shall prevent the reading of plaintext administrative passwords.
Application Note: This requirement is applicable only if the TOE provides its own password-based authentication mechanism. Thus it is included in the ST only if "password-based authentication mechanism" is selected in FIA_UAU_EXT.1.1.

The intent of the requirement is that raw password authentication data are not stored in the clear, and that no user or administrator is able to read the plaintext password through normal interfaces. An all-powerful administrator could directly read memory to capture a password, but is trusted not to do so.

In this version of the PP there are no requirements on the method used to store the passwords in non-plaintext form, but cryptographic methods based on the requirements in FCS_COP are preferred. In future versions of this PP, FCS_COP-based cryptographic methods that conform to the Level 2 Credential Storage requirements from NIST SP 800-63 will be required.
Evaluation Activities
FPT_APW_EXT.1
TSS
The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this requirement, and the method used to obscure the plaintext password data when stored. The evaluator shall ensure that the TSS also details that passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following test:
  • Test FPT_APW_EXT.1:1: The evaluator shall use forensic tools to search storage media to verify that passwords cannot be found in an unobscured (e.g., plaintext) form.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FPT_BBD_EXT.1 Application Processor Mediation

The TSF shall prevent code executing on any baseband processor (BP) from accessing application processor (AP) resources except when mediated by the AP.
Application Note: These resources include:
  • Volatile and non-volatile memory
  • Control of and data from integrated and non-integrated peripherals (e.g., USB controllers, touch screen controllers, LCD controller, codecs)
  • Control of and data from integrated and non-integrated I/O sensors (e.g. camera, light, microphone, GPS, accelerometers, geomagnetic field sensors)
Mobile devices are becoming increasingly complex having an application processor that runs an operating system and user applications and separate baseband processors that handle cellular and other wireless network connectivity.

  • The application processor within most modern Mobile Devices is a system on a chip (SoC) that integrates, for example, CPU/GPU cores and memory interface electronics into a single, power-efficient package.
  • Baseband processors are becoming increasingly complex themselves delivering voice encoding alongside multiple independent radios (LTE, Wi-Fi, Bluetooth, FM, GPS) in a single package containing multiple CPUs and DSPs.
Thus, the baseband processors in these requirements include such integrated SoCs and include any radio processors (integrated or not) on the Mobile Device.

All other requirements mostly, except where noted, apply to firmware/software on the application processor, but future requirements (notably, all Integrity, Access Control, and Anti-Exploitation requirements) will apply to application processors and baseband processors.
Evaluation Activities
FPT_BBD_EXT.1
TSS
The evaluator shall ensure that the TSS section of the ST describes at a high level how the processors on the Mobile Device interact, including which bus protocols they use to communicate, any other devices operating on that bus (peripherals and sensors), and identification of any shared resources. The evaluator shall verify that the design described in the TSS does not permit any BPs from accessing any of the peripherals and sensors or from accessing main memory (volatile and non-volatile) used by the AP. In particular, the evaluator shall ensure that the design prevents modification of executable memory of the AP by the BP.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.

FPT_INI.1 TSF Initialization

The TOE shall provide an initialization function which is self-protected for integrity and authenticity.
The TOE initialization function shall ensure that certain properties hold on certain elements immediately before establishing the TSF in a secure initial state, as specified in Table 2: Properties and assignments
The TOE initialization function shall detect and respond to errors and failures during initialization such that the TOE [selection:
  • is halted
  • successfully completes initialization with [selection: reduced functionality, signaling error state, [assignment: list of actions]]
].
The TOE initialization function shall only interact with the TSF in [assignment: defined methods] during initialization.
Application Note: The intent of this requirement is to ensure that the TOE reaches a secure initial state only through an initialization function whose integrity and authenticity are protected, and that initialization does not establish the TSF unless the required preconditions for secure startup have been satisfied. This SFR relates to the TOE initialization process and its resulting security posture. The ST author describes how the TOE transitions into an operational state, including any environmental assumptions.
Evaluation Activities
FPT_INI.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the TOE initialization function and where it occurs in the TOE startup or bring-up sequence.
  • Describes how the TOE protects the initialization function for integrity and authenticity.
  • Identifies the mechanism or mechanisms by which the TOE detects unauthorized modification or unauthorized substitution of the initialization function.
  • Identifies the elements and properties that apply to the TOE under FPT_INI.1.2.
  • Describes how the TOE determines that each applicable property holds immediately before establishing the TSF in a secure initial state.
  • Describes what constitutes establishment of the TSF in a secure initial state for the TOE.
  • Describes the error and failure conditions that may arise during initialization and the TOE response for each, consistent with the selection made in FPT_INI.1.3.
  • If the TOE claims successful completion of initialization with reduced functionality, signaling of an error state, or other actions, describes those behaviors in sufficient detail to determine that they preserve security.
  • Identifies the defined methods by which the initialization function interacts with the TSF during initialization, as required by FPT_INI.1.4.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests. Where direct manipulation of low-level initialization conditions is not practical on production hardware, the evaluator may use developer-provided test mechanisms or representative test configurations sufficient to exercise the claimed behavior.
  • Test FPT_INI.1:1: Successful initialization to secure initial state: The evaluator shall initialize or power on the TOE in its claimed configuration and verify that the TOE completes initialization and establishes the TSF in the secure initial state described in the TSS. The evaluator shall verify that the TOE behavior is consistent with the applicable Table 2 properties claimed for the TOE.

  • Test FPT_INI.1:2: Initialization function integrity/authenticity protection: The evaluator shall attempt, using an appropriate developer-supported test method or representative test setup, to cause execution of a modified, substituted, or otherwise unauthentic initialization function. The evaluator shall verify that the TOE detects the condition and responds in accordance with FPT_INI.1.3 rather than establishing the TSF in a secure initial state.

  • Test FPT_INI.1:3: Failure of a required initialization property: The evaluator shall cause one applicable property identified under FPT_INI.1.2 not to hold immediately before establishment of the secure initial state. The evaluator shall verify that the TOE detects the condition and responds in accordance with the selected failure behavior in FPT_INI.1.3.

  • Test FPT_INI.1:4: Verification of failure response behavior: The evaluator shall induce one or more initialization errors or failures described in the TSS and verify that the TOE either:
    • halts, or
    • completes initialization only with the claimed reduced functionality, signaling of an error state, or other claimed actions.
    The evaluator shall verify that the observed behavior is consistent with the TSS and does not result in operation inconsistent with the claimed secure state.

  • Test FPT_INI.1:5: Restriction of TSF interaction during initialization: The evaluator shall examine available interfaces and observable TOE behavior during initialization and verify that the initialization function interacts with the TSF only through the defined methods identified in the TSS. The evaluator shall verify that unrestricted or normal operational TSF services are not made available before the secure initial state is established, except as explicitly claimed in the ST for reduced-functionality or error-state handling.

FPT_JTA_EXT.1 JTAG Disablement

The TSF shall [selection: disable access through hardware, control access by a signing key] to JTAG.
Application Note: This requirement means that access to JTAG must be disabled either through hardware or restricted through the use of a signing key.
Evaluation Activities
FPT_JTA_EXT.1
TSS
If disable access through hardware is selected: The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to include the order of the ports (i.e. Data In, Data Out, Clock, etc.).

If control access by a signing key is selected: The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed, i.e. what has the access to the signing key.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
  • Test FPT_JTA_EXT.1:1: Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with chip level access.

    If disable access through hardware is selected: The evaluator shall connect a packet analyzer to the JTAG ports. The evaluator shall query the JTAG port for its device ID and confirm that the device ID cannot be retrieved.

FPT_KST_EXT.1 Key Storage

The TSF shall not store any plaintext key material in readable non-volatile memory.
Application Note: The intention of this requirement is that the TOE will not write plaintext keying material to persistent storage. 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, etc. These values must be stored encrypted.

This requirement also applies to any value derived from passwords. Thus, the TOE cannot store plaintext password hashes for comparison purposes before protected data is decrypted, and the TOE should use key derivation and decryption to verify the Password Authentication Factor.

If "hybrid" is selected in FIA_UAU.5.1, keying material also refers to the PIN/password used as part of the hybrid authentication.
Evaluation Activities
FPT_KST_EXT.1
TSS
The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement.

In performing their review, the evaluator shall determine that the TSS contains a description of the activities that happen on power-up and password authentication relating to the decryption of DEKs, stored keys, and data.

The evaluator shall ensure that the description also covers how the cryptographic functions in the FCS requirements are being used to perform the encryption functions, including how the KEKs, DEKs, and stored keys are unwrapped, saved, and used by the TOE so as to prevent plaintext from being written to non-volatile storage. The evaluator shall ensure that the TSS describes, for each power-down scenario how the TOE ensures that all keys in non-volatile storage are not stored in plaintext.

The evaluator shall ensure that the TSS describes how other functions available in the system (e.g., regeneration of the keys) ensure that no unencrypted key material is present in persistent storage.

The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to the persistent storage.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.

FPT_KST_EXT.2 No Key Transmission

The TSF shall not transmit any plaintext key material outside the security boundary of the TOE.
Application Note: The intention of this requirement is to prevent the logging of plaintext key information to a service that transmits the information off-device. For the purposes of this requirement, key material refers to keys, passwords, and other material that is used to derive keys.
Evaluation Activities
FPT_KST_EXT.2
TSS
The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. The evaluator shall ensure that the TSS describes the TOE security boundary. The cryptographic module may very well be a particular kernel module, the Operating System, the Application Processor, or up to the entire Mobile Device.

In performing their review, the evaluator shall determine that the TSS contains a description of the activities that happen on power-up and password authentication relating to the decryption of DEKs, stored keys, and data.

The evaluator shall ensure that the TSS describes how other functions available in the system (e.g., regeneration of the keys) ensure that no unencrypted key material is transmitted outside the security boundary of the TOE.

The evaluator shall review the TSS to determine that it makes a case that key material is not transmitted outside the security boundary of the TOE.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.

FPT_KST_EXT.3 No Plaintext Key Export

The TSF shall ensure it is not possible for the TOE users to export plaintext keys.
Application Note: Plaintext keys include DEKs, KEKs, and all keys stored in the secure key storage (FCS_STG_EXT.1). The intent of this requirement is to prevent the plaintext keys from being exported during a backup authorized by the TOE user or administrator.
Evaluation Activities
FPT_KST_EXT.3
TSS
The ST author shall provide a statement of their policy for handling and protecting keys. The evaluator shall check to ensure the TSS describes a policy in line with not exporting either plaintext DEKs, KEKs, or keys stored in the secure key storage.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.

FPT_NOT_EXT.1 Self-Test Notification

The TSF shall transition to non-operational mode and [selection: log failures in the audit record, notify the administrator, [assignment: other actions], no other actions] when the following types of failures occur:
  • Failures of the self-tests
  • TSF software integrity verification failures
  • [selection: no other failures, [assignment: other failures]]
Evaluation Activities
FPT_NOT_EXT.1
TSS
The evaluator shall verify that the TSS describes critical failures that may occur and the actions to be taken upon these critical failures.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.
  • Test FPT_NOT_EXT.1:1: The evaluator shall use a tool provided by the developer to modify files and processes in the system that correspond to critical failures specified in the second list. The evaluator shall verify that creating these critical failures causes the device to take the remediation actions specified in the first list.

FPT_PHP.1 Passive detection of physical attack

The TSF shall provide unambiguous detection of physical tampering that can compromise the TSF.
The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred.
Application Note: The audit event "Detection of intrusion" should be claimed if the TOE is capable of generating an audit event in circumstances where an intrusion is detected.
Evaluation Activities
FPT_PHP.1
TSS
The evaluator shall examine the TSS to ensure it describes the methods used by the TOE to detect physical tampering and how tampering is indicated when detected.
Guidance
The evaluator shall ensure that the AGD describes how the TOE indicates to users and administrators that it has detected tampering.
Tests
The evaluator shall verify that attempts to open the TOE enclosure result in indications consistent with the operational guidance. Such indications could include damaged tamper seals, logged events, or other physical or electronic manifestations.

FPT_PPF_EXT.1 Protection of Platform Firmware and Critical Data

The TSF shall allow modification of platform firmware and critical data only through the update mechanisms described in FPT_TUD_EXT.1.
Application Note: Platform firmware must be modifiable only through one of the secure update mechanisms specified in FPT_TUD_EXT.1. If the update mechanism itself is implemented in platform firmware, then naturally, it must itself also be modifiable only through the secure update mechanism. Configuration data used by platform firmware that is stored in nonvolatile memory is not included in these protections. Executable portions of the TSF and data critical for ensuring the integrity of the TSF are included in these protections. Specifically, this includes the key store and the signature verification algorithm used by the update mechanisms.
Evaluation Activities
FPT_PPF_EXT.1
TSS
The evaluator shall examine the TSS to ensure that it explains how the various areas of platform firmware and critical data are protected from modification outside of the platform firmware update mechanism described in FPT_TUD_EXT.1. If the TOE implements an authenticated update mechanism as specified in FPT_TUD_EXT.2, then the evaluator shall ensure that the TSS describes specifically how the signature verification code and key store is protected from update outside of the secure platform firmware update mechanism.
Guidance
The evaluator shall check the AGD to ensure that there are instructions for how to securely modify the platform firmware and critical data using a mechanism specified in FPT_TUD_EXT.1.
Tests
The evaluator shall perform the following test:

The evaluator shall attempt to overwrite or modify the platform firmware without invoking one of the update mechanisms specified in FPT_TUD_EXT.1. The test succeeds if the attempts to overwrite platform firmware fail. The evaluator shall attempt at least three such tests--one that attempts to overwrite the first platform firmware that executes after boot, one that targets the secure update mechanism (if implemented), and one that targets firmware that has been integrity-checked since the last boot.

FPT_RBP_EXT.1 Rollback Protection

The TSF shall verify that the new firmware package is not downgrading to a lower security version number by [assignment: method of verifying the security version number is the same as or higher than the currently installed version].
The TSF shall generate and return an error code if the attempted firmware update package is detected to be an invalid version.
Application Note: This requirement prevents an unauthorized rollback of the firmware to an earlier authentic version. This mitigates against unknowing installation of an earlier authentic firmware version that may have a security weakness. It is expected that vendors will increase security version numbers with each new update package.

For FPT_RBP_EXT.1.1 the purpose is to verify that the new package has a security version number equal to or larger than the security version number of currently installed firmware package.

The administrator guidance would include instructions for the administrator to configure the rollback prevention mechanism, if appropriate.
Evaluation Activities
FPT_RBP_EXT.1
TSS
The evaluator shall examine the TSS to ensure that it describes at a high level the process for verifying that security version checking is performed before an upgrade is installed. The evaluator shall verify that a high level description of the types of error codes are provided and when an error would be triggered.
Guidance
The evaluator shall ensure that a description is provided on how the user should interpret the error codes.
Tests
The evaluator shall perform the following test:
  • Test FPT_RBP_EXT.1:1: The evaluator shall try installing a lower security version number upgrade (either by just modifying the version number or by using an upgrade provided by the vendor) and will verify that the lower version cannot be installed and an error is presented to the user.

FPT_RCV.2 Automated Recovery

When automated recovery from [assignment: list of failures or service discontinuities] is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.
Application Note: The intent of this requirement is to ensure that when the TOE cannot automatically recover from specified failures or service discontinuities, it does not resume or continue normal operation in an uncontrolled state. Instead, the TOE should enter a maintenance mode that preserves the ability to return the TOE to a secure state.

The ST author should identify the failures or service discontinuities from which automated recovery is not possible. These should be limited to conditions relevant to the claimed TOE design and operational use. Examples may include persistent boot or integrity-check failures, unrecoverable cryptographic subsystem errors, repeated failure of required internal health checks, corruption of critical TSF data, failure of required protected communications between TOE components, exhaustion or corruption of required initialization state, or other service discontinuities that prevent automatic restoration of the TOE to a secure operational condition. “Maintenance mode” in this requirement is a constrained TOE state in which normal security-relevant operational services are not provided, but the TOE preserves the ability to perform the actions necessary to restore a secure state.
Evaluation Activities
FPT_RCV.2
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the failures or service discontinuities from which automated recovery is not possible.
  • Describes how the TOE detects each such failure or discontinuity.
  • Describes the conditions under which the TOE enters maintenance mode.
  • Describes the maintenance mode provided by the TOE, including the functionality that remains available and the functionality that is not available while in that mode.
  • Describes how maintenance mode preserves the ability to return the TOE to a secure state.
  • Describes the process or mechanisms by which the TOE exits maintenance mode and returns to a secure state.
  • Describes any differences in TOE behavior for different claimed failure or discontinuity conditions.
  • Describes how the TOE prevents normal operational use or insecure service continuation while in maintenance mode.
The evaluator shall determine that the TSS description is sufficient to show that maintenance mode is a controlled state intended for secure restoration and not simply degraded normal operation.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes the failures or service discontinuities that may cause the TOE to enter maintenance mode.
  • Describes how an administrator can determine that the TOE has entered maintenance mode.
  • Describes the functionality available to the administrator while the TOE is in maintenance mode.
  • Describes the steps required to restore the TOE to a secure state and return it to normal operation.
  • Describes any restrictions, cautions, or prerequisites applicable while the TOE is in maintenance mode.
  • Describes any audit records, status indications, alerts, or logs associated with entry into maintenance mode, recovery actions, and return to service, if such records or indications are provided by the TOE.
Tests
The evaluator shall perform the following tests. Where inducing a specific low-level failure is not practical on production hardware or software, the evaluator may use developer-supported test mechanisms or representative test configurations sufficient to demonstrate the claimed behavior.
  • Test FPT_RCV.2:1: Entry into maintenance mode when automated recovery is not possible: For one or more claimed failures or service discontinuities from which automated recovery is not possible, the evaluator shall induce the condition and verify that the TOE enters maintenance mode.

  • Test FPT_RCV.2:2: Maintenance mode restricts normal operation: After the TOE enters maintenance mode, the evaluator shall verify that normal operational functionality that would be inconsistent with the TOE being in a secure state is not available, and that the TOE behavior is consistent with the TSS and guidance description of maintenance mode.

  • Test FPT_RCV.2:3: Maintenance mode provides a path to secure restoration: While the TOE is in maintenance mode, the evaluator shall verify that the TOE provides the claimed ability to return to a secure state, such as secure recovery, trusted restoration, reinitialization, administrator-guided remediation, or other claimed mechanism.

  • Test FPT_RCV.2:4: Return from maintenance mode to secure state: The evaluator shall perform the documented recovery steps and verify that the TOE can return from maintenance mode to the claimed secure operational state in accordance with the TSS and guidance.

FPT_ROT_EXT.1 Platform Integrity Root

The integrity of platform firmware shall be rooted in [selection:
  • code or data written to immutable memory or storage
  • credentials held in immutable storage on-platform or protected storage off-platform
  • a separate management controller that is itself rooted in a mechanism that meets this requirement
  • integrity measurements held securely in an on-platform dedicated security component
  • integrity measurements held securely by an off-platform entity
].
Application Note: Roots of Trust are components that constitute a set of unconditionally trusted functions. The above are acceptable roots of trust for platform firmware integrity.

The ST author must select the root of trust used to ensure the integrity of the first platform firmware that executes. The integrity of subsequently executed platform firmware must be traceable back to this root or to some other root as specified in FPT_ROT_EXT.2. This SFR should be iterated for additional TOE roots (for example, a management controller or firmware executed from an add-in card).

An "on-platform dedicated security component" could be, for example, a TPM or other secure element that provides security services to the platform such as measurement or secure storage.

Selection of "a separate management controller... " implies the existence of an administrator role.
Evaluation Activities
FPT_ROT_EXT.1
TSS
The evaluator shall verify that the TSS describes the Root of Trust on which initial integrity of platform firmware is anchored, consistent with the selection above. The description shall include means by which the Root of Trust is protected from modification.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FPT_ROT_EXT.2 Platform Integrity Extension

The integrity of all mutable platform firmware outside of the platform integrity root specified in FPT_ROT_EXT.1 shall be verified prior to [selection: execution, use, or access to TSF data] through [selection:
  • computation and verification of a hash by trusted code/data
  • verification of a digital signature by trusted code/data
  • measurement and verification by trusted code/data
  • measurement by an on-platform dedicated security component and verification by an off-platform entity
].
Application Note: This requirement specifies the means to extend the initial integrity of platform firmware established by FPT_ROT_EXT.1.1 to subsequently executed platform firmware and data located in mutable storage. (Integrity of code and data written to immutable storage is assured).

Otherwise, integrity must be extended through cryptographic means: either through hashes or digital signatures computed and verified by firmware that is trusted because it has previously had its integrity verified or is itself a Root of Trust. Verification can be performed by TOE components such as management controllers or non-TOE trusted entities such as remote verifiers.

If "computation and verification of a hash by trusted code/data" is selected, then FCS_COP.1/Hash must be claimed.

If "verification of a digital signature by trusted code/data" is selected, then FCS_COP.1/SigVer must be claimed.
The TOE shall take the following actions if an integrity check specified in FPT_ROT_EXT.2.1 fails: [selection:
  • Stop all execution, or
  • Notify an [selection: administrator, user] by [selection: generating an audit event, [assignment: other notification methods]], and [selection:
    • Stop all execution
    • Shut down, or
    • Initiate a recovery process as specified in FPT_RVR_EXT.1
    • Skip all instructions that failed the integrity check and continue execution
    ][selection:
    • automatically
    • in accordance with administrator-configurable policy
    • by express determination of an [selection: administrator, user]
    ]
].
Application Note: Notification of an administrator can take many forms. For server-class platforms, such notification could take the form of administrator alerts or audit events. For platforms without management controllers, notification could be achieved, for example, by blinking lights, beep codes, screen indications, or local logging.

If "administrator" is selected anywhere in FPT_ROT_EXT.2.2, or if "in accordance with administrator-configurable policy" is selected, then all administrator authentication requirements must be included in the ST (FIA_UIA_EXT.1, FIA_UAU.5, FIA_PMG_EXT.1, FIA_AFL_EXT.1, FIA_UAU.7).

If "generating an audit event" is selected, then FAU_GEN.1, FAU_SAR.1, FAU_STG.1, FAU_STG.2, and FAU_STG.5 must be claimed in the ST. This selection should be made only if the TOE is capable of generating an audit event, e.g. if the TOE is a server that includes a management controller.

If "Initiate a recovery process as specified in FPT_RVR_EXT.1" is selected, then FPT_RVR_EXT.1 must be included in the ST.

If "in accordance with administrator-configurable policy" is selected, then management function 14 must be claimed in FMT_SMF.1.
Evaluation Activities
FPT_ROT_EXT.2
TSS
The evaluator shall verify that the TSS describes the means by which initial integrity of platform firmware is extended to other platform components, and that the means are consistent with the selections made in FPT_ROT_EXT.2. The TSS shall also describe how the TOE responds to failure of verification consistent with the selections in FPT_ROT_EXT.2.2.
Guidance
The evaluator shall examine the AGD to ensure that it describes the actions taken and notification methods used in case of failure to establish the integrity of the platform firmware root. If the actions are configurable, the AGD shall explain how they are configured.
Tests
The evaluator shall modify the platform firmware in a way that should cause a failure of the integrity check. The test passes if the mechanism specified in FPT_ROT_EXT.2.2 is triggered on the first subsequent boot of the platform.

Depending on the protections implemented, the evaluator may need a specially crafted update module from the vendor to perform this test. But note that this is not necessarily the same as a test of the update mechanism. The update mechanism can be tested either at boot time or at the time of the update. This verification check must be done during boot.

If modification of platform firmware in situ or using the update mechanism is deemed to be not feasible within the time and cost constraints of the evaluation, then the evaluator shall make such an argument in the AAR, and with concurrence of the CC scheme, this test can be replaced by evidence of vendor testing.

FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)

The TSF shall prevent reading of all pre-shared, symmetric keys, and private keys.
Application Note: The intent of this requirement is for the device to protect keys, key material, and authentication credentials from unauthorised disclosure. This data should only be accessed for the purposes of their assigned security functionality, and there is no need for them to be displayed/accessed at any other time. This requirement does not prevent the device from providing indication that these exist, are in use, or are still valid. It does, however, restrict the reading of the values outright.
Evaluation Activities
FPT_SKP_EXT.1
TSS
Regardless of whether this requirement is met by the TOE or the operational environment, the evaluator shall examine the TSS to determine that it details each persistent private and secret key needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS details how any secret or private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. If these values are not stored in plaintext, the TSS shall describe how they are protected and obscured.
Guidance
The evaluator shall examine the AGD guidance to ensure it contains any necessary instructions for configuring the TOE or operational environment to support this requirement.
Tests
The evaluator shall perform the following test:
  • Test FPT_SKP_EXT.1:1: The evaluator shall assume each of the non-administrator roles supported by the TOE and shall attempt to use the available TOE interface to read the keys specified by the TOE. The evaluator shall verify that these attempts fail.

Equivalency

Testing of the TOE may be performed on a subset of the platforms listed in the TOE’s ST. Justification must be provided for those platforms that were excluded from testing.

FPT_STM.1 Reliable Time Stamps

The TSF shall be able to provide reliable time stamps.
Application Note: It is acceptable for the TSF to provide timestamp data either through an internal clock or a counter. It is also permissible for the TSF to obtain time data from a clock contained within the same physical enclosure as the TOE.

Evaluation Activities
FPT_STM.1
TSS
The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related functions.
Guidance
The evaluator shall examine the AGD to ensure it instructs the administrator on any mechanisms for configuring the time source.
Tests
The evaluator shall perform the following tests:

[conditional] If the TSF provides a mechanism to manually set the time, the evaluator shall use the guidance documentation to set the time. The evaluator shall then use an available interface to observe that the time is reported correctly.

FPT_TST.1 TSF Self-Test

The TSF shall run a suite of the following self-tests [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the conditions [assignment: conditions under which self-test should occur]] to demonstrate the correct operation of [TSF DRBG specified in FCS_RBG.1].
The TSF shall provide authorized users with the capability to verify the integrity of [[DRBG seed/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 a required dependency of FCS_RBG.1. It is intended to require that any DRBG implemented by the TOE undergo health testing 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.
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 D - 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.

FPT_TST_EXT.1 TSF Testing

The TSF shall run a suite of the following self-tests.
  • During initial start-up (on power on) to verify the integrity of the TOE firmware and software
  • Prior to providing any cryptographic service and [selection: at no other time, on-demand, continuously [assignment: conditions under which self-tests should occur]] to verify correct operation of cryptographic implementation necessary to fulfil the TSF
  • [selection: no other, start-up, on-demand, continuous, at the conditions [assignment: conditions under which self-tests should occur] self tests[assignment: 'list an identifier for each self-test that is additional to those identified in the first two bullet points']]
to demonstrate the correct operation of the TSF.
Application Note: This requirement may be met by performing known answer tests or pair-wise consistency tests. The self-tests must be performed before the cryptographic functionality is exercised (for example, during the initialization of a process that utilizes the functionality).

The cryptographic functionality includes the cryptographic operations in FCS_COP, the key generation functions in FCS_CKM, and the random bit generation in FCS_RBG.1.
The TSF shall respond to [selection: all failures, [assignment: list of failures detected by self-tests]] by [selection: entering a maintenance mode, rebooting, [assignment: other methods to enter a secure state]].
Evaluation Activities
FPT_TST_EXT.1
TSS
The evaluator shall examine the TSS to ensure that it specifies the self-tests that are performed at start-up. This description must include an outline of the test procedures conducted by the TSF (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). The TSS must include any error states that they TSF may enter when self-tests fail, and the conditions and actions necessary to exit the error states and resume normal operation. The evaluator shall verify that the TSS indicates these self-tests are run at start-up automatically, and do not involve any inputs from or actions by the user or operator.

The evaluator shall inspect the list of self-tests in the TSS and verify that it includes algorithm self-tests. The algorithm self-tests will typically be conducted using known answer tests.
Guidance
There are no guidance evaluation activities for this component.
Tests
There are no test evaluation activities for this component.

FPT_TUD_EXT.1 TOE Firmware Update

The TSF shall implement [selection:
  • an authenticated platform firmware update mechanism as described in FPT_TUD_EXT.2
  • a delayed-authentication platform firmware update mechanism as described in FPT_TUD_EXT.3
  • a secure local platform firmware update mechanism described in FPT_TUD_EXT.4
].
Application Note: The purpose of the platform firmware update mechanism is to ensure the authenticity and integrity of platform firmware updates.

If platform firmware is immutable (not updateable by any non-destructive means), then the ST author selects "no mechanism for platform firmware update."

If the platform implements an update mechanism that does not require physical presence at the platform, and that authenticates firmware updates prior to installing them, then the ST author selects "an authenticated platform firmware update mechanism... " and includes FPT_TUD_EXT.2 and FCS_COP.1/SigVer in the ST.

If the platform implements an update mechanism that does not require physical presence at the platform, and that does not authenticate firmware updates prior to installing them, then the ST author selects "a delayed-authentication platform firmware update mechanism... " and includes FPT_TUD_EXT.3 and FCS_COP.1/SigVer in the ST.

If platform firmware is modifiable only through a local update requiring physical presence at the platform, then the ST author must select "a secure local platform firmware update mechanism... " and include FPT_TUD_EXT.4 in the ST.
Evaluation Activities
FPT_TUD_EXT.1
TSS
If the ST author selects "no provision for platform firmware update," then the evaluator shall examine the TSS to ensure that it explains all ways of modifying platform firmware in the absence of any provided mechanism. For example, breaking open the case and prying a chip off the motherboard and then reprogramming the chip. The purpose of this activity is to ensure that the TOE does not implement a local update mechanism that does not meet the requirements of FPT_TUD_EXT.4.

This requirement is met if the platform implements no means for updating platform firmware and the TSS describes a method for updating or replacing platform firmware that involves potentially destroying or damaging the TOE or some of its components.

If the ST author selects "an authenticated platform firmware update mechanism... ," then this requirement is satisfied if FPT_TUD_EXT.2 is satisfied.

If the ST author selects "a delayed-authentication platform firmware update mechanism... ," then this requirement is satisfied if FPT_TUD_EXT.3 is satisfied.

If the ST author selects "a secure local platform firmware update mechanism... ," then this requirement is satisfied if FPT_TUD_EXT.4 is satisfied.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

5.1.13 Class FTA: TOE Access

FTA_SSL.3 TSF-Initiated Termination

The TSF shall terminate a remote interactive session after a security administrator-configurable time interval of session inactivity
Application Note: An interactive session governed by this SFR is a session in which an authenticated state is achieved and then preserved across multiple commands. By contrast, if authentication accompanies each individual command, without preservation of the same authenticated state, then this is not considered an interactive session.

The intent of this requirement is to ensure that a remote interactive administrative session is not left active indefinitely when the administrator is no longer using it. The TOE is required to terminate the session after a security administrator-configurable period of inactivity.
Evaluation Activities
FTA_SSL.3
TSS
The evaluator shall determine that the TSS is consistent with the requirement that termination is TSF-initiated and occurs after a security administrator-configurable period of session inactivity.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how an administrator configures the inactivity timeout for remote interactive sessions.
  • Describes the allowable values or range of values for the timeout, if applicable.
  • Describes the effect of the timeout on an inactive remote interactive session.
Tests
The evaluator shall perform the following tests for each claimed remote interactive administrative session type, or for a representative set where the TSS and guidance show that the same mechanism is used.
  • Test FTA_SSL.3:1: Timeout configuration: The evaluator shall configure the inactivity timeout for a remote interactive administrative session in accordance with the operational guidance and verify that the TOE accepts the configured value.

  • Test FTA_SSL.3:2: TSF-initiated termination after inactivity: The evaluator shall establish a remote interactive administrative session, leave the session inactive, and verify that the TOE terminates the session after the configured inactivity interval.

FTA_SSL.4 User-Initiated Termination

The TSF shall allow administrator-initiated termination of the administrator's own interactive session.
Application Note: This SFR addresses the ability for users to terminate their own sessions. Session termination is expected to occur promptly, with no residual session data remaining accessible. “Allow administrator-initiated termination” means the TOE provides a mechanism by which the authenticated administrator can explicitly end the current interactive session. This may be accomplished through a logout, exit, disconnect, session-close, or equivalent administrator-invoked action provided by the TOE interface.
Evaluation Activities
FTA_SSL.4
TSS
The evaluator shall determine that the TSS is consistent with the requirement that the TOE provides a mechanism for an administrator to terminate the administrator’s own interactive session.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how an administrator terminates the administrator’s own interactive session for each applicable interface.
  • Describes the expected TOE behavior following administrator-initiated session termination.
Tests
The evaluator shall perform the following tests for each claimed administrator interactive session type, or for a representative set where the TSS and guidance show that the same mechanism is used.
  • Test FTA_SSL.4:1: Administrator-initiated session termination: The evaluator shall establish an administrator interactive session and invoke the documented mechanism to terminate that session. The evaluator shall verify that the TOE terminates the session.

  • Test FTA_SSL.4:2: Terminated session cannot continue to be used: Following administrator-initiated termination of the session, the evaluator shall verify that the prior session can no longer be used as an authenticated interactive session without establishing a new authenticated session.

Where appropriate, Tests 1 and 2 may be combined.

FTA_SSL_EXT.1 TSF- and TSF-initiated Session Blocking

The TSF shall, for local interactive sessions, [selection: lock the session - disable any activity of the administrator’s data access and display devices other than unlocking the session, and requiring that the administrator reauthenticate to the TSF prior to unlocking the session, terminate the session] after a security administrator-specified time period of inactivity.
Application Note: An interactive session governed by this SFR is a session in which an authenticated state is achieved and then preserved across multiple commands. By contrast, if authentication accompanies each individual command (without preservation of the same authenticated state) then this is not considered an interactive session.
The TSF shall transition to a locked state after initiation by either the user or the administrator.
The TSF shall, upon transitioning to the locked state, perform the following operations:
  • Clearing or overwriting display devices, obscuring the previous contents;
  • [assignment: Other actions performed upon transitioning to the locked state].
Application Note: The intent of this requirement is to ensure that a local interactive administrative session does not remain exposed when left unattended, and that either the administrator or the TSF can place the session into a protected locked state. For local interactive sessions, the TOE either locks the session or terminates the session after a security administrator-specified period of inactivity, as selected in FTA_SSL_EXT.1.1. When the session is locked, the TOE shall restrict activity so that the session cannot continue to be used until it is properly unlocked.
Evaluation Activities
FTA_SSL_EXT.1
TSS
The evaluator shall verify the TSS describes the actions performed upon transitioning to the locked state.
Guidance
The evaluation shall verify that the AGD guidance describes the method of setting the inactivity interval and of commanding a lock. The evaluator shall verify that the TSS describes the information allowed to be displayed to unauthorized users.
Tests
  • Test FTA_SSL_EXT.1:1: The evaluator shall configure the TSF to transition to the locked state after a time of inactivity (FMT_SMF_EXT.1) according to the AGD guidance. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are unlocking the session and those actions specified in FIA_UAU_EXT.2.

  • Test FTA_SSL_EXT.1:2: The evaluator shall command the TSF to transition to the locked state according to the AGD guidance as both the user and the administrator. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are unlocking the session and those actions specified in FIA_UAU_EXT.2.

FTA_TAB.1 Default TOE Access Banners

Before establishing a user session, the [TSF] shall display a [security administrator-specified advisory notice and consent warning regarding use of the TOE] message.
Application Note: This requirement may be met with the configuration of either text or an image containing the text of the desired message. The TSF must minimally display this information at startup, but may also display the information at every unlock. The banner is configured according to FMT_SMF_EXT.1 function .
Evaluation Activities
FTA_TAB.1
TSS
The TSS shall describe when the banner is displayed.
Guidance
There are no guidance evaluation activities for this component.
Tests
The evaluator shall also perform the following test:
  • Test FTA_TAB.1:1: The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then start up or unlock the TSF. The evaluator shall verify that the notice and consent warning message is displayed in each instance described in the TSS.

5.1.14 Class FTP: Trusted Path/Channel

FTP_ITC.1 Inter-TSF Trusted Channel

The TSF shall be capable of using [selection: IPsec, MACsec, PFED, WLAN] to provide a trusted communication channel between itself and another trusted authorized IT entities supporting the following capabilities: audit server, [selection: authentication server, [assignment: other capabilities], no other capabilities] product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.
The TSF shall permit [selection: the TSF, the authorised IT entities] to initiate communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [assignment: list of services for which the TSF is able to initiate communications].
Application Note: The intent of this requirement is for the TOE to establish and use a trusted communication channel between itself and another trusted authorized IT entity for the specific capabilities identified in the ST. The trusted channel must be logically distinct from other communication channels and must provide assured identification of its endpoints, protection of channel data from disclosure, and detection of modification of channel data.

The ST author should select the trusted-channel mechanism used by the TOE from the choices provided in FTP_ITC.1.1 and shall identify the trusted authorized IT entities and the capabilities supported over that channel. In this PP, those capabilities include at least an audit server and may also include an authentication server or other specifically identified capabilities, as claimed in the ST. Where the selected trusted-channel mechanism has its own detailed PP, PP-Module, Functional Package, or appendix-defined behavior, the ST author should ensure that the FTP_ITC.1 claim is aligned with those more detailed requirements.
Evaluation Activities
FTP_ITC.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the trusted-channel mechanism selected in FTP_ITC.1.1.
  • Identifies the trusted authorized IT entities with which the TOE establishes the trusted channel.
  • Identifies the capabilities supported over that trusted channel, including audit server and any other claimed capabilities.
  • Describes how the TOE ensures that the trusted channel is logically distinct from other communication channels.
  • Describes how the TOE assures identification of the trusted channel endpoints.
  • Describes how the selected trusted-channel mechanism protects channel data from disclosure and detects modification of channel data.
  • Identifies which party is permitted to initiate communication via the trusted channel, consistent with FTP_ITC.1.2.
  • Identifies the services for which the TOE initiates communication via the trusted channel, consistent with FTP_ITC.1.3.
Where the selected mechanism is defined in another PP, PP-Module, Functional Package, or appendix-defined protocol treatment, the evaluator shall verify that the TSS is consistent with those claims and that the protocol-specific requirements needed to support the trusted channel are also claimed in the ST.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests for each claimed trusted-channel mechanism, or for a representative set where the TSS and guidance show that the same mechanism is used.
  • Test FTP_ITC.1:1: Trusted-channel establishment to each claimed endpoint type: The evaluator shall configure the TOE to communicate with each trusted authorized IT entity type identified in the TSS and shall verify that the TOE establishes the selected trusted channel for the claimed capability or capabilities. Where protocol-specific evaluation activities already exist for the selected mechanism, those activities may satisfy or contribute to this test.

  • Test FTP_ITC.1:2: Test 2: TOE or peer initiation behavior: The evaluator shall verify that communication via the trusted channel can be initiated only by the party or parties selected in FTP_ITC.1.2. If the ST claims TOE initiation, the evaluator shall verify TOE-initiated trusted-channel establishment for at least one claimed service. If the ST claims authorized-IT-entity initiation, the evaluator shall verify that behavior as well.

  • Test FTP_ITC.1:3: Test 3: TOE-initiated services: The evaluator shall verify that the TOE initiates communication via the trusted channel for each service identified in FTP_ITC.1.3, such as audit transmission or other claimed TOE-initiated trusted communications.

  • Test FTP_ITC.1:4: Test 4: Logical distinction from other communication channels: The evaluator shall examine the TOE behavior and, where appropriate, observe communications to verify that trusted-channel traffic is separated from other communication channels in the manner described in the TSS and is not exposed as unprotected ordinary traffic.

    • One or more of these tests may be combined where appropriate.

5.1.15 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 7: SFR Rationale
ThreatAddressed byRationale
T.BASEBAND_​PROCESSOR_​COMPROMISEFPT_BBD_EXT.1Mitigates the threat by preventing the application processor's executable memory from being modified by the baseband processor, containing an attacker’s control within the baseband processor domain and providing no direct access to application processor-controlled resources, including sensitive data, system functions, security-critical components.
T.DATA_​INTEGRITYFPF_RUL_EXT.1Mitigates the threat by filtering traffic from outside the protected network.
FCS_REKEY_EXT.1/PFED (impl-dep)Mitigates the threat by rekeying ensuring session keys are fresh and reduces the window for integrity compromise.
FDP_IFC.1/HWS (impl-dep)Mitigates this threat by ensuring that only permitted information flows between the EU and CU are allowed.
FTP_ITC.1/MACsec (impl-dep)Mitigates the threat by transmitting data over a secure MACsec connection protected from unauthorized disclosure.
FTP_ITC.1/PFED (impl-dep)Mitigates the threat by transmitting data over a secure PFED connection protected from unauthorized disclosure.
FTP_ITC_EXT.1/IPsec (sel-based)Mitigates the threat by transmitting data over a secure VPN connection protected from unauthorized disclosure.
FTP_ITC_EXT.1/WLAN (sel-based)Mitigates the threat by transmitting data over a secure WLAN connection protected from unauthorized disclosure.
T.NETWORK_​ACCESSFPF_RUL_EXT.1Mitigates the threat by filtering traffic to disallow unauthorized access.
FDP_IFC.1/CU (impl-dep)Mitigates this threat by enforcing policy on inbound traffic from untrusted networks Preventing unauthorized entities from reaching internal services.
T.NETWORK_​ATTACKFAU_GEN.1Mitigates the threat by maintaining an audit trail of potential malicious activity.
FAU_SAR.1Mitigates the threat by providing a mechanism to read the audit trail.
FAU_STG.1Mitigates the threat by using an external server to preserve audit data that may provide evidence of an attack.
FAU_STG.2Mitigates the threat by preventing audit records indicating a potential attack from being destroyed.
FAU_STG.5Mitigates the threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated.
FDP_STG_EXT.1Mitigate the threat by protecting the X.509 certificates used for trusted communications.
FMT_SMF.1Mitigates the threat by providing a list of specific management functions.
FMT_SMR.1Mitigates the threat by defining the management roles which can be used to grant access to management functions.
FPT_STM.1Mitigates the threat by ensuring that audit data indicating a potential attack is accurately timestamped.
FPT_TST.1Mitigates the threat of a network attack by implementing a mechanism to detect when the DRBG may be failing to generate secure cryptographic keys.
FTA_TAB.1Mitigated the threat by providing actionable consequences for misuse of the TSF.
FCS_CKM.6 (impl-dep)Mitigates the threat by implementing key destruction to prevent the compromise of trusted channels.
FCS_CKM_EXT.7 (impl-dep)Mitigates the threat by implementing key agreement functions used for trusted communications.
FCS_REC_EXT.1/PFED (impl-dep)Mitigates this threat by suppressing EUD traffic during recovery, ensures sequential derivation of recovery keys, and terminates sessions on failure to converge.
FDP_IFC.1/PFED (impl-dep)Mitigates this threat by enforcing all EUD traffic is blocked until a secure session is authenticated and keyed, preventing attackers from injecting or tampering with traffic.
FDP_IFF.1/PFED (impl-dep)Mitigates this threat by only expected packets are processed; malformed or injected packets are dropped, preventing protocol-based attacks.
FIA_PSK_EXT.1/PFED (impl-dep)Mitigates this threat by use is limited to tunnel-0 bootstrap, preventing attackers from exploiting PSK in other sessions.
FTP_ITC.1/MACsec (impl-dep)Mitigates the threat by implementing MACsec as a means to protect data in transit.
FTP_ITC.1/PFED (impl-dep)Mitigates the threat by implementing PFED as a means to protect data in transit.
FCS_CKM.1/AKG (sel-based)Mitigates the threat by generating strong cryptographic asymmetric keys to protect data in transit.
FCS_CKM.1/SKG (sel-based)Mitigates the threat by generating strong cryptographic symmetric keys to protect data in transit.
FCS_CKM.2 (sel-based)Mitigates the threat by implementing key establishment to negotiate trusted channels to protect data in transit.
FCS_COP.1/AEAD (sel-based)Mitigates the threat by implementing AEAD functions used for trusted communications.
FCS_COP.1/CMAC (sel-based)Mitigates the threat by implementing CMAC functions used for trusted communications.
FCS_COP.1/Hash (sel-based)Mitigates the threat by implementing hash functions used for trusted communications.
FCS_COP.1/KeyedHash (sel-based)TBD
FCS_COP.1/SigGen (sel-based)Mitigates the threat by implementing signature generation functions used for trusted communications.
FCS_COP.1/SigVer (sel-based)Mitigates the threat by implementing signature verification functions used for trusted communications.
FCS_COP.1/SKC (sel-based)Mitigates the threat by implementing symmetric encryption functions used for trusted communications.
FCS_COP.1/XOF (sel-based)Mitigates the threat by implementing extensible output functions used for trusted communications.
FCS_HTTPS_EXT.1 (sel-based)Mitigates the threat by implementing HTTPS as a means to protect data in transit.
FCS_RBG.1 (sel-based)Mitigated the threat by ensuring that keys used for trusted communications are generated using a secure DRBG.
FCS_RBG.2 (sel-based)Mitigates the threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
FCS_RBG.3 (sel-based)Mitigate the threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
FCS_RBG.4 (sel-based)Mitigates the threat of a network attack by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
FCS_RBG.5 (sel-based)Mitigates the threat by ensuring that the TOE's DRBG is seeded with sufficient entropy to ensure the generation of strong cryptographic keys.
FCS_RBG.6 (sel-based)Mitigates the threat by providing a secure DRBG service for third-party applications running on the TOE which may use this service to generate their own cryptographic keys for trusted communications.
FPT_FLS.1 (sel-based)Mitigates the threat by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys.
FTP_ITC_EXT.1/Admin (sel-based)Mitigates the threat by requiring the TSF to implement trusted protocols for network communication.
FTP_ITC_EXT.1/IPsec (sel-based)Mitigates the threat by implementing IPsec as a means to protect data in transit.
FTP_ITC_EXT.1/WLAN (sel-based)Mitigates the threat by implementing WLAN as a means to protect data in transit.
FTP_ITP_EXT.1 (sel-based)Mitigates the threat by using a physically protected channel to protect data in transit.
FTP_TRP.1 (sel-based)Mitigates the threat by ensuring that remote administration only uses trusted channels.
T.NETWORK_​DISCLOSUREFPF_RUL_EXT.1
FPT_TST.1Mitigates the threat by executing self tests in a specified, repeatable manner.
FPT_TST_EXT.1Mitigates the threat by executing self tests in a specified, repeatable manner.
FPT_FLS.1 (sel-based)Mitigates the threat by ceasing operations of the TSF if a test or security failure is detected, preventing a failure in traffic filtering.
T.NETWORK_​EAVESDROPFDP_STG_EXT.1Mitigate the threat by protecting the X.509 certificates used for trusted communications.
FPT_TST.1Mitigates the threat by implementing a mechanism to detect when the DRBG may be failing to generate secure cryptographic keys.
FCS_REC_EXT.1/PFED (impl-dep)Mitigates the threat by requiring that recovery keys are derived using HKDF tied to the current session key and refreshed at the same rate as session keys, ensuring that even if recovery messages are observed, key material remains confidential.
FCS_REKEY_EXT.1/PFED (impl-dep)Mitigates the threat by frequent rekeying reducing exposure of session keys to passive attackers.
FDP_IFC.1/PFED (impl-dep)Mitigates the threat by encryption ensuring confidentiality and integrity, preventing passive monitoring of sensitive data.
FCS_CKM.1/AKG (sel-based)Mitigates the threat by ensuring the generation of strong keys used for trusted communications.
FCS_CKM.1/SKG (sel-based)Mitigates the threat by ensuring the generation of strong keys used for trusted communications.
FCS_CKM.2 (sel-based)Mitigates the threat by implementing secure methods to perform key distribution for trusted communications.
FCS_COP.1/AEAD (sel-based)Mitigates the threat by implementing a method to encrypt data in transit.
FCS_COP.1/Hash (sel-based)Mitigates the threat by ensuring that secure hash algorithms are used for trusted communications.
FCS_COP.1/KeyedHash (sel-based)Mitigates the threat by ensuring that secure HMAC algorithms are used for trusted communications.
FCS_COP.1/SigGen (sel-based)Mitigates the threat by ensuring that secure digital signature algorithms are used for trusted communications.
FCS_COP.1/SigVer (sel-based)Mitigates the threat by ensuring that secure digital signature algorithms are used for trusted communications.
FCS_HTTPS_EXT.1 (sel-based)Mitigates the threat by implementing a secure protocol (HTTPS) for trusted communications.
FPT_FLS.1 (sel-based)Mitigates the threat by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys.
FTP_ITC_EXT.1/Admin (sel-based)Mitigates the threat by requiring the TSF to implement trusted protocols for network communication.
T.PERSISTENT_​PRESENCEFMT_MOF.1Mitigates the threat by permitting management functions to be used only by authorized users.
FMT_SMF.1Mitigates the threat by defining the management functions that are supported by the TOE.
FPT_NOT_EXT.1Mitigate the threat by having the TOE enter a secure failure state when self-test integrity failures occur.
FPT_ROT_EXT.1Mitigates the threat by providing platform integrity to prevent intrusion of a persistent presence on the platform.
FPT_TST_EXT.1Mitigates the threat by performing self-tests to verify the integrity of the TSF.
FCS_COP.1/AEAD (sel-based)Mitigates the threat by implementing mechanisms to detect integrity violations of TSF data.
FCS_COP.1/KeyWrap (sel-based)Mitigates the threat by implementing mechanisms to detect integrity violations of TSF data.
FCS_STG_EXT.2 (sel-based)Mitigates the threat by enforcing access control on key data to prevent its unauthorized disclosure.
FCS_STG_EXT.3 (sel-based)Mitigates the threat by enforcing integrity protection on stored TSF data.
FPT_RVR_EXT.1 (sel-based)Mitigates the threat with firmware recovery mechanism in case of failure.
T.PHYSICAL_​ACCESSFCS_STG_EXT.1Mitigates the threat by implementing a secure key storage for keys used to protect data at rest and data in transit.
FIA_PMG_EXT.1Mitigates the threat by defining strong password characteristics.
FIA_TRT_EXT.1Mitigates the threat by limiting the extent to which brute force authentication attempts to the TOE can be made.
FIA_UAU_EXT.2Mitigates the threat by requiring successful authentication before allowing the user to take action on the TOE.
FPT_JTA_EXT.1Mitigates the threat by specifying the mechanism used to control access to JTAG.
FPT_KST_EXT.1Mitigates the threat by ensuring plaintext key material is not stored in readable non-volatile memory.
FPT_KST_EXT.2Mitigates the threat of physical access by preventing transmission of plaintext key material outside the secure boundary of the TOE.
FPT_KST_EXT.3Mitigates the threat of physical access by ensuring TOE users cannot export plaintext keys.
FPT_PHP.1Mitigates the threat by passively detecting physical tampering.
FPT_TST.1Mitigates the threat by implementing a mechanism to detect when the DRBG may be failing to generate secure cryptographic keys.
FPT_PHP.2 (objective)Mitigates the threat by providing methods to detect and report physical tampering.
FPT_PHP.3 (objective)Mitigates the threat by resisting physical tampering.
FCS_CKM.6 (impl-dep)Mitigates the threat by ensuring that keys used for trusted communications are destroyed in a secure manner.
FCS_CKM.2 (sel-based)Mitigates the threat by implementing secure methods to perform key distribution for trusted communications.
FCS_COP.1/AEAD (sel-based)Mitigates the threat by using AEAD encryption to protect data at rest.
FCS_COP.1/Hash (sel-based)Mitigates the threat by implementing an integrity mechanism used to verify stored keys.
FCS_COP.1/KeyedHash (sel-based)Mitigates the threat by implementing an integrity mechanism used to verify stored keys.
FCS_COP.1/SigGen (sel-based)Mitigates the threat by implementing an authenticity and integrity mechanism used to verify stored keys.
FCS_COP.1/SigVer (sel-based)Mitigates the threat by implementing an authenticity and integrity mechanism used to verify stored keys.
FCS_COP.1/SKC (sel-based)Mitigates the threat by using symmetric encryption to protect data at rest.
FCS_RBG.1 (sel-based)Mitigates the threat by ensuring that keys used for protected storage are generated using a secure DRBG.
FCS_STG_EXT.2 (sel-based)Mitigates the threat by enforcing confidentiality for key storage.
FCS_STG_EXT.3 (sel-based)Mitigate the threat by enforcing integrity for key storage.
FIA_AFL_EXT.1 (sel-based)Mitigates the threat by limiting the extent to which brute force authentication attempts to the TOE can be made.
FIA_UAU.5 (sel-based)Mitigates the threat by defining the supported authentication mechanisms.
FIA_UAU.7 (sel-based)Mitigates the threat by providing only limited information during authentication.
FIA_UAU_EXT.1 (sel-based)Mitigates the threat by preventing decryption prior to proper authorization to the device.
FPT_FLS.1 (sel-based)Mitigate the threat by ensuring that a malfunctioning DRBG function cannot be used to generate potentially insecure keys.
T.REPLAY_​ATTACKFTP_ITC.1/MACsec (impl-dep)Mitigates the threat by utilizing the MACsec protocol to encapsulate and encrypt channel data.
FTP_ITC.1/PFED (impl-dep)Mitigates the threat by utilizing PFED encryption to encapsulate and encrypt channel data.
FTP_ITC_EXT.1/Admin (sel-based)Mitigates the threat by utilizing the IPsec protocol to encapsulate and encrypt channel data.
FTP_ITC_EXT.1/WLAN (sel-based)Mitigates the threat by utilizing the WLAN protocol to encapsulate and encrypt channel data.
T.SECURITY_​FUNCTIONALITY_​FAILUREFCS_STG_EXT.1Mitigates the threat by generating keys and secrets and storing them in a secure manner, as well as destroying them on request.
FPT_TST.1Mitigates the threat by using self-tests to ensure correct operation of the DRBG.
FCS_CKM.6 (impl-dep)Mitigates the threat by using appropriate key destruction methods to protect the confidentiality of credential data.
FCS_COP.1/AEAD (sel-based)Mitigates the threat by implementing AEAD functions used for trusted communications.
FCS_COP.1/CMAC (sel-based)Mitigates the threat by implementing CMAC functions used for trusted communications.
FCS_COP.1/KeyEncap (sel-based)Mitigates the threat by implementing key encapsulation functions used for trusted communications.
FCS_COP.1/KeyWrap (sel-based)Mitigates the threat by implementing key wrapping functions used for trusted communications.
FCS_COP.1/SigGen (sel-based)Mitigates the threat by implementing signature generation functions used for trusted communications.
FCS_COP.1/SigVer (sel-based)Mitigates the threat by generating digital signatures with strong encryption.
FCS_COP.1/SKC (sel-based)Mitigates the threat by establishing strong symmetric-key cryptography.
FCS_RBG.1 (sel-based)Mitigates the threat by performing random-bit generation with sufficient complexity.
FCS_RBG.2 (sel-based)Mitigates the threat by using an external seed source to ensure sufficiently strong random-bit generation.
FCS_RBG.3 (sel-based)Mitigates the threat by using an internal seed source to ensure sufficiently strong random-bit generation.
FCS_RBG.4 (sel-based)Mitigates the threat by using multiple internal seed sources to ensure sufficiently strong random-bit generation.
FCS_RBG.5 (sel-based)Mitigates the threat by ensuring that each entropy source's random data is combined to ensure s Strong entropy when multiple sources are used.
FDP_ITC_EXT.1 (sel-based)Mitigates the threat by importing keys and credentials in a secure fashion.
FPT_FLS.1 (sel-based)Mitigates the threat by ensuring a DRBG self-test failure causes the TOE to enter an error state where it cannot perform secure functions using that DRBG.
T.SIDE_​CHANNEL_​LEAKAGEFPT_TUD_EXT.1Mitigates the threat of side channel leakage by providing trusted updates that are known to mitigate side channel attacks.
T.UNAUTHORIZED_​PLATFORM_​ADMINISTRATORFIA_PMG_EXT.1Mitigates the threat by enforcing password complexity requirements to prevent credentials from being easily guessed.
FIA_TRT_EXT.1Mitigates the threat by throttling authentication to prevent access via brute force.
FPT_STM.1Mitigates the threat by ensuring that time-based authentication throttling or lockout is accurately enforced.
FIA_AFL_EXT.1 (sel-based)Mitigates the threat by limiting further authentication attempts once a failure threshold of a critical authentication mechanism has been reached.
FIA_UAU.5 (sel-based)Mitigates the threat by implementing multiple authentication mechanisms for accessing the TSF.
FIA_UAU.7 (sel-based)Mitigates the threat by preventing disclosure of authentication data during authentication attempts.
T.UNAUTHORIZED_​RECONFIGURATIONFMT_MOF.1Mitigates the threat by permitting management functions to be used only by authorized users.
FMT_SMF.1Mitigates the threat by specifying the management functions implemented by the TSF.
FMT_SMR.1Mitigates the threat by defining the management roles which can be used to grant access to management functions.
FIA_UIA_EXT.1 (sel-based)Mitigates the threat by preventing the TSF from being modified by an unauthenticated subject.
T.UPDATE_​COMPROMISEFPT_PPF_EXT.1Mitigates the threat by using the official update process to be the only method to modify platform firmware.
FPT_RBP_EXT.1Mitigates this threat by protecting against a malicious or inadvertent downgrade of the software/firmware to an earlier version that may have security flaws not present in the more recent version.
FPT_ROT_EXT.2Mitigates the threat by providing a means to attest the validity of updates.
FPT_TUD_EXT.1Mitigates this threat by providing authorized users the ability to query the current version of the TOE software/firmware, initiate updates, and verify updates prior to installation using a manufacturer digital signature.
FCS_COP.1/Hash (sel-based)Mitigates the threat by providing a means to validate the integrity of an update using a hash.
FCS_COP.1/SigVer (sel-based)Mitigates the threat by providing a means to validate the integrity of an update using a digital signature verification.
FPT_TUD_EXT.2 (sel-based)Mitigates the threat by using a digital signature mechanism to verify the integrity of updates and a rollback protection mechanism to prevent application of an unauthorized update.
FPT_TUD_EXT.3 (sel-based)Mitigates the threat by using the TOE's root of trust to validate the authenticity and integrity of an update when it is applied.
FPT_TUD_EXT.4 (sel-based)Mitigates the threat through an update mechanism that requires physical access to the TOE to use.

5.2 Security Assurance Requirements

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 (EAs) to be performed are specified both in Section 5 Security Requirements as well as in this section. These SARs were chosen based on the notion that a hypothetical attacker of the TOE lacks administrative privilege on its platform but otherwise has persistent access to the TOE itself and the sophistication to interact with the platform in a way that they can attempt to access stored data without authorization or to run tools that automate more sophisticated malicious activity.

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 CCTL will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The CCTL is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The CCTL also performs the evaluation activities contained within Section 5 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 5 Security Requirements also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. The results of these activities will be documented and presented (along with the administrative guidance used) for validation.

5.2.1 Class ASE: Security Target

As per ASE activities defined in [CEM].

5.2.2 Class ADV: Development

The information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.1 Security Functional Requirements should provide the ST authors with sufficient information to determine the appropriate content for the TSS section.

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

The functional specification describes the 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 invocable 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 assurance 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.1 Security Functional Requirements, 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.

5.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 instructions to successfully install the TSF in that environment; and instructions to manage the security of the TSF as a product and as a component of the larger operational environment. Guidance pertaining to particular security functionality is also 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 Section 5.1 Security Functional Requirements 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 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.

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.

5.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 is 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 application shall be labeled with a unique reference.
Application Note: Unique reference information includes:
  • Application Name
  • Application Version
  • Application Description
  • Platform on which Application Runs
  • Software Identification (SWID) tags, if available

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/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)

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 AGD 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 developer has identified (in guidance documentation for application developers concerning the targeted platform) one or more development environments appropriate for use in developing applications for the developer’s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environments are invoked (e.g., compiler flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. 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.

ALC_TSU_EXT.1 Timely Security Updates

This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the end-user devices are updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, carriers) and the steps that are performed (e.g., developer testing, carrier testing), including worst case time periods, before an update is made available to the public.

Developer action elements:

The developer shall provide a description in the TSS of how timely security updates are made to the TOE.
Note: Application developers must support updates to their products for purposes of fixing security vulnerabilities.
The developer shall provide a description in the TSS of how users are notified when updates change security properties or the configuration of the product.

Content and presentation elements:

The description shall include the process for creating and deploying security updates for the TOE software.
The description shall express the time window as the length of time, in days, between public disclosure of a vulnerability and the public availability of security updates to the TOE.
The description shall include the mechanisms publicly available for reporting security issues pertaining to the TOE.
Application Note: The reporting mechanism could include a website or email address as well as a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).

Evaluator action elements:

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

The evaluator shall verify that the TSS contains a description of the timely security update process used by the developer to create and deploy security updates. The evaluator shall verify that this description addresses the entire application. The evaluator shall also verify that, in addition to the TOE developer’s process, any third-party processes are also addressed in the description. The evaluator shall also verify that each mechanism for deployment of security updates is described.

The evaluator shall verify that, for each deployment mechanism described for the update process, the TSS lists a time between public disclosure of a vulnerability and public availability of the security update to the TOE patching this vulnerability, to include any third-party or carrier delays in deployment. The evaluator shall verify that this time is expressed in a number or range of days.

The evaluator shall verify that this description includes the publicly available mechanisms (including either an email address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description of this mechanism includes a method for protecting the report either using a public key for encrypting email or a trusted channel for a website.

5.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 specified in the following requirements.

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 Section 5.1 Security Functional Requirements are being met, although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. 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 platform/TOE combinations that are claiming conformance to this PP. 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 the TOE for testing.
Application Note: The developer must provide at least one product instance of the TOE for complete testing on at least one platform regardless of equivalency. See the Equivalency Appendix for more details.

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.
Application Note: The evaluator should test the application on the most current fully patched version of the platform.
Evaluation Activities
ATE_IND.1

The evaluator shall prepare a test plan and report documenting the testing aspects of the system, including any application crashes during testing. The evaluator shall determine the root cause of any application crashes and include that information in the report. 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 must 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 effect; 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 AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as 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 (e.g., 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.

5.2.6 Class AVA: Vulnerability Assessment

For the current 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 application shall be suitable for testing.
Application Note: Suitability for testing means not being obfuscated or packaged in such a way as to disrupt either static or dynamic analysis by the evaluator.

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.
Application Note: Public domain sources include the Common Vulnerabilities and Exposures (CVE) dictionary for publicly known vulnerabilities. Public domain sources also include sites which provide free checking of files for viruses.
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

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 find vulnerabilities that have been found in similar applications with a particular focus on network protocols the application uses and document formats it parses.

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.

The following content should be included if:
  • the TOE implements ""
  • the TOE implements ""
  • the TOE implements ""
  • the TOE implements ""
The evaluator shall also run a virus scanner with the most current virus definitions against the application files and verify that no files are flagged as malicious.

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
The evaluator shall inspect the TSS and verify it identifies how to access the flaw remediation procedures.

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 enquiries 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
The evaluator shall inspect the TSS and verify it identifies how to access the flaw remediation procedures.

The evaluator shall inspect the guidance document and verify it describes how to access the flaw remediation guidance.

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
The evaluator shall inspect the TSS and verify it identifies how to access the flaw remediation procedures.

The evaluator shall inspect the guidance document and verify it describes how to access the flaw remediation guidance.

A.2 Objective Requirements

A.2.1 Class FPT: Protection of the TSF

FPT_PHP.2 Notification of Physical Attack

The TSF shall provide unambiguous detection of physical tampering that can compromise the TSF.
The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred.
For [assignment: list of TSF devices/elements for which active detection is required], the TSF shall monitor the devices and elements and notify [assignment: a designated user or role] when physical tampering with the TSF's devices or TSF's elements has occurred.
Application Note: FPT_PHP.2 is hierarchical to FPT_PHP.1 which means that all requirements of FPT_PHP.1 are also included as part of FPT_PHP.2. A TOE that conforms to FPT_PHP.2 therefore does not claim FPT_PHP.1.

The audit event "Detection of intrusion" should be claimed if the TOE is capable of generating an audit event in circumstances where an intrusion is detected.
Evaluation Activities
FPT_PHP.2
TSS
The evaluator shall examine the TSS to ensure it describes the methods used by the TOE to detect physical tampering and how the TOE will respond when physical tampering has been detected for each device/element specified in FPT_PHP.2.3.
Guidance
The evaluator shall ensure that the AGD describes how the TOE notifies users or administrators that it has detected tampering.
Tests
The evaluator shall perform the following tests:
  • Test FPT_PHP.2:1: The evaluator shall verify that attempts to open the TOE enclosure result in indications consistent with the operational guidance. Such indications could include damaged tamper seals, logged events, or other physical or electronic manifestations.

  • Test FPT_PHP.2:2: For each device/element listed in FPT_PHP.2.3, the evaluator shall verify that attempts to physically tamper with the device/element results in notification to the designated users or roles consistent with the operational guidance.

FPT_PHP.3 Resistance to Physical Attack

The TSF shall resist [assignment: physical tampering scenarios] to the [assignment: list of TSF devices/elements] by responding automatically such that the SFRs are always enforced.
Application Note: This SFR should be included in the ST if the TOE implements the following use cases:
  • Server-Class Platform, Enhanced
  • Tactical EUD
Evaluation Activities
FPT_PHP.3
TSS
The evaluator shall examine the TSS to ensure it describes the methods used by the TOE to detect physical tampering and how the TOE will respond when physical tampering has been detected such that SFRs are always enforced.
Guidance
The evaluator shall examine the AGD to ensure that it describes the expected response of the TOE when physical tampering is detected.
Tests
The evaluator shall perform the following test:

For each physical tampering scenario and device/element listed in FPT_PHP.3.1, the evaluator shall verify that tampering attempts result in a response from the TSF consistent with the operational guidance.

A.3 Implementation-dependent Requirements

A.3.1 Class FAU: Security Audit

FAU_GEN.1/PFED Audit Data Generation

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall generate audit records for the following events.
  • Provisioning
  • Session setup and termination
  • Rekey
  • Key recovery
Application Note: The intent of this requirement is to ensure that PFED-relevant security events are recorded so that establishment, maintenance, and recovery of the protected PFED session can be reconstructed and reviewed.

These events align with the PFED operational lifecycle described in Appendix H. The lifecycle of a PFED pair consists of provisioning the cryptographic pair-wise association between two EU’s and managing the subsequent sessions and session keys using transaction events. Provisioning establishes the initial keystore and is expected to run once at the beginning of life for the pair. Once provisioned, an EU-to-EU session must be established before EUD traffic can flow. There is a rekey event during session setup and periodically afterwards until one end goes offline. If a session key gets out of sync between the EU’s, the pair will detect and then initiate a key recovery. It is not expected that EU logs are accessible while the crypto is active. The PFED appendix currently states that the TOE maintains separate logs for the EU and CU, and specifically describes EU logging for these events.
Evaluation Activities
FAU_GEN.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED audit events for which the TOE generates records:
    • provisioning,
    • session setup,
    • session termination,
    • rekey, and
    • key recovery.
  • Describes what constitutes an auditable occurrence of each event type.
  • Describes the contents of the audit record generated for each event type.
The evaluator shall determine that the TSS is consistent with the PFED appendix logging description for provisioning, session setup, session termination, rekey, and key recovery.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FAU_GEN.1/PFED:1: Provisioning audit generation: The evaluator shall cause PFED provisioning to occur and verify that the TOE generates an audit record for the provisioning event.

  • Test FAU_GEN.1/PFED:2: Session setup and termination audit generation: The evaluator shall cause a PFED session to be established and terminated, and then verify the TOE generates audit records for session setup and session termination.

  • Test FAU_GEN.1/PFED:3: Rekey audit generation: The evaluator shall cause a PFED rekey event to occur and verify the TOE generates an audit record for the rekey event.

  • Test FAU_GEN.1/PFED:4: Key recovery audit generation: The evaluator shall cause a PFED key recovery event to occur and verify the TOE generates an audit record for the key recovery event.

  • Test FAU_GEN.1/PFED:5: Audit record review: The evaluator shall review the generated audit records and verify the records can be distinguished by event type and are consistent with the TSS and guidance.

FAU_GEN.2/PFED User Identity Association

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall associate audit records with the initiating EU+CU identity.
Application Note: The intent of this requirement is to ensure that PFED audit records can be tied to the EU+CU identity that initiated the audited action or session, so that the audit trail reflects which EU was responsible for the event.

For this requirement, “initiating EU+CU identity” is the identity of the peer or local EU+CU instance on whose behalf the auditable PFED event was initiated, as represented by the TOE’s PFED identity model. The ST author should describe the form of that identity in TOE-specific terms.
Evaluation Activities
FAU_GEN.2/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED audit records to which initiating EU+CU identity association applies.
  • Defines the initiating EU identity used by the TOE for those audit records.
  • Describes how the TOE obtains, derives, or assigns the initiating EU+CU identity for PFED events.
  • Describes how the TOE associates the initiating EU+CU identity with each applicable audit record.
  • Describes when, during provisioning, session setup, rekey, key recovery, or session termination, the initiating EU+CU identity becomes available for audit association.
The evaluator shall determine that the TSS is consistent with the PFED audit model described in Appendix H and that the association mechanism is sufficient to attribute applicable PFED audit records to the initiating EU identity.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FAU_GEN.2/PFED:1: Provisioning identity association: The evaluator shall cause PFED provisioning to occur and verify that the generated audit record is associated with the initiating EU+CU identity in accordance with the TSS and guidance.

  • Test FAU_GEN.2/PFED:2: Session setup identity association: The evaluator shall cause PFED session setup to occur and verify that the generated audit record is associated with the initiating EU+CU identity.

  • Test FAU_GEN.2/PFED:3: Rekey or key recovery identity association: The evaluator shall cause a PFED rekey event or key recovery event to occur and verify that the generated audit record is associated with the initiating EU+CU identity.

  • Test FAU_GEN.2/PFED:4: Session termination identity association: The evaluator shall cause a PFED session termination event to occur and verify that the generated audit record is associated with the initiating EU+CU identity.

  • Test FAU_GEN.2/PFED:5: Audit review consistency: The evaluator shall review the generated audit records and verify that the recorded ERD identity is presented consistently enough to distinguish the initiating EU+CU for the applicable PFED events.

FAU_STG.1/PFED Protected Audit Trail Storage

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall protect stored audit records from unauthorized modification and deletion.
Application Note: The intent of this requirement is to ensure that PFED audit records, once generated and stored, cannot be altered or removed by unauthorized entities.

For this requirement, “unauthorized modification and deletion” means that the TOE enforces access controls, storage protections, or other TOE security mechanisms such that only authorized TOE functions or authorized administrative actions may affect stored audit records in the ways permitted by the TOE design.
Evaluation Activities
FAU_STG.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the storage location or locations used for PFED audit records.
  • Describes how stored PFED audit records are protected from unauthorized modification.
  • Describes how stored PFED audit records are protected from unauthorized deletion.
  • Identifies the TOE roles, services, or internal processes that are authorized to modify, rotate, archive, export, or delete PFED audit records.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests:
  • Test FAU_STG.1/PFED:1: Stored audit record generation and persistence: The evaluator shall cause one or more PFED auditable events to occur and verify that corresponding audit records are stored in the PFED audit storage described in the TSS and guidance.

  • Test FAU_STG.1/PFED:2: Protection against unauthorized modification: Using available interfaces and roles, the evaluator shall attempt to modify stored PFED audit records in a manner not authorized by the TOE. The evaluator shall verify that the TOE prevents the unauthorized modification.

  • Test FAU_STG.1/PFED:3: Protection against unauthorized deletion: Using available interfaces and roles, the evaluator shall attempt to delete stored PFED audit records in a manner not authorized by the TOE. The evaluator shall verify that the TOE prevents the unauthorized deletion.

A.3.2 Class FCS: Cryptographic Support

FCS_CKM.1/PFEDAKG Cryptographic Key Generation - Asymmetric Key

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [[selection: ML-KEM using the parameter set [ML-KEM-1024] that meets the following: [NIST FIPS PUB 203], ML-DSA using the parameter set [ML-DSA-87] that meets the following [NIST FIPS PUB 204]]
Application Note: The intent of this requirement is to ensure that the TOE generates asymmetric cryptographic keys in accordance with the specified approved cryptographic key generation algorithms and parameter sets required for PFED operations.

ML-KEM key pairs are generated within the EU and are never exported. They are also ephemeral. A TOE will have the following different ways to handle signatures
  • ML-DSA key pair is burned in at the factory
  • A user can generate a key pair off platform and the TOE has a method to import it
Evaluation Activities
FCS_CKM.1/PFEDAKG
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 specified 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/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 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 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 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.

FCS_CKM.2/PFED Cryptographic Key Distribution

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [[selection: key encapsulation, encrypted channel]].
Application Note: The intent of this requirement is to ensure that the TOE performs PFED cryptographic key establishment only by one of the claimed and defined methods: key encapsulation or encrypted channel. The ST author should select the method or methods actually implemented by the TOE for PFED key establishment.

For PFED, the selected method should be described consistently with the PFED lifecycle in Appendix H. During initial bonding, the TOE uses a temporary secure tunnel (tunnel-0) established using a pre-shared key. During provisioning completion, the TOE exchanges ML-DSA-87 public keys and performs authentication and rekey transactions. Prior to permitting EUD traffic, session setup requires a mandatory session rekey using ML-KEM-1024. Later rekey and recovery operations update or restore keying state using newly derived shared secrets and existing protected key state.

Key Encapsulation should follow the ML-KEM-1024 protocol where A generates an ephemeral ML-KEM-1024 key pair (P/p), sends the public P to B, B encrypts a random value with P and encapsulates a response to A. The encrypted channel method should encrypt a random key with a shared Key Encrypting Key using GCM AES 256 with integrity checking.
Evaluation Activities
FCS_CKM.2/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies which selection or selections are claimed in FCS_CKM.2.1/PFED:
    • key encapsulation,
    • encrypted channel,
    • or both, if supported by the TOE.
  • Describes the PFED key-establishment process or processes that use each claimed method.
  • Identifies the PFED phase or phases in which each claimed method is used, such as provisioning, session setup, rekey, or recovery.
  • Identifies the cryptographic mechanisms underlying each claimed method.
  • Describes the keying material established by each claimed method.
  • If key encapsulation is claimed, describes the encapsulation-based method used for PFED and how it is integrated into PFED operation.
  • If encrypted channel is claimed, describes the encrypted channel used for PFED key establishment and how the channel protects the establishment of keying material.
The evaluator shall determine that the TSS description is consistent with the PFED appendix, including the PSK-based temporary provisioning tunnel, ML-DSA public-key exchange during provisioning completion, mandatory ML-KEM-1024 rekey during session setup, and subsequent rekey/recovery behavior using newly derived shared secrets.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests according to the selections claimed in the ST.
  • Test FCS_CKM.2/PFED:1: Key encapsulation selection: If the TOE claims key encapsulation, the evaluator shall invoke or otherwise cause the TOE to perform PFED key establishment using the claimed encapsulation-based method and verify that the TOE uses key encapsulation for the PFED transaction or phase identified in the TSS. Where the PFED design relies on ML-KEM during session setup, the evaluator shall verify that the observed TOE behavior is consistent with that claim.

  • Test FCS_CKM.2/PFED:2: Encrypted channel selection: If the TOE claims encrypted channel, the evaluator shall invoke or otherwise cause the TOE to perform PFED key establishment over the claimed encrypted channel and verify that the TOE uses that encrypted channel for the PFED transaction or phase identified in the TSS. Where the TOE relies on the temporary PSK-based provisioning tunnel, the evaluator shall verify that the observed TOE behavior is consistent with that claim.

FCS_CKM.5/PFED Cryptographic Key Derivation

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall derive [all session and recovery keys] from [existing key store material, newly derived shared secrets, hardware-based RBG entropy as defined in FCS_RBG.1] in accordance with a specified key derivation algorithm [Hash Key Derivation Function using [selection: SHA-384, SHA-512], and cryptographic key sizes [selection: 384, 512] that meet the following [NIST SP 800-56C Revision 2 (Section 4.1, Option 1)].
Application Note: The intent of this requirement is to ensure that the TOE derives PFED keying material only from the claimed sources of keying material and entropy, and only by means of the claimed key derivation method. If the TOE derives different PFED keys in different phases, such as session setup, rekey, or recovery, the TSS should describe the derivation inputs and outputs for each phase separately.
Evaluation Activities
FCS_CKM.5/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED keys derived under this requirement, including any session keys, recovery keys, or other operational keys claimed to be covered.
  • States that the TOE uses a Hash Key Derivation Function for the claimed PFED key derivation.
  • Identifies whether the TOE uses SHA-384, SHA-512, or both as the underlying hash for the claimed derivation.
  • Identifies the claimed derived key size or sizes, 384 bits or 512 bits, corresponding to the selected hash function.
  • Describes the input material used for derivation, including:
    • existing key store material,
    • newly derived shared secrets, and
    • hardware-based RBG entropy as defined in FCS_RBG.1.
  • Describes which of those inputs are used for each PFED derivation phase, such as initial session derivation, rekey, and recovery.
  • Describes how the TOE performs derivation in a manner consistent with NIST SP 800-56C Rev. 2, Section 4.1, Option 1.
The evaluator shall determine that the TSS is consistent with the posted PFED appendix text stating that PFED uses HKDF, that HKDF input includes hardware RNG entropy, and that rekey derives final session keys from current key-store material and newly derived shared secrets.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FCS_CKM.6/PFED Timing and Event of Cryptographic Key Destruction

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall destroy [
  • the PSK immediately after teardown of tunnel-0
  • any replaced session key immediately after a successful rekey
  • any obsolete recovery key immediately after replacement
].
Application Note: The intent of this requirement is to ensure that PFED keying material is destroyed promptly when it is no longer needed for its intended security function, so that superseded or transitional keys cannot continue to be used or recovered after the TOE has moved to the next protected state. For PFED, this includes destruction of the temporary provisioning PSK, destruction of superseded session keys after successful rekey, and destruction of obsolete recovery keys after replacement. Destruction mechanisms typically include zeroization and prevention of key recovery.

For the first bullet, the ST author should describe the TOE behavior that causes the PSK used for tunnel-0 to be destroyed immediately after teardown of tunnel-0. This should be written consistently with Appendix H, which states that tunnel-0 is terminated and the PSK is cryptographically destroyed following successful completion of the ML-KEM-1024 transaction and transition to tunnel-1.

For the second bullet, “any replaced session key immediately after a successful rekey” means that once the TOE has successfully established and activated the replacement session key, the previously active session key is destroyed without unnecessary delay. The TSS should make clear what the TOE considers a successful rekey, when the new session key becomes active, and at what point the replaced key is destroyed.

For the third bullet, “any obsolete recovery key immediately after replacement” means that once the TOE has established the replacement recovery key material, the prior recovery key that is no longer needed for recovery operations is destroyed without unnecessary delay.
Evaluation Activities
FCS_CKM.6/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies each PFED key type covered by this requirement:
    • the tunnel-0 PSK,
    • replaced session keys, and
    • obsolete recovery keys.
  • Describes where each such key exists within the TOE while active or stored.
  • Describes the event that triggers destruction for each covered key type.
  • Describes when destruction occurs relative to the triggering event for each covered key type.
  • Describes how the TOE ensures that the destroyed key is no longer available for operational use after destruction.
  • For the tunnel-0 PSK, describes behavior consistent with Appendix H, including teardown of tunnel-0 and destruction of the PSK after successful transition away from the temporary provisioning tunnel.
  • For replaced session keys, describes what constitutes a successful rekey and when the replaced session key is destroyed.
  • For obsolete recovery keys, describes what constitutes replacement of the recovery key and when the obsolete recovery key is destroyed.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests. Where direct observation of low-level key material is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, developer evidence, or other evaluation evidence sufficient to determine that destruction occurred at the claimed point.
  • Test FCS_CKM.6/PFED:1: Tunnel-0 PSK destruction: The evaluator shall cause the TOE to complete the PFED flow that transitions from tunnel-0 to tunnel-1 and verify that the TOE behavior is consistent with:
    • teardown of tunnel-0, and
    • destruction of the tunnel-0 PSK immediately after teardown of tunnel-0: This test shall be consistent with the Appendix H behavior stating that, after successful ML-KEM-1024 completion, tunnel-0 is terminated and the PSK is cryptographically destroyed.

  • Test FCS_CKM.6/PFED:2: Replaced session key destruction: The evaluator shall cause a successful PFED rekey operation and verify that the TOE destroys the replaced session key immediately after the successful rekey.

  • Test FCS_CKM.6/PFED:3: Obsolete recovery key destruction: The evaluator shall cause a recovery-key replacement event and verify that the TOE destroys the obsolete recovery key immediately after replacement.

FCS_CKM_EXT.7 Cryptographic Key Agreement

This component must be included in the ST if the TOE implements any of the following features:
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]

The following table provides the allowable choices for completion of the selection operations of FCS_CKM_EXT.7.
Table 8: Allowable choices for FCS_CKM_EXT.7
Identifier Cryptographic algorithm Cryptographic parameters List of standards
DHFinite Field Cryptography Diffie-HellmanStatic 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]]
ECDHElliptic Curve Diffie-HellmanElliptic 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: All of the above algorithms with the selectable parameters are CNSA 1.0 compliant.

This SFR must be included in the ST if key agreement or transport is a service provided by the TOE to tenant software, or if they are used by the TOE itself to support or implement PP-specified security functionality.

If this SFR is claimed, then FCS_CKM.6 an FCS_CKM.1/AKG must also be claimed.

This SFR has dependencies on FCS_COP.1/Hash and FCS_COP.1/XOF only if ML-KEM is selected.

This component must be included in the ST if the TOE implements any of the following features: IPsec.
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.

FCS_COP.1/PFEDAES Cryptographic Operation - AES Data Enctrypytion and Decryption

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform [encryption and decryption] in accordance with a specified cryptographic algorithms [AES operating in GCM mode as defined in FCS_COP.1/AEAD] and cryptographic key size [256 bits] that meet the following: [AES as specified in FIPS PUB 197, GCM as specified in NIST SP 800-38D].
Application Note: This SFR covers implementation of AES for encryption and decryption. The ST specifies supported modes and key sizes required for PFED operations. The intent of this requirement is to ensure that the TOE performs the claimed PFED encryption and decryption operations using AES in GCM mode with a 256-bit key. This requirement should be read consistently with FCS_COP.1/AEAD. The selected algorithm here is not a separate AES mode family; it is specifically AES-GCM as defined by the base AEAD requirement. The ST author should therefore describe the PFED usage of AES-GCM-256 in a way that is consistent with the TOE’s claimed AEAD implementation and PFED operational context.
Evaluation Activities
FCS_COP.1/PFEDAES
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. 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 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-GCM

Identifier Cryptographic Algorithm Cryptographic Key Sizes List of Standards
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:202 (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 tag such that approximately half of the cases are correct and half the cases contain errors. PFED Functional Test

Provision a pair of PFED’s (A1 and B1) and attach EUD’s A and B to A1 and B1. Send data between A and B (e.g., ping). Modify the encrypted portion of packets on the black network and observe if the pings stop. Capture and resend packets on the black network and see if duplicates arrive at the destination EUD.

FCS_COP.1/PFEDHash Cryptographic Operation - Hashing

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform [cryptographic hashing] in accordance with a specified cryptographic algorithm [selection: SHA-384, SHA-512] that meet the following [FIPS PUB 180-4].
Application Note: The intent of this requirement is to ensure that the TOE performs the claimed PFED cryptographic hashing operation only with the selected approved hash algorithm. The ST specifies the algorithms used that are required for PFED operations.
Evaluation Activities
FCS_COP.1/PFEDHash
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED function or functions performed under this requirement.
  • Identifies whether the TOE performs cryptographic hashing using SHA-384, SHA-512, or both.
  • States that the claimed hash algorithm or algorithms conform to FIPS PUB 180-4.
  • Describes the TOE service, interface, or PFED phase in which the claimed hash operation is used.
  • If both SHA-384 and SHA-512 are claimed, distinguishes the TOE behavior for each algorithm sufficiently to support testing.
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 on 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-384, SHA-512.

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

Algorithm Functional Test.

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

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

Monte Carlo Test

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

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

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

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

INITIAL_SEED_LENGTH = LEN(SEED)

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

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

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

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

FCS_COP.1/PFEDKeyEncap Cryptographic Operation - Key Encapsulation

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform [key encapsulation] in accordance with a specified cryptographic algorithm [ML-KEM] and cryptographic key size [parameter set ML-KEM-1024] that meet the following: [NIST FIPS 203].
Application Note: The intent of this requirement is to ensure that the TOE performs the claimed PFED key encapsulation operation only with the approved cryptographic algorithm ML-KEM using the parameter set ML-KEM-1024, in accordance with NIST FIPS 203.
Evaluation Activities
FCS_COP.1/PFEDKeyEncap
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 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 on 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/PFEDSigGen Cryptographic Operation - Signature Generation

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform [digital signature generation] in accordance with a specified cryptographic algorithm [ML-DSA] and cryptographic key size [parameter set ML-DSA-87] that meet the following: [NIST FIPS PUB 204 (Section 5.2)].
Application Note: The intent of this requirement is to ensure that the TOE performs the claimed PFED digital signature generation operation only with the approved cryptographic algorithm ML-DSA using the parameter set ML-DSA-87, in accordance with NIST FIPS PUB 204, Section 5.2.
Evaluation Activities
FCS_COP.1/PFEDSigGen
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED function or functions performed under this requirement.
  • States that the TOE performs digital signature generation using ML-DSA.
  • States that the TOE uses the parameter set ML-DSA-87.
  • States that the claimed operation conforms to NIST FIPS PUB 204, Section 5.2.
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 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-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/PFEDSigVer Cryptographic Operation - Signature Verification

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform [digital signature verification] in accordance with a specified cryptographic algorithm [ML-DSA] and cryptographic key size [parameter set ML-DSA-87] that meet the following: [NIST FIPS PUB 204 (Section 5.3)].
Application Note: The intent of this requirement is to ensure that the TOE performs the claimed PFED digital signature verification operation only with the approved cryptographic algorithm ML-DSA using the parameter set ML-DSA-87, in accordance with NIST FIPS PUB 204, Section 5.3.
Evaluation Activities
FCS_COP.1/PFEDSigVer
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED function or functions performed under this requirement.
  • States that the TOE performs digital signature verification using ML-DSA.
  • States that the TOE uses the parameter set ML-DSA-87.
  • States that the claimed operation conforms to NIST FIPS PUB 204, Section 5.3.
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 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-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_REC_EXT.1/PFED Key Recovery

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall support session key recovery such that:
  • EUD traffic is suppressed during recovery
  • Recovery keys are refreshed at the same rate as session keys
  • Recovery keys are derived via HKDF including the current session key and new session key
  • There must be at least two recovery keys
  • Only one recovery key can be derived at a time
  • Failure to converge causes session termination
.
Application Note: The intent of this requirement is to ensure that the TOE supports a controlled session key recovery process for PFED when session state diverges, while preventing use of potentially inconsistent or stale keying material during that recovery.

The TSS should describe the PFED recovery process in TOE-specific terms and should align that description with Appendix H, which says that during key recovery EUD traffic is suppressed, recovery keys are periodically refreshed using HKDF, recovery keys are not static values, and after successful resynchronization the TOE performs a new session setup transaction and replaces the prior recovery key before resuming EUD traffic.

“Recovery keys are refreshed at the same rate as session keys” means the TOE does not allow recovery keys to age more slowly than the active session keys they support. “There must be at least two recovery keys” means the TOE maintains a sufficient recovery-key state to support the claimed recovery design without relying on a single static fallback value. “Only one recovery key can be derived at a time” means the TOE serializes recovery-key derivation so that concurrent derivation does not produce an ambiguous or conflicting recovery state.

Key Recovery keys are temporary session keys for when an EU fails to decrypt some number of sequential packets. Recovery keys cannot be static values to prevent an adversary in the middle to downgrade the session tunnel to a potentially knowable key. There must be two recovery keys (R1 and R2) to ensure if whatever caused a recovery key to be not matched, there is a second one as backup. When a session is in key recovery, R1 is used to beacon a message to the peer at least the number of times the original session key failed to decrypt. If R1 does not converge then R2 is used to beacon a recovery message the same number of times. If that does not converge, retry R1, and so on. This flip flop between both recovery keys should happen several times before a node terminates the session.
Evaluation Activities
FCS_REC_EXT.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the PFED session key recovery process used to resynchronize session state after key divergence.
  • Identifies the conditions that trigger entry into the key recovery process.
  • Describes how the TOE suppresses EUD traffic during recovery.
  • Describes the recovery keys maintained by the TOE and shows that at least two recovery keys are supported.
  • Describes how recovery keys are refreshed and demonstrates that they are refreshed at the same rate as session keys.
  • Describes how recovery keys are derived using HKDF and identifies the derivation inputs, including the current session key and new session key.
  • Describes how the TOE ensures that only one recovery key can be derived at a time.
  • Describes the convergence criteria for successful recovery.
  • Describes the timeout or other failure condition under which recovery is deemed not to have converged.
  • Describes how failure to converge causes session termination.
  • Describes the TOE behavior after successful recovery, including replacement of the previous recovery key and any new session setup behavior before EUD traffic resumes.
The evaluator shall determine that the TSS is consistent with the posted PFED requirement text and Appendix H, including suppression of EUD traffic during recovery, HKDF-based recovery-key refresh, replacement of the previous recovery key upon successful resynchronization, and session termination when recovery fails to converge within the defined timeout.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FCS_REC_EXT.1/PFED:1: Entry into recovery and traffic suppression: The evaluator shall cause a PFED condition requiring session key recovery, such as session key divergence as described by the PFED recovery model and verify that the TOE enters recovery and suppresses EUD traffic during the recovery process.

  • Test FCS_REC_EXT.1/PFED:2: Recovery-key refresh behavior: The evaluator shall observe or otherwise verify, through TOE behavior, supported interfaces, traces, or developer evidence, that recovery keys are refreshed at the same rate as session keys and are not static values.

  • Test FCS_REC_EXT.1/PFED:3: Recovery-key derivation inputs: The evaluator shall verify, through TOE behavior, supported interfaces, traces, or developer evidence, that recovery keys are derived via HKDF and that the derivation includes the current session key and new session key, as claimed in the TSS and required by the SFR.

  • Test FCS_REC_EXT.1/PFED:4: Recovery-key cardinality and serialization: The evaluator shall verify that the TOE supports at least two recovery keys and that only one recovery key derivation can be in progress at a time.

  • Test FCS_REC_EXT.1/PFED:5: Successful recovery behavior: The evaluator shall cause a recoverable divergence condition and verify that, upon successful resynchronization, the TOE performs the claimed post-recovery actions, including replacement of the previous recovery key and any required new session setup behavior before EUD traffic resumes. Appendix H states that successful resynchronization results in a new session setup transaction and replacement of the previous recovery key before EUD traffic resumes.

  • Test FCS_REC_EXT.1/PFED:6: Failure to converge: The evaluator shall cause recovery not to converge within the claimed timeout or failure condition and verify that the TOE terminates the session. Both the requirement text and Appendix H require session termination when recovery fails to converge.

    Where direct observation of low-level recovery-key state is not practical, the evaluator may rely on observable TOE behavior, protocol traces, supported test interfaces, or developer evidence, sufficient to determine that the claimed recovery-key behavior is implemented.

  • Test FCS_REC_EXT.1/PFED:7: PFED Functional Test: Provision two pairs of PFED’s, A1-B1 and A2-B2. Attach EUD’s A and B to A1 and B1, verify the EUD’s can communicate (e.g., ping). Then connect A1 to B2 between the EUD’s. A1 and B2 should fail to establish a session since the session keys are different. Wait five minutes. Verify that EUD’s A and B cannot communicate. Reconnect A1-B1 and wait five minutes. Verify that EUD’s A and B can communicate.

FCS_REKEY_EXT.1/PFED Periodic Rekey

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform session rekey:
  • At a configurable interval [assignment: between 2 and 30 minutes]
  • Using ML-KEM-1024 only
  • Either synchronously or asynchronously with EUD traffic
    • .
Application Note: The intent of this requirement is to ensure that PFED session keys are refreshed periodically using a constrained and well-defined rekey mechanism, so that active session protection does not rely indefinitely on a single long-lived session key. For PFED, the TOE is required to perform session rekey at a security administrator-configurable interval within the claimed range, to use ML-KEM-1024 only for the rekey operation, and to support rekey either synchronously or asynchronously with respect to EUD traffic, as claimed by the TOE design.

The TSS should describe the PFED rekey model in TOE-specific terms and should align that description with Appendix H. Appendix H says that, following session establishment, the TOE enforces periodic rekey operations at configurable intervals between 2 and 30 minutes, that rekey operations may be initiated by either ERD, and that rekey may be performed either asynchronously while EUD traffic continues or synchronously with EUD traffic paused.
Evaluation Activities
FCS_REKEY_EXT.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the PFED periodic rekey process used by the TOE.
  • Identifies the configurable rekey interval or interval range and shows that it is limited to the claimed range between 2 and 30 minutes.
  • States that PFED rekey uses ML-KEM-1024 only.
  • Describes whether the TOE performs rekey synchronously with EUD traffic paused, asynchronously while EUD traffic continues, or supports both modes.
  • If both rekey modes are supported, distinguishes the TOE behavior for each mode.
  • Describes when the TOE initiates or responds to rekey and, if applicable, whether either ERD may initiate rekey.
  • Describes what constitutes successful completion of rekey.
  • Describes when the newly derived session key becomes active.
  • Describes how the TOE transitions away from the replaced session key after successful rekey.
The evaluator shall determine that the TSS is consistent with the PFED requirement text and Appendix H, including the configurable 2 to 30 minute interval, the use of ML-KEM-1024, the synchronous or asynchronous rekey modes, and the Appendix H statements that the final session key is derived from the current key store and newly derived shared secrets and that the replaced session key is securely destroyed.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how an administrator configures the PFED rekey interval.
  • Describes the allowable interval values or range, consistent with the claimed 2-to-30-minute range.
  • Describes whether the TOE uses synchronous rekey, asynchronous rekey, or both.
  • Describes any operational effect of rekey on EUD traffic.
  • Describes any administrator-visible indications, status, or logs associated with PFED rekey, if such outputs are generated by the TOE.
  • Describes any prerequisites for successful PFED rekey, if applicable.
Tests
The evaluator shall perform the following tests.
  • Test FCS_REKEY_EXT.1/PFED:1: Rekey interval configuration: The evaluator shall configure the PFED rekey interval in accordance with the operational guidance and verify that the TOE accepts only values within the claimed range of 2 to 30 minutes. The evaluator shall also verify that the TOE rejects values outside the claimed range, if configuration validation is exposed by the TOE.

  • Test FCS_REKEY_EXT.1/PFED:2: Periodic rekey occurrence: The evaluator shall cause a PFED session to be established, configure a rekey interval within the claimed range, and verify that the TOE performs periodic rekey in accordance with that configured interval.

  • Test FCS_REKEY_EXT.1/PFED:3: ML-KEM-1024-only rekey: The evaluator shall verify, through TOE behavior, supported interfaces, traces, metadata, or developer evidence, that PFED rekey uses ML-KEM-1024 and does not rely on a different algorithm or ML-KEM parameter set to satisfy this SFR.

  • Test FCS_REKEY_EXT.1/PFED:4: Synchronous or asynchronous traffic behavior: If the TOE claims asynchronous rekey, the evaluator shall verify that rekey can occur while EUD traffic continues. If the TOE claims synchronous rekey, the evaluator shall verify that rekey occurs with EUD traffic paused. If both are claimed, the evaluator shall verify both modes. This aligns with Appendix H’s distinction between asynchronous rekey while EUD traffic continues and synchronous rekey with EUD traffic paused.

  • Test FCS_REKEY_EXT.1/PFED:5: Successful rekey transition: The evaluator shall verify that, following successful rekey, the TOE activates the replacement session key and transitions away from the previous session key in a manner consistent with the TSS. Appendix H states that the final session key is derived from the current key store and newly derived shared secrets and that the replaced session key is securely destroyed.

  • Test FCS_REKEY_EXT.1/PFED:6: PFED Functional Test: Provision a pair of PFED’s (A1 and B1). With no EUD’s attached to A1/B1, observe the black transport for a periodic handshake of packets that happens at the configured interval. Watch long enough for at least two expected intervals. Where direct observation of a low-level rekey state is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, protocol traces, or developer evidence sufficient to determine that the claimed PFED rekey behavior is implemented.

A.3.3 Class FDP: User Data Protection

FDP_BRINGUP_EXT.1 Secure Bring-Up

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall prevent any traffic flow until:
  • PIN or CIK credentials are supplied
  • Session setup and authentication complete
.
Application Note: The intent of this requirement is to ensure that the TOE remains traffic-silent during initial bring-up until both the required activation credentials have been provided and the TOE has completed the security establishment needed to enter an operational state. For this requirement, “prevent any traffic flow” means the TOE does not permit protected or operational traffic to pass until both listed conditions have been satisfied.

The first condition requires that PIN or CIK credentials are supplied. The ST author should describe which activation factor or factors are supported by the TOE and how the TOE determines that the required bring-up credential has been provided.

The second condition requires that session setup and authentication to complete before traffic is permitted. The TSS should identify what constitutes completion of session setup, what authentication steps are required, and how the TOE ensures traffic remains blocked until those steps are complete. This should be written consistently with the PFED requirement that the TOE enforce mutual authentication prior to permitting EUD traffic.
Evaluation Activities
FDP_BRINGUP_EXT.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the TOE secure bring-up process for PFED.
  • Identifies the traffic the TOE suppresses prior to successful bring-up.
  • Describes how the TOE prevents traffic flow before bring-up completes.
  • Describes the activation credential accepted for this requirement, including PIN, CIK, or both, as implemented by the TOE.
  • Describes how the TOE determines that the required activation credential has been supplied.
  • Describes the session setup steps that must complete before traffic is permitted.
  • Describes the authentication steps that must complete before traffic is permitted.
  • Identifies the event or state transition that causes the TOE to begin permitting traffic after successful bring-up.
  • Describes TOE behavior when activation credentials are missing, invalid, or not yet supplied.
  • Describes TOE behavior when session setup or authentication fails.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how the administrator or user provides the required PIN or CIK credential for bring-up.
  • Describes how session setup is initiated or completed following credential provision.
  • Describes how the TOE indicates that traffic remains gated during bring-up.
  • Describes how the TOE indicates successful completion of bring-up, if such indication is exposed.
  • Describes failure behavior when credential provision, session setup, or authentication does not complete successfully.
Tests
The evaluator shall perform the following tests.
  • Test FDP_BRINGUP_EXT.1:1: Traffic blocked before credential provision: The evaluator shall place the TOE in a pre-bring-up state and verify that the TOE prevents traffic flow before the required PIN or CIK credential is supplied. This aligns with the requirement text and Appendix H’s statement that no traffic flows until activation credentials are provided.

  • Test FDP_BRINGUP_EXT.1:2: Traffic remains blocked until session setup and authentication complete: After providing the required PIN or CIK credential, the evaluator shall verify that the TOE continues to prevent traffic flow until session setup and authentication complete. This aligns with the requirement text and the PFED mutual-authentication requirement elsewhere in the PP.

  • Test FDP_BRINGUP_EXT.1:3: Traffic permitted after successful bring-up: The evaluator shall provide the required credential and cause session setup and authentication to complete successfully, then verify that the TOE permits traffic flow only after those conditions have been satisfied.

  • Test FDP_BRINGUP_EXT.1:4: Failure handling: The evaluator shall attempt bring-up with missing, invalid, or incomplete credential provision, and separately with unsuccessful session setup or authentication, and verify that the TOE continues to prevent traffic flow in each case.

  • Test FDP_BRINGUP_EXT.1:5: PFED Functional Test: Provision a pair of PFED’s (A1 and B1). With EUD’s A and B attached to A1/B1, attempt to reach B from A while power cycling A1 or B1 once without entering credentials (if that’s implemented). Verify that A and B are not communicating. Then enter the credential and observe if A finally connects to B.

FDP_IFC.1/CU Subset Information Flow Control

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall enforce the [CU Information Flow Control Policy] on: [
  • Packets received on an untrusted black Transport Network interface and destined for a trusted interface; and
  • Packets received on a trusted interface and destined for an untrusted black Transport Network interface.
    • ]
Application Note: The intent of this requirement is to ensure that the CU mediates and controls the specific packet flows that cross the security boundary between the trusted side of the TOE and the untrusted black transport network side.

The CU is a mapping device that takes internet facing packets and translates them to EU facing packets, and then translates any EU facing packets to internet facing packets. For PFED, the internet facing interface will have to establish connectivity with the black network and locate its peer CU before it can begin sending traffic from its EU to the peer EU.

This requirement is narrower than a complete information flow control claim. It is focused on the subset of CU packet flows that traverse between trusted and untrusted black-side interfaces. The ST author should describe the CU Information Flow Control Policy in TOE-specific terms and should make clear which interfaces are considered trusted and which interfaces are considered untrusted black transport network interfaces in the claimed TOE configuration.

The TSS should also identify the operations that cause these packet flows to occur, such as receipt, forwarding, routing, relaying, transmission, or equivalent TOE-mediated handling of packets between the covered interfaces. The ST author should describe any conditions, checks, or policy decisions the TOE applies to those flows and should do so consistently with any related CU-specific information flow control function requirements elsewhere in the ST.
Evaluation Activities
FDP_IFC.1/CU
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the CU Information Flow Control Policy enforced by the TOE.
  • Identifies the interfaces treated as trusted interfaces in the claimed TOE configuration.
  • Identifies the interfaces treated as untrusted black transport network interfaces in the claimed TOE configuration.
  • Describes the packet flows covered by this requirement, namely:
    • Packets received on an untrusted black transport network interface and destined for a trusted interface; and
    • Packets received on a trusted interface and destined for an untrusted black Transport Network interface.
  • Describes the TOE operations that cause those packet flows to occur, such as receiving, forwarding, routing, relaying, or transmitting packets between the covered interfaces.
  • Describes how the TOE ensures that those covered flows are mediated by the TSF and are subject to the CU Information Flow Control Policy.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FDP_IFC.1/CU:1: Untrusted-black to trusted coverage: The evaluator shall cause a packet to be received on an untrusted black transport network interface and destined for a trusted interface and verify that the packet flow is mediated by the TOE in accordance with the CU Information Flow Control Policy.

  • Test FDP_IFC.1/CU:2: Trusted to untrusted-black coverage: The evaluator shall cause a packet to be received on a trusted interface and destined for an untrusted black transport network interface and verify that the packet flow is mediated by the TOE in accordance with the CU Information Flow Control Policy.

  • Test FDP_IFC.1/CU:3: No bypass of covered flows: For each covered direction, the evaluator shall verify that the packet flow does not bypass TSF mediation and is subject to the TOE handling described in the TSS.

  • Test FDP_IFC.1/CU:4: Interface-role consistency: If the TOE supports multiple claimed interface types or deployment modes, the evaluator shall verify for each claimed case that the trusted/untrusted-black interface roles used for this requirement are consistent with the TSS and guidance.

    • If PFED is implemented by TOE:

  • Test FDP_IFC.1/CU:5: PFED Functional Test: Provision a pair of PFED’s (A1 and B1). Assume EU1 in A1 begins the session setup, so block and capture the first packet of the session setup. This would normally go to an interface associated with the EU that has been established during provisioning (e.g., a protocol (e.g., UDP), a port (e.g., 443) an IP address (e.g., 192.168.0.40), etc.). Modify and send the packet to a different interface on CU of B1. See if there’s a response.

    • These tests may be combined where appropriate. The purpose of this evaluation is to confirm that the covered CU packet flows fall within the scope of TSF-enforced information flow control, not to exhaustively test all attribute-based permit and deny logic that is addressed by the related CU function requirements.

FDP_IFC.1/HWS Subset Information Flow Control

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall enforce [an information flow control policy] on: [
  • User data transmitted between the EU and CU
  • TSF data transmitted between the EU and CU
    • ].
Application Note: The intent of this requirement is to ensure that in the HWS-ERD configuration, the TSF mediates the subset of information flows exchanged across the boundary between the EU and CU. This requirement is narrower than a complete information flow control claim. It is focused specifically on the internal information flows between the physically and logically separated EU and CU components of the HWS-ERD configuration.

All data leaving the EU must be encrypted and all data entering the EU must be decrypted as described in FCS_COP.1/PFEDAES. There must be no cryptographic bypass where clear text flows in either direction.

The ST author should describe the information flow control policy for the EU-to-CU and CU-to-EU path in TOE-specific terms and should clearly identify what the TOE treats as:
  • user data transmitted between the EU and CU; and
  • TSF data transmitted between the EU and CU.
For this requirement, user data should be understood as TOE-mediated data associated with the protected end-user traffic handled across the EU/CU boundary, while TSF data should be understood as security-relevant data exchanged between the EU and CU to support TOE security functions. The TSS should define these terms in the context of the claimed TOE design rather than relying on abstract or unstated assumptions.
Evaluation Activities
FDP_IFC.1/HWS
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the information flow control policy enforced by the TOE for the HWS-ERD EU/CU boundary.
  • Identifies the EU and CU components participating in the covered information flows.
  • Describes the covered flow classes:
    • user data transmitted between the EU and CU; and
    • TSF data transmitted between the EU and CU.
  • Defines what the TOE treats as user data and TSF data for purposes of this requirement.
  • Describes the TOE operations that cause those flows to occur, such as transfer, forwarding, relaying, signaling, or other exchange between the EU and CU.
  • Describes how the TOE ensures that those covered flows are mediated by the TSF and are subject to the identified information flow control policy.
  • Describes any distinctions among supported HWS-ERD modes, channels, or EU/CU interfaces relevant to this requirement.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FDP_IFC.1/PFED Information Flow Control

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall ensure all EUD traffic flows exclusively within an AES-GCM-256 protected session tunnel and is blocked until authentication and rekey complete.
Application Note: The intent of this requirement is to ensure that for the PFED configuration, all EUD traffic is constrained to the TOE’s protected PFED session tunnel and is not permitted to flow until the TOE has completed the prerequisites for a secure operational session. For this requirement, the TSF shall ensure that all EUD traffic flows exclusively within an AES-GCM-256 protected session tunnel and is blocked until authentication and rekey complete.

“Flows exclusively within an AES-GCM-256 protected session tunnel” means that the TOE does not permit EUD traffic to traverse the PFED path outside the protected session tunnel. The TSS should describe the protected session tunnel in TOE-specific terms and should identify the interfaces, paths, or processing stages by which EUD traffic enters, is protected within, and exits the PFED data path.

“Blocked until authentication and rekey complete” means that the TOE suppresses or prevents EUD traffic until the TOE has completed the required PFED session establishment steps, including authentication and the rekey condition required by the TOE’s PFED design.
Evaluation Activities
FDP_IFC.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED information flow control policy enforced for EUD traffic.
  • Describes the protected PFED session tunnel used for EUD traffic.
  • States that the protected PFED session tunnel uses AES-GCM-256.
  • Describes how the TOE ensures that all EUD traffic flows exclusively within that protected session tunnel.
  • Describes how the TOE blocks EUD traffic prior to successful completion of the required security-establishment steps.
  • Defines what constitutes completion of authentication for purposes of permitting EUD traffic.
  • Defines what constitutes completion of the required rekey event for purposes of permitting EUD traffic.
  • Identifies the event or state transition that causes the TOE to begin permitting EUD traffic.
  • Describes TOE behavior when authentication does not complete successfully.
  • Describes TOE behavior when the required rekey does not complete successfully.
    • The evaluator shall determine that the TSS is consistent with the posted PFED requirement text and the PFED appendix description that EUD traffic is confined to the protected session tunnel, that the tunnel uses AES-GCM-256, and that EUD traffic remains blocked until secure session establishment conditions are satisfied.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FDP_IFC.1/PFED:1: EUD traffic blocked before session readiness: The evaluator shall place the TOE in a PFED pre-operational state and verify that EUD traffic is blocked before authentication and the required rekey complete.

  • Test FDP_IFC.1/PFED:2: EUD traffic released only after authentication and rekey complete: The evaluator shall complete the claimed PFED authentication and required rekey steps and verify that the TOE permits EUD traffic only after those conditions have been satisfied.

  • Test FDP_IFC.1/PFED:3: EUD traffic confined to protected tunnel: The evaluator shall cause EUD traffic to flow through the TOE after secure session readiness is achieved and verify that the traffic is carried within the claimed AES-GCM-256 protected session tunnel, consistent with the TSS and guidance.

  • Test FDP_IFC.1/PFED:4: Failure handling: The evaluator shall attempt operation with unsuccessful or incomplete authentication, and separately with unsuccessful or incomplete required rekey, and verify that the TOE continues to block EUD traffic in each case.

  • Test FDP_IFC.1/PFED:5: No bypass of protected-session requirement: The evaluator shall verify that EUD traffic cannot bypass the PFED protected session tunnel and be forwarded outside the claimed AES-GCM-256 protected session path.

These tests may be combined where appropriate. The purpose of this evaluation is to confirm that PFED EUD traffic is both tunnel-constrained and blocked until the required session-protection prerequisites are complete.

FDP_IFF.1/CU Simple Security Attributes

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall enforce the [CU Information Flow Control Policy] based on the following types subject and information security attributes: [
  • Subject Security Attributes
    • Ingress interface identifier
    • Egress interface identifier
  • Information Security Attributes
    • Source IP address
    • Destination IP address
    • IP protocol type
    • Source transport-layer port (if applicable)
    • Destination transport-layer port (if applicable)
    • ].
The TSF shall permit information flow between the Untrusted Interface and the Trusted Interface via a controlled operation if the following rules hold: [assignment: for each operation, the security attribute-based relationship that hold between subject and information security attributes].
The TSF shall deny an information flow between an untrusted black Transport Network interface and a trusted interface if the packet does not match an explicitly configured allow rule.
The TSF shall ensure that all information flows between untrusted interfaces and are mediated by the TSF and are subject to the CU INformation Flow Control Policy.
Application Note: The intent of this requirement is to ensure that the CU enforces its information flow control policy by making permit and deny decisions using specific subject and information security attributes for packet flows between the trusted side of the TOE and the untrusted black transport network side. This requirement is the CU-specific decision function companion to the CU subset information flow control requirement. It identifies the attributes used in policy decisions, requires explicit permit logic, requires deny behavior for packets that do not match an allow rule, and requires TSF mediation of all covered flows. The ST author should identify the CU Information Flow Control Policy and use the listed subject and information security attributes as the basis for policy decisions.

For PFED implementations, the link between the EU and the CU is a stateless link between two non-addressable passive interfaces. The payload from an outgoing EU to CU frame persists and the payload from an incoming CU to EU frame persists after the immediate processing of that frame. The CU can act as a secondary firewall to enforce the egress of specific EU frame types.
Evaluation Activities
FDP_IFF.1/CU
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the CU Information Flow Control Policy enforced by the TOE.
  • Identifies the CU packet flows to which the policy applies, consistent with the covered trusted interface and untrusted black transport network interface flows.
  • Identifies the subject security attributes used by the TOE for CU information flow decisions:
    • Ingress interface identifier
    • Egress interface identifier
  • Identifies the information security attributes the TOE uses for CU information flow decisions:
    • Source IP address
    • Destination IP address
    • IP protocol type
    • Source transport-layer port, if applicable
    • Destination transport-layer port, if applicable
  • Describes how the TOE obtains or evaluates those attributes for each covered packet flow.
  • Describes the controlled operations for which permit decisions are made under FDP_IFF.1.2/CU.
  • Describes the attribute-based relationships that must hold for the TOE to permit information flow between the untrusted interface and the trusted interface.
  • Describes the deny behavior required by FDP_IFF.1.3/CU, including that packets received on an untrusted black transport network interface and destined for a trusted interface are denied if they do not match an explicitly configured allow rule.
  • Describes how the TOE ensures that all covered information flows are mediated by the TSF and subject to the CU Information Flow Control Policy, consistent with FDP_IFF.1.4/CU.
  • Describes any differences in handling among supported CU interfaces, deployment modes, or packet-processing paths relevant to this requirement.
The evaluator shall determine that the TSS is consistent with the posted CU-specific component text and that the CU decision function is based on the listed interface and packet attributes, uses explicit allow-rule matching for the claimed permit behavior, and prevents bypass of TSF mediation for covered flows.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how an administrator identifies or configures the trusted and untrusted CU interfaces, if configurable.
  • Describes how an administrator configures explicitly allowed packet flows using the claimed CU attributes.
  • Describes how an administrator can determine whether a packet flow should be permitted or denied based on the configured CU policy.
  • Describes any direction-specific behavior for traffic flowing from trusted to untrusted or from untrusted to trusted interfaces.
    • `
  • Describes any audit records associated with permitted flows, denied flows, or CU policy decisions, if such records are generated by the TOE.
  • Describes any policy-management behavior relevant to maintaining the explicitly configured allow rules.
Tests
The evaluator shall perform the following tests.
  • Test FDP_IFF.1/CU:1: Permit rule enforcement: The evaluator shall configure one or more explicit allow rules using the claimed CU policy attributes and generate packets whose ingress interface, egress interface, source address, destination address, protocol, and ports, if applicable, satisfy those rules. The evaluator shall verify that the TOE permits the information flow between the untrusted interface and the trusted interface only when the claimed attribute relationships hold.

  • Test FDP_IFF.1/CU:2: Deny on no allow-rule match: The evaluator shall generate packets received on an untrusted black transport network interface and destined for a trusted interface that do not match any explicitly configured allow rule. The evaluator shall verify that the TOE denies the information flow, as required by FDP_IFF.1.3/CU.

  • Test FDP_IFF.1/CU:3: Attribute variation: For one or more representative allow rules, the evaluator shall vary one or more attributes while keeping the others constant, such as ingress interface, destination address, protocol, or transport-layer port, and verify that the TOE’s permit or deny decision changes only in accordance with the configured policy.

  • Test FDP_IFF.1/CU:4: TSF mediation of covered flows: The evaluator shall verify, for both covered directions as applicable to the TOE design, that packet flows between the trusted and untrusted black-side interfaces are mediated by the TSF and are subject to the CU Information Flow Control Policy rather than bypassing policy enforcement.

  • Test FDP_IFF.1/CU:5: Directional policy behavior: If the TOE claims differing permit logic for the two flow directions, the evaluator shall test representative cases in each direction and verify that the TOE behavior matches the TSS and guidance.

These tests may be combined where appropriate. The purpose of this evaluation is to confirm that the CU uses the listed subject and information attributes to enforce explicit permit and deny logic on the covered packet flows.

FDP_IFF.1/HWS Simple Security Attributes

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall enforce [the information flow control policy] based on the following types of subject and information security attributes: [
  • The source domain (EU or CU)
  • The destination domain (EU or CU)
  • The communication interface (dedicated wired interface)
    • ].
The TSF shall permit an information flow between subjects only if all of the following rules are satisfied: [
  • Information exchange between the EU and CU occurs exclusively over the dedicated wired interface.
  • No logical or physical shared memory exists between the EU and CU.
  • The EU and CU execute on independent processors.
  • The EU and CU access only their own dedicated memory resources.
  • No alternate communication path exists between the EU and CU.
].
The TSF shall enforce the following additional information flow control rules: [None].
The TSF shall explicitly deny an information flow based on the following rules: [Any information flow not explicitly permitted in FDP_IFF.1.2].
Application Note: The intent of this requirement is to ensure that in the HWS-ERD configuration, the TSF enforces a narrowly defined information flow control policy on communications between the EU and CU using domain- and path-based attributes. This requirement is about the HWS architectural information flow function between the EU and CU. It is narrower than a general packet-policy rule set and should be read as enforcing domain separation and a single permitted communications path in the HWS-ERD design.
Evaluation Activities
FDP_IFF.1/HWS
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the information flow control policy enforced for the HWS-ERD EU/CU boundary.
  • Identifies the subject and information security attributes used by the TOE for this requirement:
    • source domain,
    • destination domain, and
    • communication interface.
  • Describes the dedicated wired interface used for permitted communication between the EU and CU.
  • Describes how the TOE ensures that information exchange between the EU and CU occurs exclusively over that dedicated wired interface.
  • Describes how the TOE ensures that no logical or physical shared memory exists between the EU and CU.
  • Describes how the TOE ensures that the EU and CU execute on independent processors.
  • Describes how the TOE ensures that the EU and CU access only their own dedicated memory resources.
  • Describes how the TOE ensures that no alternate communication path exists between the EU and CU.
  • States that no additional information flow control rules are claimed under FDP_IFF.1.3/HWS.
  • Describes how the TOE explicitly denies any information flow not permitted by the conditions in FDP_IFF.1.2/HWS.
The evaluator shall determine that the TSS is consistent with the HWS-ERD design described by the PP, which requires physical and logical separation between the EU and CU components.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FDP_IFF.1/HWS:1: Dedicated wired interface exclusivity: The evaluator shall verify that communication between the EU and CU occurs only over the dedicated wired interface identified in the TSS and that no other interface is permitted for that information flow.

  • Test FDP_IFF.1/HWS:2: No shared memory path: The evaluator shall verify, through examination of TOE behavior, configuration, supported test interfaces, or developer evidence, that the EU and CU do not communicate through logical or physical shared memory.

  • Test FDP_IFF.1/HWS:3: Independent processor execution: The evaluator shall verify, through examination of TOE behavior, configuration, supported test interfaces, or developer evidence, that the EU and CU execute on independent processors as claimed in the TSS.

  • Test FDP_IFF.1/HWS:4: Dedicated memory-resource access: The evaluator shall verify, through examination of TOE behavior, configuration, supported test interfaces, or developer evidence, that the EU and CU access only their own dedicated memory resources.

  • Test FDP_IFF.1/HWS:5: No alternate communication path: The evaluator shall verify that no alternate communication path exists between the EU and CU beyond the dedicated wired interface claimed in the TSS.

  • Test FDP_IFF.1/HWS:6: Deny behavior: The evaluator shall verify that any attempted information flow between the EU and CU that does not satisfy all of the conditions in FDP_IFF.1.2/HWS is denied by the TOE.

These tests may be combined where appropriate. The purpose of this evaluation is to confirm that the HWS design enforces the claimed allowlist architecture for EU/CU communication and denies all other information flows.

FDP_IFF.1/PFED Simple Security Attributes

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall enforce packet filtering such that:
  • Only a single expected packet type is accepted at fixed offsets
  • All malformed, unexpected, or out-of-context packets are dropped pre-stack
  • The EU does not respond to invalid packets from the CU or EUD
.
Application Note: The intent of this requirement is to ensure that the PFED TOE enforces a narrowly constrained packet acceptance model on the EU-facing path, such that only the one expected packet form is accepted, and all other traffic is rejected before it can reach normal protocol processing.

For this requirement, “Only a single expected packet type is accepted at fixed offsets” means the TOE uses a narrowly defined packet-format expectation for the relevant interface path and does not admit alternate packet structures, alternate packet signatures, or packets whose relevant identifying fields are not located at the required offsets.

“All malformed, unexpected, or out-of-context packets are dropped pre-stack” means the TOE rejects malformed, unexpected, or out-of-context packets before those packets reach the EU protocol stack or equivalent higher-layer packet processing path.

“The EU does not respond to invalid packets from the CU or EUD” means the TOE does not emit a protocol, error, or other functional response when presented with invalid input on the covered path.

The EU in principle acts as a non-configurable firewall to the CU with an allowlist of one. The EU interface to the EUD does not process the contents of the payload of any packet when the crypto is active. It forwards everything.
Evaluation Activities
FDP_IFF.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the interface, interfaces, or TOE processing path to which this PFED packet-filtering behavior applies.
  • Describes the single expected packet type accepted by the TOE.
  • Describes the fixed offsets or equivalent fixed-position parsing constraints used to recognize that expected packet type.
  • Describes how the TOE distinguishes malformed, unexpected, or out-of-context packets from the expected packet type.
  • Describes where in the TOE processing path invalid packets are dropped and shows that this occurs prior to the EU protocol stack or equivalent higher-layer packet processing.
  • Describes how the TOE ensures that the EU does not respond to invalid packets received from the CU or EUD.
  • Describes any distinctions among covered PFED interfaces or modes, if more than one is claimed.
The evaluator shall determine that the TSS is consistent with the posted PFED component text and Appendix H, including single expected fixed-offset packet acceptance, pre-stack dropping of malformed or unexpected packets, and non-response by the EU to invalid packets from the CU or EUD.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FDP_IFF.1/PFED:1: Acceptance of only the expected packet type: The evaluator shall present the TOE with a packet matching the claimed expected packet type at the claimed fixed offsets and verify that the TOE accepts that packet for the intended PFED processing path.

  • Test FDP_IFF.1/PFED:2: Rejection of malformed, unexpected, or out-of-context packets: The evaluator shall present malformed packets, unexpected packet types, and out-of-context packets on the covered interface or path and verify that the TOE drops them.

  • Test FDP_IFF.1/PFED:3: Pre-stack rejection behavior: The evaluator shall verify, through TOE behavior, supported test interfaces, traces, or developer evidence that rejected packets are dropped prior to reaching the EU protocol stack or equivalent higher-layer packet processing path.

  • Test FDP_IFF.1/PFED:4: Non-response to invalid packets: The evaluator shall present invalid packets from the CU and the EUD, as applicable to the TOE design, and verify that the EU does not respond to those invalid packets.

  • Test FDP_IFF.1/PFED:5: Fixed-offset enforcement: The evaluator shall vary the location of the expected identifying packet fields or signature away from the claimed fixed offsets and verify that the TOE rejects the packet.

  • Test FDP_IFF.1/PFED:6: PFED Functional Test: Provision a pair of PFED’s (A1 and B1). Attach EUD’s A and B to A1 and B1 respectively and set their interfaces to promiscuous mode and non-addressable. A is the sender and B is the receiver. Attach a network sniffer to the interconnect between the EUD’s and the EU (S1 and S2). From A, send an exhaustive span of packets and watch both S1 and S2. There should be no response on S1 and everything that was received by A1 should appear on S2 and B.

These tests may be combined where appropriate. The purpose of this evaluation is to confirm that the PFED path implements the claimed one-expected-packet allowlist model, fail-closed discard before protocol-stack handling, and non-response to invalid CU/EUD input.

FDP_PBR_EXT.1 Layer-2 Protocol Break

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall ensure that all traffic forwarded between an untrusted black Transport Network interface and a trusted interface undergoes a Layer-2 protocol break.
The TSF shall perform a Layer-2 protocol break when forwarding traffic that is not protected by Ethernet-layer cryptographic mechanisms across a trust boundary by:
  • Removing the complete incoming Layer-2 header and associated Layer-2 control information (decapsulation); and
  • Constructing and applying a new Layer-2 header (encapsulation) prior to transmission on the egress interface
The TSF shall prevent transparent Layer-2 bridging between untrusted black Transport Network interfaces and trusted interfaces.
The TSF shall forward Ethernet frames that contain cryptographic protections applied by a trusted component without:
  • Removing, modifying, or replacing the protected Layer-2 header
  • Terminating, decrypting, inspecting, or re-origination cryptographic protection
  • Disrupting cryptographic continuity across the trust boundary.
The TSF shall not act as a cryptographic endpoint for user data traffic and shall not terminate, decrypt, or re-originate cryptographic protection for traffic transmitted between trusted components and untrusted black transport networks.
Application Note: A Layer-2 protocol break is the stripping (decapsulation) and replacement (encapsulation) of Layer-2 headers when forwarding traffic between interfaces, preventing transparent bridging across trust boundaries. The ST author describes how protocol break is implemented.

The intent of this requirement is to ensure that the CU does not behave as a transparent Layer-2 bridge when forwarding traffic between trusted interfaces and untrusted black transport network interfaces. For traffic that is not protected by Ethernet-layer cryptographic mechanisms, the TOE must perform a Layer-2 protocol break by removing the incoming Layer-2 header and associated control information and constructing a new Layer-2 header for the egress interface.

FDP_PBR_EXT.1.1 and FDP_PBR_EXT.1.2 should therefore be read together. The first establishes the policy that all forwarded traffic across the relevant trust boundary undergoes a Layer-2 protocol break. The second explains what that means operationally for traffic that is not already protected at Ethernet layer: Full Layer-2 decapsulation of the incoming header and control information, followed by fresh Layer-2 encapsulation for transmission on the egress interface. The TSS should identify the relevant interfaces and describe the forwarding path in TOE-specific terms.

FDP_PBR_EXT.1.3 makes the transparent-bridging prohibition explicit. The TOE is not allowed to simply relay Layer-2 frames unchanged between trusted and untrusted black-side interfaces. Instead, forwarding across the trust boundary must either use the required protocol-break behavior for unprotected traffic or preserve the protected frame as required by FDP_PBR_EXT.1.4 and FDP_PBR_EXT.1.5.
Evaluation Activities
FDP_PBR_EXT.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the trusted interfaces and untrusted black Transport Network interfaces relevant to this component.
  • Describes the traffic-forwarding paths that cross that trust boundary.
  • Describes how the TOE ensures that all forwarded traffic between those interface classes undergoes a Layer-2 protocol break, except where the traffic is already protected at Ethernet layer and is handled under the continuity-preserving rules in FDP_PBR_EXT.1.4 and FDP_PBR_EXT.1.5.
  • Describes the protocol-break operation for traffic not protected by Ethernet-layer cryptographic mechanisms, including:
    • removal of the complete incoming Layer-2 header and associated Layer-2 control information, and
    • construction and application of a new Layer-2 header prior to transmission on the egress interface.
  • Describes how the TOE prevents transparent Layer-2 bridging between untrusted black Transport Network interfaces and trusted interfaces.
  • Describes the traffic to which FDP_PBR_EXT.1.4 applies, namely Ethernet frames that already contain cryptographic protection applied by a trusted component.
  • Describes how the TOE forwards such protected Ethernet frames without removing, modifying, or replacing the protected Layer-2 header.
  • Describes how the TOE ensures it does not terminate, decrypt, inspect as a cryptographic endpoint, or re-originate cryptographic protection for that protected user data traffic.
  • Describes how the TOE ensures that it is not a cryptographic endpoint for the user data traffic covered by FDP_PBR_EXT.1.5.
  • Distinguishes clearly between the forwarding treatment for unprotected traffic and the forwarding treatment for already Ethernet-protected traffic.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FDP_PBR_EXT.1:1: Layer-2 protocol break for unprotected traffic: The evaluator shall cause the TOE to forward traffic that is not protected by Ethernet-layer cryptographic mechanisms between an untrusted black transport network interface and a trusted interface and verify that the TOE performs a Layer-2 protocol break. The evaluator shall verify that the incoming Layer-2 header and associated Layer-2 control information are removed and that a new Layer-2 header is applied before transmission on the egress interface.

  • Test FDP_PBR_EXT.1:2: No transparent Layer-2 bridging: The evaluator shall verify that the TOE does not transparently bridge unprotected traffic between trusted and untrusted black-side interfaces without the required protocol break. This may be combined with Test 1 if the observed behavior is sufficient to show that unchanged Layer-2 forwarding is not performed.

  • Test FDP_PBR_EXT.1:3: Forwarding of already protected Ethernet traffic: The evaluator shall cause the TOE to forward Ethernet frames that contain cryptographic protection applied by a trusted component and verify that the TOE forwards them without removing, modifying, or replacing the protected Layer-2 header.

  • Test FDP_PBR_EXT.1:4: No cryptographic termination or re-origination for protected traffic: For the same protected Ethernet traffic, the evaluator shall verify that the TOE does not terminate, decrypt, inspect as a cryptographic endpoint, or re-originate the cryptographic protection, and that the TOE does not act as the cryptographic endpoint for the covered user data traffic.

  • Test FDP_PBR_EXT.1:5: Treatment distinction: The evaluator shall verify that the TOE distinguishes correctly between traffic that requires a Layer-2 protocol break and Ethernet traffic that already contains trusted-component-applied cryptographic protection. The TOE shall not apply protocol-break behavior to the already protected traffic in a way that would violate FDP_PBR_EXT.1.4 or FDP_PBR_EXT.1.5.

Where direct observation of low-level forwarding behavior is not practical, the evaluator may rely on observable TOE behavior, packet traces, supported test interfaces, or developer evidence sufficient to determine that the claimed forwarding treatment is applied.

A.3.4 Class FIA: Identification and Authentication

FIA_AFL.1/PFED Authentication Failure Handling

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall enforce client and server personas such that:
  • A client persona initiates session setup
  • A server persona waits for session setup initiation.
Application Note: The intent of this requirement is to ensure that the TOE enforces a fixed PFED session-establishment role model so that each EU operates only according to its assigned persona during session bring-up and recovery. For every pair of PFED, each EU is assigned either client or server role. There is no valid pair where both ends are client or both ends are server. The role is established at provisioning and does not change for the lifetime of the cryptographic association.

For this requirement, “A client persona initiates session setup” means the client persona is the side that starts the PFED session-establishment transaction.

“A server persona waits for session setup initiation” means the server persona does not begin the session-establishment exchange on its own but instead waits for the client persona to initiate it.
Evaluation Activities
FIA_AFL.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED persona roles enforced by the TOE.
  • Describes the behavior of the client persona, including that it initiates session setup.
  • Describes the behavior of the server persona, including that it waits for session setup initiation.
  • Describes how the TOE determines, assigns, stores, or enforces the active persona for an EU.
  • Describes the PFED session-setup states or transitions relevant to persona enforcement.
  • Describes whether persona enforcement also applies after dead-peer detection, session reset, or session recovery, if applicable.
  • Describes how the TOE prevents a server persona from initiating session setup and how it prevents a client persona from behaving contrary to its assigned role.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how the TOE is configured, provisioned, or deployed with the appropriate PFED persona.
  • Describes any administrator-visible indication of the configured or active persona, if such indication is provided by the TOE.
Tests
The evaluator shall perform the following tests.
  • Test FIA_AFL.1/PFED:1: Client persona initiates session setup: The evaluator shall configure or place the TOE in a client persona role and verify that the TOE initiates session setup in accordance with the TSS and guidance.

  • Test FIA_AFL.1/PFED:2: Server persona waits for initiation: The evaluator shall configure or place the TOE in a server persona role and verify that the TOE waits for session setup initiation and does not initiate session setup on its own.

  • Test FIA_AFL.1/PFED:3: Persona enforcement after session reset or dead-peer event: If the TOE claims persona enforcement after dead-peer detection or session reset, the evaluator shall cause such a condition and verify that the TOE continues to enforce the assigned persona behavior during the resulting session setup state.

FIA_PSK_EXT.1/PFED PSK Bootstrap Authentication

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall support a PSK exclusively for tunnel-0 bootstrap.
Application Note: The intent of this requirement is to ensure that any pre-shared key used by the TOE in the PFED design is constrained to the temporary bootstrap phase only and is not used as a general-purpose or long-lived session authentication mechanism.

For this requirement, the TOE shall support a PSK exclusively for tunnel-0 bootstrap. This is consistent with Appendix H.3.1, which states that initial bonding is performed during provisioning using a temporary secure tunnel, tunnel-0, established using a PSK, and with Appendix H.3.2, which states that after successful ML-KEM-1024 completion, tunnel-0 is terminated and the PSK is cryptographically destroyed.

This PSK can be referred to as PSK0. It is required simply to allow communication to exist between the EUs. As described elsewhere in the document, once the EU pair completes provisioning it is destroyed. It is only needed to complete the authenticated key exchange that occurs inside tunnel-0.

Evaluation Activities
FIA_PSK_EXT.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED use of the PSK for tunnel-0 bootstrap.
  • Describes the tunnel-0 bootstrap phase in which the PSK is used.
  • Describes how the TOE ensures that the PSK is used exclusively for tunnel-0 bootstrap.
  • Describes how the PSK is provisioned, including whether it is:
    • injected during manufacturing,
    • entered through a trusted EU entry interface,
    • or both, if supported by the TOE.
  • Describes how the TOE transitions away from PSK-based bootstrap.
  • Describes how the TOE ensures that the PSK is not used for post-bootstrap operational PFED sessions.
  • Describes the event that ends PSK usage and the TOE behavior associated with that transition.
The evaluator shall determine that the TSS is consistent with the PFED appendix, which states that tunnel-0 uses a PSK for initial bonding and that, after successful ML-KEM-1024 completion, tunnel-0 is terminated and the PSK is cryptographically destroyed.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how the PSK is provisioned for tunnel-0 bootstrap.
  • Describes any administrator or system-owner actions needed to establish tunnel-0 using the PSK.
  • Describes any prerequisites for bootstrap completion and transition away from PSK use.
  • Describes any administrator-visible indications, status, or logs associated with PSK-based bootstrap, if such visibility is provided by the TOE.
  • Describes that the PSK is only for tunnel-0 bootstrap and not for continued operational use after bootstrap.
Tests
The evaluator shall perform the following tests.
  • Test FIA_PSK_EXT.1/PFED:1: PSK use for tunnel-0 bootstrap: The evaluator shall configure or provision the TOE for PFED bootstrap and verify that the TOE supports use of the PSK to establish tunnel-0 for the bootstrap phase. This aligns with Appendix H.3.1.

  • Test FIA_PSK_EXT.1/PFED:2: Exclusive bootstrap use: The evaluator shall verify that the TOE does not rely on the PSK to satisfy post-bootstrap session establishment or ordinary operational PFED session use. The TOE shall use the PSK only for tunnel-0 bootstrap, consistent with the TSS and guidance.

  • Test FIA_PSK_EXT.1/PFED:3: Transition away from PSK use: The evaluator shall cause the TOE to complete the post-bootstrap transition described in the TSS and verify behavior consistent with Appendix H.3.2, namely that tunnel-0 is terminated and PSK use ends after successful ML-KEM-1024 completion.

    • Where direct observation of low-level PSK lifecycle behavior is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, traces, or developer evidence sufficient to determine that PSK support is limited to the tunnel-0 bootstrap role.

FIA_UAU.2/PFED Mutual Authentication Before Any Action

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall enforce mutual authentication between EU peers using ML-DSA-87 prior to permitting EUD traffic.
Application Note: The intent of this requirement is to ensure that the TOE does not permit protected PFED end-user traffic until the EU peers have successfully authenticated one another using the PFED-defined mutual-authentication mechanism. For this requirement, the TOE shall enforce mutual authentication between EU peers using ML-DSA-87 prior to permitting EUD traffic.

Because EU’s cryptographically bond at provisioning, this creates a unique security association between each EU and continuous mutual authentication after provisioning is not absolutely required. An initial PSK can serve as PSK0 and act as authentication when:
  • It is unique to the EU pair
  • It is delivered to each EU over a trusted path.
If the EU pair provisions over an untrusted channel, then mutual authentication by ML-DSA is required. This is analogous to the difference between a factory provision, where both ends of a pair are known and get provisioned in a trusted facility, and a field provision where the path between EU’s can be influenced by an adversary in the middle. It is safest, but redundant, to mutually authenticate the key exchange when any EU-to-EU session is established after the pair has been provisioned with mutual authentication. For ML-DSA-based authentication this SFR implies that each EU must have an ML-DSA-87 key pair serving only as an identity and a method to publish the public part of that ID key pair. There also must be a way to import the public of a peer EU ID key before mutual authentication occurs with that peer EU.
Evaluation Activities
FIA_UAU.2/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the PFED session setup process relevant to this requirement.
  • Identifies the EU peers that participate in the mutual-authentication exchange.
  • States that the TOE enforces mutual authentication between EU peers using ML-DSA-87.
  • Describes how ML-DSA-87 is used in the TOE’s mutual-authentication process.
  • Describes what constitutes successful completion of mutual authentication.
  • Describes how the TOE prevents EUD traffic from being permitted prior to successful completion of mutual authentication.
  • Describes TOE behavior when mutual authentication fails or does not complete.
  • If applicable, describes how this authentication step relates to other required session-setup steps, including the mandatory PFED rekey, while still making clear that this requirement specifically addresses the authentication portion.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
  • Test FIA_UAU.2/PFED:1: Successful mutual authentication before EUD traffic: The evaluator shall cause the TOE to perform PFED session setup and verify that the TOE completes mutual authentication between EU peers using ML-DSA-87 before permitting EUD traffic. This test shall confirm that EUD traffic is not released prior to successful completion of the authentication step.

  • Test FIA_UAU.2/PFED:2: Authentication failure blocks EUD traffic: The evaluator shall cause the mutual-authentication step to fail or remain incomplete and verify that the TOE does not permit EUD traffic.

  • Test FIA_UAU.2/PFED:3: Mutual, not unilateral, authentication: The evaluator shall verify that the TOE requires successful authentication of both EU peers and does not treat one-way or partial authentication success as sufficient to permit EUD traffic.

  • Test FIA_UAU.2/PFED:4: ML-DSA-87 use in the authentication step: The evaluator shall verify, through TOE behavior, supported test interfaces, traces, metadata, or developer evidence, that the TOE uses ML-DSA-87 for the PFED mutual-authentication step claimed under this requirement.

  • Test FIA_UAU.2/PFED:5: PFED Functional Test: Use a pair of unprovisioned PFEDS A1 and B1. Import B1’s public ID (P-IDB1) into A1 and import A1’s public (P-IDA1) into B1. Then attempt to provision. This should succeed. Reset A1 and B1 to an unprovisioned state. Import B1’s public ID (P-IDB1) into A1 and generate and import a random public (P-IDR) into B1. Then attempt to provision. This should fail.

    Similarly, for PSK, use a pair of unprovisioned PFEDS A1 and B1 and install PSK0 P1 in both. Then attempt to provision. This should succeed. Reset A1 and B1 to an unprovisioned state and install P1 in A1 and PSK0 P2 in B1. Then attempt to provision. This should fail.

Where direct observation of low-level authentication processing is not practical, the evaluator may rely on observable TOE behavior, protocol traces, supported test interfaces, or developer evidence sufficient to determine that the claimed authentication mechanism and traffic-gating behavior are implemented.

FIA_UAU.3/PFED Multiple Authentication Mechanisms

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall support the following authentication mechanisms:
  • Cryptographic mutual authentication using ML-DSA-87
    • and [selection: user activation using [assignment: password, PIN, or CIK], no other mechanism]
Application Note: The intent of this requirement is to ensure that the TOE supports a PFED authentication model consisting of both a cryptographic peer-authentication mechanism and, where claimed, an additional user-activation mechanism. If the ST author selects user activation using password, PIN, or CIK, the TSS should identify exactly which of those activation mechanisms is supported by the TOE. The TSS should also describe when that mechanism is used in the PFED lifecycle and how it relates to session bring-up or protected operation.

Mutual authentication using the ML-DSA key pair only authenticates an EU-to-EU association. This does not authenticate the user in possession of the EU. A user supplied credential can be combined with the ML-DSA-87 mutual authentication or supplied in establishing any subsequent session after an ML-DSA-87 mutual authentication has happened at least once.
Evaluation Activities
FIA_UAU.3/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED authentication mechanisms supported by the TOE under this requirement.
  • States that the TOE supports cryptographic mutual authentication using ML-DSA-87.
  • If an additional user-activation mechanism is claimed, identifies whether that mechanism is:
    • a password,
    • PIN,
    • CIK, or
    • more than one of those, if the ST author instantiates the assignment accordingly.
  • If no other mechanism is selected, states that no additional authentication mechanism is claimed under this requirement.
  • Describes the PFED role or phase in which the ML-DSA-87 mutual-authentication mechanism is used.
  • If an additional user-activation mechanism is claimed, describes the PFED role or phase in which that mechanism is used.
  • Describes how the TOE distinguishes the cryptographic mutual-authentication mechanism from the user-activation mechanism, if both are claimed.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes any administrator-visible prerequisites for the PFED mutual-authentication mechanism.
  • If an additional user-activation mechanism is claimed, describes how that mechanism is provisioned, entered, or activated.
  • Describes any administrator-visible indication of successful or failed use of the claimed PFED authentication mechanisms, if such indication is provided by the TOE.
Tests
The evaluator shall perform the following tests.
  • Test FIA_UAU.3/PFED:1: ML-DSA-87 mutual-authentication mechanism supported: The evaluator shall invoke or otherwise cause the TOE to perform the claimed PFED mutual-authentication function and verify that the TOE supports cryptographic mutual authentication using ML-DSA-87, consistent with the TSS and guidance. This aligns with the posted PFED appendix session-setup section.

  • Test FIA_UAU.3/PFED:2: Test 2: Additional user-activation mechanism supported: If the TOE claims an additional user-activation mechanism, the evaluator shall verify that the TOE supports the selected mechanism, namely password, PIN, or CIK, consistent with the TSS and guidance. This aligns with the posted PFED bring-up and multi-factor activation section.

  • Test FIA_UAU.3/PFED:3: No unclaimed additional mechanism relied upon: If the ST selects no other mechanism, the evaluator shall verify that the TOE does not rely on an additional claimed user-activation mechanism to satisfy this SFR.

  • Test FIA_UAU.3/PFED:4: Claimed mechanism set consistency: If both the cryptographic mutual-authentication mechanism and a user-activation mechanism are claimed, the evaluator shall verify that the TOE supports both mechanisms in the PFED roles or phases described in the TSS.

  • Test FIA_UAU.3/PFED:5: PFED Functional Test: Provision a pair of PFEDS A1 and B1. This will also create the credential needed by the user to authenticate. Attempt to use the authentication method (password, PIN, CIK, etc) to complete a session. This should succeed. Then attempt to use an incorrect value (password, PIN, CIK, etc). This should fail.

Where direct observation of low-level authentication processing is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, traces, or developer evidence sufficient to determine that the claimed mechanism set is implemented.

A.3.5 Class FMT: Security Management

FMT_SMF.1/PFED Specification of Management Functions

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall be capable of performing the following management functions:
  • Provisioning
  • Session setup
  • Rekey configuration
  • Log management
.
Application Note: The intent of this requirement is to ensure that the TOE provides the management capabilities necessary to control the PFED operational lifecycle.

These functions are the minimum. Rekey configuration can be a pre-configured periodicity, or a user entered periodicity at time of provisioning. Log management for EU consists of simply logging to a system log. Retrieving logs from the EU is not intended to occur with an active EU. The EU log serves mainly as a forensic audit tool. Logs from the CU can be extracted while the PFED is active.
Evaluation Activities
FMT_SMF.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED management functions provided by the TOE under this requirement.
  • Describes how the TOE performs provisioning management.
  • Describes how the TOE performs session setup management.
  • Describes how the TOE performs rekey configuration management.
  • Describes how the TOE performs log management.
  • Identifies the interfaces, roles, or mechanisms through which each of the claimed PFED management functions is performed.
  • If the TOE distributes these management functions across multiple components, identifies which TOE component performs each function.
The evaluator shall determine that the TSS is consistent with the posted PFED appendix structure, which includes provisioning, session setup, rekey operations and scheduling, and logging/audit as distinct PFED lifecycle areas.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how an administrator or other authorized entity performs provisioning.
  • Describes how an administrator or other authorized entity performs or controls session setup, where such control is exposed by the TOE.
  • Describes how an administrator configures or manages rekey behavior.
  • Describes how an administrator performs log management.
  • Describes any restrictions, prerequisites, or operational assumptions relevant to these PFED management functions.
Tests
The evaluator shall perform the following tests.
  • Test FMT_SMF.1/PFED:1: Test 1: Provisioning management capability: The evaluator shall verify that the TOE provides the claimed capability to perform PFED provisioning management in accordance with the TSS and guidance.

  • Test FMT_SMF.1/PFED:2: Session setup management capability: The evaluator shall verify that the TOE provides the claimed capability to perform or control PFED session setup in accordance with the TSS and guidance.

  • Test FMT_SMF.1/PFED:3: Rekey configuration management capability: The evaluator shall verify that the TOE provides the claimed capability to configure or manage PFED rekey behavior in accordance with the TSS and guidance.

  • Test FMT_SMF.1/PFED:4: Log management capability: The evaluator shall verify that the TOE provides the claimed capability to manage PFED logs or audit records in accordance with the TSS and guidance.

Where practical, the evaluator should exercise these capabilities through the administrative or TOE-exposed mechanisms described in the guidance. Where a function is automatic but configurable, the evaluator should verify the corresponding management capability through the exposed configuration mechanism.

A.3.6 Class FPT: Protection of the TSF

FPT_DPD_EXT.1 Dead Peer Detection

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall detect peer failure using:
  • RFC 3706 mechanisms or keep-alive beacons
  • Trigger session reconnect upon failure or disconnect notification
Application Note: The intent of this requirement is to ensure that the TOE detects loss of peer liveness and responds by attempting to restore the protected session state rather than continuing operation against a failed or disconnected peer. “Trigger session reconnect upon failure or disconnect notification” means the TOE initiates or enters the TOE-defined reconnection or session re-establishment behavior upon peer failure or disconnect notification.

A peer can become disconnected for several reasons, if restarted due to a timed event, the link between the pair was severed, one EU lost power, an adversary is manipulating the data in transit, etc. We cannot depend on an EU to know its peer EU is going offline. A PFED pair operates at both the link layer and the IP layer. The EUs are link-layer oriented and the CUs are IP-layer oriented. The EUs manage the link status, and they must be able to detect when the peer EU is no longer online in order to stop any further EUD traffic until the EU’s restart a new session tunnel.
Evaluation Activities
FPT_DPD_EXT.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the peer-failure detection mechanism used by the TOE.
  • States whether the TOE uses:
    • RFC 3706 mechanisms,
    • keep-alive beacons,
    • or both.
  • Describes how the TOE determines that peer failure has occurred.
  • Describes how the TOE determines that a disconnect notification has occurred, if distinct from peer failure detection.
  • Describes the TOE action taken when peer failure or disconnect notification is detected.
  • Describes the session reconnect behavior or reconnection state entered by the TOE after such detection.
  • If more than one liveness-detection mechanism is claimed, distinguishes the TOE behavior for each sufficiently to support testing.
The evaluator shall determine that the TSS is consistent with the posted PFED appendix text stating that the TOE uses RFC 3706 DPD or keep-alive beacons and transitions to session setup after dead peer detection.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_DPD_EXT.1:1: Peer failure detection: The evaluator shall cause peer failure or loss of liveness in the claimed TOE context and verify that the TOE detects the failure using the claimed mechanism, namely RFC 3706 or keep-alive beacons, consistent with the TSS and guidance. The PFED appendix expressly permits either mechanism.

  • Test FPT_DPD_EXT.1:2: Reconnect trigger on failure detection: Following peer-failure detection, the evaluator shall verify that the TOE triggers session reconnect behavior in accordance with the TSS and guidance. Where the TOE describes this as transition to a session setup state, the evaluator shall verify that behavior. The posted PFED appendix states that the TOE transitions to session setup after dead-peer detection.

  • Test FPT_DPD_EXT.1:3: Disconnect-notification handling: If the TOE distinguishes a disconnect notification from ordinary liveness failure, the evaluator shall cause that condition and verify that the TOE triggers session reconnect behavior as described in the TSS and guidance.

  • Test FPT_DPD_EXT.1:4: Claimed mechanism coverage: If the TOE claims both RFC 3706 and keep-alive beacons, the evaluator shall verify both mechanisms. If only one is claimed, the evaluator shall verify that the TOE relies on that claimed mechanism to satisfy this SFR.

  • Test FPT_DPD_EXT.1:5: PFED Functional Test: Establish a pair of communicating PFEDs A1 and B1 with respective EUD A and EUD B. A1 is a server PFED and B1 is a client PFED. Sniff the black transport. While A is sending data to B, disconnect B1. Eventually A1 should stop sending EUD traffic and revert to a passive server mode listening for a client session initiation. Reconnect B1 and observe a session setup and then EUD traffic resuming. Next disconnect A1 (the server). Eventually B1 (the client) should revert to initiating a session. This should look like a periodic beacon. Reconnect A1, and B1 should complete a session setup and EUD traffic should then be visible on the black transport.

Where direct observation of low-level liveness-detection behavior is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, traces, or developer evidence sufficient to determine that the claimed detection mechanism and reconnect trigger are implemented.

FPT_FLS.1/PFED Failure with Preservation of Secure State

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall preserve a secure state by terminating sessions when the following types of failures occur: [dead peer detected, recovery failure, provisioning failure.
Application Note: The intent of this requirement is to ensure that when specified PFED failures occur, the TOE preserves a secure state by terminating the affected session rather than allowing continued operation with uncertain peer state, incomplete provisioning state, or failed recovery state.

These failures can happen due to honest or malicious events. EU-to-EU session re-establishment restores a secure state. Any new session must restart from the previous known good session key and migrate to a new ephemeral session key through a rekey transaction before restoring EUD-to-EUD traffic.
Evaluation Activities
FPT_FLS.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED failures covered by this requirement:
    • dead peer detected,
    • recovery failure,
    • provisioning failure.
  • Describes what constitutes each failure condition in TOE-specific terms
    • .
  • Describes the session, provisional session, bootstrap tunnel, or other PFED association that is terminated for each covered failure.
  • Describes how the TOE preserves a secure state by terminating the affected session or association.
  • For dead peer detection, describes the TOE behavior after the peer-failure condition is detected.
  • For recovery failure, describes the failure-to-converge condition and the criteria that trigger session termination.
  • For provisioning failure, describes how the TOE handles incomplete or failed provisioning so that no insecure partially provisioned session remains active.
The evaluator shall determine that the TSS is consistent with the posted PFED appendix, including recovery termination on failure to converge and dead-peer handling in the PFED lifecycle.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_FLS.1/PFED:1: Dead peer detected: The evaluator shall cause a dead-peer condition in the claimed PFED context and verify that the TOE preserves a secure state by terminating the affected session. If the TOE transitions to session setup following dead-peer detection, the evaluator shall verify that the prior session is no longer active for protected traffic use.

  • Test FPT_FLS.1/PFED:2: Recovery failure: The evaluator shall cause PFED recovery not to converge in accordance with the claimed recovery-failure condition and verify that the TOE terminates the affected session.

  • Test FPT_FLS.1/PFED:3: Provisioning failure: The evaluator shall cause PFED provisioning to fail and verify that the TOE terminates the affected bootstrap, provisional, or session state so that no protected operational session remains active.

  • Test FPT_FLS.1/PFED:4: Secure-state preservation: For one or more of the above failure cases, the evaluator shall verify that after termination the TOE does not continue to permit traffic or otherwise behave as though the affected PFED session remains valid.

These tests may be combined where appropriate.

FPT_HRT.1/PFED Hardware Root of Trust

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall store a root key within a TPM 2.0 bound to a physical property of the platform and used only to unwrap other keys.
Application Note: The intent of this requirement is to ensure that the TOE anchors key protection in a hardware root of trust implemented by a TPM 2.0, such that the root key is bound to the physical platform and is not available for general cryptographic use. This SFR addresses the use of a hardware root of trust to establish confidence in the TOE environment.

“Bound to a physical property of the platform” means that the protection of the root key depends on platform-specific hardware characteristics or a TPM-resident binding that ties use of the key to the intended platform instance. The ST author should describe the relevant binding in TOE terms without disclosing sensitive implementation details that would weaken security.

“Used only to unwrap other keys” means the root key is not used directly as a traffic-encryption key, message-authentication key, signing key, general-purpose data-protection key, or for any purpose other than protecting access to subordinate keying material. The subordinate keys unwrapped by the root key may then be used by other TOE functions according to their respective SFRs.
Evaluation Activities
FPT_HRT.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the TPM 2.0 used as the hardware root of trust for this requirement.
  • Describes the root key stored within the TPM 2.0.
  • Describes how the root key is bound to a physical property of the platform.
  • Describes how the TOE ensures that the root key is used only to unwrap other keys.
  • Describes the types of subordinate keys that may be unwrapped using the root key.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FPT_ISO_EXT.1/PFED EU and CU Isolation

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall ensure:
  • EU and CU do not share computation resources
  • EU interfaces are non-addressable and stateless
  • Network namespaces are isolated.
  • Only a connectionless bus is shared
.
Application Note: The intent of this requirement is to ensure that the PFED TOE maintains strict architectural separation between the EU and CU so that the communication unit cannot become an alternate computation or state-sharing environment for the encryption unit, and so that intercomponent interaction is narrowly constrained to the intended minimal communication path.

“EU and CU do not share computation resources” means the TOE does not rely on shared execution environments, shared processing contexts, or equivalent shared computation infrastructure across the EU/CU boundary.

“EU interfaces are non-addressable and stateless” means the interfaces exposed by the EU for this PFED path are not independently addressable as conventional network endpoints and do not maintain externally reachable session state inconsistent with the claimed isolation model.

“Network namespaces are isolated” means the TOE prevents shared network namespace behavior across the EU/CU boundary that would undermine the claimed separation.

“Only a connectionless bus is shared” should be read consistently with Appendix H.12, which says only a stateless, connectionless bus is shared between the EU and CU and the EUD and EU.
Evaluation Activities
FPT_ISO_EXT.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the EU and CU components participating in the PFED architecture.
  • Describes how the TOE ensures that the EU and CU do not share computation resources.
  • Describes the EU interfaces relevant to this requirement and explains how they are non-addressable and stateless.
  • Describes the network namespace isolation used by the TOE and how it preserves separation between EU and CU.
  • Identifies the shared connectionless bus used between the EU and CU.
  • Describes how the TOE ensures that only the connectionless bus is shared.
  • Describes how the TOE prevents alternate shared communication or computation paths between the EU and CU.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_ISO_EXT.1/PFED:1: No shared computation resources: The evaluator shall verify, through TOE behavior, supported interfaces, configuration evidence, or developer evidence, that the EU and CU do not share computation resources in a manner inconsistent with the TSS.

  • Test FPT_ISO_EXT.1/PFED:2: EU interfaces non-addressable and stateless: The evaluator shall verify that the EU interfaces relevant to the PFED design are non-addressable and stateless as described in the TSS and guidance.

  • Test FPT_ISO_EXT.1/PFED:3: Network namespace isolation: The evaluator shall verify that the TOE enforces isolated network namespaces between EU and CU consistent with the TSS and guidance.

  • Test FPT_ISO_EXT.1/PFED:4: Only a connectionless bus is shared: The evaluator shall verify that the only shared intercomponent path between the EU and CU is the claimed connectionless bus, consistent with the component text and Appendix H.12.

  • Test FPT_ISO_EXT.1/PFED:5: No alternate shared path: The evaluator shall verify that no additional shared channel, stateful shared service, or alternate communication path exists between the EU and CU beyond the claimed shared bus.

  • Test FPT_ISO_EXT.1/PFED:6: PFED Functional Test: To show isolation of network namespace: provision a pair of PFED’s A1 and B1 and attach EUD A and B to them respectively. Assign the IPs of the EUDs to the same subnet as the CUs. For example, CU1 and A = 192.168.0.1 and CU2 and B == 192.168.0.2. Attach EUD C to the network switch that CU1 and CU2 communicate. Assign C == 192.168.0.3. Attach a sniffer on the wire between A and A1, B and B1, and to the switch. From C, ping 192.168.0.2. You should not see ICMP or reply emerge to EUD B. And you should see ICMP between CU2 and C. Similarly, from EUD A, ping 192.168.0.2. You should only see ICMP on the sniffer between B1 and B and A1 and A. And finally, from either A or B attempt to ping C at 192.168.0.3 and it should fail.

Where direct observation of low-level platform behavior is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, architectural evidence, or developer evidence sufficient to determine that the claimed PFED isolation model is implemented.

FPT_RCV.1/PFED Recovery Behavior

This component must be included in the ST if the TOE implements any of the following features:
The TOE shall enter a secure recovery state upon detection of: [selection: dead peer, session key divergence, failed rekey or recovery transaction].
During recovery, the TOE shall suppress all EUD traffic.
Application Note: The intent of this requirement is to ensure that, when specific PFED failures occur, the TOE transitions into a secure recovery state rather than continuing protected operation with a stale, divergent, incomplete, or uncertain session state. During recovery, the TOE shall suppress all EUD traffic.

For this requirement, “secure recovery state” should be described in TOE-specific terms. At a minimum, the TSS should make clear that in the secure recovery state the TOE no longer treats the affected PFED session as valid for ordinary protected traffic use, and instead limits behavior to recovery, reconnection, re-establishment, or other TOE-defined secure restoration actions.

For “Dead peer”, the TSS should define what event constitutes detection of peer failure and how the TOE transitions the affected PFED session into the secure recovery state.

For “Session key divergence”, the TSS should define what it means for the EU peers’ session keys or related session state to diverge and how the TOE detects that condition before entering the secure recovery state.

For “Failed rekey or recovery transaction”, the TSS should identify what transaction outcomes count as failure and how the TOE enters the secure recovery state when such failure is detected.
Evaluation Activities
FPT_RCV.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Describes the secure recovery state used by the TOE for PFED.
  • Identifies the PFED failures that cause entry into that state:
    • Dead peer,
    • Session key divergence,
    • Failed rekey transaction,
    • Failed recovery transaction.
  • Describes what constitutes each of those failure conditions in TOE-specific terms.
  • Describes how the TOE detects each such condition.
  • Describes the TOE transition into the secure recovery state for each covered failure.
  • Describes the TOE behavior while in the secure recovery state, including how it preserves security for the affected PFED session.
  • Describes how the TOE suppresses all EUD traffic while in the secure recovery state.
  • Describes the event or condition that marks exit from the secure recovery state.
  • Describes the relationship, if any, between the secure recovery state and the session setup state referenced in Appendix H.
  • Describes any distinctions among secure recovery behavior for dead peer detection, session key divergence, failed rekey, and failed recovery.
The evaluator shall determine that the TSS is consistent with the posted PFED appendix, including H.8 Session Key Recovery and H.10 Dead Peer Detection and Persona Enforcement, which establish the PFED recovery, reconnect, and EUD-traffic suppression model.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_RCV.1/PFED:1: Dead peer causes secure recovery state: The evaluator shall cause a dead-peer condition in the claimed PFED context and verify that the TOE enters the secure recovery state. If the TOE expresses that recovery state as or through transition to session setup, the evaluator shall verify that behavior is consistent with the TSS and guidance. The posted PFED appendix states that the TOE transitions to session setup after dead-peer detection.

  • Test FPT_RCV.1/PFED:2: Session key divergence causes secure recovery state: The evaluator shall cause or simulate session key divergence in the claimed PFED context and verify that the TOE enters the secure recovery state.

  • Test FPT_RCV.1/PFED:3: Failed rekey causes secure recovery state: The evaluator shall cause a PFED rekey transaction to fail and verify that the TOE enters the secure recovery state.

  • Test FPT_RCV.1/PFED:4: Failed recovery transaction causes secure recovery state: The evaluator shall cause a PFED recovery transaction to fail and verify that the TOE enters the secure recovery state.

  • Test FPT_RCV.1/PFED:5: EUD traffic suppression during recovery: For one or more of the above recovery-entry conditions, the evaluator shall verify that the TOE suppresses all EUD traffic while recovery is active. This should be consistent with the posted PFED appendix, which states that EUD traffic is suppressed during recovery.

These tests may be combined where appropriate.

FPT_SEP_EXT.1 TSF Domain Separation

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall maintain a security domain for the Encryption Unit (EU) and a separate security domain for the Communication Unit (CU) within the TOE.
The TSF shall enforce separation between the EU and CU such that:
  • The EU executes on a processor that is physically distinct from the processor used by the CU
  • The EU uses dedicated volatile and non-volatile memory resources that are physically distinct from those used by the CU
  • Independent execution environments
  • No shared memory exists between the EU and CU
  • Direct memory access from the EU to CU memory is not possible
  • Direct memory access from the CU to EU memory is not possible
  • All communication between the EU and CU is restricted to a dedicated wired interface that is part of the TSF boundary
Application Note: The intent of this requirement is to ensure that the TOE enforces hardware-backed separation between the EU and CU as distinct security domains within the TOE, so that compromise, malfunction, or misuse of one subsystem does not collapse the security boundary of the other.

FPT_SEP_EXT.1.1 establishes the domain model: The TOE maintains one security domain for the EU and a separate security domain for the CU. The TSS should describe those domains in TOE-specific terms and identify which TOE resources belong to each. FPT_SEP_EXT.1.2 then defines the required separation properties.

“Independent execution environments” means the TOE does not rely on a shared execution context between EU and CU that would undermine domain separation.

“No shared memory exists between the EU and CU” means there is no memory region jointly accessible as a shared state between the EU and CU. The separate DMA clauses make it explicit that each side is prevented from directly accessing the other side’s memory through DMA-capable mechanisms. The dedicated wired interface clause means the TOE permits EU/CU communication only over the single claimed inter-subsystem path that is inside the TSF boundary.
Evaluation Activities
FPT_SEP_EXT.1
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the EU and CU security domains maintained by the TOE.
  • Identifies the TOE resources assigned to each domain.
  • Describes how the TOE ensures that the EU executes on a processor physically distinct from the processor used by the CU.
  • Describes how the TOE ensures that the EU uses volatile and non-volatile memory resources physically distinct from those used by the CU.
  • Describes how the TOE ensures independent execution environments for EU and CU.
  • Describes how the TOE ensures that no shared memory exists between the EU and CU.
  • Describes how the TOE prevents DMA from the EU to CU memory.
  • Describes how the TOE prevents DMA from the CU to EU memory.
  • Identifies the dedicated wired interface used for all EU/CU communication.
  • Describes how the TOE ensures that all EU/CU communication is restricted to that dedicated wired interface and that no alternate communication path exists.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_SEP_EXT.1:1: Distinct processor enforcement: The evaluator shall verify, through TOE behavior, supported interfaces, platform evidence, or developer evidence, that the EU executes on a processor physically distinct from the processor used by the CU.

  • Test FPT_SEP_EXT.1:2: Distinct memory enforcement: The evaluator shall verify that the EU and CU use physically distinct volatile and non-volatile memory resources.

  • Test FPT_SEP_EXT.1:3: No shared memory: The evaluator shall verify that no shared memory exists between the EU and CU.

  • Test FPT_SEP_EXT.1:4: DMA isolation: The evaluator shall verify that direct memory access from the EU to CU memory is not possible and that direct memory access from the CU to EU memory is not possible.

  • Test FPT_SEP_EXT.1:5: Dedicated wired interface restriction: The evaluator shall verify that all communication between the EU and CU is restricted to the claimed dedicated wired interface that is part of the TSF boundary.

  • Test FPT_SEP_EXT.1:6: No alternate communication path: The evaluator shall verify that no additional communication path exists between the EU and CU beyond the claimed dedicated wired interface.

Where direct observation of low-level hardware behavior is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, architectural evidence, or developer evidence sufficient to determine that the claimed separation model is implemented.

FPT_TRAN_EXT.1/PFED Transaction Control

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall allow only one transaction at a time, prohibit nesting, and enforce a reaper timer.
Application Note: The intent of this requirement is to ensure that PFED transaction processing remains serialized, bounded, and fail-safe so that the TOE does not enter ambiguous or conflicting security states due to overlapping lifecycle operations.

The EU transactions must be atomic. For example, if the EU pair is in a key recovery transaction and a timeout for rekey happens, the rekey transaction does not start until the current recovery transaction completes or restarts the session. When a transaction begins, a transaction reaper timer must also start so that if the transaction gets into an endless or fails, the reaper guarantees the EU either restarts the session or stops altogether. When the transaction completes, the reaper is disabled.
Evaluation Activities
FPT_TRAN_EXT.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED operations treated as transactions by the TOE.
  • Describes how the TOE ensures that only one PFED transaction is active at a time.
  • Describes how the TOE prohibits nested PFED transactions.
  • Describes the reaper timer or equivalent timeout control used for PFED transactions.
  • Describes what starts the reaper timer.
  • Describes what stops or satisfies the reaper timer.
  • Describes the TOE action taken when the reaper timer expires.
  • Describes any distinctions among transaction types, if different PFED transactions have different timeout or control behavior.
  • Describes how the TOE handles an attempted second transaction while one is already active.
  • Describes how the TOE returns to a secure or usable state after transaction completion, abort, or timeout.
The evaluator shall determine that the TSS is consistent with the PFED lifecycle operations described in Appendix H and that the TOE’s transaction model prevents concurrency and nesting while bounding active transaction lifetime.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_TRAN_EXT.1/PFED:1: One transaction at a time: The evaluator shall cause the TOE to begin one PFED transaction and then attempt to begin a second PFED transaction before the first has completed. The evaluator shall verify that the TOE does not allow both transactions to proceed concurrently.

  • Test FPT_TRAN_EXT.1/PFED:2: No nested transactions: The evaluator shall attempt to invoke a PFED transaction while another PFED transaction is active in a way that would constitute nesting and verify that the TOE prohibits the nested transaction.

  • Test FPT_TRAN_EXT.1/PFED:3: Reaper timer enforcement: The evaluator shall cause a PFED transaction to remain incomplete past the claimed timeout condition and verify that the TOE enforces the reaper timer behavior described in the TSS and guidance.

  • Test FPT_TRAN_EXT.1/PFED:4: Post-timeout behavior: After reaper-timer expiration, the evaluator shall verify that the TOE performs the claimed timeout action, such as cleanup, abort, return to an idle state, or secure recovery behavior, and does not leave the timed-out transaction active indefinitely.

  • Test FPT_TRAN_EXT.1/PFED:5: Transaction sequencing after completion or timeout: The evaluator shall verify that, once an active transaction has completed or been reaped, the TOE can then permit the next PFED transaction in accordance with the TSS and guidance.

These tests may be combined where appropriate. The purpose of this evaluation is to confirm that PFED transaction processing is serialized, non-nestable, and bounded by timeout control.

FPT_TST.1/PFED TSF Self-TEst

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall perform self-tests of cryptographic functions and hardware root of trust during initialization.
Application Note: The intent of this requirement is to ensure that, before the TOE enters operational PFED use, it verifies the availability and correct initialization of the security-relevant cryptographic functions on which PFED depends and verifies the hardware root of trust that anchors those functions.
Evaluation Activities
FPT_TST.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED cryptographic functions covered by initialization self-tests.
  • Describes the self-tests performed for those cryptographic functions.
  • Identifies the hardware root of trust covered by initialization self-tests.
  • Describes the self-tests or verification actions performed for the hardware root of trust.
  • Describes when during initialization the TOE performs these self-tests.
  • Describes what constitutes success and failure for the covered self-tests.
  • Describes the TOE behavior when a covered self-test fails.
  • Describes how the TOE ensures that the covered cryptographic functions and hardware root of trust are not treated as operationally available before the required initialization self-tests complete successfully.
The evaluator shall determine that the TSS is consistent with the PFED appendix’s Hardware Root of Trust section and the presence of the TSF testing and self-test notification extended components.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The evaluator shall perform the following tests.
  • Test FPT_TST.1/PFED:1: Cryptographic self-tests during initialization: The evaluator shall initialize or restart the TOE and verify that the TOE performs the claimed self-tests of PFED cryptographic functions during initialization, consistent with the TSS and guidance.

  • Test FPT_TST.1/PFED:2: Hardware root-of-trust self-test during initialization: The evaluator shall initialize or restart the TOE and verify that the TOE performs the claimed self-test or verification of the hardware root of trust during initialization, consistent with the TSS and guidance.

  • Test FPT_TST.1/PFED:3: Operational gating until self-tests complete: The evaluator shall verify that the TOE does not treat the covered PFED cryptographic functions or hardware root of trust as operationally available before the claimed initialization self-tests have completed successfully.

  • Test FPT_TST.1/PFED:4: Failure behavior: Where practical, using supported test mechanisms, representative test configurations, or developer evidence, the evaluator shall verify that a failure of a covered initialization self-test results in TOE behavior consistent with the TSS and guidance.

Where direct observation of low-level self-test behavior is not practical, the evaluator may rely on observable TOE behavior, supported test interfaces, status indications, developer evidence, or other evaluation evidence sufficient to determine that the claimed initialization self-tests are performed.

A.3.7 Class FTP: Trusted Path/Channel

FTP_ITC.1/MACsec Trusted Channel Communication

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall use MACsec in accordance with the PP-Module for MACsec Ethernet Encryption, version 2.0 to provide a communication channel between itself and a MACsec peer that is logically distinct from other communication channels and provides assured identification of its endpoints, protects channel data from disclosure, and detects modification of the channel data.
Application Note: The intent of this requirement is to ensure that the TOE provides a trusted communication channel using MACsec between itself and a MACsec peer, and that this channel is logically distinct from other communication channels. For this requirement, the TOE uses MACsec in accordance with the PP-Module for MACsec Ethernet Encryption.
The TSF shall permit [selection: the TSF, a MACsec peer] to initiate communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [communications with MACsec peers that require the use of MACsec]
Evaluation Activities
FTP_ITC.1/MACsec
The evaluator shall apply the test activities for FCS_MACSEC_EXT.1, FCS_MACSEC_EXT.2, FCS_MACSEC_EXT.3, and FCS_MACSEC_EXT.4 as defined in the PP-Module for MACsec Ethernet Encryption.

FTP_ITC.1/PFED Trusted Channel Communication

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall provide a communication channel using PFED in accordance with the PFED specification in Appendix H and PFED SFRs to provide a trusted channel between itself and a PFED peer 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 this requirement is to ensure that the TOE provides a PFED-based trusted channel to a PFED peer that is separate from other communications and that provides endpoint assurance plus protection of channel data against disclosure and modification. This requirement applies to all TSF communications that leverage PFED to exchange cryptographic material, session keys, or other sensitive control information. This requirement is about the PFED trusted channel itself. It should be read together with the related PFED cryptographic, authentication, rekey, recovery, and traffic-isolation requirements, but this subsection should remain focused on the existence and properties of the PFED trusted channel between PFED peers.
Evaluation Activities
FTP_ITC.1/PFED
TSS
The evaluator shall examine the TSS to determine that it:
  • Identifies the PFED peer or peer types with which the TOE establishes the trusted channel.
  • Describes the PFED communication channel used to satisfy this requirement.
  • Describes how that PFED channel is logically distinct from other communication channels.
  • Describes how the TOE assures identification of the PFED channel endpoints.
  • Describes how the TOE protects PFED channel data from disclosure.
  • Describes how the TOE protects PFED channel data from modification.
  • Describes the PFED session or tunnel state or states in which the trusted channel exists.
  • Describes how the TOE’s PFED trusted channel claim is consistent with the PFED specification in Appendix H and the PFED SFRs claimed in the ST.
The evaluator shall determine that the TSS is consistent with the posted PFED appendix, including the PFED tunnel and session model, mutual authentication, and protected traffic handling.
Guidance
The evaluator shall examine the operational guidance to determine that it:
  • Describes how the TOE is configured, provisioned, or operated to establish the PFED trusted channel.
  • Describes any prerequisites for PFED trusted-channel establishment, such as provisioning, peer preparation, credentials, or successful PFED session setup.
Tests
The evaluator shall perform the following tests.
  • Test FTP_ITC.1/PFED:1: Establishment of PFED trusted channel: The evaluator shall configure or provision the TOE in accordance with the operational guidance and verify that the TOE establishes the claimed PFED trusted channel with a PFED peer consistent with the TSS and guidance. This test shall be consistent with the PFED specification in Appendix H and the claimed PFED SFR set.

  • Test FTP_ITC.1/PFED:2: Logical distinction from other channels: The evaluator shall verify that the PFED trusted channel is logically distinct from other communication channels in the manner described in the TSS and guidance.

  • Test FTP_ITC.1/PFED:3: Endpoint identification: The evaluator shall verify that the TOE provides assured identification of the PFED trusted-channel endpoints, consistent with the PFED mutual-authentication model described in the TSS and Appendix H. Appendix H.6 describes mutual authentication between ERDs using ML-DSA-87 as part of session setup.

  • Test FTP_ITC.1/PFED:4: Protection from disclosure and modification: The evaluator shall verify that PFED channel data is protected from disclosure and modification in a manner consistent with the TSS and the PFED cryptographic protections described in Appendix H.

  • Test FTP_ITC.1/PFED:5: Channel failure or disruption behavior: The evaluator shall cause a PFED trusted-channel failure, interruption, or loss of peer liveness and verify that the TOE behaves consistently with the TSS and the related PFED dead-peer, rekey, and recovery behavior claimed elsewhere in the ST. Appendix H includes dead-peer detection and recovery behavior for PFED sessions.

Where direct observation of low-level channel internals is not practical, the evaluator may rely on observable TOE behavior, packet traces, supported test interfaces, or developer evidence sufficient to determine that the claimed PFED trusted channel is established and provides the claimed protections.

FTP_ITC_EXT.1/IPsec Trusted Channel Communication

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall use [selection:
  • IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version 3.0
  • IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Gateway, version 2.0
] protocols to provide a communication channel between itself and another trusted IT product using certificates as defined in [Functional Package for X.509, version 1.0] that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
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 between the TOE and a VPN Gateway, or other trusted IT product.

Appendix B - Selection-based Requirements contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1/Admin in the main body of the ST.

Assured identification of endpoints is performed according to the authentication mechanisms used by the listed trusted channel protocols

Claims from the Functional Package for X.509, version 1.0 are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed.
Evaluation Activities
FTP_ITC_EXT.1/IPsec
TSS
The evaluator shall review the TSS to determine that it lists all trusted channels the TOE uses for remote communications, including both the external IT entities and remote users that use the channel as well as the protocol that is used for each.
Guidance
The evaluator shall confirm that the AGD contains instructions for establishing connections to external IT entities and remote users.
Tests
The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.

FTP_ITC_EXT.1/WLAN Trusted Channel Communication

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall use [selection:
  • 802.11-2012 in accordance with the [PP-Module for Wireless LAN Clients, version 2.0]
  • 802.1X in accordance with the [PP-Module for Wireless LAN Clients, version 2.0]
  • EAP-TLS in accordance with the [PP-Module for Wireless LAN Clients, version 2.0]
  • Mutually authenticated TLS in accordance with [Functional Package for Transport Layer Security (TLS), version 2.1]
] protocols to provide a communication channel between itself and another trusted IT product using certificates as defined in [Functional Package for X.509, version 1.0] that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
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 between the TOE and an access point, or other trusted IT product.

Appendix B - Selection-based Requirements contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1/Admin in the main body of the ST.

Assured identification of endpoints is performed according to the authentication mechanisms used by the listed trusted channel protocols

Claims from the Functional Package for X.509, version 1.0 are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed.

The TSF is mandated to support mutually authenticated TLS, which means that it implements a protocol that requires the validation of a certificate presented by an external entity. Therefore, FIA_X509_EXT.1 and FIA_X509_EXT.2 as defined in Functional Package for X.509, version 1.0 will be claimed, as will FIA_TSM_EXT.1 for management of the trust store.

The requirement to implement mutually authenticated TLS also means that it implements a protocol that requires the presentation of any certificates to an external entity. Therefore, FIA_XCU_EXT.2 will be claimed. FIA_X509_EXT.6 will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.
The TSF shall permit the TSF to initiate communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for wireless access point connections, administrative communication, configured enterprise connections, and [selection: OTA updates, no other connections]
Evaluation Activities
FTP_ITC_EXT.1/WLAN
TSS
The evaluator shall review the TSS to determine that it lists all trusted channels the TOE uses for remote communications, including both the external IT entities and remote users that use the channel as well as the protocol that is used for each.
Guidance
The evaluator shall confirm that the AGD contains instructions for establishing connections to external IT entities and remote users.
Tests
The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.

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 FCS: Cryptographic Support

FCS_CKM.1/AKG Cryptographic Key Generation - Asymmetric Key

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

The TOE shall 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]

The following table provides the allowable choices for completion of the selection operations of FCS_CKM.1/AKG.
Table 9: Allowable choices for FCS_CKM.1/AKG
Identifier Cryptographic key generation algorithm Cryptographic algorithm parameters List of standards
RSARSAModulus of size [selection: 3072, 4096, 6144, 8192] bits NIST FIPS PUB 186-5 (Section A.1.1)
ECC-ERBECC-ERB - Extra Random BitsElliptic Curve [selection: P-384, P-521] FIPS PUB 186-5 (Section A.2.1)

NIST SP 800-186 (Section 3) [NIST Curves]
ECC-RSECC-RS - Rejection SamplingElliptic Curve [selection: P-384, P-521] FIPS PUB 186-5 (Section A.2.2)

NIST SP 800-186 (Section 3) [NIST Curves]
FFC-ERBFFC-ERB - Extra Random BitsStatic 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-RSFFC-RS - Rejection SamplingStatic 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]]
LMSLMSPrivate 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-KEMML-KEM KeyGenParameter set = ML-KEM-1024NIST FIPS 203 (Section 7.1)
ML-DSAML-DSA KeyGenParameter set = ML-DSA-87NIST FIPS 204 (Section 5.1)
XMSSXMSSPrivate 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: This SFR must be included in the ST if asymmetric key generation is a service provided by the TOE to tenant software, or if it is used by the TOE itself to support or implement PP-specified security functionality.

This SFR must also be claimed in the ST if FCS_IPSEC_EXT.1 is claimed, or if "causing the TOE to generate [asymmetric] keys/secrets" is selected in FCS_STG_EXT.1.2.

Furthermore, this SFR must be claimed if TLS or HTTPS is claimed in FTP_ITC_EXT.1/Admin.

If this SFR is included in the ST, then FCS_CKM.6 and FCS_RBG.1 must also be claimed.

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

RSA Key Generation

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

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

These are:
  • Random Provable primes
  • Random Probable primes
  • Provable primes with conditions based on auxiliary provable primes
  • Probable primes with conditions based on auxiliary provable primes
  • Probable primes with conditions based on auxiliary probable primes

In addition to the key generation method, the input parameters are:
  • Modulus [3072, 4096, 6144, 8192]
  • Hash algorithm [SHA-384, SHA-512] (methods 1, 3, 4 only)
  • Rabin-Miller prime test [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 must 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/public key pairs (d, Q). The private key, d, shall be generated using a random bit generator as specified 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/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/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 shall 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 such that 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 10: 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 11: 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 specified in .

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

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

The TSF shall 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]

The following table provides the allowable choices for completion of the selection operations of FCS_CKM.1/SKG.
Table 12: Allowable choices for FCS_CKM.1/SKG
Identifier Cryptographic Key Generation Algorithm Cryptographic Key Sizes List of standards
RSKDirect Generation from a Random Bit Generator as specified in FCS_RBG.1[selection: 256, 384, 512] bits NIST SP 800-133 Revision 2 (Section 6.1)[Direct generation of symmetric keys]
Application Note: This SFR must be included in the ST if it is a service provided by the TOE to tenant software, or if it is used by the TOE itself to support or implement PP-specified security functionality.

This SFR must be included in the ST if "causing the TOE to generate [symmetric] keys/secrets" is selected in FCS_STG_EXT.1.2.

This SFR must be claimed if any SFRs are claimed that require generation of a symmetric key, such as FCS_COP.1/AEAD, FCS_COP.1/KeyedHash, FCS_COP.1/KeyWrap, FCS_COP.1/CMAC, or FCS_COP.1/SKC.

If this SFR is claimed in the ST, then FCS_CKM.6 and FCS_RBG.1 must also be claimed.
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 specified 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 RBG 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 asymmetric cryptographic key generation capability for each claimed key size. The evaluator shall use the description of the RBG interface to verify that the TOE requests and receives an amount of RBG output greater than or equal to the requested key size.

FCS_CKM.2 Cryptographic Key Distribution

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [selection: key encapsulation, key wrapping, encrypted channels] that meets the following: [none].
Application Note:

If "key encapsulation" is selected, FCS_COP.1/KeyEncap must be claimed, which specifies the relevant list of standards.

If "key wrapping" is selected, FCS_COP.1/KeyWrap must be claimed, which specifies the relevant list of standards.

If "encrypted channels" is selected, FTP_ITC_EXT.1/Admin must be claimed.

Evaluation Activities
FCS_CKM.2.1
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, FCS_COP.1/KeyWrap, or FTP_ITC_EXT.1/Admin.

FCS_CKM.6 Timing and Event of Cryptographic Key Destruction

This component must be included in the ST if any of the following SFRs are included:
The TSF shall destroy [all plaintext keying material and critical security parameters (CSPs)] when [selection: no longer needed, [assignment: other circumstances for destruction]].
The TSF shall destroy plaintext keying material and critical security parameters by 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 a TSF DRBG (as specified 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 a TSF DRBG (as specified 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[selection: a single direct overwrite consisting of zeros followed by a read-verify, a 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[selection: a single direct overwrite consisting of zeros, a 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.
]
Application Note:

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

Evaluation Activities
FCS_CKM.6
TSS
The evaluator shall verify that the TSS identifies all plaintext keying material and CSPs 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.
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. 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.

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

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

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]

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/AEAD.
Table 13: Allowable choices for FCS_COP.1/AEAD
Identifier Cryptographic algorithm Cryptographic key sizes List of standards
AES-CCMAES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits256 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-GCMAES 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 1.0 and 2.0.
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 nonrepeating IVs using [selection: deterministic, RBG-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/CMAC Cryptographic Operation - CMAC

This component may also be included in the ST as if optional.

The TSF shall perform [CMAC] 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]

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/CMAC.
Table 14: Allowable choices for FCS_COP.1/CMAC
Identifier Cryptographic algorithm Cryptographic key sizes List of standards
AES-CMACAES using CMAC mode256 bits[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]

[selection: : ISO/IEC 9797-1:2011 Subclause 7.6, NIST SP 800-38B] [CMAC]
Application Note: The use of 256-bit keys for AES algorithms is required by CNSA 1.0 and 2.0.
Evaluation Activities
FCS_COP.1/CMAC
TSS
The evaluator shall examine the TSS to verify that the IV consists of all zeros in accordance with the relevant standards.
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-CMAC

Identifier Cryptographic Algorithm Cryptographic Key Sizes List of Standards
AES-CMAC AES using CMAC mode 256 bits [selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]

[selection: ISO/IEC 9797-1:2011 (Subclause 7.6), NIST SP 800-38B] [CMAC]

To test the TOE’s ability to generate MAC values using AES in CMAC mode the evaluator shall perform the CMAC Generation Test and CMAC Verification Test using the following input parameters:
  • Key Size [256] bits
  • Message size [0-524288] bits in increments of 8
  • MAC sizes [1-128] bits


CMAC Generation Test

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

  • For each claimed key size,
  • For four message sizes as follows:
    • The smallest supported message size,
    • The largest supported message size,
    • Two sizes that are divisible by the block size, and
    • Two sizes that are not divisible by the block size
  • For three MAC sizes as follows:
    • The smallest supported MAC size,
    • The largest supported MAC size, and
    • Some other supported MAC size

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

The evaluator shall generate 20 test cases using random keys and data for each combination of the above parameters as follows:
  • For each claimed key size,
  • For four message sizes as follows:
    • The smallest supported message size,
    • The largest supported message size,
    • Two sizes that are divisible by the block size, and
    • Two sizes that are not divisible by the block size
  • For three MAC sizes as follows:
    • The smallest supported MAC size,
    • The largest supported MAC size, and
    • Some other supported MAC size

The evaluator shall modify the tag such that 25% of the test cases in each group of 20 test cases should fail.

The evaluator shall determine that the verification fails for the test cases with modified inputs, and succeeds for those with unmodified inputs.

FCS_COP.1/Hash Cryptographic Operation - Hashing

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

The TSF shall perform [cryptographic hashing] in accordance with a 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 1.0 and 2.0:
  • 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 a PRF or MAC as part of a key derivation function, or 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.
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 inclusion of this selection-based component depends upon selection in:

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

This component may also be included in the ST as if optional.

The TSF shall 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]

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/KeyedHash.
Table 15: Allowable choices for FCS_COP.1/KeyedHash
Keyed Hash Algorithm Cryptographic key sizes List of standards
HMAC-SHA-256256 bits[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
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 HMAC minimum key sizes in the table are specified in ISO/IEC 9797-2:2021, which requires that the minimum key size be equal to the digest size. The FIPS standard specifies no minimum or maximum key sizes, so if FIPS PUB 198-1 is selected, larger or smaller key sizes may be used. This is indicated by the parenthesized annotations in the Cryptographic Key Sizes column.

In accordance with CNSA 1.0 and 2.0, HMAC-SHA-256 may be used only as a PRF or MAC step in a key derivation function.
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.

The evaluator shall examine the TSS to verify that if HMAC-SHA-256 is selected, that it is being used only as a PRF or MAC step in a key derivation function.
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.

HMAC

Keyed Hash Algorithm Cryptographic Key Sizes List of Standards
HMAC-SHA-256 256 bits [selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
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/KeyEncap Cryptographic Operation - Key Encapsulation

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

This component must be included in the ST if the TOE implements any of the following features:
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]

The following table 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-KEMML-KEMParameter set = ML-KEM-1024NIST 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 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.


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:

This component must be included in the ST if the TOE implements any of the following features:
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]

The following table 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-KWAES in KW mode256 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-KWPAES in KWP mode256 bits[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]

NIST SP 800-38F (Section 6.3) [KWP mode]
AES-CCMAES in CCM mode with unpredictable, non-repeating nonce, minimum size of 64 bits256 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-GCMAES 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 or is used as a mechanism supporting verification of imported key integrity (FDP_ITC_EXT.1.2) or the integrity of stored key data (FCS_STG_EXT.3.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/SigGen Cryptographic Operation - Signing Generation

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

This component may also be included in the ST as if optional.

The TSF shall 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]

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/SigGen.
Table 18: Allowable choices for FCS_COP.1/SigGen
Identifier Cryptographic algorithm Cryptographic key sizes List of standards
RSA-PKCSRSASSA-PKCS1-v1_5Modulus 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-PSSRSASSA-PSSModulus 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]
ECDSAECDSAElliptic 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]
LMSLMSPrivate 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-DSAML-DSA Signature GenerationParameter set = ML-DSA-87NIST FIPS 204 (Section 5.2)
XMSSXMSSPrivate 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: This SFR must be included in the ST if digital signature generation is a service provided by the TOE to tenant software, or if digital signature generation is used by the TOE itself to support or implement PP-specified security functionality.

Specifically, this SFR must be included if "A digital signature of the stored key in accordance with FCS_COP.1/SigGen using an asymmetric key that is protected in accordance with FCS_STG_EXT.2" is selected in FCS_STG_EXT.3.

If this SFR is included in the ST, then FCS_COP.1/Hash and FCS_RBG.1 must also be claimed.
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 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.


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.

LMS Signature Generation

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 generate 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 10 signatures. The evaluator shall verify the correctness of the implementation by comparing values generated by the TOE with those generated by a known good implementation using the same input parameters.


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
XMSS Signature Generation

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 generate digital signatures 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 Key Generation Test

For each supported combination of the above parameters, the evaluator shall generate 10 signatures. The evaluator shall verify the correctness of the implementation by comparing values generated by the TOE with those generated by a known-good implementation using the same input parameters.

FCS_COP.1/SigVer Cryptographic Operation - Signature Verification

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

This component may also be included in the ST as if optional.

The TSF shall 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]

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/SigVer.
Table 19: Allowable choices for FCS_COP.1/SigVer
Identifier Cryptographic algorithm Cryptographic key sizes List of standards
RSA-PKCSRSASSA-PKCS1-v1_5Modulus 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-PSSRSASSA-PSSModulus 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]
ECDSAECDSAElliptic 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]
LMSLMSPrivate 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]
XMSSXMSSPrivate 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-DSAML-DSA Signature VerificationParameter set = ML-DSA-87NIST FIPS 204 (Section 5.3)
Application Note: This SFR must be included in the ST if digital signature verification is a service provided by the TOE to tenant software, or if digital signature verification is used by the TOE itself to support or implement PP-specified security functionality.

Specifically, this SFR must be included if the ST author chooses "implement an authenticated platform firmware update mechanism as described in FPT_TUD_EXT.2" or "implement a delayed-authentication platform firmware update mechanism as described in FPT_TUD_EXT.3" in FPT_TUD_EXT.1; or if the ST author selects "verification of a digital signature by trusted code/data" in FPT_ROT_EXT.2.

If this SFR is included in the ST, then FCS_COP.1/Hash must also be claimed.

The ST author should choose the algorithm implemented to perform verification of digital signatures. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm. In particular, if ECDSA is selected as one of the signature algorithms, the key size specified must match the selection for the curve used in the algorithm.

For elliptic curve-based schemes, the key size refers to the binary logarithm (log2) of the order of the base point. As the preferred approach for digital signatures, elliptic curves will be required after all the necessary standards and other supporting information are fully established.

The TOE may contain a public key which is integrity protected (e.g., in hardware), in which case the FDP_ITC.1 and FDP_ITC.2 dependencies do not apply. In this case, no dependencies may be chosen. For signature verifications, private keys are not necessary, so there are no dependencies required for generating or destroying cryptographic keys.

If LMS or XMSS is claimed, then FCS_COP.1/XOF must also be claimed.
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 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.

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.

DSA Signature Verification

Identifier Cryptographic Algorithm Parameters Cryptographic Key Sizes List of Standards
DSA DSA Domain parameters for (L, N) = [(3072, 256)] bits FIPS PUB 186-4 (Section 4.7) [DSA Signature Verification]

To test the TOE’s ability to perform DSA Digital Signature Verification, the evaluator shall perform the Algorithm Functional Test using the following input parameters:
  • (L, N) = (3072, 256)
  • 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 15 test cases consisting of messages and signatures such that the 15 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

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 4 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_COP.1/SKC Cryptographic Operation - Symmetric Key Encryption/Decryption

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

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]

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/SKC.
Table 20: Allowable choices for FCS_COP.1/SKC
Identifier Cryptographic Algorithm Cryptographic Key Sizes List of Standards
AES-CBCAES in CBC mode with non-repeating and unpredictable IVs256 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]
AES-CTRAES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key256 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] [CBC]
XTS-AESAES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer512 bits[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES]

[selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS]
Application Note: This SFR must be included in the ST if symmetric-key cryptography is a service provided by the TOE to tenant software, or if the TOE itself uses SKC to support or implement PP-specified security functionality.

Specifically, this SFR must be included if the ST includes FCS_IPSEC_EXT.1 or FCS_STG_EXT.2, or includes any of the following selections:

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

The following table provides the allowable choices for completion of the selection operations of FCS_COP.1/XOF.
Table 21: Allowable choices for FCS_COP.1/XOF
Cryptographic Algorithm Parameters List of Standards
SHAKEFunctions = [SHAKE256] NIST FIPS PUB 202 Section 6.2 [SHAKE]
Application Note: In accordance with CNSA 2.0, 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.

Since LMS and XMSS use both SHAKE128 and SHAKE256 internally, claiming and testing of both functions is mandatory.
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:
The TSF shall implement the HTTPS protocol that complies with RFC 2818.
Application Note: This SFR is included in the ST if the ST author selects "HTTPS" in FTP_ITC_EXT.1.1.
The TSF shall implement HTTPS using TLS as defined in [the Functional Package for Transport Layer Security (TLS), version 2.1].
Application Note: The Functional Package for Transport Layer Security (TLS), version 2.1 must be included in the ST, with the following selections made:
  • FCS_TLS_EXT.1:
    • TLS must be selected
    • Client must be selected
Evaluation Activities
FCS_HTTPS_EXT.1
TSS
There are no additional TSS evaluation activities for this component.
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 webserver, 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 testing in the Functional Package for Transport Layer Security (TLS), version 2.1.

    Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1 as defined in , and the evaluator shall perform the following test:

  • Test FCS_HTTPS_EXT.1:2: The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator shall then delete one of the certificates, and show that the application is notified of the validation failure.

FCS_RBG.1 Random Bit Generation (RBG)

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

This component must be included in the ST if any of the following SFRs are included:

This component may also be included in the ST as if optional.

TSF shall perform deterministic random bit generation services using [selection: DRBG Algorithm] in accordance with [selection: List of standards] after initialization.

The following table provides the allowable choices for completion of the selection operations of FCS_RBG.1.
Table 22: Allowable choices for FCS_RBG.1.1
Identifier DRBG Algorithm List of standards
HASH_DRBGHash_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_DRBGHMAC_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_DRBGCTR_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: CNSA 1.0 and 2.0 requires the use of 256-bit AES and SHA-384 or SHA-512. SHA-256 and all SHA3 hashes are not allowed.

NIST SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.

This SFR must be included in the ST if random bits are provided by the TOE to tenant software, or if it is used by the TOE itself to support or implement PP-specified security functionality.

This SFR is also needed if the following SFRs are included in the ST: FCS_IPSEC_EXT.1, FCS_CKM.1/AKG, FCS_CKM.1/SKG, and FCS_COP.1/SigGen.

Also, this SFR must be claimed if "KDF-CTR," "KDF-FB," or "KDF-DPI" is selected in FCS_CKM.5.

If "HMAC_DRBG" is selected, then FCS_COP.1/KeyedHash must be claimed.

If "Hash_DRBG" is selected, then FCS_COP.1/Hash must be claimed.

If "CTR_DRBG" is selected, then FCS_COP.1/SKC must be claimed. If "PFED" is included, you must select "DRBG
The TSF shall use a [selection: TSF entropy source [assignment: name of entropy source], multiple TSF entropy sources [assignment: name of entropy sources], TSF interface for seeding] for initialization and reseeding.
Application Note:

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 TSF entropy sources" if a seed is formed from a combination of two or more 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 TSF entropy sources" is only selected if a single DRBG uses multiple entropy sources for its seed. The ST author selects "TSF interface for seeding" if entropy source data is generated outside the TOE boundary.

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

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

If "TSF interface for seeding" is selected, FCS_RGB.2 must be claimed.

The security strength of the entropy used for seeding depends on the functions for which the TSF uses entropy. The security strength for the various functions is defined in Tables 2 and 3 of NIST SP 800-57A.

The TSF shall update the DRBG state by [selection: reseeding, uninstantiating and re-instantiating] using a [selection: TSF entropy source [assignment: name of entropy source], multiple TSF entropy sources [assignment: name of entropy sources], 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].
Application Note:

If a reseeding is selected in the first selection and something other than “never” is selected in the third selection of FCS_RBG.1.3, but reseeding is not feasible, the TSF will uninstantiate RBGs, rather than produce output that is of insufficient quality. The listed standards should specify the reseed interval and procedure for uninstantiating and reseeding. The remaining selection allows the PP Author to require application-specific conditions for reseeding.

"Uninstantiate” means that the internal state of the DRBG is no longer available for use. In the second selection of FCS_RBG.1.3, “on demand” means that a TOE presents an interface to reseed as a TSFI (e.g., an API call). The interface causes the DRBG to reseed at the request of an authorized user, either with an internal source, an external source, or from input provided through the TSFI (e.g., the API call).

Evaluation Activities
FCS_RBG.1
TSS
If the ST specifies more than one DRBG, the evaluator shall examine the TSS to verify that it identifies the usage of each DRBG mechanism.

The evaluator shall examine the TSS to verify that it specifies the DRBG type, identifies entropy sources initializing and reseeding the DRBG, and the situations under which this may occur.
Guidance
The evaluator shall verify that the Guidance instructs the administrator how to configure the TOE to use the selected DRBG mechanisms, if necessary, and provides information regarding how to instantiate/call the DRBG for RBG services.

If the ST claims that the DRBG state can be updated on demand, the evaluator shall verify that the guidance includes instructions for how to perform this operation.
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.


HASH_DRBG, HMAC_DRBG

Identifier RBG 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)]

To test the TOE’s ability to generate random bits using Hash_DRBG or HMAC_DRBG, the evaluator shall perform the Algorithm Functional Test using the following input parameters:
  • Function [SHA-384, SHA-512]
  • Max security strength [256] bits
  • Entropy length [256-65536] bits
  • Max Personalization String size [65536] bits
  • Max additional string [65536] bits
  • Nonce length [128-65536] bits
  • Min returned bits length [256, 384, 512]
  • Prediction resistance [on, off]
  • Reseed [on, off]

Algorithm Functional Test

The evaluator shall generate 16 test groups for each claimed function. Eight with prediction resistance enabled, and eight with prediction resistance turned off. For each of the eight test groups, four must have reseed enabled and four must have reseed turned off.

Each test group within the core sets of four test groups shall consist of 15 test cases each, such that minimum lengths and maximum lengths for the above parameters are used at least once across the four groups, and the rest are random lengths.

Correctness is determined by comparing the results from a known-good implementation using the same input parameters.

CTR_DRBG

Identifier RBG Algorithm List of Standards
CTR_DRBG CTR_DRBG with AES-CTR-256 [selection: ISO/IEC 18031:2011 (Section C.3.2), NIST SP 800-90A Revision 1 (Section 10.2.1)]

To test the TOE’s ability to generate random bits using CTR_DRBG, the evaluator shall perform the Algorithm Functional Test using the following input parameters:
  • Mode [AES-CTR-256]
  • Max security strength [256] bits
  • Entropy length [256-65536] bits
  • Max Personalization String size [65536] bits
  • Max additional string [65536] bits
  • Nonce length [0-65536] bits
  • Min returned bits length [128]
  • Prediction resistance [on, off]
  • Reseed [on, off]
  • Derivation Function [true, false]

Algorithm Functional Test

The evaluator shall generate 16 test groups for each claimed function and supported derivation function state (on or off). Eight with prediction resistance enabled, and eight with prediction resistance turned off. For each of the eight test groups, four must have reseed enabled and four must have reseed turned off.

Each test group within the core sets of four test groups shall consist of 15 test cases each, such that minimum supported lengths and maximum supported lengths for the above parameters are used at least once across the four groups, and the rest are random lengths.

Correctness is determined by comparing the results from a known-good implementation using the same input parameters.

FCS_RBG.2 Random Bit Generation (External Seeding)

The inclusion of this selection-based component depends upon selection in:
The TSF shall be able to accept a minimum input of [assignment: minimum input length greater than zero] from a TSF interface for the purpose of seeding.
Application Note: This requirement is claimed when a DRBG is seeded with entropy from one or more noise source that is outside the TOE boundary. In the case of a mobile device this would likely only occur when the entropy source is a Dedicated Security Component that is integrated with the TOE. Typically the entropy produced by an environmental noise source is conditioned such that the input length has full entropy and is therefore usable as the seed. However, if this is not the case, it should be noted what the minimum entropy rate of the noise source is so that the TSF can collect a sufficiently large sample of noise data to be conditioned into a seed value.

This SFR is included in the ST when "TSF interface for seeding" is selected in FCS_RBG.1.2.
Evaluation Activities
FCS_RBG.2

The evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF external interface 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 sufficient entropy can be made available for the highest strength keys that the TSF can generate (e.g., 256 bits). If the seed data cannot be assumed to have full entropy (e.g., the min-entropy of the sampled bits is less than 1), the evaluator shall ensure that the entropy documentation describes the method by which the TOE estimates the amount of entropy that has been accumulated to ensure that sufficient data is collected and any conditioning that the TSF applies to the output data to create a seed of sufficient size with full 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:
The TSF shall be able to seed the RBG using a [selection, choose one of: TSF software-based noise source, TSF hardware-based noise source [assignment: name of noise source]] with a minimum of [assignment: number of bits] bits of min-entropy.
Application Note: The ST author claims this requirement when a TOE uses a single internal source of entropy to initialize or reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG.

Hardware-based noise sources are entropy sources whose primary function is noise generation, such as ring oscillators, diodes, and thermal noise. While a TOE may use software to collect the noise from these hardware sources, these are not software-based.

Software-based noise sources generate noise as a byproduct of their normal operation. Examples of software-based noise sources can be user or system-based events such as reading the least significant bits from an event timer, etc.

The TOE collects enough input from the internal noise source such that the total measured entropy of the input is sufficient to initialize or reseed a DRBG. The ST author ensures that the assignment is completed with the number of bits of the input sufficient to initialize or reseed a DRBG.

This SFR is included in the ST when "TSF entropy source" is selected in FCS_RBG.1.2.
Evaluation Activities
FCS_RBG.3
TSS
The evaluator shall verify that the TSS documents the types of entropy sources selected in FCS_RBG.3.1 and indicates the amount of entropy provided by these sources.
Guidance
The evaluator shall verify that the guidance describes any settings, operational requirements, or user input necessary for the proper function of the entropy sources.
Tests
The evaluator shall exercise the interface to determine whether the interface can handle at least the number of bits claimed in the assignment.

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

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

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall be able to seed the DRBG using [selection: [assignment: number] TSF software-based entropy sources, [assignment: number] TSF hardware-based entropy sources].
Application Note: The ST author claims this requirement when a TOE uses two or more internal sources of entropy to initialize or reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG. FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy.

This SFR is included in the ST when "multiple TSF entropy sources" is selected in FCS_RBG.1.2.
Evaluation Activities
FCS_RBG.4
TSS
The evaluator shall verify that the TSS documents number and the types of entropy sources selected in FCS_RBG.4.1.
Guidance
The evaluator shall verify that the Guidance describes any settings, operational requirements, or user input necessary for the proper function of the noise sources.
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:

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall [selection: hash, concatenate and hash, XOR, input into a linear feedback shift register, [assignment: combining operation]] [selection: output from TSF entropy noise sources, input from TSF interfaces for obtaining entropy] to create the entropy input into the derivation function as defined in [selection: ISO/IEC 18031:2011, NIST SP 800-90A Revision 1], resulting in a minimum of [assignment: number of bits] bits of min-entropy.
Application Note: The ST author claims this requirement when a TOE combines two or more sources of entropy to initialize or reseed a DRBG. Seeding a DRBG is the same as initializing a DRBG. The ST author ensures that the assignment is completed with the number of bits of the combined entropy sufficient to initialize or reseed a DRBG.

One can apply NIST SP 800-90B (or AIS-31) statistical tests against internal noise sources (aka raw entropy) to confirm the min-entropy of the noise sources either in aggregate or individually. One should not apply NIST SP 800-90B (or AIS-31) statistical tests against external noise sources since the TOE is unable to enforce entropy requirements or conditioning requirements against external sources of entropy. However, the TSS may include estimates for min-entropy from external sources that contribute to the overall entropy requirements for the DRBG.

This SFR is included in the ST when "multiple TSF entropy sources" is selected in FCS_RBG.1.2.
Evaluation Activities
FCS_RBG.5
TSS
The evaluator shall examine the TSS and verify that it documents the types of noise sources selected in FCS_RBG.5.1 and indicates the amount of entropy provided by these sources in combination.
Guidance
The evaluator shall verify that the guidance describes any settings, operational requirements, or user input necessary for the proper function of the noise sources.
Tests
The evaluator shall ensure that the combination of claimed entropy sources can provide at least the number of bits of entropy claimed in the assignment.

FCS_RBG.6 Random Bit Generation Service

This component may also be included in the ST as if optional.

The TSF shall provide a [selection: hardware, software, [assignment: other interface type]] interface to make the DRBG output, as specified in FCS_RBG.1 Random Bit Generation (RBG), available as a service to entities outside of the TOE.
Application Note: This SFR must be included in the ST if the TOE provides an entropy source accessible to tenant software.

This requirement ensures that the TOE makes available entropy to any tenant that requires it.
Evaluation Activities
FCS_RBG.6
TSS
The evaluator shall examine the TSS to verify that it describes how the DRBG output is made available to entities outside the TOE.
Guidance
The evaluator shall examine the guidance to verify that it describes how to configure and use the claimed interfaces so that DRBG output is available to entities outside of the TOE.
Tests
The evaluator shall perform the following test:

The evaluator shall invoke the entropy sources from tenant software. The evaluator shall verify that the tenant acquires values from the interface.

FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

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

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall encrypt [AKs, SKs, KEKs, and [selection: long-term trusted channel key material, all software-based key storage, no other keys]] using Key Wrapping as defined in FCS_COP.1/KeyWrap.
Application Note: This SFR is included in the ST if "software-based" is selected in FCS_STG_EXT.1.
Evaluation Activities
FCS_STG_EXT.2
TSS
The evaluator shall review the TSS to determine that the TSS describes the protection of symmetric keys, KEKs, long-term trusted channel key material, and software-based key storage as claimed in FCS_STG_EXT.2.1.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FCS_STG_EXT.3 Key Integrity Protection

The inclusion of this selection-based component depends upon selection in:
The TSF shall protect the integrity of any encrypted [AKs, SKs, KEKs, and [selection: long-term trusted channel key material, all software-based key storage, no other keys]] by using [selection:
  • Key wrapping accordance with FCS_COP.1/KeyWrap
  • A keyed hash of the stored key in accordance with FCS_COP.1/KeyedHash
  • A digital signature of the stored key in accordance with FCS_COP.1/SigGen using an asymmetric key that is protected in accordance with FCS_STG_EXT.2
  • An immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known information
].
Application Note: This SFR is included in the ST if "software-based" is selected in FCS_STG_EXT.1.
The TSF shall verify the integrity of the [selection: digital signature, MAC] of the stored key prior to use of the key.
Application Note: This requirement is not applicable to derived keys that are not stored. It is not expected that a single key will be protected from corruption by multiple of these methods; however, a product may use one integrity-protection method for one type of key and a different method for other types of keys.
Evaluation Activities
FCS_STG_EXT.3
TSS
The evaluator shall examine the TSS and ensure that it contains a description of how the TOE protects the integrity of its keys.
Guidance
There are no additional Guidance evaluation activities for this component.
KMD
The documentation of the product’s encryption key management should be detailed enough that, after reading, the evaluator will thoroughly understand the product’s key management and how it meets the requirements to ensure the keys are adequately protected. This documentation should include an essay and diagrams. This documentation may be marked as developer proprietary.
Tests
There are no test activities for this component.

B.2 Class FDP: User Data Protection

FDP_ITC_EXT.1 Key/Credential Import

The inclusion of this selection-based component depends upon selection in:
The TSF shall support importing keys/key material using [selection: physically protected channels as specified in FTP_ITP_EXT.1, encrypted data buffers as specified in FTP_ITE_EXT.1, key distribution mechanisms as specified in FCS_CKM.2]
The TSF shall verify the integrity of imported keys/key material using [selection: cryptographic hash as specified in FCS_COP.1/Hash, keyed hash as specified in FCS_COP.1/KeyedHash, integrity-providing encryption algorithm as specified in FCS_COP.1/KeyWrap, digital signature as specified in FCS_COP.1/SigVer, integrity verification provided through FCS_CKM.2, key distribution mechanisms, integrity verification supported by FTP_ITC_EXT.1/Admin]
Application Note: This SFR is included in the ST when "importing keys/secrets into the TOE" is selected in FCS_STG_EXT.1.

The way the TSF checks the integrity of the keys depends on the method of importation. For example, the encrypted data channel may provide data integrity as part of its service.
Evaluation Activities
FDP_ITC_EXT.1
TSS
The evaluator shall confirm the TSS contains descriptions of the supported methods the TSF uses to import keys and key material into the TOE. For each import method selected, the TSS shall describe integrity verification schemes employed.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
For each supported import method selected in FDP_ITC_EXT.1.1 and for each supported integrity verification method selected in FDP_ITC_EXT.1.2, used by the selected import method, provide one key/credential with valid integrity credentials, one with invalid integrity credentials (e.g., hash). The operations with invalid integrity credentials must result in error. The operations with valid integrity credentials must accept the keys/credentials.

B.3 Class FIA: Identification and Authentication

FIA_AFL_EXT.1 Authentication Failure Handling

The inclusion of this selection-based component depends upon selection in:
The TSF shall consider password and [selection: [assignment: other authentication mechanisms], no other authentication mechanisms] as critical authentication mechanisms.
Application Note: This SFR is included in the ST if the "administrator" role is selected in FMT_SMR.1.

If this SFR is included in the ST, then FCS_CKM.6 must also be claimed.

This SFR specifies the actions to be taken in the event of multiple authentication failures.

This requirement applies to both critical and non-critical authentication mechanisms. The difference between the two is that excessive authentication failures of critical authentication mechanisms result in the actions defined in FIA_AFL_EXT.1.5.

If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lockscreen interface, an auxiliary boot mode interface), this element applies to all available interfaces. For example, a password is a critical authentication mechanism regardless of if it is being entered at the DAR decryption interface or at a lockscreen interface.
The TSF shall detect when a configurable positive non-zero integer within [assignment: range of acceptable values for each authentication mechanism] of [selection, choose one of: unique, non-unique] unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism.
Application Note: The positive integer is configured according to Table 6 in FMT_SMF.1.1.

An unique authentication attempt is defined as any attempt to verify an authentication attempt in which the input is different from a previous attempt. "Unique" must be selected if the authentication system increments the counter only for unique unsuccessful authentication attempts. For example, if the same incorrect password is attempted twice the authentication system increments the counter once. "Non-unique" must be selected if the authentication system increments the counter for each unsuccessful authentication attempt, regardless of whether the input is unique. For example, if the same incorrect password is attempted twice the authentication system increments the counter twice.

If the TOE supports multiple authentication mechanisms per FIA_UAU.5.1, this element applies to all authentication mechanisms. It is acceptable for each authentication mechanism to utilize an independent counter or for multiple authentication mechanisms to utilize a shared counter. The interaction between the authentication factors with regard to the authentication counter must be in accordance with FIA_UAU.5.2.

If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lockscreen interface, an auxiliary boot mode interface), this element applies to all available interfaces. However, it is acceptable for each Authentication Factor interface to be configurable with a different number of unsuccessful authentication attempts.

The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off if the minimum boot time of the system is shorter than the lockout time specified in FIA_AFL_EXT.1.5.
Application Note: The purpose of this requirement is to prevent hammering attacks focused on a device's pre-OS-firmware from bypassing the actions in FIA_AFL_EXT.1.5 by power cycling the system in order to zero the authentication failure count. The intention is to protect the pre-OS firmware without making assumptions as to boot duration per device. This purpose is achieved by default if the minimum reboot time of the system is greater than the timeout penalty specified in FIA_AFL_EXT.1.5.

If the actions specified in FIA_AFL_EXT.1.5 are device wipe or a non-time-limited lockout, or if the minimum reboot time is shorter than the specified lockout time, then the authentication failure count must be maintained across power cycles. The variation of boot duration of individual devices and the configurability of FIA_AFL_EXT.1.5 may create scenarios where some devices are compliant by default (specifically slow-booting servers and workstations) while other devices (specifically fast-booting desktops and notebooks) may need to implement this requirement.

The TOE may implement an Authentication Factor interface that precedes another Authentication Factor interface in the boot sequence (for example, a volume DAR decryption interface which precedes the lockscreen interface) before the user can access the TOE. In this situation, because the user must successfully authenticate to the first interface to access the second, the number of unsuccessful authentication attempts need not be maintained for the second interface.
When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts shall be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism.
Application Note: See FIA_AFL_EXT.1.5 for exceeding the maximum failure threshold for critical authentication mechanisms.

In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off and powered back on.
When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or a critical authentication mechanism has been surpassed, the TSF shall [selection:
  • perform a wipe of all protected data
  • exclude the current administrator from further authentication attempts
  • exclude the current administrator from further authentication attempts for [assignment: a period of time greater than zero seconds]
  • exclude the current administrator from further authentication attempts for [assignment: a period of time greater than the minimum boot time of the system]
].
Application Note: The "current administrator" is the entity attempting to authenticate to the TOE that has run afoul of the limit on authentication attempts. For platforms that support multiple administrator identities, only the identity that has run afoul is punished. For platforms without such support, these actions are effectively applied to the authentication mechanism rather than a specific user.

Wipe is performed in accordance with FCS_CKM.6. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.

If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lockscreen interface, an auxiliary boot mode interface), this element applies to all available interfaces.
The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful.
Application Note: This requirement is to ensure that if power is cut to the device directly after an authentication attempt, the counter will be incremented to reflect that attempt.
Evaluation Activities
FIA_AFL_EXT.1
TSS
The evaluator shall ensure that the TSS describes that a value corresponding to the number of unsuccessful authentication attempts since the last successful authentication is kept for each Authentication Factor interface. The evaluator shall ensure that this description also includes if and how this value is maintained when the TOE loses power, either through a graceful powered off or an ungraceful loss of power. The evaluator shall ensure that if the value is not maintained, the interface is after another interface in the boot sequence for which the value is maintained.

If the TOE supports multiple authentication mechanisms, the evaluator shall ensure that this description also includes how the unsuccessful authentication attempts for each mechanism selected in FIA_UAU.5.1 is handled. The evaluator shall verify that the TSS describes if each authentication mechanism utilizes its own counter or if multiple authentication mechanisms utilize a shared counter. If multiple authentication mechanisms utilize a shared counter, the evaluator shall verify that the TSS describes this interaction.

The evaluator shall confirm that the TSS describes how the process used to determine if the authentication attempt was successful. The evaluator shall ensure that the counter would be updated even if power to the device is cut immediately following notifying the TOE user if the authentication attempt was successful or not.
Guidance
The evaluator shall verify that the AGD describes how the administrator configures the maximum number of unique unsuccessful authentication attempts, and the lockout time period, if applicable.

The evaluator shall verify that the AGD describes how an administrator may recover from authentication failure when another administrator is locked out.
Tests
The evaluator shall configure the device with all authentication mechanisms selected in FIA_UAU.5.1, and configure a maximum number of unsuccessful authentication attempts for each mechanism.

  • Test FIA_AFL_EXT.1:1: The evaluator shall for each authentication mechanism make unsuccessful authentication attempts until the maximum is exceeded and verify that the number of failures corresponds to the configured maximum and that no further authentication attempts can be made using that mechanism.

  • Test FIA_AFL_EXT.1:2: [conditional] If the mechanism is critical or if all authentication mechanisms are exhausted, then if "perform a wipe of all protected data" is selected in FIA_AFL_EXT.1.5 the evaluator shall verify that the wipe is implemented.

  • Test FIA_AFL_EXT.1:3: [conditional] If the mechanism is critical or if all authentication mechanisms are exhausted, then if "exclude the current user/administrator from further authentication attempts" is selected in FIA_AFL_EXT.1.5 the evaluator shall verify that the user/administrator can make no further authentication attempts.

  • Test FIA_AFL_EXT.1:4: [conditional] If the mechanism is critical or if all authentication mechanisms are exhausted, then if "exclude the current user/administrator from further authentication attempts for a period of [assignment: greater than zero seconds] time" is selected in FIA_AFL_EXT.1.5 the evaluator shall verify that the user/administrator can make no further authentication attempts until the specified time period has expired.

FIA_UAU.5 Multiple Authentication Mechanisms

This component must be included in the ST if any of the following SFRs are included:
The TSF shall provide [password and [selection: certificate-based authentication, public key-based authentication, biometric authentication, no other mechanism]] to support user authentication.
Application Note: This SFR is included in the ST if the "administrator" role is selected in FMT_SMR.1.

A "user" in the context of this SFR is an administrator.

The TSF must support a Password Authentication Factor and may optionally implement a biometric authentication factor.

The Password Authentication Factor is configured according to FIA_PMG_EXT.1.

If "X.509 certificate-based authentication" is selected, then the ST must include FIA_X509_EXT.1 and FIA_X509_EXT.2 from.

If "public key-based authentication" is selected, then the ST must claim the.
The TSF shall authenticate any user's claimed identity according to the [assignment: rules describing how the multiple authentication mechanisms provide authentication].
Application Note: Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL_EXT.1.
Evaluation Activities
FIA_UAU.5
TSS
The evaluator shall ensure that the TSS describes each mechanism provided to support user authentication and the rules describing how the authentication mechanisms provide authentication.

Specifically, for all authentication mechanisms specified in FIA_UAU.5.1, the evaluator shall ensure that the TSS describes the rules as to how each authentication mechanism is used. Example rules are how the authentication mechanism authenticates the user (i.e. how does the TSF verify that the correct password or biometric sample was entered), the result of a successful authentication (i.e. is the user input used to derive or unlock a key) and which authentication mechanism can be used at which authentication factor interfaces (i.e. if there are times, for example, after a reboot, that only specific authentication mechanisms can be used). If multiple Biometric Authentication Factors (BAF) are supported per FIA_UAU.5.1, the interaction between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time.
Guidance
The evaluator shall verify that configuration information for each authentication mechanism is addressed in the AGD guidance.
Tests
  • Test FIA_UAU.5:1: For each authentication mechanism selected in FIA_UAU.5.1, the evaluator shall enable that mechanism and verify that it can be used to authenticate the user at the specified authentication factor interfaces.

  • Test FIA_UAU.5:2: For each authentication mechanism rule, the evaluator shall ensure that the authentication mechanism behaves accordingly.

FIA_UAU.7 Protected Authentication Feedback

The inclusion of this selection-based component depends upon selection in:
The TSF shall provide only [obscured feedback] to the user while the authentication is in progress.
Application Note: This SFR is included in the ST if the "administrator" role is selected in FMT_SMR.1.

This requirement applies to all authentication mechanisms specified in FIA_UAU.5.1 that provide feedback to a user or administrator during authentication.

For authentication mechanisms that require the user or administrator to enter a password or PIN, the TSF may briefly (1 second or less) display each character or provide an option to allow the user to unmask the user input; however, the user input must be obscured by default.

If a BAF is selected in FIA_UAU.5.1, the TSF must not display sensitive information regarding the biometric that could aid an adversary in identifying or spoofing the respective biometric characteristics of a given human user. While it is true that biometric samples, by themselves, are not secret, the analysis performed by the respective biometric algorithms, as well as output data from these biometric algorithms, is considered sensitive and must be kept secret. Where applicable, the TSF must not reveal or make public the reasons for authentication failure.

In the cases of SSH- or X.509-based authentication, the TSF must likewise not display sensitive information regarding the authentication factors that could aid an adversary in spoofing or circumventing the authentication protocols.
Evaluation Activities
FIA_UAU.7
TSS
The evaluator shall ensure that the TSS describes the means of obscuring the authentication information for all authentication methods specified in FIA_UAU.5.1.
Guidance
The evaluator shall verify that any configuration of this requirement is addressed in the AGD guidance and that user authentication input is obscured by default.
Tests
The evaluator shall perform the following tests:
  • Test FIA_UAU.7:1: The evaluator shall enter passwords on the device, including at least the Password Authentication Factor at lockscreen, and verify that the password is not displayed on the device.

  • Test FIA_UAU.7:2: [conditional] For each Biometric Authentication Factor (BAF) selected in FIA_UAU.5.1, the evaluator shall authenticate by producing a biometric sample at lockscreen. As the biometric algorithms are performed, the evaluator shall verify that sensitive images, audio, or other information identifying the user are kept secret and are not revealed to the user. Additionally, the evaluator shall produce a biometric sample that fails to authenticate and verify that the reasons for authentication failure (user mismatch, low sample quality, etc.) are not revealed to the user. It is acceptable for the BAF to state that it was unable to physically read the biometric sample, for example, if the sensor is unclean or the biometric sample was removed too quickly. However, specifics regarding why the presented biometric sample failed authentication shall not be revealed to the user. [conditional] For each SSH- or X.509-based authentication mechanism, the evaluator shall examine whether the TSF displays sensitive information during the authentication process for both successful and failed authentication attempts.

FIA_UAU_EXT.1 Authentication for Cryptographic Operation

The inclusion of this selection-based component depends upon selection in:
The TSF shall require the user to present the Password Authentication Factor prior to decryption of protected data and encrypted DEKs, KEKs and [selection: long-term trusted channel key material, all software-based key storage, no other keys] at startup.
Application Note: The intent of this requirement is to prevent decryption of protected data before the user has authorized to the device using the Password Authentication Factor. The Password Authentication Factor is also required in order derive the key used to decrypt sensitive data, which includes software-based secure key storage.
Evaluation Activities
FIA_UAU_EXT.1
TSS
The evaluator shall verify that the TSS section of the ST describes the process for decrypting protected data and keys. The evaluator shall ensure that this process requires the user to enter a Password Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK, which is used to protect the software-based secure key storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
The following tests may be performed in conjunction with FDP_DAR_EXT.1 and FDP_DAR_EXT.2.

Evaluation Activity Note: The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.

  • Test FIA_UAU_EXT.1:1: The evaluator shall enable encryption of protected data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a unique string treated as protected data.

    The evaluator shall reboot the device, use a tool provided by developer to search for the unique string within the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by the developer to access the unique string within the application data, and verify that the unique string can be found.


  • Test FIA_UAU_EXT.1:2: [conditional] The evaluator shall require user authentication according to the AGD guidance. The evaluator shall store a key in the software-based secure key storage.

    The evaluator shall lock the device, use a tool provided by developer to access the key within the stored data, and verify that the key cannot be retrieved or accessed. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the key, and verify that the key can be retrieved or accessed.


  • Test FIA_UAU_EXT.1:3: [conditional] The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a unique string treated as sensitive data.

    The evaluator shall lock the device, use a tool provided by developer to attempt to access the unique string within the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the unique string within the application data, and verify that the unique string can be retrieved.

FIA_UIA_EXT.1 Administrator Authentication

This component must be included in the ST if any of the following SFRs are included:
The TSF shall require administrators to be successfully authenticated using one of the methods in FIA_UAU.5 before allowing any TSF-mediated management function to be performed by that administrator.
Application Note: This SFR is included in the ST if the "administrator" role is selected in FMT_SMR.1.

Ordinary unprivileged users of the platform need not authenticate to the platform, though they may well have to authenticate themselves to tenant software such as an Operating System.

The TSF-mediated management functions are listed in the management functions table (Table 6) in FMT_SMF.1.
Evaluation Activities
FIA_UIA_EXT.1
TSS
The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the platform. 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 AGD to determine that any necessary preparatory steps (e.g., establishing credential material such as pre-shared keys, tunnels, certificates) to logging in are described. For each supported login method, the evaluator shall ensure the AGD provides clear instructions for successfully logging on. If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the AGD provides sufficient instruction on limiting the allowed services.
Tests
There are no test activities for this component.

B.4 Class FPT: Protection of the TSF

FPT_FLS.1 Failure with Preservation of Secure State

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

This component must be included in the ST if any of the following SFRs are included:
The TSF shall preserve a secure state by terminating sessions when the following types of failures occur: [
  • dead peer detected
  • recovery failure
  • provisioning failure
].
Application Note: 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_RVR_EXT.1 Platform Firmware Recovery

The inclusion of this selection-based component depends upon selection in:
The TSF shall implement a mechanism for recovering from boot firmware failure consisting of [selection:
  • the secure local update mechanism described in FPT_TUD_EXT.4
  • installation of a known-good or recovery firmware image
  • reversion to the prior firmware image
  • installation of a recovery image that puts the TOE into a maintenance mode
].
Application Note: This SFR must be included in the ST if: If the ST author selects "the secure local update mechanism described in FPT_TUD_EXT.4," then FPT_TUD_EXT.4 must be claimed in the ST.

As indicated above, in addition to integrity or update failure, the TOE may use a recovery mechanism to deal with non-security-related failures, such as a power outage during update or a power surge during normal operation.

The recovery process may be initiated automatically on failure, as the result of physically present user action, or as the result of pre-configured policy. The action taken may depend on the nature of the failure as specified in FPT_ROT_EXT.2.2 and FPT_TUD_EXT.2.5.

Evaluation Activities
FPT_RVR_EXT.1
TSS
The evaluator shall examine the TSS section to confirm that it describes how the platform firmware recovery mechanism works and the conditions under which it is invoked.
Guidance
The evaluator shall examine the AGD to ensure that is describes how to configure the conditions under which the recovery mechanism is initiated (if configurable).
Tests
The evaluator shall perform the following tests:
  • Test FPT_RVR_EXT.1:1: To test this requirement, the evaluator shall trigger the recovery process either by forcing an update error or a boot integrity failure and observing that the recovery process has been initiated.

  • Test FPT_RVR_EXT.1:2: The evaluator shall engage with the recovery process as necessary, and after recovery will determine the version of the current firmware image. The test is passed if the resultant image is as expected in accordance with policy and the selections in FPT_RVR_EXT.1.1. If the recovery process uses the secure local update process as specified in FPT_TUD_EXT.4, then this test is satisfied by testing of that requirement.

FPT_TUD_EXT.2 Platform Firmware Authenticated Update Mechanism

The inclusion of this selection-based component depends upon selection in:
The TSF shall authenticate the source of all platform firmware updates using a digital signature algorithm specified in FCS_COP.1/SigVer and using a key store that contains [selection: the public key, hash value of the public key].
Application Note: This SFR must be included in the ST if "an authenticated platform firmware update mechanism as described in FPT_TUD_EXT.2" is selected in FPT_TUD_EXT.1.1.

The ST must include FCS_COP.1/Hash if "hash value of the public key" is selected.
The TSF shall allow installation of updates only if the digital signature has been successfully verified as specified in FCS_COP.1/SigVer and [selection: the version number of the platform firmware update is more recent than the version number of the current installed platform firmware, no other conditions].
Application Note: The ST author should select "the version number... " if the TSF supports rollback prevention. That is, the TSF does not allow "update" to an older version of the platform firmware. In general, rollback should be permitted only through a secure local update mechanism at the express direction of an physically present administrator or user.
The TSF shall include a platform firmware version identifier that is accessible by the update mechanism and includes information that enables the update mechanism to determine the relative order of updates.
The TSF shall provide an observable indication of the success or failure of the update operation.
Application Note: For success, this indication should include the version number of the newly installed firmware. Notification of failure could include generation of an audit event by a management subsystem, a beep code, an updated version number on a splash screen, or simple failure to continue functioning.
The TOE shall take the following actions if a platform firmware integrity, authenticity, or rollback-prevention check fails, or a platform firmware update fails for any other reason:
  • Do not install the update,
and [selection, choose one of:
  • Continue execution
  • Halt
  • Stop all execution and shut down
  • Initiate recovery as specified in FPT_RVR_EXT.1
]
[selection, choose one of:
  • automatically
  • in accordance with administrator-configurable policy
  • by express determination of a user
].
Application Note: If "generating an audit event" is selected, then FAU_GEN.1 and the other audit requirements must be claimed.

If "Initiate recovery as specified in FPT_RVR_EXT.1" is selected, then FPT_RVR_EXT.1 must be included in the ST.

The platform firmware authenticated update mechanism employs digital signatures to ensure the authenticity of the firmware update image. The TSF includes a signature verification algorithm and a key store containing the public key needed to verify the signature on the firmware update image.

A hash of the public key may be stored if a copy of the public key is provided with firmware update images. In this case, the update mechanism hashes the public key provided with the update image, and ensure that it matches a hash which appears in the key store before using the provided public key to verify the signature of the update image. If the hash of the public key is selected, the ST author may iterate the FCS_COP.1/Hash requirement to specify the hashing functions used.

An indication of success or failure can be generation of an audit event by a management subsystem, a beep code, an updated version number on a splash screen, or simple failure to continue functioning.

If the update mechanism generates audit events, the ST author must make the appropriate selections from the audit events table (Table t-audit-sel-based).

In the selection "by express determination of a user," the "user" could be more properly expressed as the "operator." It can be either a user or an administrator, but the distinction is not important in the context of this requirement.
Evaluation Activities
FPT_TUD_EXT.2

TSS
The evaluator shall ensure that the TSS includes a comprehensive description of how the authentication of platform firmware updates is implemented by the TSF. The TSS should cover the initialization process and the activities that are performed to ensure that the digital signature of the update image is verified before modification of the firmware.

The evaluator shall examine the TSF to ensure that it describes the platform firmware version identifier and explains its meaning and encoding.

The evaluator shall also ensure that the TSS describes the actions taken by the TSF is an update image fails authentication.
Guidance
The evaluator shall examine the AGD to ensure that it describes the process for updating the platform firmware.

The evaluator shall examine the AGD to ensure that it documents the observable indications of update success or failure, and that it describes how to access the platform firmware version indicators.
Tests
The evaluator shall perform the following tests:
  • Test FPT_TUD_EXT.2:1: The evaluator determines the current version of the platform firmware, and obtains or produces a valid, authentic, and permissible update image of platform firmware. The evaluator initiates an update using this image through the process described in the operational guidance. After the process is complete, the evaluator checks the current firmware version to ensure that the new firmware version matches that of the update.

  • Test FPT_TUD_EXT.2:2: The evaluator performs the same test, this time using a valid update image that is signed with an incorrect key. The update must fail.

  • Test FPT_TUD_EXT.2:3: The evaluator performs the same test, this time using an update image that is corrupted but is signed with the correct key. The update must fail.

  • Test FPT_TUD_EXT.2:4: The evaluator performs the same test, this time using a valid update image that is not signed. The update must fail.

  • Test FPT_TUD_EXT.2:5: [conditional] If the TSF implements rollback protections, the evaluator performs the same test, this time using a valid, signed update image that has an earlier version number than the currently installed firmware. The update must fail.

FPT_TUD_EXT.3 Platform Firmware Delayed-Authentication Update Mechanism

The inclusion of this selection-based component depends upon selection in:
The TSF shall allow execution or use of platform firmware updates only if new platform firmware is integrity- and authenticity-checked using the mechanism described in FPT_ROT_EXT.2 prior to its execution or use, and [selection: the version number of the platform firmware update is more recent than the version number of the previously installed platform firmware, no other conditions].
Application Note: This requirement must be included in the ST if "implement a delayed-authentication platform firmware update mechanism as described in FPT_TUD_EXT.3" is selected in FPT_TUD_EXT.1.1.

This update mechanism does not require an integrity or authenticity check prior to installation, but the newly installed platform firmware must have its integrity and authenticity verified prior to being executed or used. This update mechanism takes advantage of the existing FPT_ROT_EXT.2 requirement to avoid having to verify the integrity and authenticity of an update package at install time.

The ST author should select "the version number of the platform firmware update is more recent than the version number of the previously installed platform firmware" if the TSF supports rollback prevention.
The TSF shall include an observable platform firmware version identifier that is accessible by the update mechanism and includes information that enables the update mechanism to determine the relative order of updates.
The TSF shall provide an observable indication of the success or failure of the update operation.
Application Note: For success, this should at least include an indication of the version number of the newly installed firmware. Notification of failure could include generation of an audit event by a management subsystem, a beep code, an updated version number on a splash screen, or simple failure to continue functioning.
The TOE shall take the following actions if a platform firmware update integrity, authentication, or rollback-prevention check fails, or a platform firmware update fails for any other reason: [selection, choose one of:
  • Halt
  • Stop all execution and shut down
  • Initiate a recovery process as specified in FPT_RVR_EXT.1
]
[selection, choose one of:
  • automatically
  • in accordance with administrator-configurable policy
  • by express determination of a user
].
Application Note: If "generating an audit event" is selected, then FAU_GEN.1 and the other audit SFRs must be claimed.

If "Initiate recovery as specified in FPT_RVR_EXT.1" is selected, then FPT_RVR_EXT.1 must be included in the ST.

The platform firmware unauthenticated update mechanism installs platform firmware updates without first checking their integrity or authenticity. Instead, this mechanism either invokes a special authentication/integrity check on the firmware in situ after install or relies on the firmware checks required by FPT_ROT_EXT.2 to ensure the integrity and authenticity of the update image. In either case, the integrity and authenticity of the update must be verified before the updated firmware is executed or used.

Likewise, if the TSF implements rollback prevention, this check must be made before the newly installed firmware is executed.

In the selection "by express determination of a user," the "user" could be more properly expressed as the "operator." It can be either a user or an administrator, but the distinction is not important in the context of this requirement.
Evaluation Activities
FPT_TUD_EXT.3

TSS
The evaluator shall ensure that the TSS includes a comprehensive description of how the authentication of platform firmware updates is implemented by the TSF. The TSS should cover the initialization process and the activities that are performed to ensure that the digital signature of the update image is verified before it is executed or used.

The evaluator shall examine the TSF to ensure that it describes the platform firmware version identifier and explains its meaning and encoding.

The evaluator shall also ensure that the TSS describes the actions taken by the TSF if an update image fails authentication, integrity, or rollback-prevention checks.
Guidance
The evaluator shall examine the AGD to ensure that it describes the process for updating the platform firmware.

The evaluator shall examine the AGD to ensure that it documents the observable indications of update success or failure, and that it describes how to access the platform firmware version indicators.
Tests
The evaluator shall perform the following tests:
  • Test FPT_TUD_EXT.3:1: The evaluator determines the current version of the platform firmware, and obtains or produces a valid, authentic, and permissible update image of platform firmware. The evaluator initiates an update using this image through the process described in the operational guidance. After the process is complete, the evaluator checks the current firmware version to ensure that the new firmware version matches that of the update.

  • Test FPT_TUD_EXT.3:2: The evaluator performs the same test, this time using a inauthentic update image. The update code must fail to execute.

  • Test FPT_TUD_EXT.3:3: The evaluator performs the same test, this time using an update image that is corrupted but is otherwise authentic. The update code must fail to execute.

  • Test FPT_TUD_EXT.3:4: [conditional] If the TSF implements rollback protections, the evaluator performs the same test, this time using a valid, signed update image that is has an earlier version number than the currently installed firmware. The update code must fail to execute.

FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism

The inclusion of this selection-based component depends upon selection in:
The TSF shall provide a secure local update mechanism that requires an assertion of physical access to the TOE before installation of an update.
A user shall assert physical presence to the TSF through: [selection:
  • login to the TOE from a physically connected console or terminal
  • physical connection of a jumper or cable
  • connection to a debug port
  • [assignment: description of other mechanism for asserting physical presence]
].
Application Note: The requirement included in the ST if "the secure local update mechanism described in FPT_TUD_EXT.4" is selected in FPT_RVR_EXT.1.1 or "implement a secure local platform firmware update mechanism described in FPT_TUD_EXT.4" is selected in FPT_TUD_EXT.1.1.

This requirement pertains to platform firmware update mechanisms that do not use the authentication-based update mechanism described in FPT_TUD_EXT.2 or the delayed-authentication described in FPT_TUD_EXT.3. The secure local update mechanism ensures the authenticity and integrity of the firmware update image by requiring a user to be physically present at the TOE. An assertion of physical presence can take the form, for example, of requiring entry of a password at a boot screen, unlocking of a physical lock (e.g., a motherboard jumper), or inserting a USB cable before permitting platform firmware to be updated.

There is no requirement that the local update mechanism support rollback prevention.

The local update mechanism must be a designed mechanism. If update can be accomplished only through the physical removal and replacement of a part, then that is not a secure local update mechanism, and "make no provision for platform firmware update" should be selected in FPT_TUD_EXT.1.1.

The TSF shall include a platform firmware version identifier that is accessible by the update mechanism or to the user who asserts physical presence.
The TSF shall provide an observable indication of the success or failure of the update operation.
Application Note: For success, this indication should include the version number of the newly installed firmware. Notification of failure could be through a beep code, an indication on a splash screen, or simple failure to continue functioning.
Evaluation Activities
FPT_TUD_EXT.4
TSS
The evaluator shall check the TSS section to confirm that it clearly and thoroughly describes how the secure local update functionality is implemented.
Guidance
The evaluator shall examine the AGD to ensure that it describes instructions for using the local update mechanism, and how to validate that the update was successful.
Tests
The evaluator shall perform the following tests:
  • Test FPT_TUD_EXT.4:1: The evaluator tests the secure local update by following the instructions provided in the operational guidance to update the platform firmware image. The update must succeed.

  • Test FPT_TUD_EXT.4:2: The evaluator next tries to update the platform firmware image without first asserting physical presence. The update must fail or be not possible.

B.5 Class FTP: Trusted Path/Channel

FTP_ITC_EXT.1/Admin Physically Protected Channel

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

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall use [selection: ] protocols with [selection, choose one of: X.509 certificate-based authentication of the remote peer, non-certificate-based authentication of the remote peer, no authentication of the remote peer] to provide a communication channel between itself and [selection:
  • audit servers (as required by FAU_STG.1.1 if selected)
  • remote administrators (as required by FTP_TRP.1.1 if selected in FMT_MOF.1)
  • [assignment: other capabilities]
  • no other capabilities
] that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
Application Note: This SFR is included in the ST if a trusted channel is used to offload audit data or if the platform is administered remotely. That is, if "a trusted channel as specified in FTP_ITC_EXT.1/Admin" is selected in FAU_STG.1.1, if "physically protected channels as specified in FTP_ITP_EXT.1" is selected in FDP_ITC_EXT.1.1, or if "remotely" is selected in Management Function 1 in FMT_SMF.1.1.

If the ST author selects either "TLS" or "HTTPS," the TOE must be validated against the Functional Package for Transport Layer Security (TLS), version 2.1. This PP does not mandate that a product implement TLS with mutual authentication, but if the product includes the capability to perform TLS with mutual authentication, then mutual authentication must be included within the TOE boundary.

If the ST author selects "SSH," the TOE must conform to Functional Package for Secure Shell (SSH), version 2.0.

If the ST author selects "certificate-based authentication of the remote peer," then the TOE must conform to Functional Package for X.509, version 1.0.

Claims from this package are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed.

If the TSF implements a protocol that requires the validation of a certificate presented by an external entity, FIA_X509_EXT.1 and FIA_X509_EXT.2 will be claimed. FIA_TSM_EXT.1 may also be claimed if the TSF implements its own trust store. If the TSF implements a protocol that requires the presentation of any certificates to an external entity, FIA_XCU_EXT.2 will be claimed. FIA_X509_EXT.3 will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.
Evaluation Activities
FTP_ITC_EXT.1/Admin
TSS
The evaluator shall review the TSS to determine that it lists all trusted channels the TOE uses for remote communications, including both the external IT entities and remote users that use the channel as well as the protocol that is used for each.
Guidance
The evaluator shall confirm that the AGD contains instructions for establishing connections to external IT entities and remote users.
Tests
The evaluator will configure the TOE to communicate with each external IT entity and type of remote user identified in the TSS. The evaluator will monitor network traffic while the VS performs communication with each of these destinations. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the selection.

FTP_ITP_EXT.1 Physically Protected Channel

The inclusion of this selection-based component depends upon selection in:
The TSF shall provide a physically protected communication channel between itself and [assignment: list of other IT entities within the same platform].
Application Note: This SFR focuses on persistent internal communication channels and does not apply to communication channels intended for use with external media, ephemeral devices, or peripherals. This SFR must be claimed if "physically protected channels as specified in FTP_ITP_EXT.1" is selected in FDP_ITC_EXT.1.
Evaluation Activities
FTP_ITP_EXT.1
TSS
The evaluator shall review the TSS to determine that it lists all mechanisms the TOE uses for physically protected external communications, along with the types of communications protected using each mechanism.
Guidance
There are no additional Guidance evaluation activities for this component.
Tests
There are no test activities for this component.

FTP_TRP.1 Trusted Path

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

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall use a trusted channel as specified in FTP_ITC_EXT.1/Admin to provide a trusted communication path between itself 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 permit [remote administrators] to initiate communication via the trusted path.
The TSF shall require the use of the trusted path for [[all remote administrator actions]]
Application Note: This SFR is included in the ST if "remotely" is selected in Management Function 1 of FMT_SMF.1.1.

Protocols used to implement the remote administration trusted channel must be selected in FTP_ITC_EXT.1/Admin.

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 the protocol chosen in the first selection in FTP_ITC_EXT.1/Admin.
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.
Guidance
The evaluator shall confirm that the AGD 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: Test FTP_TRP.1:1: The evaluator shall ensure that communications using each specified (in the AGD) remote administration method is tested during the course of the evaluation, setting up the connections as described in the AGD and ensuring that communication is successful.

  • Test FTP_TRP.1:2: Test FTP_TRP.1:2: For each method of remote administration supported, the evaluator shall follow the AGD 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: Test FTP_TRP.1:3: The evaluator shall ensure, for each method of remote administration, the channel data is not sent in plaintext.

  • Test FTP_TRP.1:4: Test FTP_TRP.1:4: The evaluator shall ensure, for each method of remote administration, modification of the channel data is detected by the TOE.

Additional 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 23: Extended Component Definitions
Functional ClassFunctional Components
Class FCS: Cryptographic SupportFCS_CKM_EXT Cryptographic Key Management
FCS_HTTPS_EXT HTTPS Protocol
FCS_REC_EXT Key Recovery
FCS_REKEY_EXT Periodic Rekey
FCS_STG_EXT Key Storage and Protection
Class FDP: User Data ProtectionFDP_BRINGUP_EXT Secure Bring-Up
FDP_ITC_EXT Key/Credential Import
FDP_PBR_EXT Protocol Break Enforcement
FDP_STG_EXT User Data Storage
Class FIA: Identification and AuthenticationFIA_AFL_EXT Authentication Failure Handling
FIA_PMG_EXT Password Management
FIA_PSK_EXT Pre-Shared Key Composition
FIA_TRT_EXT Authentication Throttling
FIA_UAU_EXT User Authentication
FIA_UIA_EXT Administrator Authentication
Class FPF: Packet FilteringFPF_RUL_EXT Packet Filtering
Class FPT: Protection of the TSFFPT_APW_EXT Protection of Administrator Password
FPT_BBD_EXT Baseband Processing
FPT_DPD_EXT Baseband Processing
FPT_ISO_EXT EU and CU Isolation
FPT_JTA_EXT JTAG Disablement
FPT_KST_EXT Key Storage
FPT_NOT_EXT Self-Test Notification
FPT_PPF_EXT Protection of Platform Firmware
FPT_RBP_EXT Rollback Protection
FPT_ROT_EXT Platform Integrity
FPT_RVR_EXT Platform Firmware Recovery
FPT_SEP_EXT Hardware-Enforced Separation Between TOE Subsystems
FPT_SKP_EXT Protection of TSF Data
FPT_TRAN_EXT Transaction Control
FPT_TST_EXT TSF Testing
FPT_TUD_EXT Trusted Updates
Class FTA: TOE AccessFTA_SSL_EXT Session Locking and Termination
Class FTP: Trusted Path/ChannelFTP_ITC_EXT Trusted Channel Communications
FTP_ITP_EXT Physically Protected Channel

C.2 Extended Component Definitions

C.2.1 Class FCS: Cryptographic Support

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

C.2.1.1 FCS_CKM_EXT Cryptographic Key Management

Family Behavior

This family defines requirements for management of cryptographic keys that are not addressed by FCS_CKM 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 attributes, and object values 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],
[FCS_CKM.1 Cryptographic key generation, or
FCS_CKM.5 Cryptographic key derivation, or
FCS_CKM_EXT.8 Password-based key derivation] and
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation] and
FCS_CKM.6 Timing and event of cryptographic key destruction and
[FCS_COP.1 Cryptographic operation, or
no other dependencies].

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.1.2 FCS_HTTPS_EXT HTTPS Protocol

Family Behavior

This family defines requirements for implementation of the HTTPS protocol.

Component Leveling

FCS_HTTPS_EXT1

FCS_HTTPS_EXT.1, HTTPS Protocol, requires the TSF to implement the HTTPS protocol in accordance with the specified standard, using TLS, and notifying the application if invalid.

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 to establish an HTTPS Session

FCS_HTTPS_EXT.1 HTTPS Protocol

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

FCS_HTTPS_EXT.1.1

The TSF shall implement the HTTPS protocol that complies with RFC 2818.

FCS_HTTPS_EXT.1.2

The TSF shall implement HTTPS using TLS as defined in [assignment: specification that defines TLS implementation requirements].

C.2.1.3 FCS_REC_EXT Key Recovery

Family Behavior

This family defines requirements for session key recovery.

Component Leveling

FCS_REC_EXT1

FCS_REC_EXT.1, Periodic Rekey, requires the TSF to perform session rekey under specific circumstances.

Management: FCS_REC_EXT.1

There are no management activities foreseen.

Audit: FCS_REC_EXT.1

There are no auditable events foreseen.

FCS_REC_EXT.1 Periodic Rekey

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

C.2.1.4 FCS_REKEY_EXT Periodic Rekey

Family Behavior

This family defines requirements for session rekeying.

Component Leveling

FCS_REKEY_EXT

C.2.1.5 FCS_STG_EXT Key Storage and Protection

Family Behavior

This family defines requirements for managing key storage and protection.

Component Leveling

FCS_STG_EXT123

FCS_STG_EXT.1, Protected Storage, requires the TSF to enforce protected storage for keys and secrets so that they cannot be accessed or destroyed without authorization.

FCS_STG_EXT.2, Encrypted Cryptographic Key Storage, requires the TSF to ensure the confidentiality of stored data using a specified method.

FCS_STG_EXT.3, Key Integrity Protection, requires the TSF to ensure the integrity of stored data using a specified method.

Management: FCS_STG_EXT.1

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

  • Ability to manage import and export keys/secrets to and from protected storage.

Audit: FCS_STG_EXT.1

There are no audit events foreseen.

FCS_STG_EXT.1 Protected Storage

Hierarchical to:No other components.
Dependencies to:FCS_CKM.6 Timing and Event of Cryptographic Key Destruction

FCS_STG_EXT.1.1

The TSF shall provide [assignment: protected storage type] protected storage for asymmetric private keys and [assignment: secrets to be stored].

FCS_STG_EXT.1.2

The TSF shall support the capability of [assignment: capability for acquiring keys] upon request of [assignment: entity requesting storage].

FCS_STG_EXT.1.3

The TSF shall be capable of destroying keys and secrets in the protected storage upon request of [assignment: authorized subject].

FCS_STG_EXT.1.4

The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be explicitly authorized by [assignment: authorized role].

FCS_STG_EXT.1.5

The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by [assignment: authorized role].

Management: FCS_STG_EXT.2

There are no management functions foreseen.

Audit: FCS_STG_EXT.2

There are no audit events foreseen.

FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation
FCS_STG_EXT.1 Protected Storage

FCS_STG_EXT.2.1

The TSF shall encrypt [assignment: types of key material] using [assignment: cryptographic algorithm].

Management: FCS_STG_EXT.3

There are no management functions foreseen.

Audit: FCS_STG_EXT.3

There are no audit events foreseen.

FCS_STG_EXT.3 Key Integrity Protection

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation

FCS_STG_EXT.3.1

The TSF shall protect the integrity of any encrypted [assignment: types of key material] by using [assignment: integrity protection mechanism].

FCS_STG_EXT.3.2

The TSF shall verify the integrity of the [selection: digital signature, MAC] of the stored key prior to use of the key.

C.2.2 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.2.1 FDP_BRINGUP_EXT Secure Bring-Up

Family Behavior

This family defines requirements for preventing traffic flow until certain conditions are met.

Component Leveling

FDP_BRINGUP_EXT1

FDP_BRINGUP_EXT.1, Secure Bring-Up, requires the TSF to prevent traffic flow until authentication and credentials are met.

Management: FDP_BRINGUP_EXT.1

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

  • Ability to configure the activation mechanism used for secure bring-up, where the TOE supports PIN or CIK options.
  • Ability to initiate or re-initiate session setup following provision of required activation credentials.
  • Ability to manage the operational state associated with traffic suppression prior to successful bring-up, where such management is exposed by the TOE.

Audit: FDP_BRINGUP_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:

  • Provision of PIN or CIK credentials for secure bring-up.
  • Successful completion of session setup and authentication resulting in release of traffic gating.
  • Failure of secure bring-up due to missing or invalid activation credentials, or failure of session setup or authentication.

FDP_BRINGUP_EXT.1 Secure Bring-Up

Hierarchical to:No other components.
Dependencies to: FIA_UAU.2/PFED Mutual Authentication Before Any Action

FIA_UAU.3/PFED Multiple Authentication Mechanisms

No other dependencies

FDP_BRINGUP_EXT.1.1

The TSF shall prevent any traffic flow until:
  • PIN or CIK credentials are supplied
  • Session setup and authentication complete
.

C.2.2.2 FDP_ITC_EXT Key/Credential Import

Family Behavior

This family defines requirements for supporting and integrity of importing keys and key material.

Component Leveling

FDP_ITC_EXT1

FDP_ITC_EXT.1, Key/Credential Import, requires the TSF to choose a method for importing keys and key material.

Management: FDP_ITC_EXT.1

There are no management activities foreseen.

Audit: FDP_ITC_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:

  • Initiation of the trusted channel.
  • Termination of the trusted channel.
  • Failures of the trusted path functions.

FDP_ITC_EXT.1 Key/Credential Import

Hierarchical to:No other components.
Dependencies to:FTP_ITP_EXT.1 Physically Protected Channel

FTP_ITE_EXT.1 Encrypted Data Communications

FCS_CKM.2 Cryptographic Key Distribution

FCS_COP.1 Cryptographic Operations

FDP_ITC_EXT.1.1

The TSF shall support importing keys/key material using [assignment: import method].

FDP_ITC_EXT.1.2

The TSF shall verify the integrity of imported keys/key material using [assignment: method of integrity verification].

C.2.2.3 FDP_PBR_EXT Protocol Break Enforcement

Family Behavior

This family defines requirements for enforcing a Layer-2 protocol break when forwarding traffic between untrusted black Transport Networks and trusted components. A protocol break prevents transparent Layer-2 bridging across trust boundaries.

A Layer-2 protocol break is defined as the stripping (decapsulation) and replacement (encapsulation) of Layer-2 headers when forwarding traffic between interfaces, preventing transparent bridging across trust boundaries.

The CU represents the minimum TOE configuration supported by this Protection Profile and provides the network-facing boundary between trusted components and untrusted networks.

Component Leveling

FDP_PBR_EXT1

FDP_PBR_EXT.1, Layer-2 Protocol Break, requires the TSF to ensure and manage the use of a Layer-2 protocol break.

Management: FDP_PBR_EXT.1

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

  • Ability to configure or manage the routing and forwarding behavior that determines when traffic is forwarded between an untrusted black transport network interface and a trusted interface.
  • Ability to configure or manage the interface roles relevant to protocol-break enforcement, including trusted interfaces and untrusted black transport network interfaces.
  • Ability to configure or manage the treatment of traffic that is not protected by Ethernet-layer cryptographic mechanisms and therefore requires a Layer-2 protocol break.
  • Ability to configure or manage the drop behavior for traffic that cannot be forwarded in accordance with the protocol-break and cryptographic-continuity requirements.

Audit: FDP_PBR_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:

  • Changes to forwarding, routing, or related policy that affect protocol-break enforcement across the trust boundary.
  • Dropping of traffic that cannot be routed or forwarded in accordance with the protocol-break or cryptographic-continuity requirements.
  • Detection of attempts to forward traffic in a manner that would violate the required protocol-break behavior or transparent-bridging prohibition, if such detection is exposed by the TOE.

FDP_PBR_EXT.1 Layer-2 Protocol Break

Hierarchical to:No other components.
Dependencies to: FMT_SMF.1 Specification of Management Functions

FAU_GEN.1 Audit Data Generation

No other dependencies.

FDP_PBR_EXT.1.1

The TSF shall ensure that all traffic forwarded between an untrusted black Transport Network interface and a trusted interface undergoes a Layer-2 protocol break.

FDP_PBR_EXT.1.2

The TSF shall perform a Layer-2 protocol break when forwarding traffic that is not protected by Ethernet-layer cryptographic mechanisms across a trust boundary by:
  • Removing the complete incoming Layer-2 header and associated Layer-2 control information (decapsulation); and
  • Constructing and applying a new Layer-2 header (encapsulation) prior to transmission on the egress interface

FDP_PBR_EXT.1.3

The TSF shall prevent transparent Layer-2 bridging between untrusted black Transport Network interfaces and trusted interfaces.

FDP_PBR_EXT.1.4

The TSF shall forward Ethernet frames that contain cryptographic protections applied by a trusted component without:
  • Removing, modifying, or replacing the protected Layer-2 header
  • Terminating, decrypting, inspecting, or re-origination cryptographic protection
  • Disrupting cryptographic continuity across the trust boundary.

FDP_PBR_EXT.1.5

The TSF shall not act as a cryptographic endpoint for user data traffic and shall not terminate, decrypt, or re-originate cryptographic protection for traffic transmitted between trusted components and untrusted black transport networks.

C.2.2.4 FDP_STG_EXT User Data Storage

Family Behavior

This family defines requirements for managing data storage.

Component Leveling

FDP_STG_EXT1

FDP_STG_EXT.1, User Data Storage, requires the TSF to be able to label, encrypt, store, and decrypt sensitive data and keys.

Management: FDP_STG_EXT.1

There are no management activities foreseen.

Audit: FDP_STG_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 to encrypt/decrypt data.

FDP_STG_EXT.1 User Data Storage

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation
FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

FDP_STG_EXT.1.1

The TSF shall provide protected storage for the Trust Anchor Database.

C.2.3 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.3.1 FIA_AFL_EXT Authentication Failure Handling

Family Behavior

This family defines requirements for the TOE’s behavior when repeated failed attempts to gain authorization to access TSF data occur.

Component Leveling

FIA_AFL_EXT1

FIA_AFL_EXT.1, Authentication Failure Handling, requires the TSF to monitor authorization attempts, including counting and limiting the number of attempts at failed or passed authorizations. This extended component permits considerably more flexibility for dealing with multiple authentication mechanisms than FIA_AFL.

Management: FIA_AFL_EXT.1

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

  • Ability to set parameters for allowable number of authentication failures.

Audit: FIA_AFL_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:

  • Failed attempt at administrator authentication.

FIA_AFL_EXT.1 Authentication Failure Handling

Hierarchical to:No other components.
Dependencies to:FCS_CKM.6 Timing and Event of Cryptographic Key Destruction
FIA_SMF.1 Specification of Management Functions

FIA_AFL_EXT.1.1

The TSF shall consider password and [assignment: type of authentication mechanisms] as critical authentication mechanisms.

FIA_AFL_EXT.1.2

The TSF shall detect when a configurable positive non-zero integer within [assignment: range of acceptable values for each authentication mechanism] of [selection, choose one of: unique, non-unique] unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism.

FIA_AFL_EXT.1.3

The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off if the minimum boot time of the system is shorter than the lockout time specified in FIA_AFL_EXT.1.5.

FIA_AFL_EXT.1.4

When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts shall be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism.

FIA_AFL_EXT.1.5

When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or a critical authentication mechanism has been surpassed, the TSF shall [assignment: rules for unsuccessful authentication attempts].

FIA_AFL_EXT.1.6

The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful.

C.2.3.2 FIA_PMG_EXT Password Management

Family Behavior

This family defines requirements for the composition of administrator passwords.

Component Leveling

FIA_PMG_EXT1

FIA_PMG_EXT.1, Password Management, requires the TSF to support passwords with varying composition and length requirements.

Management: FIA_PMG_EXT.1

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

  • Ability to configure password composition and length requirements for authorization of administrators.
  • Ability to manage authentication methods and change default authorization factors

Audit: FIA_PMG_EXT.1

There are no audit 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 support the following for the Password Authentication Factor:
  1. Passwords shall be able to be composed of any combination of [assignment: characters sets], numbers, and special characters: [assignment: special characters].
  2. Password length up to [assignment: an integer greater than or equal to 14] characters shall be supported.

C.2.3.3 FIA_PSK_EXT Pre-Shared Key Composition

Family Behavior

This family defines requirements for the use of pre-shared keys.

Component Leveling

FIA_PSK_EXT1

FIA_PSK_EXT.1, Pre-Shared Key Composition, requires the TSF to allow the use of pre-shared keys and the ability to accept and generate them.

Management: FIA_PSK_EXT.1

There are no management functions foreseen.

Audit: FIA_PSK_EXT.1

There are no audit events foreseen.

FIA_PSK_EXT.1 Pre-Shared Key Composition

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

FIA_PSK_EXT.1.1

The TSF shall be able to use pre-shared keys that conform to RFC 8784 for IPsec

FIA_PSK_EXT.1.2

The TSF shall be able to [selection: accept externally generated pre-shared keys, generate 256 bit-based pre-shared keys via FCS_RBG.1].

C.2.3.4 FIA_TRT_EXT Authentication Throttling

Family Behavior

This family defines requirements for managing the number of authentication attempts.

Component Leveling

FIA_TRT_EXT1

FIA_TRT_EXT.1, Authentication Throttling, requires the TSF to limit user authentication attempts.

Management: FIA_TRT_EXT.1

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

  • Ability to configure authentication throttling policy.

Audit: FIA_TRT_EXT.1

There are no audit events foreseen.

FIA_TRT_EXT.1 Authentication Throttling

Hierarchical to:No other components.
Dependencies to:FIA_UAU.5 Multiple Authentication Mechanisms

FIA_TRT_EXT.1.1

The TSF shall limit automated user authentication attempts by [selection: preventing authentication via an external port, enforcing a delay between incorrect authentication attempts] for all authentication mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500 milliseconds.

C.2.3.5 FIA_UAU_EXT User Authentication

Family Behavior

This family defines requirements for user authentication that are not addressed by FIA_UAU in CC Part 2.

Component Leveling

FIA_UAU_EXT12

FIA_UAU_EXT.1, Authentication for Cryptographic Operation, requires the TSF enforce data-at-rest protection until successful authentication has occurred.

FIA_UAU_EXT.2, Timing of Authentication, requires the TSF to prevent a subject’s use of TOE until the user is authenticated.

Management: FIA_UAU_EXT.1

There are no management activities foreseen.

Audit: FIA_UAU_EXT.1

There are no auditable events foreseen.

FIA_UAU_EXT.1 Authentication for Cryptographic Operation

Hierarchical to:No other components.
Dependencies to:FDP_DAR_EXT.1 Protected Data Encryption
FDP_DAR_EXT.2 Sensitive Data Encryption

FIA_UAU_EXT.1.1

The TSF shall require the user to present the Password Authentication Factor prior to decryption of protected data and encrypted DEKs, KEKs and [assignment: types of keys].

Management: FIA_UAU_EXT.2

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

  • Enabling/disabling display TSF notifications while in the locked state.
  • Enabling/disabling bypass of local user authentication.

Audit: FIA_UAU_EXT.2

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

  • Action performed before authentication

FIA_UAU_EXT.2 Timing of Authentication

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

FIA_UAU_EXT.2.1

The TSF shall allow [selection: [assignment: list of actions], no actions] on behalf of the user to be performed before the user is authenticated.

FIA_UAU_EXT.2.2

The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.

C.2.3.6 FIA_UIA_EXT Administrator Authentication

Family Behavior

This family defines requirements for authenticating administrators.

Component Leveling

FIA_UIA_EXT1

FIA_UIA_EXT.1, Administrator Authentication, requires the TSF to ensure that all subjects attempting to perform TSF-mediated actions are authenticated prior to authorizing these actions to be performed.

Management: FIA_UIA_EXT.1

There are no management functions foreseen.

Audit: FIA_UIA_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:

  1. All use of the authentication mechanism.

FIA_UIA_EXT.1 Administrator Authentication

Hierarchical to:No other components.
Dependencies to:FIA_UAU.5 Multiple Authentication Mechanisms

FIA_UIA_EXT.1.1

The TSF shall require administrators to be successfully authenticated using one of the methods in FIA_UAU.5 before allowing any TSF-mediated management function to be performed by that administrator.

C.2.4 Class FPF: Packet Filtering

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

C.2.4.1 FPF_RUL_EXT Packet Filtering

Family Behavior

This family defines requirements for using packet filtering.

Component Leveling

FPF_RUL_EXT1

FPF_RUL_EXT.1, Packet Filtering Rules, requires the TSF to perform packet filtering using specific protocols.

Management: FPF_RUL_EXT.1

There are no management activities foreseen.

Audit: FPF_RUL_EXT.1

There are no auditable events foreseen.

FPF_RUL_EXT.1 Packet Filtering Rules

Hierarchical to:No other components.
Dependencies to:

FPF_RUL_EXT.1.1

The TSF shall perform packet filtering on network packets processed by the TOE.

FPF_RUL_EXT.1.2

The TSF shall allow the definition of packet filtering rules using the following network protocols and protocol fields: [
  • IPv4 (RFC 791)
    • source address
    • destination address
    • protocol
  • IPv6 (RFC 8200)
    • source address
    • destination address
    • next header (protocol)
  • TCP (RFC 793)
    • source port
    • destination port
  • UDP (RFC 768)
    • source port
    • destination port
]

FPF_RUL_EXT.1.3

The TSF shall allow the following operations to be associated with packet filtering rules: permit and drop with the capability to log the operation.

FPF_RUL_EXT.1.4

The TSF shall allow the packet filtering rules to be assigned to each distinct network interface.

FPF_RUL_EXT.1.5

The TSF shall process the applicable packet filtering rules (as determined in accordance with FPF_RUL_EXT.1.4) in the following order: [assignment: rule processing order].

FPF_RUL_EXT.1.6

The TSF shall drop traffic if a matching rule is not identified.

C.2.5 Class FPT: Protection 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 FPT_APW_EXT Protection of Administrator Password

Family Behavior

Components in this family ensure that the TSF will protect plaintext administrator credential data such as passwords from unauthorized disclosure.

Component Leveling

FPT_APW_EXT1

FPT_APW_EXT.1, Protection of Administrator Password, requires that the TSF prevent plaintext administrator credential data from being read by any user or subject.

Management: FPT_APW_EXT.1

There are no management activities foreseen.

Audit: FPT_APW_EXT.1

There are no auditable events foreseen.

FPT_APW_EXT.1 Protection of Administrator Password

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

FPT_APW_EXT.1.1

The TSF shall store administrative passwords in non-plaintext form.

FPT_APW_EXT.1.2

The TSF shall prevent the reading of plaintext administrative passwords.

C.2.5.2 FPT_BBD_EXT Baseband Processing

Family Behavior

This family defines requirements for separation of baseband and application processor execution.

Component Leveling

FPT_BBD_EXT1

FPT_BBD_EXT.1, Application Processor Mediation, requires the TSF to enforce separation between baseband and application processor execution except through application processor mechanisms.

Management: FPT_BBD_EXT.1

There are no management activities foreseen.

Audit: FPT_BBD_EXT.1

There are no auditable events foreseen.

FPT_BBD_EXT.1 Application Processor Mediation

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

FPT_BBD_EXT.1.1

The TSF shall prevent code executing on any baseband processor (BP) from accessing application processor (AP) resources except when mediated by the AP.

C.2.5.3 FPT_DPD_EXT Baseband Processing

Family Behavior

This family defines requirements for detecting peer failure.

Component Leveling

FPT_DPD_EXT1

FPT_DPD_EXT.1, Dead Peer Detection, requires the TSF to detect peer failure under specified conditions.

Management: FPT_DPD_EXT.1

There are no management activities foreseen.

Audit: FPT_DPD_EXT.1

There are no auditable events foreseen.

FPT_DPD_EXT.1 Dead Peer Detection

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

FPT_DPD_EXT.1.1

The TSF shall detect peer failure using:
  • RFC 3706 mechanisms or keep-alive beacons
  • Trigger session reconnect upon failure or disconnect notification

C.2.5.4 FPT_ISO_EXT EU and CU Isolation

Family Behavior

This family defines requirements for ensuring compliance to the sent requirement.

Component Leveling

FPT_ISO_EXT1

FPT_ISO_EXT.1, Isolation, requires the TSF to ensure the use of EU and CU.

Management: FPT_ISO_EXT.1

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

  • Ability to configure or verify the deployment mode or TOE configuration that enforces PFED EU/CU isolation.
  • Ability to manage or verify interface exposure such that EU interfaces remain non-addressable and stateless in the claimed operational configuration.
  • Ability to manage or verify network-namespace isolation where such configuration is exposed by the TOE.
  • Ability to manage or verify the allowed intercomponent communication path such that only the claimed connectionless bus is shared.

Audit: FPT_ISO_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:

  • Changes to configuration affecting EU/CU isolation properties.
  • Detection of an attempt to violate network-namespace isolation, if such detection is exposed by the TOE.
  • Detection of an attempt to use a communication path other than the shared connectionless bus between EU and CU, if such detection is exposed by the TOE.

FPT_ISO_EXT.1 Isolation

Hierarchical to:No other components.
Dependencies to:FMT_SMF.1 Specification of Management Functions

FAU_GEN.1 Audit Data Generation

No other dependencies

C.2.5.5 FPT_JTA_EXT JTAG Disablement

Family Behavior

This family defines requirements for disabling JTAG.

Component Leveling

FPT_JTA_EXT1

FPT_JTA_EXT.1, JTAG Disablement, requires the TSF to disable JTAG through a selected method.

Management: FPT_JTA_EXT.1

There are no management activities foreseen.

Audit: FPT_JTA_EXT.1

There are no auditable events foreseen.

FPT_JTA_EXT.1 JTAG Disablement

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

FPT_JTA_EXT.1.1

The TSF shall [assignment: access method] to JTAG.

C.2.5.6 FPT_KST_EXT Key Storage

Family Behavior

This family defines requirements for protecting plaintext keys.

Component Leveling

FPT_KST_EXT123

FPT_KST_EXT.1, Key Storage, requires the TSF to avoid storage of plaintext keys in readable memory.

FPT_KST_EXT.2, No Key Transmission, requires the TSF to prevent transmitting plaintext key material to the operational environment.

FPT_KST_EXT.3, No Plaintext Key Export, requires the TSF to prevent the export of plaintext keys.

Management: FPT_KST_EXT.1

There are no management activities foreseen.

Audit: FPT_KST_EXT.1

There are no auditable events foreseen.

FPT_KST_EXT.1 Key Storage

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

FPT_KST_EXT.1.1

The TSF shall not store any plaintext key material in readable non-volatile memory.

Management: FPT_KST_EXT.2

There are no management activities foreseen.

Audit: FPT_KST_EXT.2

There are no auditable events foreseen.

FPT_KST_EXT.2 No Key Transmission

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

FPT_KST_EXT.2.1

The TSF shall not transmit any plaintext key material outside the security boundary of the TOE.

Management: FPT_KST_EXT.3

There are no management activities foreseen.

Audit: FPT_KST_EXT.3

There are no auditable events foreseen.

FPT_KST_EXT.3 No Plaintext Key Export

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

FPT_KST_EXT.3.1

The TSF shall ensure it is not possible for the TOE users to export plaintext keys.

C.2.5.7 FPT_NOT_EXT Self-Test Notification

Family Behavior

This family defines requirements for generation of notifications in response to completed self-tests.

Component Leveling

FPT_NOT_EXT1

FPT_NOT_EXT.1, Self-Test Notification, requires the TSF to become non-operational when certain failures occur.

Management: FPT_NOT_EXT.1

There are no management activities foreseen.

Audit: FPT_NOT_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:

  • Measurement of TSF software.

FPT_NOT_EXT.1 Self-Test Notification

Hierarchical to:No other components.
Dependencies to:FPT_TST_EXT.1 TSF Cryptographic Functionality Testing

FPT_NOT_EXT.1.1

The TSF shall transition to non-operational mode and [selection: log failures in the audit record, notify the administrator, [assignment: other actions], no other actions] when the following types of failures occur:
  • Failures of the self-tests
  • TSF software integrity verification failures
  • [selection: no other failures, [assignment: other failures]]

C.2.5.8 FPT_PPF_EXT Protection of Platform Firmware

Family Behavior

This family defines requirements for protecting platform firmware from unauthorized update.

Component Leveling

FPT_PPF_EXT1

FPT_PPF_EXT.1, Protection of Platform Firmware and Critical Data, requires that the TSF prevent platform firmware from being modified outside of the update mechanisms defined in FPT_TUD_EXT.

Management: FPT_PPF_EXT.1

There are no management functions foreseen.

Audit: FPT_PPF_EXT.1

There are no audit events foreseen.

FPT_PPF_EXT.1 Protection of Platform Firmware and Critical Data

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

FPT_PPF_EXT.1.1

The TSF shall allow modification of platform firmware and critical data only through the update mechanisms described in FPT_TUD_EXT.1.

C.2.5.9 FPT_RBP_EXT Rollback Protection

Family Behavior

This family requires that the TSF protects against rollbacks or downgrades to its firmware.

Component Leveling

FPT_RBP_EXT1

FPT_RBP_EXT.1, Rollback Protection, requires the TSF to detect and prevent unauthorized rollback.

Management: FPT_RBP_EXT.1

There are no management functions foreseen.

Audit: FPT_RBP_EXT.1

There are no audit events foreseen.

FPT_RBP_EXT.1 Rollback Protection

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

FPT_RBP_EXT.1.1

The TSF shall verify that the new firmware package is not downgrading to a lower security version number by [assignment: method of verifying the security version number is the same as or higher than the currently installed version].

FPT_RBP_EXT.1.2

The TSF shall generate and return an error code if the attempted firmware update package is detected to be an invalid version.

C.2.5.10 FPT_ROT_EXT Platform Integrity

Family Behavior

This family defines requirements for platform firmware and hardware integrity.

Component Leveling

FPT_ROT_EXT12

FPT_ROT_EXT.1, Platform Integrity Root, requires that the platform integrity be anchored in a root of trust.

FPT_ROT_EXT.2, Platform Integrity Extension, specifies how platform integrity is extended from the integrity root to other platform firmware.

Management: FPT_ROT_EXT.1

There are no management functions foreseen.

Audit: FPT_ROT_EXT.1

There are no audit events foreseen.

FPT_ROT_EXT.1 Platform Integrity Root

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

FPT_ROT_EXT.1.1

The integrity of platform firmware shall be rooted in [assignment: platform firmware root of trust].

Management: FPT_ROT_EXT.2

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

  • Configuration of action to take on integrity failure.

Audit: FPT_ROT_EXT.2

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

FPT_ROT_EXT.2 Platform Integrity Extension

Hierarchical to:No other components.
Dependencies to:FPT_ROT_EXT.1 Platform Integrity Root

FPT_ROT_EXT.2.1

The integrity of all mutable platform firmware outside of the platform integrity root specified in FPT_ROT_EXT.1 shall be verified prior to execution or use through: [assignment: method for extending the platform integrity root].

FPT_ROT_EXT.2.2

The TOE shall take the following actions if an integrity check specified in FPT_ROT_EXT.2.1 fails: [selection:
  • Stop all execution, or
  • Notify an [selection: administrator, user] by [selection: generating an audit event, [assignment: other notification methods]], and [selection:
    • Stop all execution
    • Shut down, or
    • Initiate a recovery process as specified in FPT_RVR_EXT.1
    • Skip all instructions that failed the integrity check and continue execution
    ][selection:
    • automatically
    • in accordance with administrator-configurable policy
    • by express determination of an [selection: administrator, user]
    ]
].

C.2.5.11 FPT_RVR_EXT Platform Firmware Recovery

Family Behavior

This family defines requirements for recovering from a firmware integrity failure.

Component Leveling

FPT_RVR_EXT1

FPT_RVR_EXT.1, Platform Firmware Recovery, defines mechanisms for recovering from a platform firmware integrity failure.

Management: FPT_RVR_EXT.1

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

  • Configuration of action to take on integrity failure.

Audit: FPT_RVR_EXT.1

There are no audit events foreseen.

FPT_RVR_EXT.1 Platform Firmware Recovery

Hierarchical to:No other components.
Dependencies to:FPT_TUD_EXT.4 Secure Local Update Mechanism

FPT_RVR_EXT.1.1

The TSF shall implement a mechanism for recovering from boot firmware failure consisting of [assignment: recovery mechanism].

C.2.5.12 FPT_SEP_EXT Hardware-Enforced Separation Between TOE Subsystems

Family Behavior

This family defines requirements for hardware-enforced physical and logical separation between TOE subsystems such that compromise of one subsystem does not permit direct compromise of the other.

Component Leveling

FPT_SEP_EXT1

FPT_SEP_EXT.1, TSF Domain Separation, requires the TSF to maintain separation between security domains for the EU and CU.

Management: FPT_SEP_EXT.1

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

  • Ability to configure or verify the TOE deployment mode that enforces separate EU and CU security domains.
  • Ability to verify the processor, memory, and interconnect configuration used to preserve EU/CU separation, where such verification is exposed by the TOE.
  • Ability to configure or verify the dedicated wired interface used for EU/CU communication, where such configuration is exposed by the TOE.
  • Ability to configure or verify that no alternate communication path exists between the EU and CU, where such verification is exposed by the TOE.

Audit: FPT_SEP_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:

  • Changes to TOE configuration affecting EU/CU separation properties.
  • Detection of an attempted violation of the required EU/CU separation properties, if such detection is exposed by the TOE.
  • Detection of an attempted use of a non-permitted communication path between the EU and CU, if such detection is exposed by the TOE.

FPT_SEP_EXT.1 TSF Domain Separation

Hierarchical to:No other components.
Dependencies to:FMT_SMF.1 Specification of Management Functions

FAU_GEN.1 Audit Data Generation

No other dependencies

FPT_SEP_EXT.1.1

The TSF shall maintain a security domain for the Encryption Unit (EU) and a separate security domain for the Communication Unit (CU) within the TOE.

FPT_SEP_EXT.1.2

The TSF shall enforce separation between the EU and CU such that:
  • The EU executes on a processor that is physically distinct from the processor used by the CU
  • The EU uses dedicated volatile and non-volatile memory resources that are physically distinct from those used by the CU
  • Independent execution environments
  • No shared memory exists between the EU and CU
  • Direct memory access from the EU to CU memory is not possible
  • Direct memory access from the CU to EU memory is not possible
  • All communication between the EU and CU is restricted to a dedicated wired interface that is part of the TSF boundary

C.2.5.13 FPT_SKP_EXT Protection of TSF Data

Family Behavior

Components in this family define requirements for managing and protecting TSF data, such as cryptographic keys.

Component Leveling

FPT_SKP_EXT1

FPT_SKP_EXT.1, Protection of TSF Data (for reading of all symmetric keys), requires preventing symmetric keys from being read by any user or subject.

Management: FPT_SKP_EXT.1

There are no management activities foreseen.

Audit: FPT_SKP_EXT.1

There are no auditable events foreseen.

FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)

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

FPT_SKP_EXT.1.1

The TSF shall prevent reading of all pre-shared, symmetric keys, and private keys.

C.2.5.14 FPT_TRAN_EXT Transaction Control

Family Behavior

This family defines requirements for controlling transactions.

Component Leveling

FPT_TRAN_EXT1/PFED

FPT_TRAN_EXT.1/PFED, Transaction Control, requires that the TSF allow only one transaction at a time.

Management: FPT_TRAN_EXT.1/PFED

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

  • Ability to configure or verify the transaction-control policy that limits the TOE to one active PFED transaction at a time.
  • Ability to configure or verify the reaper-timer value or timer policy, where such configuration is exposed by the TOE.
  • Ability to manage or observe the operational state associated with transaction timeout, cleanup, or restart behavior.
  • Ability to initiate or re-initiate the next permitted PFED transaction after completion, timeout, or abort of the current transaction, where such control is exposed by the TOE.

Audit: FPT_TRAN_EXT.1/PFED

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

  • Start of a PFED transaction, if audited by the TOE.
  • Rejection of an attempted nested or concurrent PFED transaction.
  • Expiration of the reaper timer and the resulting transaction cleanup, abort, or restart behavior, if audited by the TOE.

FPT_TRAN_EXT.1/PFED Transaction Control

Hierarchical to:No other components.
Dependencies to:FMT_SMF.1 Specification of Management Functions

FAU_GEN.1 Audit Data Generation

No other dependencies

FPT_TRAN_EXT.1.1/PFED

The TSF shall allow only one transaction at a time, prohibit nesting, and enforce a reaper timer.

C.2.5.15 FPT_TST_EXT TSF Testing

Family Behavior

This family defines requirements for running self-tests.

Component Leveling

FPT_TST_EXT1

FPT_TST_EXT.1, TSF Testing, requires the TSF to run self-test at start-up to verify correct operation.

Management: FPT_TST_EXT.1

There are no management activities foreseen.

Audit: FPT_TST_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:

  • Initiation of self-test.
  • Failure of self-test.

FPT_TST_EXT.1 TSF Testing

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation

FPT_TST_EXT.1.1

The TSF shall run a suite of the following self-tests.
  • During initial start-up (on power on) to verify the integrity of the TOE firmware and software
  • Prior to providing any cryptographic service and [selection: at no other time, on-demand, continuously [assignment: conditions under which self-tests should occur]] to verify correct operation of cryptographic implementation necessary to fulfil the TSF
  • [selection: no other, start-up, on-demand, continuous, at the conditions [assignment: conditions under which self-tests should occur] self tests[assignment: 'list an identifier for each self-test that is additional to those identified in the first two bullet points']]
to demonstrate the correct operation of the TSF.

FPT_TST_EXT.1.2

The TSF shall respond to [selection: all failures, [assignment: list of failures detected by self-tests]] by [selection: entering a maintenance mode, rebooting, [assignment: other methods to enter a secure state]].

C.2.5.16 FPT_TUD_EXT Trusted Updates

Family Behavior

This family defines requirements for applying updates to the TOE.

Component Leveling

FPT_TUD_EXT1234

FPT_TUD_EXT.1, TOE Firmware Update, requires that the TSF support update of platform firmware.

FPT_TUD_EXT.2, Platform Firmware Authenticated Update Mechanism, specifies the requirements for authenticated update of platform firmware.

FPT_TUD_EXT.3, Platform Firmware Delayed-Authentication Update Mechanism, specifies the requirements for delayed-authentication update of platform firmware.

FPT_TUD_EXT.4, Secure Local Platform Firmware Update Mechanism, specifies the requirements for secure local update of platform firmware.

Management: FPT_TUD_EXT.1

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

  • Initiation of the update process.

Audit: FPT_TUD_EXT.1

There are no audit events foreseen.

FPT_TUD_EXT.1 TOE Firmware Update

Hierarchical to:No other components.
Dependencies to:FPT_TUD_EXT.2 Platform Firmware Authenticated Update Mechanism
FPT_TUD_EXT.3 Platform Firmware Delayed-Authentication Update Mechanism
FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism

FPT_TUD_EXT.1.1

The TSF shall implement [assignment: update mechanism].

Management: FPT_TUD_EXT.2

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

  • Configuration of action to take on an update failure.

Audit: FPT_TUD_EXT.2

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 update authentication/integrity check/rollback
  • Failure of update operation
  • Success of update operation

FPT_TUD_EXT.2 Platform Firmware Authenticated Update Mechanism

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operations

FPT_TUD_EXT.2.1

The TSF shall authenticate the source of all platform firmware updates using a digital signature algorithm specified in FCS_COP.1 and using a key store that contains [selection: the public key, hash value of the public key].

FPT_TUD_EXT.2.2

The TSF shall allow installation of updates only if the digital signature has been successfully verified as specified in FCS_COP.1 and [assignment: additional constraints on updates].

FPT_TUD_EXT.2.3

The TSF shall include a platform firmware version identifier that is accessible by the update mechanism and includes information that enables the update mechanism to determine the relative order of updates.

FPT_TUD_EXT.2.4

The TSF shall provide an observable indication of the success or failure of the update operation.

FPT_TUD_EXT.2.5

The TOE shall take the following actions if a platform firmware integrity, authenticity, or rollback-prevention check fails, or a platform firmware update fails for any other reason:
  • Do not install the update,
and [selection, choose one of:
  • Continue execution
  • Halt
  • Stop all execution and shut down
  • Initiate recovery as specified in FPT_RVR_EXT.1
] [selection, choose one of:
  • automatically
  • in accordance with administrator-configurable policy
  • by express determination of a user
].

Management: FPT_TUD_EXT.3

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

  • Configuration of action to take on an update failure.

Audit: FPT_TUD_EXT.3

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 update authentication/integrity check/rollback
  • Failure of update operation
  • Success of update operation

FPT_TUD_EXT.3 Platform Firmware Delayed-Authentication Update Mechanism

Hierarchical to:No other components.
Dependencies to:FPT_ROT_EXT.2 Platform Integrity Extension

FPT_TUD_EXT.3.1

The TSF shall allow execution or use of platform firmware updates only if new platform firmware is integrity- and authenticity-checked using the mechanism described in FPT_ROT_EXT.2 prior to its execution or use, and [assignment: additional constraints on update].

FPT_TUD_EXT.3.2

The TSF shall include an observable platform firmware version identifier that is accessible by the update mechanism and includes information that enables the update mechanism to determine the relative order of updates.

FPT_TUD_EXT.3.3

The TSF shall provide an observable indication of the success or failure of the update operation.

FPT_TUD_EXT.3.4

The TOE shall take the following actions if a platform firmware update integrity, authentication, or rollback-prevention check fails, or a platform firmware update fails for any other reason: [selection, choose one of:
  • Halt
  • Stop all execution and shut down
  • Initiate a recovery process as specified in FPT_RVR_EXT.1
]
[selection, choose one of:
  • automatically
  • in accordance with administrator-configurable policy
  • by express determination of a user
].

Management: FPT_TUD_EXT.4

There are no management functions foreseen.

Audit: FPT_TUD_EXT.4

There are no audit events foreseen.

FPT_TUD_EXT.4 Secure Local Platform Firmware Update Mechanism

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

FPT_TUD_EXT.4.1

The TSF shall provide a secure local update mechanism that requires an assertion of physical access to the TOE before installation of an update.

FPT_TUD_EXT.4.2

A user shall assert physical presence to the TSF through: [assignment: method for asserting physical presence].

FPT_TUD_EXT.4.3

The TSF shall include a platform firmware version identifier that is accessible by the update mechanism or to the user who asserts physical presence.

FPT_TUD_EXT.4.4

The TSF shall provide an observable indication of the success or failure of the update operation.

C.2.6 Class FTA: TOE Access

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

C.2.6.1 FTA_SSL_EXT Session Locking and Termination

Family Behavior

This family defines requirements for session locking capabilities that are not addressed by FTA_SSL in CC Part 2.

Component Leveling

FTA_SSL_EXT1

FTA_SSL_EXT.1, TSF- and TSF-initiated Session Blocking, requires the TSF to manage the transition to a locked state and what operations can be performed.

Management: FTA_SSL_EXT.1

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

  • Configuring session locking policy.
  • Transitioning to the locked state.

Audit: FTA_SSL_EXT.1

There are no auditable events foreseen.

FTA_SSL_EXT.1 TSF- and TSF-initiated Session Blocking

Hierarchical to:No other components.
Dependencies to:FMT_SMR.1 Security Roles
FPT_STM.1 Reliable Time Stamps

FTA_SSL_EXT.1.1

The TSF shall, for local interactive sessions, [selection: lock the session - disable any activity of the administrator’s data access and display devices other than unlocking the session, and requiring that the administrator reauthenticate to the TSF prior to unlocking the session, terminate the session] after a security administrator-specified time period of inactivity.

FTA_SSL_EXT.1.2

The TSF shall transition to a locked state after initiation by either the user or the administrator.

FTA_SSL_EXT.1.3

The TSF shall, upon transitioning to the locked state, perform the following operations:
  • Clearing or overwriting display devices, obscuring the previous contents;
  • [assignment: Other actions performed upon transitioning to the locked state].

C.2.7 Class FTP: Trusted Path/Channel

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

C.2.7.1 FTP_ITC_EXT Trusted Channel Communications

Family Behavior

This family defines requirements for protection of data in transit between the TOE and its operational environment.

Component Leveling

FTP_ITC_EXT1

FTP_ITC_EXT.1, Physically Protected Channel, requires the TSF to implement one or more cryptographic protocols to secure connectivity between the TSF and various external entities.

Management: FTP_ITC_EXT.1

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

  1. Ability to configure the cryptographic functionality.

Audit: FTP_ITC_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:

  1. Initiation of the trusted channel.
  2. Termination of the trusted channel.
  3. Failures of the trusted path functions.

FTP_ITC_EXT.1 Physically Protected Channel

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

C.2.7.2 FTP_ITP_EXT Physically Protected Channel

Family Behavior

This family defines requirements for use of physically protected communications mechanisms.

Component Leveling

FTP_ITP_EXT1

FTP_ITP_EXT.1, Physically Protected Channel, requires the TSF to use a physically protected channel for transmission of data to an external entity.

Management: FTP_ITP_EXT.1

There are no management functions foreseen.

Audit: FTP_ITP_EXT.1

There are no audit events foreseen.

FTP_ITP_EXT.1 Physically Protected Channel

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

FTP_ITP_EXT.1.1

The TSF shall provide a physically protected communication channel between itself and [assignment: list of other IT entities within the same platform].

Appendix D - Entropy Documentation and Assessment

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

The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon 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.

D.1 Design Description

Documentation shall include the design of the 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 shall describe how unprocessed (raw) data was obtained for the analysis. This description shall be sufficiently detailed to explain at what point in the entropy source model the data was collected and what effects, if any, the process of data collection had on the overall entropy generation rate. 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/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 RBG. A description of any RBG state saving between power-off and power-on shall be included.

D.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 RBG 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 upon 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.

D.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. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become inconsistent. Methods used to detect failure or degradation of the source shall be included.

D.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, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.

Appendix E - Validation Guidelines

This appendix contains "rules" specified by the PP Authors that indicate whether certain selections require the making of other selections in order for a Security Target to be valid. For example, selecting "HMAC-SHA-3-384" as a supported keyed-hash algorithm would require that "SHA-3-384" be selected as a hash algorithm.

This appendix contains only such "rules" as have been defined by the PP Authors, and does not necessarily represent all such dependencies in the document.

Appendix F - Implicitly Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. 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.3 Dependencies between components.

This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP provides evidence that these controls are present and have been evaluated.

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. 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.3 Dependencies between components.

This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP provides evidence that these controls are present and have been evaluated.

Appendix G - Use Case Templates

Needs to be completed.

Appendix H - PFED Specification

H.1 TOE Cryptographic Boundary and Overview

A TOE claiming PFED as its trusted channel must also implement a Hardware Separated Encrypted Retransmission Device, including EU+CU and all required SFRs for a combined implementation. In addition, a PFED-conformant HWS-ERD TOE must adhere to the additional requirements outlined below."
All communication between paired ERDs is protected by an AES-based secure session tunnel implemented by the EU. The TOE does not rely on external key management protocols. When MACsec encapsulation is used, the IEEE 802.1X MACsec Key Agreement (MKA) protocol is not implemented or invoked.

H.2 Cryptographic Algorithms and Parameters

The TOE implements a secure session tunnel using AES in Galois/Counter Mode (AES-GCM) with a 256-bit key size. AES-GCM provides confidentiality, integrity protection, data origin authentication, and anti-replay protection for all session traffic.

All cryptographic operations are implemented within the EU. No cryptographic keys are available to or processed by the CU.

H.3 ERD Pair Provisioning and Cryptographic Bonding

H.3.1 Tunnel-0 Establishment Using a Pre-Shared Key

The TOE requires an ERD pair to be cryptographically bonded prior to the transmission of any End User Data (EUD). Initial bonding is performed during provisioning using a temporary secure tunnel (tunnel-0). Tunnel-0 is established using a Pre-Shared Key (PSK) that is either:

The PSK is used exclusively for tunnel-0 and is not retained after provisioning.

During tunnel-0 operation, the TOE enforces a packet allowlist. Only the following packet types are accepted and processed by the EU.

All other packets received during tunnel-0 are dropped by the EU prior to protocol stack processing.

H.3.2 Transition to Tunnel-1 and PSK Destruction

Upon successful completion of the ML-KEM-1024 transaction, the following occurs.

Tunnel-1 is used to complete the remainder of the provisioning process.

H.4 Provisioning Completion and Key Material GenerationZ

During tunnel-1, the TOE performs the following provisioning operations.

The TOE does not permit EUD traffic until all provisioning steps have successfully completed. Upon completion of provisioning, the active EU keystore contains the following.

H.5 Key Derivation and Key Storage

H.5.1 Key Derivation

The TOE derives all session keys, recovery keys, and operational keys using a Hash-based Key Derivation Function (HKDF). HKDF input material includes entropy generated by the hardware random number generator (RNG) of each ERD.

The TOE uses SHA-384 or SHA-512 as the underlying hash function for HKDF operations.

When session keys are replaced, the TOE ensures that superseded keys are securely destroyed.

H.5.2 Hardware Root of Trust

The TOE implements a hardware root of trust using a TPM 2.0, either as a discrete device or as a firmware-based implementation.

A Root Key is stored within the TPM and is cryptographically bound to physical properties of the platform. The Root Key is used only to unwrap subordinate keys and is not exportable.

H.6 Session Setup and Mutual Authentication

Prior to permitting EUD traffic, the TOE requires successful completion of a session setup transaction. Session setup includes the following.
  1. Mutual authentication between ERDs using ML-DSA-87 exclusively.
  2. A mandatory session rekey using ML-KEM-1024 exclusively.

The TOE enforces the completion of both steps before transitioning the session to an operational state. Until session setup completes, the following applies.

H.7 Rekey Operations

H.7.1 Rekey Scheduling

Following session establishment, the TOE enforces periodic rekey operations at configurable intervals between 2 and 30 minutes.

Rekey operations may be initiated by either ERD, and may be performed by either of the following.

H.7.2 Rekey Modes

The TOE supports the following rekey mechanisms.

In all cases, the following applies.

H.8 Session Key Recovery

The TOE supports a session key recovery transaction to resynchronize session state in the event of key divergence.

During key recovery, the following applies.

Upon successful resynchronization, the following applies.

If key recovery does not converge within a defined timeout, the TOE terminates the session.

The TOE does not provide any mechanism to offload cryptographic keys. Channel recovery is performed only through reprovisioning or ERD replacement.

H.9 Traffic Isolation and Interface Filtering

The TOE enforces strict isolation between the EU, CU, and EUD interfaces.

All packets received from the EUD are encapsulated and forwarded to the peer EU.

H.10 Dead Peer Detection and Persona Enforcement

Each EU implements dead peer detection using either RFC 3706 mechanisms or a keep-alive beacon.

When a dead peer is detected, the TOE transitions to a session setup state.

The TOE enforces ERD persona roles as follows.

H.11 Logging and Audit

The TOE maintains separate logs for the EU and CU.

EU logs are as follows.

H.12 Platform and Operational Environment Enforcement

The TOE enforces platform separation such that the following is true.

The EU executes transaction processing at non-root privilege on a minimal operating system providing only timers, interface handling, and inter-process communication.

Unused peripherals are disabled, unused pins are terminated, and power supplies are isolated or filtered.

H.13 Bring-Up and Multi-Factor Activation

The TOE enforces PIN- or CIK-based gating such that no traffic flows until activation credentials are provided.

Multi-factor activation includes the following.

Appendix I - Acronyms

Table 24: Acronyms
AcronymMeaning
AESAdvanced Encryption Standard
ANSIAmerican National Standards Institute
APIApplication Programming Interface
appApplication
ASLRAddress Space Layout Randomization
Base-PPBase Protection Profile
CCCommon Criteria
CEMCommon Evaluation Methodology
CMSCryptographic Message Syntax
CNCommon Names
cPPCollaborative Protection Profile
CRLCertificate Revocation List
CSAComputer Security Act
CUCommunication Unit
DEPData Execution Prevention
DESData Encryption Standard
DHEDiffie-Hellman Ephemeral
DMGApple Disk Image
DNSDomain Name System
DPAPIData Protection Application Programming Interface
DRBGDeterministic Random Bit Generator
DSSDigital Signature Standard
DTDate/Time Vector
DTLSDatagram Transport Layer Security
EAPExtensible Authentication Protocol
ECDHEElliptic Curve Diffie-Hellman Ephemeral
ECDSAElliptic Curve Digital Signature Algorithm
ELFExecutable and Linkable Format
EMETEnhanced Mitigation Experience Toolkit
EPExtended Package
ESTEnrollment over Secure Transport
EUEncryption Unit
EUEncryption Unit
EUDEnd-User Device
FIPSFederal Information Processing Standards
FPFunctional Package
GPSGlobal Positioning System
HMACHash-based Message Authentication Code
HTTPHypertext Transfer Protocol
HTTPSHypertext Transfer Protocol Secure
HWS-ERDHardware Separated Encrypting Retransmission Device
IANAInternet Assigned Number Authority
ICInterconnect
IECInternational Electrotechnical Commission
IETFInternet Engineering Task Force
IPInternet Protocol
IPAiOS Package archive
IRIntermediate Integer
ISOInternational Organization for Standardization
ITInformation Technology
ITSEFInformation Technology Security Evaluation Facility
JNIJava Native Interface
LDAPLightweight Directory Access Protocol
MIMEMulti-purpose Internet Mail Extensions
MPKGMeta Package
MSIMicrosoft Installer
NFCNear Field Communication
NIAPNational Information Assurance Partnership
NISTNational Institute of Standards and Technology
OCSPOnline Certificate Status Protocol
OEOperational Environment
OIDObject Identifier
OMBOffice of Management and Budget
OSOperating System
PDFPortable Document Format
PEPortable Executable
PIDProcess Identifier
PIIPersonally Identifiable Information
PKGPackage file
PKIPublic Key Infrastructure
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
RBGRandom Bit Generator
RFCRequest for Comment
RNGRandom Number Generator
RNGVSRandom Number Generator Validation System
S/MIMESecure/Multi-purpose Internet Mail Extensions
SANSubject Alternative Name
SARSecurity Assurance Requirement
SESecurity Enhancements
SFRSecurity Functional Requirement
SHASecure Hash Algorithm
SIPSession Initiation Protocol
SPSpecial Publication
SSHSecure Shell
STSecurity Target
SWIDSoftware Identification
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification
UIUser Interface
URIUniform Resource Identifier
URLUniform Resource Locator
USBUniversal Serial Bus
XCCDFeXtensible Configuration Checklist Description Format
XORExclusive Or

Appendix J - Bibliography

Table 25: Bibliography
IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -
[OMB] Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006.