Infinera G42

Certificate

Approved Algorithms (29)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Infinera G42
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Firmware Load Test<br/>Firmware Update</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Block Ciphers (SNMPv3)<br/>Block Ciphers (SSHv2)<br/>Block Ciphers (TLSv1.2/v1.3)</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>kernel<br/>bootloader<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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."]
    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["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"]
    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 Infinera G42
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Firmware Load Test<br/>Firmware Update</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Block Ciphers (SNMPv3)<br/>Block Ciphers (SSHv2)<br/>Block Ciphers (TLSv1.2/v1.3)</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>kernel<br/>bootloader<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 C2,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

This is a non-proprietary cryptographic module security policy for the Infinera G42 with the firmware version R6.2.2 or R6.2.3 (hereinafter calls the Module). The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 and ISO/IEC 19790 for a

Purpose and Use: The Infinera G42 is a next-generation compact modular transport network elements deployed as part of a point-to-point, point-to-multipoint network for terrestrial and/or subsea applications. The G42 chassis provides multi-service client access (e.g. Ethernet, Optical Transport Network (OTN), etc.) to the Dense Wavelength Division Multiplexing (DWDM) transport bandwidth. The module is operated in a limited operational environment. Module Type: Hardware Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: © 2021-2025 Nokia Corporation.

The module is a multiple-chip standalone hardware cryptographic module. The cryptographic boundary is defined as the entire chassis unit’s physical perimeter encompassing the "top," "front," "left," "right," “rear” and "bottom" surfaces of the case and shown in the figures below and in the Physical Security section. These modules are described in more detail further below in this section. Figure 1: Infinera G42 Module Front View Figure 2: Infinera G42 IOP Card Figure 3: Infinera G42 XMM4 Card © 2021-2025 Nokia Corporation.

Figure 5: Infinera G42 Module Back View

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): © 2021-2025 Nokia Corporation.

N/A for this module. Tested Module Identification

• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

N/A for this module. Modes List and Description: Table 3: Modes List and Description By default, the module is delivered with a non-compliant state but supports an Approved mode following the steps in section "Secure Operation" of this document by the Crypto Officer, the module can only operate in the Approved mode. The module does not claim implementation of The tables in section 2.5 below list all Approved security functions of the module, including specific key size(s) (in bits unless noted otherwise) employed for Approved services, and implemented modes of operation. There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in these tables.

Approved Algorithms: © 2021-2025 Nokia Corporation.

HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA2512 HMAC-SHA2512 © 2021-2025 Nokia Corporation.

Table 4: Approved Algorithms Notes:

• The IV for AES-GCM is constructed in compliance with IG C.H scenario 1a (TLSv1.2). For TLS 1.2, the module offers the AES-GCM implementation and uses the context of Scenario 1a of IG C.H. The module is compliant with SP 800-52r2 section 3.3.1 and the mechanism for IV generation is compliant with RFC5288. The module’s implementation of AES-GCM is compliant to IG C.H option i) where module implements TLS protocol. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. © 2021-2025 Nokia Corporation.

• For TLS 1.3, the Module offers the AES-GCM implementation and uses the context of Scenario #5 of FIPS 140-3 IG C.H. The protocol that provides this compliance is TLS 1.3, defined in RFC8446 of August 2018, using the cipher suites that explicitly select AES-GCM as the encryption/decryption cipher (Appendix B.4 of RFC8446). The Module supports acceptable AES-GCM cipher suites from Section 3.3.1 of SP800-52 Rev2. The Module implements, within its boundary, an IV generation unit for TLS 1.3 that keeps control of the 64-bit counter value within the AES-GCM IV. If the exhaustion condition is observed, the Module will return an error indication to the calling application, who will then need to either trigger a re-key of the session (i.e., a new key for AES-GCM), or terminate the connection.
• The IV for AES-GCM is constructed in compliance with IG C.H scenario 1a (IPsec-v3). This IV generation of IPsec AES-GCM implementation is compliant with RFC 4106 and an IKEv2 protocol RFC7296 shall be used to establish the shared secret SKEYSEED from which the AES GCM encryption keys are derived. 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. The IPsec AES-GCM IV is only be used in the context of the AES GCM mode encryptions within the IPsec protocol. In case the Module’s power is lost and then restored, the key used for IPsec AES-GCM shall be regenerated.
• The PBKDF aligns with Option 1a in Section 5.4 of SP 800-132. The PBKDF algorithm parameters are: Password length 512 bits long, Salt length 256 bits long, and the number of iterations is 598502. The resulting key material is only used for storage applications.
• The module was algorithm tested based on the FIPS 186-4 standard for Digital Signatures. According to IG C.K, this module is 186-5 compliant as all 186-4 CAVP tests performed are mathematically identical to the 186-5 CAVP tests. The Module does not support 186-4 DSA or RSA X9.31 for Signature Generation or Signature Verification.
• SP800-90A Rev1 DRBG. N/A Table 5: Vendor-Affirmed Algorithms © 2021-2025 Nokia Corporation.

Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module.

