PL-4000M and PL-4000T

Certificate

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for PL-4000M and PL-4000T
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Firmware Load<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for PL-4000M and PL-4000T
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Firmware Load<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

PacketLight Networks Ltd. PL-4000M and PL-4000T Document Version 1.0 July 2025 Prepared by: www.lightshipsec.com PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

This document is the non-proprietary FIPS 140-3 Security Policy for the PacketLight Networks Ltd. PL-4000M and PL-4000T cryptographic modules (also referred to as “the module(s)” hereafter) running firmware version 2.1.0. It contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard

The table below describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas. Table 1: Security Levels PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Purpose and Use: The PL-4000M and PL-4000T are two product variations of the PL-4000x clone. The hardware modules run the same firmware and provide the same cryptographic security services. The PL-4000M is a cost-effective solution for rolling out multi-rate 10/25/100GbE, 16G FC, OTU2/2e/4 services, or increasing existing network capacity. The device delivers up to 600G in a 1U chassis using dual 400G CFP2-DCO Open ROADM standards-based pluggable coherent modules for metro and long-haul applications. The PL-4000M provides a full demarcation point between the service and the OTN/DWDM network and is interoperable with any third-party switch or router. This provides full visibility and performance monitoring of both line optical transport layer (OTN) and 10/25/100GbE, 16G FC, and OTU2/2e/4 service interfaces. The PL-4000M can be configured to work in the following system modes: - Single 400G Muxponder: mix of client interfaces aggregated into a 400G uplink - Dual 100/200/300G Muxponder: mix of client interfaces aggregated into two 100/200/300G uplinks - Optical Amplifiers: Up to two EDFA modules (optional) - Optical Switch: 1+1 facility protection (optional) The PL-4000T is a cost-effective high-capacity solution for rolling out 400GbE and 100GbE services or increasing existing network capacity. The device has four 400G pluggable uplink optical modules, delivering up to 1.6T in a 1U chassis. The PL-4000T integrates mux/demux, EDFA and OSW and delivers the entire optical layer. This flexible solution enables pay-as-you-grow architecture. The solution provides a full demarcation point between the service and the DWDM network and is interoperable with any third-party switch or router. This provides full visibility and performance monitoring of both the optical transport layer (OTN) and 100GbE/400GbE/OTU4 service interfaces. The PL-4000T can be configured to work in the following system modes: - Muxponder: 4x100G clients per 200G/300G/400G slice - Transponder: 1x400G per 400G - Optical Amplifiers: Up to two EDFA modules (optional) - Mux/Demux: 4ch mux/demux module (optional) - Optical Switch: 1+1 optical switch, 4 x 1+1 optical switches Module Type: Hardware Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the modules is defined as the entire outer casing of the chassis as pictured below. The PL-4000T’s cryptographic boundary includes uplink module(s) which are protected by Tamper-evident Seals (see Section 7.1). Figure 1: PL-4000M PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware

None. Modes List and Description: The table below details the Mode of Operation supported by the module. Table 3: Modes List and Description

Approved Algorithms: The table below lists all the Approved Algorithms supported by the module. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: The table below lists all the Vendor-Affirmed Algorithms supported by the module. Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The module does not support any Non-Approved, Allowed Algorithms. N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: The module does not support any Non-Approved, Allowed Algorithms with No Security Claimed. N/A for this module. Non-Approved, Not Allowed Algorithms: The module does not support any Non-Approved Algorithms that are not Allowed in the Approved Mode of Operation. N/A for this module.

The table below lists the Security Function Implementations supported by the module. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 6: Security Function Implementations PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module's TLS v1.2 firmware AES-GCM implementation conforms to FIPS 140-3 IG C.H Scenario #1. The module is compatible with TLS v1.2 and provides support for the acceptable GCM ciphersuites from SP 800-52 Rev2, Section 3.3.1. The counter portion of the IV is set by the module within its cryptographic boundary. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key (in accordance with RFC 5246). In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established. The module's TLS v1.3 firmware AES-GCM implementation conforms to FIPS 140-3 IG C.H Scenario #5. The TLS v1.3 protocol, and specifically the use of the AES-GCM encryption within the TLS v1.3 protocol is defined in RFC 8446. The module supports the acceptable GCM ciphersuites from SP 800-52 Rev2, Section 3.3.1. The IV is generated and used within this protocol’s implementation. The module's SSHv2 firmware AES-GCM implementation conforms to FIPS 140-3 IG C.H Scenario #1. The SSHv2 implementation is compliant with RFC 4252 and RFC 4253, and the IV generation of SSHv2 AES-GCM implementation is compliant with RFC 5647. The module's hardware AES-GCM implementations conform to IG C.H, scenario #4. The module uses a 96-bit IV, which is constructed deterministically per SP 800-38D Section 8.2.1 from a nonce and counter. PL-4000T - from a Frame Block Counter, Multi-Frame Index (MFI), Multi Frame Alignment Signal (MFAS) and nonce. PL-4000M - from Frame Counter (which is comprised of MFAS and MFI-38 bits and 26 zero pads), and Frame Block Counter (32-bits). Per the requirements specified in Section 8 in NIST SP 800-38D, the probability that the authenticated encryption function ever will be invoked with the same IV and the same key on two (or more) distinct sets of input data is no greater than 2-32. In all cases the module enforces FIPS 140-3 IG C.H, which states, “In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established.”

