Ruckus FastIron ICX ™ 7550/7650/7850 Series Switch/Router

Certificate

Approved Algorithms (30)

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

flowchart LR
  %% Deterministic review-risk graph for Ruckus FastIron ICX ™ 7550/7650/7850 Series Switch/Router
  %% 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>Update<br/>Firmware Load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output</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>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 Ruckus FastIron ICX ™ 7550/7650/7850 Series Switch/Router
  %% 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>Update<br/>Firmware Load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output</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>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

Ruckus FastIron ICX™ 7550/7650/7850 Series Switch/Router Firmware Version: IronWare OS 09.0.10 Document Version: 1.5 Last Update Date: 10-07-2024 Prepared by: Ruckus Wireless LLC Salarpuria Supreme, #137, Marathahalli Bangalore, Karnataka 560037 India www.commscope.com

This is a non-proprietary cryptographic module security policy for Ruckus FastIron ICX™ 7550/7650/7850 Series Switch/Router (hereinafter referred to as the module). The firmware version running on each module is IronWare OS 09.0.10. This security policy describes how the module meets the FIPS 140-3 Level 1 security requirements, and how to operate the module in a FIPS 140-3 mode. This security policy may be freely distributed. FIPS 140-3 (Federal Information Processing Standards Publication 140-3 — Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the NIST website at https://csrc.nist.gov/projects/cryptographic-module-validation-program. Table 1 below indicates the actual security levels for each area of the module. Table 1 - Security Levels The module is designed to meet an overall security level 1.

2. Cryptographic Module Specification Cryptographic Boundary The module is a hardware, multi-chip standalone cryptographic module. The cryptographic boundary is defined as the module’s chassis unit encompassing the "top," "front," "left," "right," “rear” and "bottom" surfaces of the case representing the module’s physical perimeter. This section illustrates the module hardware with the help of photographs. Ruckus ICX-7550 Series Figure 1 - ICX7550 Series Figure 2 - ICX 7550 – 24F Figure 3 - ICX 7550 - 24

Figure 4 - ICX 7550-24P Figure 5 - ICX 7550-24ZP Figure 6 - ICX 7550-48 Figure 7 - ICX 7550-48F Figure 8 - ICX 7550-48P

Figure 9 - ICX 7550-48ZP Figure 10 - ICX 7550-Rear View Please note that Ruckus ICX 7550 Series switches offer up to 2 redundant power supplies (AC or DC), one RJ-45 Ethernet port for out of band network management, one USB Type-C port for console management, and one RJ-45 port for serial console management. Ruckus ICX-7650 Series Figure 11 - ICX7650 Series Figure 12 - ICX 7650-48ZP Figure 13 - ICX 7650-48P Figure 14 - ICX7650-48F

Figure 15 - ICX7650 Rear View Please note that Ruckus ICX 7650 Series switches offer dual power supply slots, one RJ-45 Ethernet port for out-of-band network management, one USB Type-C port for console management, and one RJ-45 port for serial console management. Ruckus ICX-7850 Series Figure 16 - ICX7850 Series Figure 17

• ICX7850-32Q Figure 18 - ICX 7850-48FS Figure 19
• ICX7850- 48F

Figure 20 - ICX7850-48C Please note that Ruckus ICX 7850 Series switches offer dual power supply slots, one RJ-45 Ethernet port for out-of-band network management, one USB Type-C port for console management, flexibility, and scalability required for enterprise access deployment. Table 2 below lists the model and firmware version included in this validation.

Table 2 – Tested Operational Environments Modes of Operation By default, the module is delivered with a non-Approved mode of operation but supports an Approved mode of operation. Once the module is configured to operate in the Approved mode of operation by 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 a degraded mode of operation. Tables 3 and 4 below list all Approved or Vendor-affirmed 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 Security Functions The module implements the following approved cryptographic algorithms that have been ACVP certified.

Table 3 - Approved Algorithms (Crypto Library I)

Table 4 - Approved Algorithms (Crypto Library II)

• 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 Tables 3 and 4.
• The module’s AES-GCM implementation conforms to IG C.H scenario #1 following RFC

5288 for TLS. The module is compatible with TLSv1.2 and provides support for the

acceptable GCM cipher suites from SP 800-52 Rev1, Section 3.3.1. The operations of one of the two parties involved in the TLS key establishment scheme 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. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established.

• The module takes on the role of Authenticator (not by aid of RADIUS Authentication Server) reference to the MACsec protocol. The AES GCM IV construction is performed in compliance with IEEE 802.1AE and its amendments. The IV length used is 96 bits (per SP 800-38D and FIPS 140-3 IG C.H). If the module loses power, then new AES GCM keys should be established. The module should only be used with FIPS 140-3 validated modules when supporting the MACsec protocol for providing Peer, Authenticator functionality. The Peer and the Authenticator Modules Security Policies shall state that the link between the Peer and the Authenticator is protected by AES-KW/KWP (ACVP Cert. #A2345) to prevent the possibility for an attacker to introduce foreign equipment into the local area network.
• No parts of the SSH, TLS and SNMP protocols, other than the KDFs, have been tested by the CAVP and CMVP. As the module can only be operated in the Approved mode of operation, and any algorithms not listed in Tables 3-4 above will be rejected by the module while in the approved mode, the tables defined in SP800-140B for the following categories are missing from this document.
• Non-Approved Algorithms Allowed in Approved Mode of Operation
• Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed
• Non-Approved Algorithms Not Allowed in Approved Mode of Operation

3. Cryptographic Module Interfaces interfaces provided by the module are mapped to the following FIPS 140-3 defined logical logical interfaces and their mapping are described in the Tables 5-7 below. Please note that the Table 5 - Ports and Interfaces for ICX 7550 Table 6 – Ports and Interfaces for ICX7650

Table 7– Ports and Interfaces for ICX7850

4. Roles, Services, and Authentication The module supports role-based authentication. In approved mode, the cryptographic module supports the following roles:
5. Crypto Officer Role: The Crypto Officer role has complete access to the system. The Crypto Officer is the only role that can perform firmware loading, security management. A crypto officer can create additional accounts thereby creating additional crypto officers.
6. Port Config Admin Role: The Port Config Admin role has read and write access for configuring specific ports but not for global (system‐wide) parameters.
7. User Role: The User role on the device has read-only privileges and no configuration mode access. The module does not support the maintenance role. The services for someone without an authorized role are to view the status output from the For all other services, an operator must authenticate to the module as described in Table below. The following subsections describe services available to operators based on role.

Table 12 - Approved Services 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

5. Software/Firmware Security Integrity Techniques The module performs the Firmware Integrity tests by using CRC-32 during the Pre-Operational Self-Test. At Module’s initialization, the integrity of the runtime executable binary file is verified using the following two integrity check mechanisms to ensure that the module has not been tampered:

• Bootloader Integrity Test (CRC-32)
• Firmware Integrity Test (CRC-32) If at the load time the CRC-32 value does not match the stored, known CRC-32 value, the module would enter to an Error state with all crypto functionality inhibited. In addition, the module also supports the firmware load test by using RSA 2048 bits with SHA2-

256 (RSA Cert. #A2345) 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 binary the factory and used for firmware load test. In order to load new firmware, the Crypto Officer must authenticate into the module before loading any 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. Integrity Test On-Demand 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. This automatically performs the integrity test of all firmware components included within the boundary of the module.

6. Operational Environment The module is a hardware module. The module’s operational environment is limited as the modules include a firmware load service to support necessary updates. New firmware versions within the scope of this validation must be validated through the FIPS 140-3 CMVP. Any other firmware loaded into these modules is out of the scope of this validation and requires a separate FIPS 140-3 validation. The module’s firmware version running on each model is IronWare OS 09.0.10.
7. Physical Security The module is a multi-chip standalone hardware cryptographic module. The module meets the FIPS 140-3 Level 1 security requirements as production grade equipment.
8. Non-Invasive Security No approved non-invasive attack mitigation test metrics are defined at this time.

9. Sensitive Security Parameter Management

Table 13 - SSPs Notes:

1. The module uses procedural zeroization to explicitly zeroize all SSPs listed in Table 13.
2. The zeroization operations shall be performed under the control of the CO role by using the CLI command “fips zeroize all”.
3. To initiate zeroization, see Section End of Life / Sanitization in this document for more
4. The zeroized SSPs cannot be retrieved or reused. Once the command is initiated, the SSPs are overwritten with 0s. Table 14 – Non-Deterministic Random Number Generation Specification
5. Self-Tests The modules perform the following self-tests, including the pre-operational self-tests and conditional self-tests. The module runs all self-tests without operator intervention. In the event that

a self-test fails, the module will enter an error state, output an error message and follow up with a module reboot. The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling). Pre-Operational Self-Tests:

• Pre-Operational Firmware Integrity Test
• BootLoader Integrity Test (CRC-32)
• Firmware Integrity Test (CRC-32)
• No Pre-Operational Bypass Test
• No Pre-Operational Critical Functions Test Conditional Self-Tests
• Conditional Cryptographic Algorithm Tests:
• AES-CBC 128 bits encryption KAT
• AES-CBC 128 bits decryption KAT
• AES-GCM 128 bits authenticated encryption KAT
• AES-GCM 128 bits authenticated decryption KAT
• AES-CMAC 128 bits encryption KAT
• AES-CMAC 128 bits decryption KAT
• ECDSA P-256 with SHA2-256 SigGen KAT
• ECDSA P-256 with SHA2-256 SigVer KAT
• CTR_DRBG Instantiate KAT
• CTR_DRBG Generate KAT
• CTR_DRBG Reseed KAT Note: DRBG Health Tests as specified in SP800-90Arev1 Section 11.3 are performed.
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-384 KAT
• KAS-FFC-SSC Primitive KAT
• KAS-ECC-SSC Primitive KAT
• RSA 2048 bits modulus with SHA2-256 SigGen KAT
• RSA 2048 bits modulus with SHA2-256 SigVer KAT
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-384 KAT
• KBKDF KAT
• KDF SSH KAT
• KDF SNMP KDF KAT
• KDF TLS KAT
• SP800-90B Entropy Source start-up health tests:
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT)
• SP800-90B Entropy Source Continuous Health Tests:
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT)