© 2021-2025 Nokia Corporation. Method : MODP2048, MODP4096, and

AsymKeyPairKeyGen © 2021-2025 Nokia Corporation. Method: MODP2048, MODP3072, MODP4096, MODP6144 and

AsymKeyPairKeyGen AsymKeyPairKeyGen AsymKeyPairKeyGen © 2021-2025 Nokia Corporation.

© 2021-2025 Nokia Corporation. HMAC-SHA2256 HMAC-SHA2512 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA2256

© 2021-2025 Nokia Corporation. HMAC-SHA2512 HMAC-SHA2256 HMAC-SHA2512 HMAC-SHA2256 HMAC-SHA2512 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512

HMAC-SHA2512 © 2021-2025 Nokia Corporation. HMAC-SHA2256 HMAC-SHA2512

Table 6: Security Function Implementations

No specific algorithm information.

Table 7: Entropy Certificates Table 8: Entropy Sources The module implements two approved CTR_DRBGs based on SP800-90Arev1, with Algo Certs. #A4958 and #A4959. Each DRBG is used internally by the module (e.g. to generate symmetric keys, seeds for asymmetric key pairs, and random numbers for security functions). The DRBG is seeded by the entropy source described in the table above. The CTR_DRBG (AES-128/192/256) enables Derivation Function capability. The DRBG is instantiated with a 384-bits long entropy input (corresponding to 384 bits of entropy) and provides at least 256 bits security strength for the following cryptographic keys generation. The entropy source implementation generates an output that is considered to have full entropy. More information can be found in the public use document for ESV cert #E156.

The module generates RSA, ECDSA, EC Diffie-Hellman, and Diffie-Hellman asymmetric key pairs compliant with FIPS 186-4, using a NIST SP 800-90A CTR DRBG for random number © 2021-2025 Nokia Corporation.

generation. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs CKG for asymmetric keys as per section 5 of NIST SP 800-133rev2 (vendor affirmed) by obtaining a random bit string directly from an approved DRBG. The random bit string supports the required security strength requested by the calling application (without any V, as described in Additional Comments 2 of IG D.H.).

The module provides the following key/SSP establishment services in the approved mode of operation:

• KAS-FFC Shared Secret Computation:
• The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-FFC shared secret computation. The shared secret computation provides between 112 and 200 bits of encryption strength.
• The module supports the use of the safe primes defined in RFC 4419 (SSH), RFC

