Ruckus FastIron ICX™ 7150/7250 Series Switch/Router

Certificate

Approved Algorithms (25)

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

flowchart LR
  %% Deterministic review-risk graph for Ruckus FastIron ICX™ 7150/7250 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>Status Output<br/>Self-test</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™ 7150/7250 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>Status Output<br/>Self-test</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™ 7150/7250 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™ 7150/7250 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 an approved 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. The table 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. 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-7150 Series Figure 1 ICX7150-24

Figure 2 ICX7150-24F Figure 3 ICX7150-24P Figure 4 ICX7150-48 Figure 5 ICX7150-48P Figure 6 ICX7150-48PF Figure 7 ICX7150-48ZP

Figure 8 ICX7150-C10ZP Figure 9 ICX7150-C12P Figure 10 ICX7150-C08P Figure 11 ICX7150-C08PT Please note that each Ruckus ICX 7150 model also offers a single integrated power supply, one RJ-

45 Ethernet port for out-of-band network management, one USB Type-C port for console

management, one RJ-45 port for serial console management. Ruckus ICX-7250 Series Figure 12 ICX7250-24

Figure 13 ICX7250-24P Figure 14 ICX7250-48 Figure 15 ICX7250-48P Please note that each Ruckus ICX 7250 model also offers a single integrated power supply, one RJ-

45 Ethernet port for out-of-band network management, one USB Type-C port for console

Table 2 below lists the models and firmware version included in this validation. Please note that “RMT3” is referred to “with Three Years Remote Support”, and “-A” is referred to Trade Agreements Act (TAA) Compliant.

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. Table 3 below lists 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. Approved Security Functions The module implements the following approved cryptographic algorithms that have been CAVP certificated.

Table 3 - Approved Algorithms

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

● 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 the table 3 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 Tables 4 and
4. Please note that the module Table 4 – Ports and Interfaces for ICX7150 Series

Table 5 – Ports and Interfaces for ICX7250 Series

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 For all other services, an operator must authenticate to the module as described in Tables 6-8 below. management and configuration of cryptographic functions. The following subsections describe services available to operators based on role.

Table 10 - 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 FIPS 140-3 validated through the 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 11 - SSPs Notes:

1. The module uses procedural zeroization to explicitly zeroize all SSPs listed in Table 11.
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 12 – 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 Tests ▪ 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
• 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
• ECDSA P-256 with SHA2-256 SigGen KAT
• ECDSA P-256 with SHA2-256 SigVer KAT
• 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
• KDF SSH KAT
• KDF SNMP 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)
• Conditional Pair-Wise Consistency Tests
• RSA PCT
• ECDSA PCT
• KAS (ECC) PCT
• KAS (FFC) PCT
• Conditional Firmware Load Test
• 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. The table below shows the different causes that lead to the Error State and the status indicators reported. Table 13 – 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 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.

2. The Crypto Officer shall replace the default login password with a new one upon the firsttime authentication.
3. The Crypto Officer shall create the account for Port Config Admin role and User role respectively.
4. Enter into the configuration mode by using ‘conf t’ command.
5. Configure SSH, TLS, and SNMPv3 services by using only approved algorithms listed in Table 3 and 4 above.
6. 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
7. Disable the TFTP server.
8. Ensure that installed digital certificates are signed using approved algorithms.
9. Save the configuration.
10. Reload the module.
11. 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”).
12. The Crypto Officer shall load the 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.
13. Access the module via SSH with Crypto Officer
14. Authenticate using proper credentials
15. Execute command: “fips zeroize all” a. Confirm command
16. 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 configurations and keys.
17. Mitigation of Other Attacks This module is not designed to mitigate against any other attacks outside of the FIPS 140-3 scope.