Infinera G42

Certificate

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["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Firmware Load<br/>upgrade<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output<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/>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["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 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["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Firmware Load<br/>upgrade<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output<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/>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,C5,C6 clueLow;

Security Policy, page by page

Nokia Corporation Infinera G42 © 2021-2025 Nokia Corporation

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: 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. © 2021-2025 Nokia Corporation

Figure 1: Infinera G42 Module Front View Figure 2: Infinera G42 IOP Card Figure 3: Infinera G42 XMM4 Card Figure 4: Infinera G42 CHM6 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): 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: © 2021-2025 Nokia Corporation

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

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: Table 5: Vendor-Affirmed Algorithms 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.

Table 6: Security Function Implementations

• 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 © 2021-2025 Nokia Corporation

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.

• 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.
• In accordance with FIPS 140-3 IG D.H, the cryptographic Module performs Cryptographic Key Generation as per section 5 in SP800-133rev2. The resulting generated seed used in the asymmetric key generation is the unmodified output from SP800-90Arev1 DRBG.

Table 7: Entropy Certificates © 2021-2025 Nokia Corporation

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-90Arev1 CTR DRBG for random number 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): © 2021-2025 Nokia Corporation

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 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.

The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides physical ports which are mapped to logical interfaces provided by the module (data input, data output, control input, control output and status output) as above. 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.

Method Name

Description sessions per second to authenticate in a one-minute period, the probability of successfully authenticating to the module within a one minute period is 17,000 * 60 = 1,020,000/(2^128), which is less than 1/100,000.

Security Mechanism

Strength Each Attempt

Strength per Minute

Table 10: Authentication Methods The module supports identity-based authentication mechanism. The module supports the 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 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. © 2021-2025 Nokia Corporation

The module also allows the concurrent operators.

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 Crypto Officer shall configure self-initiated cryptographic output capability. Prior to executing the self-initiated cryptographic output capability, the module conducts two 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.

Type of Operational Environment: Limited Module is operated in a limited operational environment. New firmware versions within the scope of this validation must be validated through the FIPS 140-3 CMVP. Any firmware loaded into the module that is not shown on the module certificate, is out of scope of this validation and requires a separate FIPS 140-3 validation.

The module meets the FIPS 140-3 Level 1 security requirements as production grade equipment.

Table 13: Mechanisms and Actions Required

Table 14: Storage Areas © 2021-2025 Nokia Corporation

Table 15: SSP Input-Output Methods

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. h © 2021-2025 Nokia Corporation

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

Table 18: SSP Table 2 © 2021-2025 Nokia Corporation

• 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.

Table 20: Conditional Self-Tests 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 © 2021-2025 Nokia Corporation

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. 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. © 2021-2025 Nokia Corporation

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. 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-140Crev2 and/or NIST SP800-131Arev2 are disabled as applicable in the FIPS 140-3 validated firmware.

No specific Administrator guidance.

No specific Non-Administrator guidance.

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