WaveLogic 5 Extreme Encryption Modem

Certificate

Approved Algorithms (24)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for WaveLogic 5 Extreme Encryption Modem
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>12.3</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Perform a firmware upgrade<br/>Perform a firmware upgrade2</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Report the firmware version, alarms, Status and…<br/>Initialize the module<br/>Configure PSK and certificate</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>UART/Host Connector</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>linux<br/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    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
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  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 C1,C2,C3,C4,C5,C6 clue;
  class I1,I2,I3,I4,I5,I6 infer;
  class R1,R2,R3,R4,R5,R6 risk;
  class E1,E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for WaveLogic 5 Extreme Encryption Modem
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>12.3</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Perform a firmware upgrade<br/>Perform a firmware upgrade2</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Report the firmware version, alarms, Status and…<br/>Initialize the module<br/>Configure PSK and certificate</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>UART/Host Connector</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>linux<br/>kernel<br/>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 C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

WaveLogic 5 Extreme Encryption Modem By Ciena Corporation [012 (P/Ns 174-0506-841) with components Mech Kit 500-0506-020 Version 001] [012 (P/Ns 174-0506-842) with components Mech Kit 500-0506-020 Version 001] [014 (P/N 174-0506-843) with components Mech Kit 500-0506-020 Version 001] [007 (P/N 174-0506-844) with components Mech Kit 500-0506-020 Version 001] Firmware Version: 12.3 Date: 11/28/2024 Prepared by: Acumen Security

