Ruckus FastIron ICXTM 7150/8200 Series Switch/Router

Certificate

Approved Algorithms (25)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Ruckus FastIron ICXTM 7150/8200 Series Switch/Router
  %% 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/>Perform Zeroization</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Block ciphers (SSHv2)<br/>Block ciphers (TLSv1.2)<br/>Block ciphers (SNMPv3)</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["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 Ruckus FastIron ICXTM 7150/8200 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["[high] Firmware update / recovery / rollback services<br/><i>Firmware Load Test<br/>Perform Zeroization</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Block ciphers (SSHv2)<br/>Block ciphers (TLSv1.2)<br/>Block ciphers (SNMPv3)</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/>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 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Ruckus Wireless LLC Ruckus FastIron ICXTM 7150/8200 Series Switch/Router

This is a non-proprietary cryptographic module security policy for Ruckus FastIron ICX™ 7150/8200 Series Switch/Router (hereinafter referred to as the module). The firmware version running on each module is IronWare OS 10.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-modulevalidation-program.

Purpose and Use: The module delivers the performance, flexibility, and scalability required for enterprise access deployment. Module Type: Hardware Module Embodiment: MultiChipStand

Module Characteristics: Cryptographic Boundary: The Tested Operational Environment Physical Perimeter (TOEPP) is defined as the entire chassis unit’s physical perimeter encompassing the "top," "front," "left," "right," “rear” and "bottom" surfaces of the case as shown in the figures below and in the Physical Security section. The cryptographic boundary encompasses the entire TOEPP. This section illustrates the module hardware with the help of photographs. Figure 1: ICX 7150-24 Figure 2: ICX 7150-24P Figure 3: ICX 7150-48

Figure 4: ICX 7150-48P Figure 5: ICX 7150-48PF Figure 6: ICX 7150-48ZP Figure 7: ICX 7150-C12P

Figure 8: ICX 8200-24/ICX 8200-24P/ICX 8200-24F Figure 9: ICX 8200-24FX Figure 10: ICX 8200-24ZP Figure 11: ICX 8200-48/ICX 8200-48P Figure 12: ICX 8200-48F

Figure 13: ICX 8200-48PF/ICX 8200-48PF2 Figure 14: ICX 8200-48ZP2 Figure 15: ICX 8200-C08PF Figure 16: ICX 8200-C08ZP

Tested Module Identification

• Hardware:

ICX820048PF2 ICX820048ZP2 ICX8200C08PF ICX8200C08ZP ICX820048PF2 ICX820048ZP2 ICX8200C08PF ICX8200C08ZP Table 2: Tested Module Identification

• Hardware The module is a hardware module. The module’s operational environment is limited. The module’s firmware version running on each model is IronWare OS 10.0.10. The distinguishing features of each Hardware Model are detailed below:

Figure 17: ICX 7150 Series Note: The USB Port for external file storage is functionally disabled Figure 18: ICX 7150 Z-Series Note: The USB Port for external file storage is functionally disabled Figure 19: ICX 7150 Compact Series Note: The USB Port for external file storage is functionally disabled

Figure 20: ICX 8200 Series with fixed power supply and fans Note: The USB Port for external file storage is functionally disabled Figure 21: ICX 8200 Series with hot-swap power supply and fans Note: The USB Port for external file storage is functionally disabled

Figure 22: ICX 8200 Compact Series Note: The USB Port for external file storage is functionally disabled Figure 23: ICX 8200 Fiber Series Note: The USB Port for external file storage is functionally disabled 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: N/A for this module.

Modes List and Description: Table 3: Modes List and Description By default, the module is delivered in an un-initialized state but supports an approved mode of following the steps in section " Life-Cycle Assurance" of this document by the Crypto Officer, the module can only operate in the approved mode. The module does not claim implementation of a

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: N/A Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: Non-Approved, Allowed Algorithms with No Security Claimed: Non-Approved, Not Allowed Algorithms:

Groups: MODP2048, MODP4096, MODP8192

Table 6: Security Function Implementations 2.7 Algorithm Specific Information Notes:

• The Module’s AES-GCM implementation conforms to Implementation Guidance 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 keys for the client and server negotiated in the TLSv1.2 handshake process (client_write_key and server_write_key) are compared and the Module aborts the session if the key values are identical. 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.

• In accordance with FIPS 140-3 IG D.H, the cryptographic Module performs Cryptographic Key Generation as per section 5 in SP800-133 Rev2. The resulting generated seed used in the asymmetric key generation is the unmodified output from SP800-90A Rev1 DRBG.

Table 7: Entropy Certificates NonPhysical N/A Table 8: Entropy Sources Ruckus FastIron™ IronWare 10.0.10 Entropy Source v1.0 is the entropy source used on each Ruckus FastIron ICX™ 7150 and 8200 Series Router with firmware IronWare OS 10.0.10 to seed the approved DRBG. The noise source of entropy is periodic sampling of the highprecision CPU clock within the ARM CPU. There is no conditioning component applied on the output of the clock source. Health testing is implemented on the output of the noise source. The entropy source provides a minimum entropy of 4 bits per sample with the sample size of 8 bits. The module makes repeated calls to the entropy source after which the random data is loaded into a buffer. This buffer is used by the DRBG to get entropy input. Buffer size is big enough that the overall effective entropy is more than that is required for the DRBG instantiation. Similar implementation is done for DRBG reseeding.

The module generates RSA, ECDSA, EC Diffie-Hellman, and Diffie-Hellman asymmetric key pairs compliant with FIPS 186-5, using a NIST SP 800-90Ar1 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.1 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.
• KAS-ECC 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-ECC shared secret computation. The shared secret computation provides between 128 and 256 bits of encryption strength.

The module supports SSHv2, TLS v1.2, and SNMPv3 industrial protocols. No parts of the SSH, TLS and SNMP protocols, other than the KDFs, have been tested by the CAVP and CMVP. Please refer to SSPs Table for more information.

Table 9: Ports and Interfaces 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.

Table 10: Authentication Methods and the User role. The module also allows the concurrent operators.

Table 11: Roles Unauthenticated Users can run the self-test service by power-cycling the module by removing the power and re-applying.

n s l W,E G,W,E,Z G,W,E,Z W,E G,W,E,Z G,W,E,Z Table 12: Approved Services Unauthenticated Services Unauthenticated Users can run the self-test service by power-cycling the module by removing the power and re-applying.

The module also supports the firmware load test by using RSA 2048 bits with SHA2-256 (RSA Cert. #A5076) 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

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 detailed in the “External Software/Firmware Loaded” section above.

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.

Type of Operational Environment: Limited

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.

No approved non-invasive attack mitigation test metrics are defined at this time.

) m Table 14: SSP Input-Output Methods

Table 15: 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 n s s

n s s MODP2048, MODP4096, MODP2048, MODP4096, KASECC KASECC KASECC KASFFC

MODPderive SSH MODPSecret MODPderive SSH MODPEncryption MODPSession n n Curve PSSH 256/Psessions n KASFFC KASFFC

KASECC ) KASECC ) KASECC ) KASFFC ) KASFFC ) KASFFC )