The tables below detail the modules ESV information. Table 7: Entropy Certificates Table 8: Entropy Sources

Please see SFI table.

Please see SFI table. The module implements the DH and ECDH key agreement schemes specified in NIST SP 800-56Arev3. This specification requires that certain checks are performed to provide assurances regarding the keys being used. The following assurance checks are performed by the cryptographic module: PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

• Assurances of domain parameter validity (section 5.5.2 of NIST SP 800-56Arev3)
• Assurances required by the key pair owner (section 5.6.2.1 of NIST SP 800-56Arev3)
• Assurances required by the public key recipient (section 5.6.2.2 of NIST SP 800-56Arev3)

No parts of the SSH protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. No parts of the SNMP protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Figure 3: PL-4000M (Front) Figure 4: PL-4000T (Front) Figure 5: PL-4000M and PL-4000T (Rear) The table below details the modules Ports and Interfaces. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 9: Ports and Interfaces PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below details the modules Authentication Methods. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Method Name

Description monitoring and management

Security Mechanism

Strength Each Attempt password allowing all legal characters (73) with repetition equates to a 1:(73^8), or 1: 806,460,091,894,081 chance of false acceptance.

Strength per Minute minute period is 600/73^8, which is less than 1/100,000.

The module supports four different roles: Admin, Crypto, Read-Write and Read-Only, which are detailed in the table below. Table 11: Roles

The table below lists all approved services supported by the module. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

G,E G,E G,E PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access Authentication key: G,E Read-Write - Operator Passwords: W - Diffie-Hellman (DH) Key Pair: G,E - Diffie-Hellman Shared Secret: G,E - Elliptic Curve Diffie-Hellman (ECDH) Key Pair: G,E - EC Diffie- Hellman Shared Secret: G,E - SSH/SFTP Host Key Pair: G,E - SSH/SFTP Session Encryption Key: G,E - SSH/SFTP Session Authentication key: G,E Read-Only - Operator Passwords: W - Diffie-Hellman (DH) Key Pair: G,E - Diffie-Hellman Shared Secret: G,E - Elliptic Curve Diffie-Hellman (ECDH) Key Pair: G,E - EC Diffie- Hellman Shared Secret: G,E - SSH/SFTP Host Key Pair: G,E

G,E G,E G,E G,E G,E PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

G,E G,E G,E PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access Diffie-Hellman (ECDH) Key Pair: G,E - EC Diffie- Hellman Shared Secret: G,E - TLS Key Pair: G,E - TLS Premaster Secret: G,E - TLS Master Secret: G,E - TLS Session Encryption Key: G,E - TLS Session Authentication Key: G,E Read-Write - Operator Passwords: W - Diffie-Hellman (DH) Key Pair: G,E - Diffie-Hellman Shared Secret: G,E - Elliptic Curve Diffie-Hellman (ECDH) Key Pair: G,E - EC Diffie- Hellman Shared Secret: G,E - TLS Key Pair: G,E - TLS Premaster Secret: G,E - TLS Master Secret: G,E - TLS Session Encryption Key: G,E - TLS Session Authentication Key: G,E

G,E G,E G,E G,E G,E G,E PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

G,E G,E G,E G,E PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access - Data Encryption Key (DEK): Z - Peer- Authentication Pre-Shared Secret: Z - Diffie-Hellman (DH) Key Pair: Z - Diffie-Hellman Shared Secret: Z - Elliptic Curve Diffie-Hellman (ECDH) Key Pair: Z - EC Diffie- Hellman Shared Secret: Z - SNMP Privacy Key: Z - SNMP Authentication Key: Z - SNMPv3 Passwords (Privacy and Auth): Z - TLS Key Pair: Z - TLS Premaster Secret: Z - TLS Master Secret: Z - TLS Session Encryption Key: Z - TLS Session Authentication Key: Z - SSH/SFTP Host Key Pair: Z - SSH/SFTP Session Encryption Key: Z - SSH/SFTP