Rockville, MD 20850 www.acumensecurity.net (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program About this Document This non-proprietary Cryptographic Module Security Policy for the WaveLogic 5 Extreme Encryption Modem provides an overview of the product and a high-level description of how it meets the overall Level

The WaveLogic 5 Extreme Encryption Modem may also be referred to as the “module” or “modem” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ciena Corporation shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

1. Scope Extreme Encryption Modem (Hardware versions: 007, 012 and 014) (Firmware Version 12.3) by Ciena Corporation. It contains specification of the security rules under which the cryptographic module operates, including those derived from the requirements of the FIPS 140-3 standard. Overview The WaveLogic 5 Extreme Encryption Modem is an optical transponder daughter card installed within a Ciena optical transponder service module. It consists of a multiple chip-embedded application specific integrated circuit (ASIC) along with optical components and supporting circuitry. All security-relevant communications to the module via its management interface (Ethernet) are encrypted using TLS v1.3. The module also supports a client input and output data interface and optical connector. All traffic entering and exiting the module via the optical connector is encrypted/decrypted using AES GCM. The module provides fully secure cryptographic functionality, including peer authentication, key derivation, datapath encryption, physical security, and identification and authentication of the module’s Crypto Officer (CO). This module is configured and monitored by a Ciena Control Processor Module. The module operates in Approved mode by default. No additional configuration is needed for rendering or operating the module in the Approved mode. The following table lists the level of validation for each area in FIPS 140-3: N/A N/A N/A Table 1 – Security Levels The module meets the requirements of an overall Security Level
2. (Ciena Corporation © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification Figure 1: High level module block diagram As shown in the above block diagram, the module consists of an ARM A53 quad core processor with internal RAM. The firmware running on the processor performs all the monitoring/control activities related to the datapath encryption feature. The crypto accelerator is a security co-processor. It contains hardware cryptographic engines and firmware for the WaveLogic 5e Encryption Modem Crypto library. The datapath encryption and decryption block performs the AES-GCM encryption and decryption function on the client payload data. The module is packaged within other Ciena products to form a complete encryption transport solution. The Ciena product forms the Trusted Operational Environment’s Physical Perimeter (TOEPP) for the module. Figure 2 below shows the cryptographic boundary of the module (highlighted in red). (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Figure 2: Cryptographic Boundary of WaveLogic 5 Extreme Encryption Modem (represents all P/Ns in Table 2) Table 2

• Cryptographic Module Tested Configuration (Ciena Corporation © 2024) Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 1864 ) SP80056arev3 KASECCSSC KASECC1 SP80056arev3 800108 There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

800135rev1 80056Crev1 80090Arev1 80056Arev3 80056Arev3 80056Arev3 SP 80038F prerequisite for KAS-ECCSSC Sp80056Ar3/ KAS-ECCSSC Sp80056Ar3/ Sp80056Cr1/ Sp80056Ar3/ AESKWP/ AESGCM/ SP 80038F (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

SP800133rev2 Table 3

• Approved Algorithms Table 4
• Non-Approved Algorithms Allowed in the Approved Mode of Operation Table 5
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The module does not support Non-Approved Algorithms Not Allowed in the Approved Mode of Operation. Overall security design and the rules of operation
• No parts of the TLS 1.3 protocol, other than the KDF, have been tested by the CAVP and CMVP per FIPS 140-3 IG D.C. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key seed value for asymmetric keys are the unmodified output from the Approved DRBG. The module’s AES-GCM implementation also conforms to IG C.H Scenario #5 following RFC 8446 for TLS v1.3 and provides support for GCM cipher suites from Section 8.4 of RFC 8446. The IV is generated internally using the module’s Approved DRBG and will only be used in the context of (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

• the AES-GCM encryption in the context of the TLS v1.3 protocol. The protocol’s implementation is contained within the boundary of the module under test. The module’s AES-GCM implementation also conforms to IG C.H Scenario #2 and the IV is generated by the Approved DRBG that is internal to the module’s boundary. The IV length is 96 bits as per SP800-38D. The initialization requirements for the module can be found in Section 11 Life-cycle Assurance in this document. (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces The module supports the following physical ports and interfaces:

• Table 5 below provides a mapping of the physical interfaces of the module to the logical interfaces: Table 6
• Ports and Interfaces (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

4. Roles, Services, and Authentication The module supports one authorized role (i.e., Crypto Officer role). The CO role is responsible for module initialization and module configuration, including security parameters, key management, status activities, and audit review. The CO role is assumed explicitly by the Ciena Control Processor Module that configures and monitors the module. The Ciena Control Processor Module authenticates to the module using TLS 1.3 certificatebased authentication. N/A Table 7

• Roles, Service Commands, Input and Output The services that require operator to assume an authorized role are listed in Table 9 below. Please note that the Sensitive Security Parameters (SSPs) listed in Table 9 use the following indicators to show the type of access required:
• 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.
• (Ciena Corporation © 2024) Public Material
• May be reproduced only in its original entirety (without revision).

(Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Table 8

• Roles and Authentication (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

In Approved mode, the module provides a limited number of services for which the operator is not required to assume an authorized role (see Table 7). None of the services listed in the table disclose

• Authentication The module supports identity-based authentication. Module operators must authenticate to the module before being allowed access to services that require the assumption of an authorized role. The CO authenticates to the module from the Control Processor module using the TLS 1.3 protocol. The TLS 1.3 The module can be configured to use either a Pre-Shared Key or X.509 Certificate for module peer authentication. The pre-shared key is a 256-bit key. The X.509 certificate is P-384 or P-521. HMACSHA2-256 Sp80056Cr1 G ECDSA P521 Sp80056Cr1 s (E) (G) (R, G, E), TLS 1.3 PreMaster (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

1.3 SHA2384 P-384, P521 ECDSA P521 Sp80056Cr1 1.3 SHA2384 s (W) (G) (G) (E) TLS 1.3 PreMaster (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

P-384, P521 s TLS 1.3 PreMaster (W) (E) (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

N/A s N/A ECDSA P521 Sp80056Cr1 1.3 SHA2384 P-384, P521 (E) (R, G,E) TLS 1.3 PreMaster (G, E, W) (G, E, Z) (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

s d N/A N/A N/A ECDSA P521 SHA2512 N/A For firmware load test, the module runs ECDSA P-521 with SHA2-512 check. Please note that the module does not support complete image replacement. (Ciena Corporation © 2024) Public Material

• May be reproduced only in its original entirety (without revision).

operator reauthenticatio n ECDSA P521 Sp80056Cr1 1.3 SHA2384 P-384, P521 s (W) (E, R) (G, W) TLS 1.3 PreMaster (W, E, R) (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Issue reauthenticatio initiate a reauthenticatio demand selftests (Perform selftests ) Perform preoperational ECDSA P521 Sp80056Cr1 1.3 SHA2384 P-384, P521 ECDSA P521 SHA2512 s TLS 1.3 PreMaster (W, E, R) N/A Table 9

• Approved Services (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Self-initiated Cryptographic Output The module supports self-initiated cryptographic output functionality via the Datapath Encryption/ Decryption Service. Before enabling this service, the CO must configure and perform two independent internal actions in order for the service to get activated. The independent internal actions are as follows:

1. The CO must authenticate with the modem.
2. The CO must perform the service to activate PSK or install a certificate authentication. (Ciena Corporation © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security The module uses ECDSA P-521 using SHA2-512 for firmware integrity testing/verification. The FIT_PUBLIC, an ECDSA P-521 SHA2-512 Public key, is used to authenticate the Linux kernel. This is run at startup and on demand by reloading the module. The module also runs the self-tests for ECDSA Signature verification, SHA2-256 and SHA2-512 prior to running the integrity check. The executable form of the module firmware is a pre-compiled binary. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

6. Operational Environment The module is a hardware module with the embodiment type as a multi-chip embedded cryptographic module. Hence, the module’s operational environment (OE) is a limited OE since the module is designed to accept only controlled firmware changes that successfully pass the firmware load test. The requirements per this section do not apply to the module since the module claims to meet Physical Security Level 2 requirements. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

7. Table 10

• Physical Security Inspection Guidelines seals, metal covers and PCB layers) installed. The CO must perform a physical inspection of the unit for signs of damage and to ensure that all physical security mechanisms are in place. Additionally, the CO should check the package for any irregular tears or openings. If damage is found or tampering is Section 2 of this document shows the placement of the tamper seals. (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

8. Non-invasive Security This section is not applicable. The module does not implement any Non-invasive attack mitigation techniques. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management HMACSHA2-256 K Sp80056Cr1 Sp80056Cr1 Generation N/A N/A N/A N/A Zeroisation ) N/A N/A N/A N/A N/A (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

ECDSA P521 key (TLSPSK) ECDSA P521 ECDSA P521 Sp80056Cr1#A33 ECDSA P521 Sp80056Cr1 ECDSA P521 Generation N/A N/A Zeroisation the DPEPSK and TLSPSK N/A 1.3 N/A N/A N/A h 1.3 N/A 1.3 N/A N/A N/A (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Generation N/A in nonvolatile in nonvolatile N/A ECDSA P521 ECDSA P521 N/A N/A 1.3 Zeroisation N/A N/A ECDSA P521 ECDSA P521 N/A PreMaster 1.3 N/A (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

1.3 SHA2384 1.3 1.3 1.3 Generation Zeroisation 1.3 1.3 1.3 (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Generation 1.3 Zeroisation e s 1.3 N/A ) ) Sp80056Cr1 Sp80056Cr1 N/A (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). h

Generation N/A Zeroisation h Table 11

• SSPs The Module contains the following non-SSPs:
• VAULT_PUBLIC; 256 bits; ECDSA P-256 public key #A3379; Used to authenticate the Vault firmware image. BOOT_PUB; ECDSA P-521 Public key #A3379; Used to authenticate boot image FIT_PUBLIC; ECDSA P-521 Public key #A3379; Used to authenticate the Linux kernel ROOTFS_PUB; ECDSA P-521 Public key #A3379; Used to authenticate the ROOTFS of the SW load. LOAD_KEY; ECDSA P-521 Public key #A3379; Used for the load check during upgrades. The module generates keys as described in SP 800-133rev2 Section 4, Option #1, 5.1, 5.2, 6.2.1 and 6.2.2. It uses an Approved CTR_DRBG (as specified in SP 800-90Arev1) to generate symmetric keys and seed for asymmetric keys. The DRBG is seeded from seeding material provided by a hardware-based (Wavelogic 5e Encryption Modem EIP-76 TRNG), which provides an entropy source and unbiased random sequence of bits to the DRBG. The module is a hardware module with an entropy generating inside the module’s cryptographic boundary compliant with Scenario 1 (a) described in FIPS 140-3 IG 9.3.A. The entropy source produces Table 12
• Non-Deterministic Random Number Generator Specification (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

10. Self-tests ISO/IEC 19790 requires the module to perform pre-operational self-tests to ensure the module integrity and the correctness of the cryptographic functionality at start-up. The algorithms supported by the module require cryptographic self-tests and these tests are run when the module is in operational state prior to the first use of algorithm. Some functions also require conditional tests during normal operation of the module. The pre-operational firmware integrity test (using ECDSA P-521 SHA2-512) can be run on demand by reloading the module.
11. Pre-operational self-tests: a. Firmware Integrity test using ECDSA P-521/SHA2-512
12. Conditional self-tests: a. conditional cryptographic algorithm test ▪ Ciena WaveLogic 5e Encryption Modem Crypto Implementation: o AES-CBC 128-bit KAT (Encrypt) o AES-CBC 128-bit KAT (Decrypt) o AES-GCM 256-bit KAT (Encrypt) o AES-GCM 256-bit KAT (Decrypt) o SHA2-256 KAT o SHA2-384 KAT o SHA2-512 KAT o HMAC-SHA2-256 KAT o HMAC-SHA2-384 KAT o HMAC-SHA2-512 KAT o AES-256 CTR DRBG KAT ▪ SP800-90Arev1 Section 11 health tests o SP800-56Arev3 KAS-ECC-SSC KAT (Curve used: P-521) o ECDSA P-521 Sign KAT o ECDSA P-521 Verify KAT o KDF NIST SP 800-108 (HMAC SHA2-256) KAT o One-Step KDA KAT o Two Step KDA KAT o TLS 1.3 KDF KAT ▪ o o o o Ciena WaveLogic 5e Encryption Modem Datapath Ciphers Implementation: AES-GCM KAT (Encrypt) AES-GCM KAT (Decrypt) Repetition Count Test on ENT Adaptive Proportion Test on ENT b. Conditional pair-wise consistency test: (Ciena Corporation © 2024) Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

• ECDSA keys generated for signature generation/verification and ECDSA keys used for key agreement c. Conditional Firmware Load test: ECDSA P-521 SHA2-512 The CAST for the cryptographic algorithms used to perform the Approved integrity technique, ECDSA P521 SHA2-512 KATs, occur before the integrity test. The module implements the above cryptographic algorithm self-tests which are run prior to the first use of the algorithm for the cryptographic operations and are also classified as a part of conditional self-tests. Upon the failure of any pre-operational self-test and the cryptographic algorithm self-tests, the module goes into “Critical Error” state and disables all access to cryptographic functions and SSPs. A permanent error status will be relayed via the status output interface, which then raises an alarm and adds an entry to the system log file. In case of a firmware integrity failure, the module returns “failed loading sn kernel image” and “Cryptographic Algorithm Self-Test failure” in case of one or more CAST failures. Upon failure of the firmware load test, the module enters “Soft Error” state. The soft error state is a nonpersistent state wherein the module resolves the error by rejecting the loading of the new firmware. Upon rejection, the error state is cleared, and the module resumes its services using the previously loaded firmware. If the module encounters an error in any other conditional self-tests (Pairwise Consistency tests, noise source error, etc.) the module will enter a soft error state where the requested command fails. The error condition may be cleared by re-executing the service which prompted the conditional self-test. If the error condition is not cleared, then the module is considered to be malfunctioning and should be returned to Ciena. (Ciena Corporation © 2024) Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

11. Life-Cycle Assurance The module only runs in an Approved mode of operation. The CO can monitor and configure the module via the TLS 1.3 management channel from the Ciena Control Processor Module. Detailed instructions for monitoring and troubleshooting the module are provided in the Ciena’s User’s Guide and Technical Practices document. Ciena uses Git software for the management of source code artifacts and SharePoint for hardware and documentation version control. The module is developed using high level programming languages C and C++. The module is always delivered via commercial bounded carrier. The shipment will contain a packing slip with the serial numbers of all shipped devices. Prior to deployment the receiver shall verify that the hardware serial numbers match the serial numbers listed in the packing slip. The module is shipped from the factory with the required physical security mechanisms (tamper-evident labels, metal covers and PCB layers) installed. The CO must perform a physical inspection of the unit for signs of damage and to ensure that all physical security mechanisms are in place. Additionally, the CO should check the package for any irregular tears or openings. If damage is found or tampering is suspected, the CO should immediately contact Ciena. There is no special procedure to decommission the modem. Disconnecting fibers and removing the encryption module from the system (powering down) results in all SSP zeroisation. There are no other sanitization procedures to complete. The module only supports an approved mode of operation. No additional configuration is required on the Crypto Officer’s part except for installing the module since the provisioning of the module will be taken care of by another Ciena module, the Control Processor. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any other attacks. (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

End of Document (Ciena Corporation © 2024) Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Referenced URLs

• www.acumensecurity.net
• https://csrc.nist.gov/projects/cryptographic-module-validation-program