In addition, the module also performs the Conditional Cryptographic Algorithm Self-tests to the following AES-GCM algorithm:

• AES-GCM 128 bits authenticated encryption KAT for AES Cert. #4550
• AES-GCM 128 bits authenticated decryption KAT for AES Cert. #4550
• Conditional Pair-Wise Consistency Tests:
• RSA PCT
• ECDSA PCT
• KAS (ECC) PCT
• KAS (FFC) PCT
• Firmware Load Test (RSA 2048 bits modulus with SHA2-256)
• No Conditional Manual Entry Test
• No Conditional Bypass Test
• No Conditional Critical Function Test Error Handling If any of the above-mentioned self-tests fail, the module reports the cause of the error and enters an 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 reperforming the selftests, including the pre-operational software 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. Table 15 below shows the different causes that lead to the Error State and the status indicators reported. Table 15
• Error State Indicators Periodic Self-Tests The module permits operators to initiate the pre-operational or conditional self-tests on demand for periodic testing of the module by rebooting the system (i.e., power-cycling). The full suite of selftests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. In addition, the Crypto Officer shall perform the periodic test on demand no more than 10 days to ensure all components are functioning correctly.

11. Life-Cycle Assurance The module is designed to handle the various stages of a module’s life-cycle. The sections below highlight the details for each stage. Secure Operation 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 will remove the module from the approved mode of operation. The module runs firmware version IronWare OS 09.0.10. This is the only allowable firmware image for this current approved mode of operation. The Crypto Officer shall load the CMVP FIPS 140-3 validated firmware only to maintain validation. The module is initiated into the approved mode of operation via the following procedures through the Command Line interface (CLI).
12. The Crypto Officer must login by using the default login password.
13. The Crypto Officer shall replace the default login password with a new one upon the firsttime authentication.
14. The Crypto Officer shall create the account for Port Config Admin role and User role respectively.
15. Enter into the configuration mode by using ‘conf t’ command.
16. Configure SSH, TLS, SNMPv3 and MACSec services by using only approved algorithms listed in Table 3 and 4 above.
17. Configure the module as the MACSec Peer Authenticator in the MACSec service.
18. If using RADIUS server for roles authentication, please configure a secure TLS tunnel to secure traffic between the module and the RADIUS server. The RADIUS shared secret must be at least 8 characters long
19. Disable the TFTP server.
20. Ensure that installed digital certificates are signed using approved algorithms.
21. Save the configuration.
22. Reload the module.
23. Verify the approved mode by using command ‘fips show’ (This command outputs the module’s status. After the approved mode was enabled, the output would be “approved mode: Administrative status ON”).
24. The Crypto Officer shall load the CMVP FIPS 140-3 validated firmware only to maintain validation. Once the module has completed initialization into the approved mode of operation, it would reject any non-approved algorithms or security functions automatically, and output an error message accordingly.

End of Life / Sanitization Crypto Officers should follow the procedure below for the secure destruction of their module.

1. Access the module via SSH with Crypto Officer
2. Authenticate using proper credentials
3. Execute command: “fips zeroize all” a. Confirm command
4. Module will begin zeroization process and wipe all security parameters and configurations Please note that this process will cause the module to no longer function after it has wiped all
5. Mitigation of Other Attacks This module is not designed to mitigate against any other attacks outside of the FIPS 140-3 scope. I. Terms and Definitions