Waveserver 5 Control Processor Module

Certificate

Approved Algorithms (44)

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

flowchart LR
  %% Deterministic review-risk graph for Waveserver 5 Control Processor Module
  %% 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>Upgrade<br/>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</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 Waveserver 5 Control Processor Module
  %% 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>Upgrade<br/>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status</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/>HTTPS</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

Waveserver 5 Control Processor Module By Ciena Corporation Hardware Version(s): 186-3011-900 revision 001 and revision 002, 186-3011-901 revision 001 and revision 002 Firmware Version: 2.3.12 Date: 11/28/2024 Prepared by: Acumen Security

2400 Research Blvd, Suite 395

Rockville, MD 20850 www.acumensecurity.net Public Material – May be reproduced only in its original entirety (without revision).

1. General 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 Waveserver 5 Control Processor Module provides an overview of the product and a high-level description of how it meets the overall Level

The Waveserver 5 Control Processor Module may also be referred to as the “CP” or “module” 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. Scope This non-proprietary document describes the cryptographic module security policy for the Waveserver 5 Control Processor Module (Hardware version: 186-3011-900 revision 001 and revision 002 and 1863011-901 revision 001 and revision 002, Firmware Version 2.3.12). The two part numbers are equivalent and just used to differentiate the manufacturing process and sites. 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. Public Material – May be reproduced only in its original entirety (without revision).

Overview The Waveserver 5 Control Processor Module is a multi-chip embedded hardware cryptographic module. The module is a purpose-built field replaceable unit intended for operation within the Ciena Waveserver

5 chassis. Its primary function is management of the Waveserver 5 chassis, which includes one or more

Waveserver 5 Encryption Modules. The module serves as the central control and storage facility for any SSPs utilized by the Encryption Module. Management functions of the module include device configuration, alarm monitoring, and log collection. The security functions performed by the module include operations related to the provisioning of the chassis (access controls, user passwords, remote authentication, and firmware upgrades), as well as control of the Encryption Module via TLS v1.3. All communication to the module via its management interface is encrypted either using TLS v1.2 or SSHv2. The module also supports a local serial console interface and read-only SNMPv3 data. The major components of the module include a Marvell CN9130 System on a Chip (SOC) with external DDR memory, an SSD, a CPLD (Complex Programmable Logic Device), and FPGA (Field-Programmable Gate Arrays). The module is installed inside the Waveserver 5 chassis and is attached to other Waveserver subsystems via a host connector, PCIe, Ethernet, serial, and USB-C. The module is shipped in factory state and the module is explicitly configured to operate in an Approved mode of operation. Section 14 provides additional information for configuring the module in the Approved mode of operation. Public Material – May be reproduced only in its original entirety (without revision).

The following table lists the level of validation for each area in FIPS 140-3: Table 1

• Security Levels The module meets the overall Security Level 2 requirements. Public Material
• May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification Figure 1 below depicts the Waveserver 5 chassis, which consists of a CP card and up to four Encryption Modules. The validated module i.e., the Waveserver 5 Control Processor Module (CP card), is a multichip embedded embodiment housed in the Waveserver 5 chassis; the module components are completely enclosed within a hard metal clamshell cover with tamper evident labels applied. Figure 2 provides a block diagram of the module, depicting the major components of the module and the cryptographic boundary as shown in red. No module components have been excluded from the cryptographic boundary. The Ciena Waveserver 5 Chassis forms the Trusted Operational Environment’s Physical Perimeter (TOEPP) for the module. Figure 1

• Ciena Waveserver 5 Chassis Public Material
• May be reproduced only in its original entirety (without revision).

Figure 2

• Waveserver 5 Control Processor Module Public Material
• May be reproduced only in its original entirety (without revision).

Figure 3 below shows the cryptographic boundary of the module (highlighted in red). Figure 3

• Waveserver 5 Control Processor Module Cryptographic Boundary Public Material
• May be reproduced only in its original entirety (without revision).

The cryptographic module tested configuration can be found in the table below: Table 2