SHA-1 The module includes an implementation of SHA-1 for hashing and message authentication. This implementation will be non-Approved for all uses starting January 1, 2031. User should move to SHA2, which is available in this module.

N/A N/A Table 18: Pre-Operational Self-Tests The modules perform the self-tests, including the pre-operational self-tests and conditional selftests. 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).

d SHA2256 SHA2384 SHA2512 MODP2048 Curve P256 Curve P256 HMACSHA-1 HMACSHA2-256 HMACSHA2-384 HMACSHA2-512 N/A N/A

d s Table 19: Conditional Self-Tests

Table 20: Pre-Operational Periodic Information

N/A N/A N/A N/A Table 21: Conditional Periodic Information

Table 22: Error States 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 self-tests, 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.

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 put the module operate in a non-compliant state. The module runs firmware version IronWare OS 10.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. Any firmware/software 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 is initiated into the approved mode of operation via the following procedures through the Command Line interface (CLI): 1. 2. 3. 4. 5. The Crypto Officer must login by using the default login password. The Crypto Officer shall replace the default login password with a new one. Enter into the configuration mode by using ‘conf t’ command. Enable approved mode by using ‘fips enable’ command. Create accounts for Port Config Admin role and User role respectively.

6. Configure SSH, TLS, and SNMPv3 services by using only approved algorithms listed above.
7. 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.
8. Disable the TFTP server.
9. Ensure that installed digital certificates are signed using approved algorithms.
10. Save the configuration.
11. Reload the module.
12. 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”).
13. 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, the module automatically enforces a password change for the Crypto Officer. Any non-approved algorithms or security functions are rejected automatically by the module and an error message is output.

No specific Administrator guidance.

No specific Non-Administrator guidance.

Crypto Officers should follow the procedure below for the secure destruction of their module. Please note that this process will cause the module to no longer function after it has wiped all configurations and keys.

1. Access the module via SSH with Crypto Officer
2. Authenticate using proper credentials
3. Execute command: “fips zeroize all” a. Confirm command Module will begin zeroization process and wipe all security parameters and configurations.

Referenced URLs

• https://csrc.nist.gov/projects/cryptographic-module-