- SSH (RFC 4419): MODP-2048 (ID =

14. MODP-4096 (ID =
15. MODP-8192 (ID = 18) - TLS (RFC 7919): ffdhe2048 (ID = 256) - IKE (RFC 3526): MODP-2048 (ID =
16. MODP-3072 (ID =
17. MODP-4096 (ID =
18. MODP-6144 (ID =
19. MODP-8192 (ID = 18) • KAS-ECC Shared Secret Computation: o The module provides SP800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (2) with KAS-ECC shared secret computation. The shared secret computation provides between 128 and 256 bits of encryption strength.

The module supports SSHv2, TLS v1.2, TLSv1.3, SNMPv3 and IPsec/IKEv2 industrial protocols. No parts of SSH, TLS, SNMP and IKEv2 protocols, other than the KDFs, have been tested by the CAVP and CMVP. Please refer to SSPs Table for more information. © 2021-2025 Nokia Corporation.

The module’s physical perimeter encompasses the case of the tested platform mentioned in The module’s data output interface will be disabled when performing pre-operational self-tests, loading new firmware, zeroizing keys, or when in an error state.

ECDSAbased Table 10: Authentication Methods multiple Crypto Officer roles and User roles. Each role is authenticated by the module upon initial access to the module, as detailed below. Crypto Officer Roles:

• Security Admin (SA): This role performs all security functions provided by the module. This role has read and write access to all security related operations, full access to security management model, remote server configurations. Implements all operations to © 2021-2025 Nokia Corporation.

manage the creation, enabling / disabling of new Users and Passwords, User session monitoring, and configuration.

• Network Admin (NA): This role has read and write access to overall system configuration. For example, DCN / networking infrastructure / software and firmware configuration and upgrade schedules or management interface configurations.
• Encryption Admin (EA): This role has permissions to configure the data and control plane encryption functions. User Roles:
• Network Engineer (NE): This role has basic non-security related read and write access to equipment and traffic management model. For example, PM data, connectivity, provisioning status.
• Monitoring Access (MA): This role has read-only access to equipment and traffic management model. For example, PM data, connectivity, provisioning status.
• Provisioning (PR): This role has permissions to monitor the module, configure facility endpoints, and provision services. For example, provisioning of equipment and facility end-points.
• Turn-up and Test (TT): This role has required permissions for monitor, turn-up, and troubleshoot the module fix network problems. The module also allows the concurrent operators.

n (nonsecurity the nonsecurity N/A N/A N/A e e N/A N/A t N/A N/A © 2021-2025 Nokia Corporation. G,R,W,E,Z

n KAS-ECCKeyGen KAS-FFCKeyGen © 2021-2025 Nokia Corporation. Z W,Z W,Z W,Z

n KAS-ECCKeyGen KAS-FFCKeyGen © 2021-2025 Nokia Corporation. W,Z W,Z W,Z W,Z W,Z

n © 2021-2025 Nokia Corporation. KAS-ECCKeyGen KAS-FFCKeyGen W,Z W,Z W,Z W,Z

n KAS-ECCKeyGen © 2021-2025 Nokia Corporation. W,Z W,Z W,Z W,Z D: W,Z

n © 2021-2025 Nokia Corporation. KAS-ECCKeyGen KAS-FFCKeyGen G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z

n KAS-ECCKeyGen KAS-FFCKeyGen 1.3) 1.3) © 2021-2025 Nokia Corporation. G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z

n KAS-ECCKeyGen KAS-FFCKeyGen © 2021-2025 Nokia Corporation. G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z

n KAS-ECCKeyGen © 2021-2025 Nokia Corporation. G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z G,W,E,Z

The module supports the firmware load test by using ECDSA with Curve P-521 and SHA2-512 (ECDSA Cert. #A4956) for the new validated firmware to be uploaded into the module. A Firmware Load Test Key was preloaded to the module’s binary at the factory and used for firmware load test. In order to load new firmware, the Crypto Officer must authenticate to the module before loading the firmware. This ensures that unauthorized access and use of the module is not performed. The module will load the new update upon reboot. The update attempt will be rejected if the verification fails. 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 module implements Self-initiated cryptographic output capability without external operator request. The Security Admin (SA) shall configure self-initiated cryptographic output capability. Prior to executing the self-initiated cryptographic output capability, the module conducts two © 2021-2025 Nokia Corporation.

independent internal actions to activate the capability to prevent the inadvertent output due to a single error.

The module supports unauthenticated service. The unauthenticated User/Operators can trigger the self-test service by power-cycling the module, and is able to observe the module’s LEDs status.

The module is provided in the form of binary executable code. To ensure firmware security, the module is protected by conducting multiple layers firmware integrity tests. Please refer to section 10.1 Pre-Operational Self-Tests of this Security Policy document for more details. If the firmware integrity test fails, the module would enter to an Error state with all crypto functionality inhibited.

Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power-cycle or reboot the module to initiate the firmware integrity test on-demand.

N/A for this module. Type of Operational Environment: Limited

N/A N/A Table 13: Mechanisms and Actions Required Appling Tamper Evidence Labels The tamper evident labels shall be installed on the security devices containing the module prior to operating in Approved mode. TELs shall be applied as depicted in the figures below. Any unused TELs must be securely stored, accounted for, and maintained by the Security Admin (SA) in a protected location. Should the Security Admin (SA) have to remove, change or replace TELs for any reason, the Security Admin (SA) must examine the location from which the TEL was removed and ensure that no residual debris is still remaining on the chassis or card. If residual debris remains, the CO must remove the debris using a damp cloth. Any deviation of the TELs placement by unauthorized operators such as tearing, misconfiguration, removal, change, replacement or any other change in the TELs from its original configuration as depicted below shall mean the module is no longer in Approved mode of operation. Returning the system back to Approved mode of operation requires the replacement of the TELs as depicted below and any additional requirement per the site security policy which are out of scope of this Security Policy. The Security Admin (SA)checks the integrity of the label by following the guidance listed above. In case of notification of tamper evidence, the Security Admin (SA) shall not power on this module and shall contact Infinera Support team. The picture below shows the physical interface side of the module’s enclosure with tamperevident labels.

Number: Twenty-one (21) Small Tamper Evident Labels (P/N 550-0158-001) and Two (2) Large Tamper Evident Labels (P/N 550-0159-001). Placement: © 2021-2025 Nokia Corporation.

Figure 6: TELs on top of chassis Figure 7: TELs on rear of chassis © 2021-2025 Nokia Corporation.

Figure 8: TELs on front of chassis - IOP card (slot

2. Figure 9: TELs on front of chassis - XMM4 card (slot
3. Figure 10: TELs on front of chassis - XMM4 card (slot 3) © 2021-2025 Nokia Corporation.

Figure 11: TELs on front of chassis - CHM6 card (slot 4) Figure 12: TELs on front of chassis - CHM6 card (slot 4) and Blank card (slot 6) © 2021-2025 Nokia Corporation.

Figure 13: TELs on front of chassis - CHM6 card (slot 5) Figure 14: TELs on front of chassis - CHM6 card (slot 5) and Blank card (slot 7) © 2021-2025 Nokia Corporation.

Figure 15: TELs on front of chassis - CHM6 card (slot 4 and slot 5) and Blank card (slot 6 and slot 7) Surface Preparation: Clean the chassis of any grease, dirt, or oil before applying the tamper evident labels. Alcohol-based cleaning pads are recommended for this purpose. Operator Responsible for Securing Unused Seals: Must be stored in a secure location under controlled access

The module uses the filler panels with Hardware number: GX-BLANK while in the approved mode.

N/A for this module. © 2021-2025 Nokia Corporation.

Table 15: SSP Input-Output Methods © 2021-2025 Nokia Corporation.

Table 16: SSP Zeroization Methods Please note that the Firmware Load Test Key is only used for Firmware Load Test Authentication and not subject to the zeroization requirement. n © 2021-2025 Nokia Corporation. h

n © 2021-2025 Nokia Corporation. h MODP2048, MODP4096, MODP2048, MODP4096, MODP2048, MODP4096, MODP8192 N/A MODP2048, MODP4096, KASFFCKeyGen KAS-FFCKeyGen KAS-FFCKeyGen KAS-FFCKeyGen KASECCKAS-ECCKeyGen

h n © 2021-2025 Nokia Corporation. KAS-ECCKeyGen KAS-ECCKeyGen

n h © 2021-2025 Nokia Corporation. KASFFCKeyGen KAS-FFCKeyGen .3) KASECCKeyGen KAS-FFCKeyGen KAS-FFCKeyGen .3) KAS-ECCKeyGen

n h and P521 N/A © 2021-2025 Nokia Corporation. KAS-ECCKeyGen .3) KAS-ECCKeyGen .3)

n h .3) .3) .3) .3) .3) MODP2048, MODP3072, MODP4096, MODP6144 MODP2048, MODP3072, MODP4096, MODP6144 © 2021-2025 Nokia Corporation. KASFFCKeyGen KAS-FFCKeyGen .3) KAS-FFCSSC Sp80056Ar3