• Cryptographic Module Tested Configuration The module is shipped in factory state and the module is explicitly configured to operate in an Approved mode of operation. Section 11 provides additional information for configuring the module in the Approved mode of operation. The module does not support a non-approved mode. The module implements the following Approved algorithms in Table 3: (PThere 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. Public Material
• May be reproduced only in its original entirety (without revision).

(P(Pd Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 3

• Approved Algorithms The module does not implement any non-Approved algorithms that are allowed for use within an Approved mode of operation. The following table lists the Non-Approved Algorithms Allowed in the Approved Mode of Operation with 2.4.A Table 4
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Overall security design and the rules of operation
• No parts of the TLS, SNMP and SSH protocols, 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 Generation (CKG) as per SP800-133rev2 (vendor affirmed). The resulting symmetric keys and seed value for asymmetric keys are the unmodified output from the Approved DRBG. The module supports Sections 4, 5.1, 5.2, 6.1, 6.2.1, 6.2.3 per NIST SP 800-133r2.
• The module’s AES-GCM implementation conforms to IG C.H Scenario #1 following RFC 5288 for TLS v1.2. The operations of one of the two parties involved in the TLS key establishment scheme Public Material
• May be reproduced only in its original entirety (without revision).

were performed entirely within the cryptographic boundary of the module being validated. The counter portion of the IV is set by the module within its cryptographic boundary. The module supports AES-GCM cipher suites from Section 3.3.1 of SP800-52 rev2. The implementation of the nonce_explicit management logic inside the module ensures that when the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key (e.g., a 64-bit counter starting from 0 and increasing, when it reaches the maximum value of 2^64 -1), either party (the client or the server) that encounters this condition triggers a handshake to establish a new encryption key (per Sections 7.4.1.1 and 7.4.1.2 in RFC 5246).

• 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 the AES-GCM encryption in the context of the TLS v1.3 protocol.
• 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 module only supports testable RSA moduli/key sizes (2048 and 3072 bits) and thus the requirements per FIPS 140-3 IG C.F do not apply.
• The module implements a CAVP compliance tested key derivation function compliant to NIST SP800- 132 KDF (PBKDF). The password consists of at least 14-128 bits. The probability that a random attempt will end up with the same output is: 1/(2^14) = 0.00006 (using a minimum size for the password). PBKDFv2 is implemented to support option 1 a per SP800-132. The iteration count is 4086 bits. This is in accordance with NIST SP 800-132 which recommends that iteration count should be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The derived keys may only be used in storage applications. The initialization requirements for the module can be found in Section 11 Life-cycle Assurance in this document. 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:

• UART interface (providing connectivity to external Console port)
• 10/100/1000 Base-T Ethernet interface (providing connectivity to internal chassis components Figure 4
• Waveserver 5 Control Processor Module (Front and Rear) Table 5 below provides a mapping of the physical interfaces of the module to the logical interfaces: Public Material
• May be reproduced only in its original entirety (without revision).

Power Supply/Input

Power Interface

Power supply/input from within the Waveserver 5 chassis where the module resides

Table 5

• Ports and Interfaces Public Material
• May be reproduced only in its original entirety (without revision).

4. Roles, Services, and Authentication The module supports one authorized role: 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 module supports both role-based and identity-based operator authentication methods as specified in Section 5.1. The CO role is able to configure and monitor the module via a console, HTTPS or SSH connection. s Table 6

• Roles, Service Commands, Input and Output The module does not support a bypass capability. Public Material
• May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 7– Roles and Authentication The services that require operators to assume an authorized role are listed in Table 8 below:

• 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. Public Material
• May be reproduced only in its original entirety (without revision).

] Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

] Public Material – May be reproduced only in its original entirety (without revision).

] Public Material – May be reproduced only in its original entirety (without revision).

] ] Public Material – May be reproduced only in its original entirety (without revision).

] Public Material – May be reproduced only in its original entirety (without revision).

], (W, X) ] Public Material – May be reproduced only in its original entirety (without revision).

Table 8 – Approved Services 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 8). None of the services listed in the table disclose cryptographic keys and CSPs or otherwise affect the security of the module. The module does not support any non-approved services. Self-initiated Cryptographic Output The module supports self-initiated cryptographic output in the context of two services, namely, the Manage the Encryption Modem and Secure Backup services. The module is designed to require the following two internal actions in support of the self-initiated cryptographic output: For the Manage the Encryption Modem service:

1. Entered the "system encryption enable" command.
2. Activation of the PSK. For the Secure Backup service: Public Material – May be reproduced only in its original entirety (without revision).