Z Z Z PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access Session Authentication key: Z - Firmware Update Key: Z - SP 800-90A CTR_DRBG Seed: Z - SP 800-90A CTR_DRBG Entropy Input: Z - SP 800-90A CTR_DRBG key value: Z - SP 800-90A CTR_DRBG V value: Z Read-Write - Operator Passwords: Z - EC DH Key Pair for DEK: Z - ECC CDH primitive for DEK: Z - Data Encryption Key (DEK): Z - Peer- Authentication Pre-Shared Secret: Z - Diffie-Hellman (DH) Key Pair: Z - Diffie-Hellman Shared Secret: Z - Elliptic Curve Diffie-Hellman (ECDH) Key Pair: Z - EC Diffie- Hellman Shared Secret: Z - SNMP Privacy Key: Z

Z PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Z Z PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access for DEK: Z - ECC CDH primitive for DEK: Z - Data Encryption Key (DEK): Z - Peer- Authentication Pre-Shared Secret: Z - Diffie-Hellman (DH) Key Pair: Z - Diffie-Hellman Shared Secret: Z - Elliptic Curve Diffie-Hellman (ECDH) Key Pair: Z - EC Diffie- Hellman Shared Secret: Z - SNMP Privacy Key: Z - SNMP Authentication Key: Z - SNMPv3 Passwords (Privacy and Auth): Z - TLS Key Pair: Z - TLS Premaster Secret: Z - TLS Master Secret: Z - TLS Session Encryption Key: Z - TLS Session Authentication Key: Z - SSH/SFTP Host Key Pair: Z - SSH/SFTP

Z Z PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module does not support any Non-Approved Services. N/A for this module.

The version signature is verified by HMAC-SHA-384. Any firmware loaded into this module that is not shown on the module certificate, is out of the scope of this validation and requires a separate FIPS 140-3 validation.

The Bypass capability is the ability of a service to partially or wholly circumvent a cryptographic function or process. The following two independent internal actions are required to activate the bypass capability, to prevent the inadvertent bypass of plaintext data due to a single error: 1. The admin shuts down the interface. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

2. Then switches the interface to non-encrypted mode. *Both actions are accompanied by a service impact warning The module shows status to indicate that the bypass capability is alternately activated and deactivated, and that the module is providing some services with cryptographic processing and some services without cryptographic processing, as follows: If the bypass service indicator is “Bypass is in effect”, it means that at least one active service is not encrypted. If the bypass service indicator is “Bypass in not in effect”, it means that all active services are encrypted.

The Self-initiated cryptographic output capability is the ability of the module to perform cryptographic operations and other approved security functions or SSP management techniques without external operator request. The following two independent internal actions are required to activate the self-Initiated cryptographic output capability to prevent the inadvertent output due to a single error:

1. The admin selects the service type and turns on the interface.
2. The admin confirms the changes. The module shows status to indicate whether the self-Initiated cryptographic output capability is activated through the Admin Status of the respective channel. If the self-Initiated cryptographic output service indicator is “Up” for a respective channel, it means that the capability is activated. If the self-Initiated cryptographic output service indicator is “Down” for a respective channel, it means that the capability is not activated. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The firmware is delivered as an executable file and the module implements a HMAC-SHA2-384 keyed hash firmware integrity test.

The Firmware Integrity Test can be invoked by rebooting the module. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Type of Operational Environment: Limited PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below details the Physical Security Mechanisms supported by the module. Table 13: Mechanisms and Actions Required The module has a multi-chip standalone embodiment and is made of commercially available, production grade components meeting commercial specifications for power, temperature, reliability, shock and vibration. All production-grade components include standard passivation techniques, in the form of a coating applied over the module’s circuitry to protect against environmental and other physical damage. The production grade metal enclosure is opaque to the visible spectrum, and all openings are designed in such a way to obscure

Number: The PL-4000M is sealed with 4-5 tamper-evident seals, and the PL-4000T is sealed with 4-7 tamper-evident seals. Placement: The locations of the tamper-evident seals are indicated by the red rectangles in Figures 6 and 7. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Figure 6: PL-40000M (Front, Rear, Left, Right, Bottom) PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Figure 7: PL-40000T (Front, Rear, Left, Right, Bottom) Surface Preparation: For optimum adhesion, surfaces must be cleaned with alcohol to remove surface contaminants before affixing the tamper-evident seals:

• Use 90% (or higher) Isopropyl Alcohol
• Apply alcohol to a clean paper towel and wipe the intended surface to remove contaminants.
• Dry the surface with another clean paper towel (some contaminants will remain on the surface if the alcohol is allowed to air dry)
• Apply the label to the clean surface. NOTE: The adhesive side of the label must not be touched during the label placement. If it is inevitable, tweezer must be used for handling. Operator Responsible for Securing Unused Seals: Crypto-Officer Part Numbers: Holo-Guard FIPS PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Currently, the ISO/IEC 19790:2012 non-invasive security area is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below lists Sensitive Security Parameters (SSPs) storage areas for the module. Section 9.4 below selects from the storage areas listed and specifies the appropriate parameter in the “Storage” column if applicable to a specific SSP. Table 14: Storage Areas The table below lists SSP input and output methods for the module. Section 9.4 below selects from the input and output methods listed and specifies the appropriate parameter in the “Inputs/Outputs” column if applicable to a specific SSP. Table 15: SSP Input-Output Methods The table below lists SSP zeroization methods for this module. Section 9.4 below selects from the zeroization methods listed and specifies the appropriate parameter in the “Zeroization” column if applicable to a specific SSP. Table 16: SSP Zeroization Methods The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 17: SSP Table 1 PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 18: SSP Table 2 PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

This section specifies the pre-operational and conditional self-tests performed by the module. The pre-operational and conditional selftests ensure that the module is not corrupted and that the cryptographic algorithms work as expected.

Pre-operational Self-Tests are run upon the power up/initialization of the module. The module transitions to the operational state only after the pre-operational self-tests (and the cryptographic algorithm self-tests (CASTs)) are passed successfully. The design of the modules ensures that all data output, via the data output interface, is inhibited whenever the module is in a pre-operational self-test condition. The Pre-Operational Self-Tests are detailed in the table below. Table 19: Pre-Operational Self-Tests

Conditional Self-Tests are run when an applicable security function or process is invoked. The Conditional Self-Tests are detailed in the table below. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 20: Conditional Self-Tests

Pre-operational self-tests can be run on-demand, for periodic testing, by rebooting the module. Table 21: Pre-Operational Periodic Information PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 22: Conditional Periodic Information PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

If any of the Pre-operational Self-Tests or Cryptographic Algorithm Self-Tests fail, the module will output an error status and enter a critical error state, where all data output is inhibited. Upon entering a critical error state, an operator can attempt to clear the critical error state by rebooting the module. If the critical error state cannot be cleared, the module must be returned to the manufacturer. The action taken upon failure of a conditional self-test is context dependent. The table below shows the different causes that lead to the Error States and the status indicators reported. Table 23: Error States PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The secure delivery of the modules is guaranteed by the trusted courier (DHL). Upon receipt of the module, the Crypto-Officer is responsible for verifying the packaging information slip and checking the delivery packaging for any irregularities (such as openings or tears). If the Crypto-Officer suspects any tampering, they should immediately contact PacketLight Networks Ltd. If the Crypto-Officer does not suspect tampering upon delivery of the module, they shall follow the steps defined in the Installation section of the PacketLight PL4000M/PL-4000T Security Guides (shipped with the cryptographic module). The operator shall set up the device as defined in the PacketLight PL-4000M/PL-4000T Security Guides

The following steps are required to enable the secure operation of the Module:

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

•    Ensure use of Approved algorithms for SSH: o    Key Exchange Algorithms:     ecdh-sha2-nistp256     ecdh-sha2-nistp384     ecdh-sha2-nistp521     diffie-hellman-group-exchange-sha256 (use modulus size 2048 or greater) o    Encryption Algorithms:     AES128-CTR     AES192-CTR     AES256-CTR     AES128-GCM     AES256-GCM o    Mac Algorithms:     HMAC-SHA2-256     HMAC-SHA2-512 •    Ensure use of Approved algorithms for SNMP: o    Authentication Algorithms:     SHA-256     SHA-384     SHA-512 o    Privacy Algorithms:     AES-CFB128-128     AES-CFB128-192     AES-CFB128-256

PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module does not claim mitigation of other attacks. PacketLight Networks Ltd. 2025 This document may be reproduced and distributed only in its original entirety without revision.