n h MODP2048, MODP3072, MODP4096, MODP6144 MODP8192 N/A MODP2048, MODP3072, MODP4096, MODP6144 © 2021-2025 Nokia Corporation. KAS-FFCKeyGen KAS-FFCKeyGen KASECCKeyGen KAS-ECCKeyGen

n © 2021-2025 Nokia Corporation. h KAS-ECCKeyGen KASECCKeyGen

n h Table 17: SSP Table 1 © 2021-2025 Nokia Corporation. n n n n n n

• SHA-1: The module includes an implementation of SHA-1 for hashing and digital signature verification. This implementation will be non-Approved for all uses starting January 1, 2031. At this time, the user should move to SHA2, which is available in this
• FIPS 186-4/186-5: As of February 5, 2024, the CMVP does not accept module submissions that implement DSA or RSA X9.31 in the approved mode, other than for signature verification which is approved for legacy use. This module does not implement DSA or RSA X9.31 for signature generation and therefore is unaffected by the current transition from 186-4 to 186-5. As detailed in section 2.7, the CAVP testing performed on the 186-4 algorithms is mathematically similar to the testing performed on the 186-5 algorithms and therefore this module claims compliance with 186-5. This means that no timeline exists in which any of the implemented algorithms will transition from approved to non-approved.