1. Invocation of the service.
2. Saved the configuration using “Config save” command. The tester observed that no other firmware components are executed in the process of activation apart from the firmware/code related to the commands specified above and that related to the services themselves. Authentication The module supports both role-based and identity-based authentication. Module operators must authenticate before being allowed access to services that require the assumption of an authorized role. The module authenticates an operator using password or operator public key. Authentication is achieved by initiating a console, SSH, or TLS/HTTPS session. Digital certificates and public keys are used for SSH and TLS authentication. The strength calculations below provide the minimum strength based on the public key or password. The module employs the authentication methods described in Table 7 above to authenticate Crypto Officers. Public Material – May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security The module uses ECDSA P-521 using SHA2-384 for integrity testing/verification. This is run at startup and on demand by reloading the module. The module also runs the self-tests for ECDSA Signature verification and SHA2-384 prior to running the integrity check. The Ciena signature public key (CPK) (256 bits; ECDSA P-521, #A3284) is used for ECDSA validation of all firmware. For firmware load test, the module runs ECDSA P-521 with SHA2-384 check. Please note that the module does not support complete image replacement, and the upgrade is considered a partial replacement since it is not replacing the entire firmware. 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 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. This section is classified as not applicable as the module is a hardware module and the physical security section is claimed for level
7. Public Material – May be reproduced only in its original entirety (without revision).

The chassis of the multi-chip embedded cryptographic module are sealed with 3 tamper-evident seals, applied during manufacturing. The physical security of the module is intact if there is no evidence of tampering with the tamper-evident seal(s). 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 figure shows the placement of the tamper seals. Public Material – May be reproduced only in its original entirety (without revision).

Figure 5

• Location of Tamper Seal Placement on the Waveserver 5 Control Processor Module 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. Public Material – May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management The module supports the following SSPs listed below in Table 10: Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

1.3 1.3 1.3 1.2 Public Material – May be reproduced only in its original entirety (without revision).

1.3 1.3 Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 10

• SSPs
• Ciena signature public key (CPK); 256 bits; ECDSA P-521 public keys #A3284; Used for ECDSA validation of all FW. The module supports AD/EE per FIPS 140-3 IG 9.5.A. The module generates keys as described in SP800-133 rev2 Section 4, Option #1. It uses an Approved Hash DRBG (as specified in SP800-90Arev1) to generate symmetric keys and seed for asymmetric keys. The DRBG is seeded from seeding material provided by a hardware based SRNG (Infineon SLB9672 SRNG), which provides an entropy source and unbiased random sequence of bits to the DRBG. The module is a hardware module with an entropy generating SRNG inside the module’s cryptographic boundary consistent with Scenario 1 (a) described in FIPS 140-3 IG 9.3A. Public Material
• May be reproduced only in its original entirety (without revision).

Table 11

• Non-Deterministic Random Number Generation Specification 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. 1. Pre-operational self-tests: a. Pre-operational firmware integrity test: ECDSA P-521 with SHA2-384. 2. Conditional self-tests: b. Conditional cryptographic algorithm test: Ciena Waveserver Crypto Library 1 Implementation:     ECDSA P-521 Signature verification KAT     SHA2-384 KAT     AES-CBC 256-bit KAT (Encrypt)     AES-CBC 256-bit KAT (Decrypt)     AES-GCM 256-bit KAT (Encrypt)     AES-GCM 256-bit KAT (Decrypt)     Triple-DES CBC KAT (Decrypt)     SHA-1 KAT     SHA2-256 KAT     SHA2-384 KAT     SHA2-512 KAT     HMAC-SHA-1 KAT     HMAC-SHA2-256 KAT     HMAC-SHA2-384 KAT     HMAC-SHA2-512 KAT     Hash DRBG (SHA2-256) KAT • SP800-90Arev1 Section 11 health tests     KAS-ECC-SSC primitive “Z” KAT (Curves used for CAST: P-256)     KAS-FFC-SSC primitive “Z” KAT (Modulus used for CAST: 2048-bit)     ECDSA P-256 with SHA2-256 Sign KAT     ECDSA P-256 with SHA2-256 Verify KAT     ECDSA P-521 with SHA2-384 Verify KAT     RSA 2048 bits with SHA2-256 using PKCS1 v1.5 Sign KAT     RSA 2048 bits with SHA2-256 using PKCS1 v1.5 Verify KAT     SP800-132 PBKDF (HMAC SHA2-256) KAT     SP800-108 KBKDF (HMAC SHA2-256) KAT     SP800-135rev1 TLS 1.2 KDF KAT     SP800-135rev1 KDF SSH KAT     KDF TLS 1.3 (HMAC SHA2-256) KAT Ciena Waveserver Crypto Library 2 Implementation: Public Material – May be reproduced only in its original entirety (without revision).

 AES-GCM 256-bit KAT (Decrypt)  Transition Count Health Test on noise source: This test covers both RCT and APT test implementations. The test is implemented per the details of SP800-90B section 4.5 developer defined health tests. c. Conditional pairwise-consistency test: Whenever an RSA and ECDSA key pair of any valid size is generated on the module (RSA and/or ECDSA key pairs for use in signature generation/verification and ECDSA key pairs for use in SSP agreement), before the operation is completed and the keys are made available for use to the operator, a pairwise consistency test is executed on the key pair. d. Conditional firmware load test: When firmware is updated on the module, the update image must be validated before the underlying firmware on the device is updated. This is accomplished through an ECDSA P-521 with SHA2-384 signature validation on the update image. The CASTs for the cryptographic algorithms used to perform the Approved integrity technique, ECDSA P-

521 SHA2-384 KATs, occur before the integrity test. The respective Conditional cryptographic algorithm

self-tests (CAST) are run prior to the first use of each algorithm for the cryptographic operations. Preoperational self-tests can be performed on demand by reloading the module. Conditional self-tests can be performed by invoking the corresponding cryptographic functionality of the module. Upon the failure of any pre-operational self-test and the cryptographic algorithm self-tests, the module goes into “Hard Error” state and disables all access to cryptographic functions and SSPs. A permanent error status will be relayed via the status output interface. The module returns the error indicator/message "Error Validating image" for a failure in the firmware integrity test and "FIPS Self-Test Suite: self-test failure for <algorithm> (forced)" in case of failures triggered in the CASTs. 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 Pairwise Consistency tests, the module re-generates the key pair and performs the test again until it is passed. If the error condition is not cleared, then the module is considered to be malfunctioning and should be returned to Ciena. Public Material – May be reproduced only in its original entirety (without revision).

a. Life-cycle Assurance 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, C++ and Python. 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. The end of life for the module meets the ISO/IEC 19790 requirements. The sanitization requirements are met by zeroising the module using Secure Erase via RTFD command or pushbutton. The following steps must be followed by the CO to place the module in Approved mode of operation. Please note that the module does not support a non-approved mode of operation. The module is shipped to the customers in default state and the following steps must be used by the CO to place the module in Approved mode of operation.

1. As soon the module is powered up, the module runs the pre-operational self-tests and conditional cryptographic algorithm self-tests. After, successful completion of these tests, the module allows the operator to enter the default credentials. The CO can then enter "user set user su password *********" to change the default credentials.
2. Once the default credentials are entered, the operator must configure the IP address and gateway for the module.
3. The operator must enter the following command to disable the shell access to the operator. <system environment diag disable diag-shell>
4. The operator must enter the following command to disable the RADIUS and TACACS services to the operator. <system encryption remote-authentication radius disable> <system encryption remote-authentication tacacs disable>
5. The operator can verify the status by entering the following commands: system environment show: This command shows if the root/shell access is disabled system encryption show: This command shows if RADIUS and TACACS is disabled If both the above commands display that root/shell access, RADIUS and TACACS are disabled, that confirms the operator/tester that the module is in Approved mode of operation. The CO can monitor Public Material – May be reproduced only in its original entirety (without revision).

and configure the module via the console port or SSH. The CO is responsible for configuring, maintaining, and monitoring the status of the module to ensure that the module is in Approved mode of operation. No additional maintenance requirements apply for the module. For additional details regarding the management of the module, please refer to Ciena’s User’s Guide and Technical Practices document. Public Material – May be reproduced only in its original entirety (without revision).

b. Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any other attacks. Public Material – May be reproduced only in its original entirety (without revision).

End of Document Public Material – May be reproduced only in its original entirety (without revision).