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.
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 EUD or 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.
An HWS-ERD will encrypt traffic between two endpoints while maintaining a defined physical
and logical protocol break between the trusted and the untrusted 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.
Stack Cookie
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.
Network transport and routing security functionality
Cryptographic protection of user data
Hardware-enforced isolation between trusted and untrusted interfaces, or
A hardware-separated architecture combining encryption and communications functions
The TOE is deployed between an EUD or trusted network and an untrusted network environment. Its primary security objectives are to do the following.
Prevent unauthorized access from black networks to trusted interfaces
Ensure controlled forwarding of traffic
Enforce isolation between trusted and untrusted domains
Where applicable, cryptographically protect transmitted data
The TOE supports the following evaluated configurations.
In the CU-Only configuration, the TOE performs the following.
Network routing and transport functionality and
Hardware-based isolation via a dedicated wired interface between EUDs or EUs and black transport networks
The CU provides isolation between trusted components and untrusted black transport networks and represents the minimum TOE configuration supported by
the PP.
CU Characteristics
Network-facing component (cellular, Wi-Fi, or Ethernet)
Provides hardware isolation between untrusted networks and the EUD or EU
Implements a stateless firewall
Provides routing functionality across untrusted black transport networks
Performs a mandatory Layer-2 protocol break only when required by the selected encryption option
The CU provides routing and isolation services between trusted and untrusted networks.
When the EU implements IPsec, the CU routes IPsec-protected IP packets and performs a Layer-2 protocol break for isolation.
The CU does not terminate IPsec security associations.
When the EU implements MACsec or PFED, the CU forwards or transports already-encrypted Ethernet frame or packet traffic across untrusted
networks without terminating, decrypting, or re-originating cryptographic protection, and without performing a Layer-2 protocol break that
would disrupt cryptographic continuity.
The CU does not implement cryptographic services for MACsec or PFED traffic and forwards already-encrypted traffic when those options are
selected.
The CU does not act as a cryptographic endpoint for user data traffic. The CU routes or forwards already-encrypted traffic across untrusted
black transport networks without terminating, decrypting, or re-originating cryptographic protection while enforcing interface isolation
policies.
1.3.2.2 EU-Only Configuration
In the EU-Only configuration, the TOE does the following.
Provides hardware isolation between the EUD and black transport networks (e.g., WLAN or tactical radio) or CU
Encrypts all EUD traffic to form an encrypted tunnel to an authorized encryption endpoint.
Implements one selectable encryption option from the following set.
The interfaces between the EUD and EU shall be via a dedicated wired connection.
In non-WLAN configurations, the interface between the EU and CU (or other device) shall be via a dedicated wired connection.
Implements stateless Layer-2 traffic filtering when MACsec or PFED is selected, limited to Ethernet frame attributes (e.g.,
EtherType, source or destination MAC address).
When MACsec or PFED is selected, the EU presents a non-addressable Ethernet interface toward the CU (i.e., no IP address or
higher-layer protocol termination is supported on the EU–CU interface).
When PFED encryption is selected, the TOE must consist of the hardware-separated CU and EU (HWS-ERD) configuration.
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.
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.2.4 PFED Configuration
A TOE that claims Protocol Free Encrypting Device (PFED) functionality implements PFED as a specialized form of the HWS-ERD configuration. A PFED-conformant TOE therefore consists of the hardware-separated EU and CU configuration described in Section 1.3.2.3, with the additional PFED-specific properties, cryptographic
behavior, provisioning behavior, isolation rules, and operational requirements described in this section.
A TOE claiming PFED as its trusted channel must implement an HWS-ERD, including the EU, CU, and all required SFRs for a combined implementation. 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.
An HWS-ERDPFED has unique properties that are not normally present in traditional encryption systems. The security function of separating Red and Black
within any ERD must work correctly, and to work correctly it must be completely understandable. The separation of functions into an EU and CU allows the
security examination to narrow to the EU IC1 and IC3 interfaces as shown in Figure 4.
The EU is a figurative bump on the wire and operates at Layer 2 of the network stack. EUD packets are simply frames from the EU’s perspective. The payload
is not inspected from or to IC1. There is no cryptographic bypass. All packets from the EUD are forwarded through the EU to the CU. Packets that emerge from
the EU on IC3 cannot be routable across a Layer 3 network without a CU. If they are routable without a CU, then the device is not considered an
HWS-ERDPFED.
The purpose of having two independent hardware devices, namely a stateless EU and a stateful CU, is to move complex stateful processing outside of the EU
and preserve only stateless processing inside the EU. The Layer 3 complexity necessary to traverse any typical transport is removed from the security
argument and safely remains outside the trust boundary of the EU. This isolates and simplifies the policy enforcement performed by the EU interfaces on IC3
and IC1. This translates directly into a simplified understanding of the isolation argument for an EUD protected by an ERD, both for a user and for an
evaluator. In an HWS-ERD/PFED context, all packets going to or from the EUD will always pass through the black-box EU to a peer EU.
Hardware separation significantly reduces the attack surface of any EUD protected by an ERD. Measuring the HWS-ERD/PFED attack surface can be summarized as
follows.
Attack surface = complexity of the interface code at a stateless EU-IC3 × 1/2^256
The ERD attack surface can be summarized as follows.
Attack surface = complexity of the stateful network interface and cryptographic code handling of EU-IC2 × 1/2^256
The size of a stateful space in this context dwarfs the size of a stateless space. Smaller is better.
Inherent to the HWS-ERDPFED is an almost perfect firewall. It is a rule of one, and this rule is not a configurable parameter. This is because the CU
must translate the Layer 3 packet on IC2 into a Layer 2 packet on IC3, where that Layer 2 packet is a fixed type that the EU expects. Any other packet
type is easily dismissed before it can be further processed by more sophisticated logic. The formula implemented by the EU to dismiss packets can easily
be verified.
if (packet != type X) {drop}
There is no negotiation between the EU and the CU regarding what X can be. Enforcement is completely removed from a possibly misconfigured CU due to
hardware separation. Additionally, the payload of the CU-translated Layer 2 frame must pass the authentication and integrity checking of AES-GCM-256 in
the EU, or it is dropped. This combination protocol break ensures that only the peer HWS-ERD/PFED could possibly succeed at sending a packet to the
receiving EUD unless the key was somehow compromised.
The CU may include a firewall, but it is embedded in a complex environment that has never been shown to be impervious to failure and therefore
cannot be trusted by the EU to be active or correct. Imposing a security requirement on the CU would be unrealistic when the black transport can be
almost anything. While a CU firewall may be useful, it is not required to be correct for the isolation or confidentiality security argument of the
EUD to be enforced.
A packet that emerges from the EU may be labeled, where the label is also cryptographically authenticated. A CU must maintain the label between each EU. This may be considered a channel. There may be more than one channel in an HWS-ERDPFED. Each channel is a unique cryptographic bond
between two EUs. When a channel is established, one EU acts as the client and the other acts as the server for session management that must occur between EUs. Transactions such as rekey or dead peer detection may originate from either EU.
1.3.2.4.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.
1.3.2.4.3 EU Pair Provisioning and Cryptographic Bonding
Tunnel-0 Establishment Using a Pre-Shared Key
The TOE requires an EU pair to be cryptographically bonded prior to the transmission of any EUD. Initial bonding is performed during
provisioning using a temporary secure tunnel, referred to as tunnel-0. Tunnel-0 is established using a Pre-Shared Key (PSK) that is either:
Injected during manufacturing, or
Entered by the system owner through a trusted EU entry interface.
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:
HELLO
HELLO-ACK
A single ML-KEM-1024 key encapsulation transaction
All other packets received during tunnel-0 are dropped by the EU prior to protocol stack processing.
Transition to Tunnel-1 and PSK Destruction
Upon successful completion of the ML-KEM-1024 transaction, the following occurs.
Tunnel-0 is terminated.
The PSK is cryptographically destroyed.
A new secure tunnel, referred to as tunnel-1, is established using the shared secret derived from the ML-KEM-1024 transaction.
Tunnel-1 is used to complete the remainder of the provisioning process.
1.3.2.4.4 Provisioining Completion and Key Material Generation
During tunnel-1, the TOE performs the following provisioning operations.
Generation of an ML-DSA-87 public and private key pair
Secure exchange of ML-DSA-87 public keys with the peer
Exchange of link parameters, including MTU and event timing values, such as rekey intervals
Execution of at least one authentication transaction
Execution of at least one operational rekey transaction
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.
Transmit (TX) session key
Receive (RX) session key
Recovery Key 1
Recovery Key 2
ML-DSA-87 private key
Peer ML-DSA-87 public key
1.3.2.4.5 Key Derivation and Key Storage
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 EU.
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.
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.
1.3.2.4.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.
Mutual authentication between EUs using ML-DSA-87 exclusively.
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.
The EU executes transaction processing at non-root privilege on a minimal operating system providing only timers, interface handling, and
interprocess communication.
Unused peripherals are disabled, unused pins are terminated, and power supplies are isolated or filtered.
1.3.2.4.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.
A user password to activate EU cryptographic functions.
A removable media or keyboard entry combined with device authentication to boot the 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.
Enforces hardware-based separation between trusted and black interfaces
Prevents direct access from black networks to trusted components
Ensures all traffic traverses controlled forwarding paths
Prevents bypass of isolation mechanisms, including cryptographic and administrative
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
Encrypts all EUD or trusted network payload traffic prior to transmission over black networks
Establishes encrypted tunnels to authorized endpoints
Ensures plaintext traffic is restricted to trusted network interfaces
Protects cryptographic keys and critical security parameters within the TOE boundary
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.
Configure network interfaces and routing parameters (as applicable)
Configure encryption parameters and endpoints (as applicable)
Manage security-relevant configuration settings
Restrict administrative access to authorized administrators via independent, physically isolated interfaces, i.e., it must not be
possible to administer the EU from the CU or vice versa
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.
The dedicated wired interface between the EU and CU is included within the TOE boundary.
The following are excluded from the TOE.
EUDs
Remote encryption endpoints
External network infrastructure
Black transport networks
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:
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:
The following table depicts how each SFR is applicable to CU and EU.
Status Markers
M - Mandatory
Ob - Objective
IMP - Implementation Dependent
SB - Selection-Based
N/A - Not applicable Applicability Meaning
All - Applies to every TOE CU - Applies when TOE includes CU functionality EU - Applies when TOE includes EU functionality
HWS - Applies when TOE claims HWS-ERD
Trigger/Notes - Protocol or implementation condition Applicability Rules
EU-only TOE claims: All + EU + one complete EU protocol package, such as IPsec, MACsec, or WLAN.
HWS-ERDTOE claims: All + CU + EU + HWS + one complete EU protocol package.
PFEDTOE claims: All + CU + EU + HWS + all PFED-triggered rows. PFED is HWS-only, but PFED cryptography applies to the EU. PFED-specific
cryptographic SFRs are marked with a PFED-triggered note.
Hardware-separation, isolation, and EU/CU boundary SFRs are marked HWS = M.
Conditional requirements apply only when the TOE implements the corresponding function, interface, authentication method, cryptographic mechanism, storage
mechanism, update mechanism, or managed path.
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:
PP-Module for MACsec Ethernet Encryption, Version 2.0
This PP is
Functional Package for Secure Shell (SSH), Version 2.0 conformant.
This PP is
Functional Package for Transport Layer Security (TLS), Version 2.0 conformant.
This PP is
Functional Package for X.509, Version 1.0 conformant.
This PP does not conform to any
assurance packages.
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
The 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 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.
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:
Refinement operation (denoted by bold text or strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1 Security Functional Requirements
5.1.1 Auditable Events for Mandatory SFRs
Table 2: Auditable Events for Mandatory Requirements
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
Initiation and termination of trusted channel
Trusted channel protocol, non-TOE endpoint of connection
The TSF shall record within the audit data at least the following information:
Date and time of the auditable event
Type of event
Subject and object identity (if applicable)
The outcome (success or failure) of the event
[For each auditable event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional
package or ST, Additional information defined in Table 2]
[selection:
Additional information defined in Table 3 for Objective SFRs
Additional information defined in Table 4 for Implementation-Dependent SFRs
Additional information defined in Table 5 for Selection-Based SFRs
For PFED, the TOE shall generate audit records for the following events.
Provisioning
Session setup and termination
Rekey
Key recovery
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 3, Table 4, and
Table 5 should be included in the ST if the
associated SFRs and selections are included.
For PFED, 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.
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.
Specific auditable events required for SFRs from the functional packages are defined in the respective packages.
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.
For PFED
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 Configuration section logging description for provisioning, session setup, session termination, rekey, and key recovery.
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.
For PFED
The evaluator shall perform the following tests
:
Test FAU_GEN.1: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: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: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: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: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.
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.
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, protect stored audit records from unauthorized modification and deletion.]]
Application
Note:
The ST author selects "transmits audit data to an external..." 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.
For PFED, the intent is to ensure that PFED audit records, once generated and stored, cannot be altered or removed by unauthorized
entities.
For this requirement, "protect stored audit records from...” 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.
The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit
server.
For PFED, 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
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.
For PFED
The evaluator shall perform the following tests:
:
Test FAU_STG.1.1: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.1: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.1: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.
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.
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.
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 a full audit trail is evident as described in the guidance.
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 the "software-based key storage" selection in FCS_STG_EXT.2,
the ST author is expected to select "software-based, and vice versa." If "software-based" is selected, the ST author is expected to
claim FCS_STG_EXT.3.
If this SFR is included in the ST, then FCS_CKM.6 must also be claimed.
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..." 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 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].
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.
The evaluator shall perform the following tests
:
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:
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.
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.
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.
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.
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.
We need to make this extended and define all information that goes along with that.
The TSF shall enforce the [selection: CU information flow control policy, information flow control policy] based on the following types of subject and
information security attributes: [selection:
denial of information flow between an untrusted black transport network interface and a trusted interface if the packet
does not match an explicitly configured allow rule
following additional information flow control rules: [None]
The TSF shall explicitly [selection: authorize, ensure] an information flow based on the following rules:[selection: [assignment:
rules, based on security attributes, that explicitly authorize information flows], between untrusted interfaces and are mediated by the TSF and are subject to the CU Information Flow Control
Policy].
The TSF shall explicitly deny an information flow based on the following rules:[selection: Any information flow not explicitly permitted in FDP_IFF.1.2, [assignment:
rules, 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.
For CU, 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. The CU-specific decision function companion to the CU subset information flow control
requirement, identifies the attributes used in policy decisions, requires explicit permit logic, deny behavior for packets that do not match an allow rule, and 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 HWS-only, 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.
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.
If the TOE claims CU only, the ST author should select the following.
"CU Information Flow Control Policy" and the lists for "Subject Security Attributes" and "Information Security
Attributes" in FDP_IFF.1.1
"the untrusted interface and the trusted interface" and the assignment "for each operation..." in FDP_IFF.1.2
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.
For CU-only
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:
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.
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, 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.
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.
For HWS-only
The evaluator shall examine the TSS to determine that it:
Identifies the information flow control policy enforced for the HWS-ERDEU/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.
Describes how the TOE explicitly denies any information flow not permitted by the conditions in FDP_IFF.1.2.
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
For CU-only
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:1:
[CU-only] 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:2:
[CU-only] 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.
Test FDP_IFF.1:3:
[CU-only] 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:4:
[CU-only] 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:5:
[CU-only] 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.
Test FDP_IFF.1:6:
[HWS-only] 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:7:
[HWS-only] 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:8:
[HWS-only] 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:9:
[HWS-only] 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:10:
[HWS-only] 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:11:
[HWS-only] 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 is denied by the TOE.
The tests for either CU or HWS may be combined where appropriate. The purpose of the CU-only 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. The purpose of the HWS-only evaluation is to confirm that the HWS design enforces the claimed allowlist architecture for EU/CU communication and denies all other information flows.
The evaluator shall ensure the TSS describes the Trust Anchor Database
implemented that contains 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.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.8 Class FIA: Identification and Authentication
The TSF shall support the following for the Password Authentication Factor:
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]]
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 more, 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 the TOE; they may optionally list additional special characters
supported using the assignment.
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.
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.
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.
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.1 and are allowed by unauthorized users in a locked
state should be listed. For example, if the user can enable/disable the camera per
function of FMT_SMF.1 and unauthorized users can
take a picture when the device is in a locked state, this action must be listed.
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.
Need to complete App Note, EAs, and auditable events.
The TSF shall allow [assignment:
list of TSF-mediated actions] on behalf of the user to be performed before the user is identified.
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.
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.
Need to complete note, EAs, and auditable events
The TSF shall enforce the [assignment:
access control SFP(s), information flow control
SFP(s)] to restrict the ability to [selection: change_default, query, modify, delete, [assignment:
other operations]]
the security attributes [assignment:
list of security
attributes] to [assignment:
the authorized identified roles].
Need to complete note, EAs, and auditable events
The TSF shall enforce the [assignment:
access control SFP, information flow control
SFP] to provide [selection, choose one of: restrictive, permissive, [assignment:
other property]]
default values for security attributes that are used to enforce the SFP.
The TSF shall allow the [assignment:
the authorized identified roles] to specify alternative initial values to override the default values
when an object or information is created.
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 Function
Admin
User
Application 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.
5
Ability 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.
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.
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 that the result of the function is demonstrated.
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
authenticated to tenant software and are considered to be users in the context of the TOE.
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 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 easily recognized 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 processed for matches.
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
The evaluator shall perform the following 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.
There are no EAs specified for this element. Definitions for 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.
There are no EAs specified for this element. Definitions for 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.
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:
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:
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
The evaluator shall perform the following 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:
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.
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 rulesets.
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
The evaluator shall perform the following 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 confirmation.
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.
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
The evaluator shall perform the following 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:
Protocol
Defined 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
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 NISTSP 800-63 will be required.
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 fol
:
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.
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:
App Note and EAs need to be completed. The information that was included came from the mobile device PP.
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 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.
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.
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
The evaluator shall perform the following test
:
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.
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.
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.
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.
This needs to be evaluated to reference retransmission device. It looks like a copy and paste from GPOS or MDF.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.
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.
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.
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:
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 requires 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.
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.
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.
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.
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 the currently installed firmware
package.
The administrator guidance should include instructions for the administrator to configure the
rollback prevention mechanism, if appropriate.
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.
Need to complete note, EAs, and auditable events
After [assignment:
list of failures/service discontinuities] the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.
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.
For [assignment:
list of failures/service discontinues], the TSF shall ensure the return of the TOE to a secure state using automated procedures.
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 the following.
Persistent boot or integrity-check failures
Unrecoverable cryptographic subsystem errors
Repeated failure of required internal health checks
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.
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
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. The evaluator shall perform the following tests
:
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.
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.
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.
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 execute
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 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_AFL_EXT.1, FIA_PMG_EXT.1, FIA_UAU.5, FIA_UAU.7, FIA_UIA_EXT.1).
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.
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, 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.
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.
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.
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 test.
[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.
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 [TSFDRBG specified in FCS_RBG.1].
The TSF shall provide authorized users with the capability to verify the integrity of [[TSFDRBG 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.
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.
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']]
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 uses 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]].
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 the 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.
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.
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.
The TSF shall terminate a remote interactive session after a security
administrator-configurable [assignment:
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.
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.
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.
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, 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.
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
The evaluator shall perform the following 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.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.
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.1 function.
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 shall follow 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.
The TSF shall be capable of using [selection: IPsec, MACsec, PFED in accordance with PFEDSFRs, WLAN] to provide a trusted communication channel between itself and another trusted [selection:
authorizedITentities
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 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, as selected, 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.
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.
For PFED
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 the PFED Configuration section and the PFEDSFRs
claimed in the ST.
The evaluator shall determine that the TSS is consistent with the PFED tunnel and session model, mutual authentication, and protected
traffic handling.
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
For PFED
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 for each claimed trusted-channel mechanism, or for a representative set where the TSS and guidance show that the same mechanism is used
:
One or more of these tests may be combined where appropriate.
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.
For 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.
For PFED
The evaluator shall perform the following tests
:
Test FTP_ITC.1:5:
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 PFED Configuration section and the claimed PFEDSFR set.
Test FTP_ITC.1:6:
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:7:
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 PFED Configuration section. The PFED Configuration section describes mutual authentication between ERDs using ML-DSA-87 as part of session setup.
Test FTP_ITC.1:8:
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 PFED Configuration section.
Test FTP_ITC.1:9:
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. The PFED Configuration section 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.
5.1.14 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:
Mitigates 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.
Mitigates this threat by suppressing EUD traffic during recovery, ensures sequential derivation of
recovery keys, and terminates sessions on failure to converge.
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.
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.
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.
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.
Mitigates 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.
Mitigates 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.
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.
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.
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.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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 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.
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 documentation shall describe the methods used to
provide flaw information, corrections and guidance on corrective actions to TOE users.
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 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 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 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 may register
with the developer, to be eligible to receive security flaw reports and corrections.
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.
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.
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.
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.
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.
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.
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:
Physical tampering scenarios may include attempts to open the TOE enclosure, probe or modify internal circuitry, remove or replace protected components,
induce abnormal environmental or electrical conditions, perform fault injection, or otherwise observe, analyze, or modify TSF devices or TSF elements.
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.2/PFED User Identity Association
This component must be included in the ST if the TOE implements any of the following features:
For audit events resulting from actions of identified users, the TOE shall be able to 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.
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 the PFED Configuration section 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.
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: [NISTFIPS PUB 203], ML-DSA using the parameter set [ML-DSA-87] that meets the following [NISTFIPS 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
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
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
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 the PFED Configuration section. 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.
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 Configuration section, 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 [NISTSP 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.
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 NISTSP 800-56C Rev. 2, Section 4.1, Option 1.
The evaluator shall determine that the TSS is consistent with the posted PFED Configuration section 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:
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 the PFED Configuration section, 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.
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 the PFED Configuration section, 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 PFED Configuration section 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.
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.
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
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]]
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:
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
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 algorithm [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 NISTSP 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.
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
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.
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.
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.
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.
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: [NISTFIPS 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 NISTFIPS 203.
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
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.
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: [NISTFIPS 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 NISTFIPS PUB 204, Section 5.2.
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 NISTFIPS 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
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)
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
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: [NISTFIPS 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 NISTFIPS PUB 204, Section 5.3.
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 NISTFIPS 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
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:
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 the PFED Configuration section, 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.
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 the PFED Configuration section, 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. The PFED Configuration section 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 the PFED Configuration section 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:
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 the PFED Configuration section. The PFED Configuration section 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.
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 the PFED Configuration section, including the configurable 2 to 30 minute interval, the use of ML-KEM-1024, the synchronous or asynchronous rekey modes, and the PFED Configuration section 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 the PFED Configuration section’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. The PFED Configuration section 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:
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.
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 the PFED Configuration section’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_IFF.1/PFED Simple Security Attributes
This component must be included in the ST if the TOE implements any of the following features:
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 PFEDTOE 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.
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 the PFED Configuration section, 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 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.
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_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 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:
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 the PFED Configuration section, which states that initial bonding is performed during provisioning using a temporary secure tunnel, tunnel-0, established using a PSK, and with the PFED Configuration section, 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.
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 Configuration section, 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.
:
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.
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 the PFED Configuration section.
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 the PFED Configuration section, namely that tunnel-0 is terminated and PSK use ends after successful ML-KEM-1024 completion.
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:
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.
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.
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.
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 Configuration section 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: [selection: RFC 3706 mechanisms or keep-alive beacons, trigger session reconnect upon failure or disconnect notification, [assignment:
other method of detecting dead peers]].
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.
If the TOE is an EU+CU implementing PFED, the expectation is that the combined TOE will choose a persona during session bring-up, and must select both options. A TOE that is in client persona will initiate all connections; such TOEs will trigger session reconnect upon failure or disconnect notification. A TOE that is in server persona will wait for session establishment, and will trigger session reconnect keep-alive beacons or use mechanisms defined in RFC 3706. For TOEs that do not implement PFED, the ST author will select the appropriate dead peer detection mechanism.
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 Configuration section 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 Configuration section 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 Configuration section 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_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.
Application
Note:
The intent of this requirement is to ensure that the PFEDTOE 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 the PFED Configuration section, which says only a stateless, connectionless bus is shared between the EU and CU and the EUD and EU.
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 the PFED Configuration section.
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_EXT.1/PFED Recovery Behavior
This component must be included in the ST if the TOE implements any of the following features:
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.
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 the PFED Configuration section.
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 Configuration section, 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_EXT.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 Configuration section states that the TOE transitions to session setup after dead-peer detection.
Test FPT_RCV_EXT.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_EXT.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_EXT.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_EXT.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 Configuration section, 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:
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.
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.
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 the PFED Configuration section 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 provide authorized users with the capability to verify the integrity of [selection: [assignment:
parts of TSF], TSF]
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.
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 Configuration section’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_EXT.1/IPsec Trusted Channel Communication - IPsec
This component must be included in the ST if the TOE implements any of the following features:
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.
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 - WLAN
This component must be included in the ST if the TOE implements any of the following features:
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 initiate communication via the trusted channel for wireless access point connections, administrative communication, configured enterprise
connections, and [selection: OTA updates, no other connections]
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.
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 parameterskey 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.
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.
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
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)
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]]
Static domain parameters approved for [selection:
IKE groups [selection: MODP-3072, MODP-4096,
MODP-6144, MODP-8192], TLS groups [selection:
ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]
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:
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
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:
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
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
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]
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:
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.
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.
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.
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:
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.
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.
The TSF shall destroy [all plaintext keying material and critical security
parameters (CSPs)] when
[selection: no longer needed, [assignment:
other circumstances for key or keying material 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 TSFDRBG (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
TSFDRBG (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.
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 use 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:
Record the value of the key in the TOE subject to clearing.
Cause the TOE to perform a normal cryptographic processing with the
key from Step #1.
Cause the TOE to dump the entire memory of the TOE into a binary
file.
Search the content of the binary file created in Step #5 for instances
of the known key value from Step #1.
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:
Record the value of the key in the TOE subject to clearing.
Cause the TOE to perform a normal cryptographic processing with the
key from Step #1.
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.
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:
Record the storage location of the key in the TOE subject to
clearing.
Cause the TOE to perform a normal cryptographic processing with the
key from Step #1.
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.
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.
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
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
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, or 128] bits.
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.
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
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:
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.
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.
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.
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.
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
[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:
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.
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.
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.
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
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.
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.
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.
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.
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
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
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.
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.
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]
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.
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
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:
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
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:
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
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]
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:
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:
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]
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:
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
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)
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]
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:
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.
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.
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.
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
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:
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:
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:
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:
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:
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
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:
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]
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:
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]
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:
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
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.
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.
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:
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
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]
}
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
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
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.
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.
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
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:
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:
TSF shall perform deterministic random bit generation services using
[selection:
[assignment:
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.
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.
NISTSP 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: TSFentropy source [assignment:
name of entropy
source], multiple TSFentropy 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 NISTSP 800-57A.
The TSF shall update the DRBG state by [selection: reseeding, uninstantiating and re-instantiating] using a [selection: TSFentropy source [assignment:
name of entropy source], multiple TSFentropy 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).
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
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:
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
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:
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.
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.
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.
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:
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.
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:
The TSF shall [selection: hash, concatenate and hash, XOR, input into a linear feedback shift register, [assignment:
combining operation]]
[selection: output from TSFentropy 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, NISTSP 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 NISTSP 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 NISTSP 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.
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.
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:
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.
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:
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.
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.
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
use an independent counter or for multiple authentication mechanisms to use 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.
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 uses its own counter or if multiple
authentication mechanisms use a shared counter. If multiple authentication mechanisms
use 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, support for cryptographic mutual authentication using ML-DSA-87 and user activation using [assignment:
password, PIN, or
CIK], 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 "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 .
If "support for cryptographic mutual authentication using ML-DSA-87..." is selected, the intent 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.
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.
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.
For PFED
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 verify that configuration information for each authentication mechanism is addressed in the AGD guidance.
For PFED
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
:
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.
For PFED
The evaluator shall perform the following tests.
:
Test FIA_UAU.5:3:
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 Configuration section session-setup
section.
Test FIA_UAU.5:4:
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.5:5:
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.5:6:
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.5:7:
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.
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.
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.
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.
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:
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.
For PFED
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.
The evaluator shall verify that the TSF describes how the TOE enters an error state in the event of a DRBG
self-test failure.
For PFED
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 Configuration section, including recovery termination on failure to converge and dead-peer handling in the PFED lifecycle.
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
For PFED
The evaluator shall perform the following tests.
:
Test FPT_FLS.1: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: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: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: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_RVR_EXT.1 Platform Firmware Recovery
The inclusion of this selection-based component depends upon selection in:
The TOE implements a recovery mechanism for firmware corruption not necessarily related to
integrity or update failure.
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.
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.
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:
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.
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.
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.
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:
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 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.
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:
]
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)
]
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.
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.
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:
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 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.
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:
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_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_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:
At a configurable interval [assignment:
between 2 and 30 minutes]
Using ML-KEM-1024 only
Either synchronously or asynchronously with EUD traffic
.
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_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].
This family defines requirements for supporting and integrity of importing keys and key
material.
Component Leveling
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_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_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:
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_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_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:
Passwords shall be able to be composed of any combination of
[assignment:
characters sets],
numbers, and special characters: [assignment:
special characters].
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_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_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.
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_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_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:
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_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:
No dependencies.
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: [assignment:
supported network protocols and protocol fields.]
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_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_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_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: [selection: RFC 3706 mechanisms or keep-alive beacons, trigger session reconnect upon failure or disconnect notification, [assignment:
other method of detecting dead peers]].
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_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 PFEDEU/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
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:
[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_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_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_RCV_EXT Recovery Behavior
Family Behavior
This family defines requirements for using a secure recovery state and suppressing traffic.
Component Leveling
FPT_RCV_EXT.1,
Recovery Behavior,
require using a secure recovery state.
Management: FPT_RCV_EXT.1
There are no management activities foreseen.
Audit: FPT_RCV_EXT.1
There are no auditable events foreseen.
FPT_RCV_EXT.1 Recovery Behavior
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FPT_RCV_EXT.1.1
The TOE shall enter a secure recovery state upon detection of: [selection: dead peer, session key divergence, failed rekey or recovery transaction].
C.2.5.11 FPT_ROT_EXT Platform Integrity
Family Behavior
This family defines requirements for platform firmware and hardware integrity.
Component Leveling
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:
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:
[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: [assignment:
actions taken if failure
occurs].
C.2.5.12 FPT_RVR_EXT Platform Firmware Recovery
Family Behavior
This family defines requirements for recovering from a firmware integrity failure.
Component Leveling
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 Platform Firmware 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.13 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_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
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.14 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_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, and private keys.
C.2.5.15 FPT_TRAN_EXT Transaction Control
Family Behavior
This family defines requirements for controlling transactions.
Component Leveling
FPT_TRAN_EXT.1,
Transaction Control,
requires that the TSF allow only one transaction at a time.
Management: FPT_TRAN_EXT.1
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
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 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
The TSF shall allow only one transaction at a time, prohibit nesting, and enforce a reaper timer.
C.2.5.16 FPT_TST_EXT TSF Testing
Family Behavior
This family defines requirements for running self-tests.
Component Leveling
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']]
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.17 FPT_TUD_EXT Trusted Updates
Family Behavior
This family defines requirements for applying updates to the TOE.
Component Leveling
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:
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:
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_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
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:
This family defines requirements for protection of
data in transit between the TOE and its operational environment.
Component Leveling
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:
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:
Initiation of the trusted channel.
Termination of the trusted channel.
Failures of the trusted path functions.
FTP_ITC_EXT.1 Physically Protected Channel
Hierarchical to:
No other components.
Dependencies to:
No dependencies.
FTP_ITC_EXT.1.1
The TSF shall use [assignment:
trusted channel protocols]
protocols to provide a communication channel between itself and
another trusted IT product using certificates as defined in [assignment:
external entities]
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.
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_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 the 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.
