Ruckus FastIron ICXTM 7550/7650/7850 Series Switch/Router

Certificate

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

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

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 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 7550-24 Figure 2: ICX 7550-24F Figure 3: ICX 7550-24P

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

Figure 8: ICX 7550-48ZP Figure 9: ICX 7650-48ZP Figure 10: ICX 7650-48P

Figure 11: ICX 7650-48F Figure 12: ICX 7850-32Q Figure 13: ICX 7850-48FS Figure 14: ICX 7850-48F Figure 15: ICX 7850-48C

Tested Module Identification

• Hardware: 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 16: ICX-7550 Series Note: The USB Port for external file storage is functionally disabled

Figure 17: ICX-7650 Series Note: The USB Port for external file storage is functionally disabled Figure 18: ICX-7850 Series

Note: The USB Port for external file storage is functionally disabled Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Tested Module Identification
• Hybrid Disjoint Hardware: Tested Operational Environments - Software, Firmware, Hybrid: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid:

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

Approved Algorithms: Crypto Library I

Table 4: Approved Algorithms - Crypto Library I Crypto Library II Table 5: Approved Algorithms - Crypto Library II Vendor-Affirmed Algorithms: Table 6: 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 7: Security Function Implementations

• 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.
• 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 AESKW/KWP (ACVP Cert. #A5076) to prevent the possibility for an attacker to introduce foreign equipment into the local area network.
• 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 8: Entropy Certificates Table 9: Entropy Sources Ruckus FastIron™ IronWare 10.0.10 Entropy Source v1.0 is the entropy source used on each Ruckus FastIron ICX™ 7550, 7650, and 7850 Series Router with firmware IronWare OS 10.0.10 to seed the approved DRBG. The noise source of entropy is periodic sampling of the high-

precision 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 152 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, SNMPv3 and MACSec 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.

The module’s physical perimeter encompasses the case of the tested platform mentioned in

and the User role. The module also allows the concurrent operators.

Name

Descriptio n

Indicator

Inputs

Outputs

Security Function s

SSP Access Private Key: Z - SSH DH Public Key: Z - SSH Peer DH Public Key: Z - SSH DH Shared Secret: Z - SSH ECDH Private Key: Z - SSH ECDH Public Key: Z - SSH Peer ECDH Public Key: Z - SSH ECDH Shared Secret: Z - SSH ECDSA Private Key: Z - SSH ECDSA Public Key: Z - SSH RSA Private Key: Z - SSH RSA Public Key: Z - SSH Session Encryption Key: Z - SSH Session Authenticatio n Key: Z - TLS DH Private Key: Z

Name

Descriptio n

Indicator

Inputs

Outputs

Security Function s

SSP Access - TLS DH Public Key: Z - TLS Peer DH Public Key: Z - TLS DH Shared Secret: Z - TLS ECDH Private Key: Z - TLS ECDH Public Key: Z - TLS Peer ECDH Public Key: Z - TLS ECDH Shared Secret: Z - TLS ECDSA Private Key: Z - TLS ECDSA Public Key: Z - TLS RSA Private Key: Z - TLS RSA Public Key: Z - TLS Master Secret: Z - TLS Session Encryption Key: Z - SNMPv3 Authenticatio n Secret: Z - SNMPv3 Encryption Key: Z - SNMPv3

Name

Descriptio n

Indicator

Inputs

Outputs

Security Function s

SSP Access - SSH RSA Private Key: E - SSH RSA Public Key: R,E - SSH ECDSA Private Key: E - SSH ECDSA Public Key: R,E - SSH Session Encryption Key: G,W,E,Z - SSH Session Authenticatio n Key: G,W,E,Z - DRBG Entropy Input: G,W,E - DRBG Seed: G,W,E - DRBG Internal State V value: G,W,E - DRBG Key: G,W,E - RADIUS Secret: W,E Port Config Admin - SSH DH Private Key: R,E - SSH DH Public Key: R,E - SSH Peer DH Public

Name

Descriptio n

Indicator

Inputs

Outputs

Security Function s

SSP Access Key: R,E - SSH DH Shared Secret: R,E - SSH ECDH Private Key: R,E - SSH ECDH Public Key: R,E - SSH Peer ECDH Public Key: R,E - SSH ECDH Shared Secret: R,E - SSH RSA Private Key: R,E - SSH RSA Public Key: R,E - SSH ECDSA Private Key: R,E - SSH ECDSA Public Key: R,E - SSH Session Encryption Key: R,E - SSH Session Authenticatio n Key: R,E - DRBG Entropy Input: R,E - DRBG Seed: R,E - DRBG Internal State V value: R,E - DRBG Key:

Name

Descriptio n

Indicator

Inputs

Outputs

Security Function s

SSP Access R,E - RADIUS Secret: W,E User - SSH DH Private Key: R,E - SSH DH Public Key: R,E - SSH Peer DH Public Key: R,E - SSH DH Shared Secret: R,E - SSH ECDH Private Key: R,E - SSH ECDH Public Key: R,E - SSH Peer ECDH Public Key: R,E - SSH ECDH Shared Secret: R,E - SSH RSA Private Key: R,E - SSH RSA Public Key: R,E - SSH ECDSA Private Key: R,E - SSH ECDSA Public Key: R,E - SSH Session Encryption Key: R,E - SSH Session

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 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 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 (SPR10010dufi.bin) 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 components.

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

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

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

Table 19: 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).

Table 20: Conditional Self-Tests

Table 21: Pre-Operational Periodic Information

Table 22: Conditional Periodic Information

Table 23: 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. 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.
3. Enter into the configuration mode by using ‘conf t’ command.
4. Enable approved mode by using ‘fips enable’ command.
5. Create accounts for Port Config Admin role and User role respectively.
6. Configure SSH, TLS, SNMPv3 and MACSec services by using only approved algorithms listed above.
7. Configure the module as the MACSec Peer Authenticator in the MACSec service.
8. 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.
9. Disable the TFTP server.
10. Ensure that installed digital certificates are signed using approved algorithms.
11. Save the configuration.
12. Reload the module.
13. 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”).
14. 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: Note: 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