Table 19: Pre-Operational Self-Tests The module performs the following self-tests, including the pre-operational self-tests and Conditional self-tests. Prior to the module providing any data output via the data output interface, the module performs and passes the pre-operational self-tests. Following the successful pre-operational self-tests, the module executes the Conditional Cryptographic Algorithm Self-tests (CASTs). If anyone of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state.

N/A N/A N/A N/A N/A N/A N/A N/A N/A © 2021-2025 Nokia Corporation. N/A N/A N/A N/A N/A N/A N/A N/A KAS-ECCSSC KAS-FFCSSC N/A

MODP2048 W Table 20: Conditional Self-Tests N/A N/A N/A N/A N/A n KASECC n n n n The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.

Table 21: Pre-Operational Periodic Information © 2021-2025 Nokia Corporation.

Table 22: Conditional Periodic Information

On demand and periodic self-tests are performed by powering off the module and powering it on again. This service performs the same cryptographic algorithm tests executed during pre-operational self-tests and CASTs. During the execution of the periodic and on-demand self-tests, crypto services are not available and no data output or input is possible.

Table 23: Error States If any of the above-mentioned self-tests fail, the module reports the error and enters the Error state. In the Error State, no cryptographic services are provided, and data output is prohibited. The only method to recover from the error state is to reboot the module and perform the selftests, including the pre-operational firmware integrity test and the conditional CASTs. The module will only enter into the operational state after successfully passing the pre-operational firmware integrity test and the conditional CASTs.

The module meets all the Level 1 requirements for FIPS 140-3. Follow the secure operations provided below to place the module in approved mode. Operating this module without maintaining the following settings would put module operated in a non-compliance state. Secure Operation The Security Admin (SA) must configure and enforce the following initialization steps. Step 1. Strictly follow up the steps in section Physical Security to place the Opacity Shield and Tamper Evident Labels on the module. © 2021-2025 Nokia Corporation.

Step

2. Ensure that the firmware version R6.2.2 or R6.2.3 is running on the module. To verify the firmware version, the Security Admin (SA) shall use the following command. >show sw-management software-load-active swload-version swload-label software-load-active swload-version 'R6.2.2' or >show sw-management software-load-active swload-version swload-label software-load-active swload-version 'R6.2.3' Step
3. Enable approved mode. Execute the following steps to enable approved mode on the module: • To enable approved mode via CLI: Execute the following command from the CLI interface: ‘fips mode-enable’ A confirmation message is displayed. Enter y to proceed with the operation. This operation will cold reboot the system, delete the entire system configuration, including networking details, and may leave the system unreachable until the reboot is complete. • To enable approved mode via WebGUI: Navigate to Security > FIPS tab. Click ‘FIPS Control’. A pop-up window is displayed, and select mode-enable against Action field and click ‘Submit’. A success message is displayed Step
4. Create the User account and privileges for other roles defined in the Security Policy. Step
5. Ensuring that any of the deleted/deprecated algorithms by NIST SP800-140Cr2 and/or NIST SP800-131Ar2 are disabled as applicable in the FIPS certified version of the firmware. © 2021-2025 Nokia Corporation.

No specific Administrator guidance.

No specific Non-Administrator guidance.

N/A for this module. © 2021-2025 Nokia Corporation.