Brocade Fabric OS FIPS Cryptographic Module

Certificate

Approved Algorithms (34)

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

flowchart LR
  %% Deterministic review-risk graph for Brocade Fabric OS FIPS Cryptographic Module
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>No authentication<br/>Show status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<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 Brocade Fabric OS FIPS Cryptographic Module
  %% 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</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>No authentication<br/>Show status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<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

Brocade Fabric OS FIPS Cryptographic Module Firmware Version 9.1.1 Document Revision 1.3 Last Update: October 21, 2024 Brocade Communications Systems LLC

San Jose, CA 95131 USA Brocade Communications Systems LLC grants permission to freely reproduce in entirety without revision

This non-proprietary FIPS 140-3 security policy for the Brocade Fabric OS FIPS Cryptographic Module with firmware version 9.1.1 (hereinafter referred to the module) details the secure operation of the Brocade Communications Systems LLC Brocade Fabric OS FIPS Cryptographic Module as required in Federal Information Processing Standards Publication 140-3 (FIPS 140-3) as published by the National Institute of Standards and Technology (NIST) of the United State Department of Commerce. This document, the Cryptographic Module Security Policy, also referred to as the Security Policy, specifies the security rules under which the module must operate. The Brocade Fabric OS FIPS Cryptographic Module underpins Brocade’s Fabric Operating System equipment and is used as a shared library object by applications in Brocade’s Fabric Operating System, for its various cryptographic requirements. The calling applications leverage the module’s well-defined APIs to initialize the module and call cryptographic algorithms for encryption/decryption, key generation, signature generation/verification, and hashing. The Brocade Fabric OS is the firmware foundation for Brocade’s purpose-built network infrastructure for mission-critical storage. The Brocade Fabric OS family of supported products includes Fiber Channel directors, switches, embedded switches and network extension switches. In addition to supporting the switching functionality of these product lines, Fabric OS supports Fabric Vision Technology features for network monitoring, management, and diagnostics, as well as advanced features that help ensure the highest level of reliability, availability, and serviceability. Table 1 - Security levels The module is designed to meet an overall security level of 1.

2. Cryptographic module specification The module is a single binary object file (libfipscrypto.so) running on the tested platform defined in Table 2, and is classified as a multi-chip standalone firmware module. Table 2 - Tested operational environments The following platforms have not been tested as part of the FIPS 140-3 Level 1 certification however Brocade affirms that these platforms are compliance to the tested and validated platforms. Additionally, Brocade also affirms that the Module will function the same way and provide the same security services on any of the operating systems listed below. Table 3 - Vendor affirmed operational environments Please note that the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Modes of operation The module supports both approved and non-approved mode of operation. The module will be in approved mode when all pre-operational self-tests have completed successfully and only approved algorithms/services are invoked. See Table 4 and Table 8 below for a list of the supported approved/allowed algorithms/services. The non-approved mode is entered when a non-approved algorithm/non-approved service is invoked. See Table 5 and Table 9 below for a list of non-approved algorithms/non-approved services. The Approved mode of operation can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table
3. Table 4 below lists all Approved or Vendor-affirmed security functions of the module, including specific key size(s) -in bits otherwise noted- employed for approved services, and implemented modes of operation.

Table 4 - Approved algorithms Notes: • 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. Table 5 - Non-approved algorithms not allowed in approved mode The module does not implement non-approved algorithms allowed in approved mode of operation and non-approved algorithms allowed in approved mode of operation with No security claimed. vetted conditioning component in ENT (NP).

Cryptographic boundary Figure 1 below depicts the cryptographic boundary (red dashed line) and physical perimeter (solid red line). The cryptographic boundary is defined as the cryptographic library. The physical perimeter is the Tested Operational Environment’s Physical Perimeter (TOEPP) on which the module runs. Figure 1 - Cryptographic boundary

3. Cryptographic module interfaces The module’s physical perimeter encompasses the peripheral’s devices (USB devices, network devices [Ethernet and Wireless adapters], and power adapter) on the tested platform running Brocade’s Fabric Operating System. However, the module provides only a logical interface via Application Programming Interface (API) calls and does not interface or communicate with or across any of the physical ports of the GPC. This logical interface exposes service that calling applications may use directly. The logical interfaces (APIs) provided by the module are mapped onto the FIPS 140-3 defined logical interfaces (data input, data output, control input, control output and status output). It is through this logical API that the module logically separates them into distinct and separate interfaces. Please note FIPS 140-3 interfaces is as follows. Table 6 - Cryptographic module interfaces

4. Roles, services, and authentication The module supports both Crypto Officer (CO) role and User role. No authentication is required at security level 1 and the assumption of the role is implicit by the service being performed. The module Table 7 - Roles, service commands, input and output Table 8 below defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as: 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 = Zeroize: The module zeroizes the SSP.

Table 9 - Non-approved services

5. Software/Firmware security Integrity techniques The cryptographic module is a binary file (libfipscrypto.so) dynamically linked within the application in FOS (Fabric Operating System). To ensure firmware security, the module is protected by an HMAC-SHA-1 (HMAC Cert. #A2604) algorithm. The firmware integrity test key was preloaded to the module’s binary at the factory and used only for the pre-operational firmware integrity self-test. During initialization of the module, the integrity of the runtime executable is verified using an HMAC-SHA-1 which is compared to a value computed at build time. If at load time the MAC does not match the stored, known MAC value, the module enters a critical error state where all crypto functionality inhibited. The module must be reloaded to attempt the integrity test again. Integrity test on-demand The 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 tested platform to initiate the integrity test ondemand.

6. Operational environment The module will operate in a non-modifiable operational environment per the definition in FIPS 140-3 level 1 specifications. The module runs on the operating system executing on the tested platforms listed in Table
7. The operational environment shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded). The application that requests cryptographic services is the single user of the module. All cryptographic keys and CSPs are under the control of the OS, which protects its SSPs against unauthorized disclosure, modification, and substitution. Additionally, the OS provides dedicated process space to each executing process, and the module operates entirely within the process space.

7. Physical security The module is running on the multi-chip standalone production grade platform to meet physical security requirements from FIPS 140-3 level
8. The module’s Tested Operational Environment’s Physical Perimeter (TEOPP) is drawn at the casing of the tested platforms in Table
9. The module’s tested platforms consist of production-grade components. All ICs are coated with industry standard passivation.

8. Non-invasive security The module does not claim to implement non-invasive security beyond the FIPS 140-3 Level 1 requirements for validation.

9. Sensitive security parameter management The module possesses firmware integrity test HMAC key (non-SSP). Beyond that key, the module does not store any other keys persistently, and it is the calling applications responsibility to appropriately manage keys.

Table 10 - Sensitive security parameters

Note: All SSPs will be zeroized by all “0”s and cannot be retrievable or reusable after zeroization operation. RBG entropy source Table 11 - Non-deterministic random number generation specification

10. Self-tests The module automatically performs both Pre-Operational Self-Tests and Cryptographic Algorithm SelfTests (CASTs) after the power is on. Prior to providing any data output via the data output interface, the module would perform and pass the pre-operational self-tests. Following the successful pre-operational self-tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs). The remaining self-tests for all approved algorithms are performed right before first instance of use of the respective algorithm. In the event a self-test fails, the module enters the critical error state and an error message is logged. In this state, cryptographic operations are halted and the module inhibits all data output from the module as the API interface is disabled. In order to attempt to exit the error state, the module must be rebooted. If the error persists, the module must be reinitialized. Pre-operational self-tests:

• HMAC-SHA-1 KAT
• Firmware integrity test by using HMAC-SHA-1 Conditional self-tests Cryptographic algorithm self-tests (CASTs):
• AES-ECB Encryption KAT (128 bits)
• AES-ECB Decryption KAT (128 bits)
• AES-CBC Encryption KAT (128 bits)
• AES-CBC Decryption KAT (128 bits)
• AES-CCM Encryption KAT (128 bits)
• AES-CCM Decryption KAT (128 bits)
• DRBG Instantiate KAT
• DRBG Generate KAT
• DRBG Reseed KAT Note: DRBG Health Tests as specified in SP800-90A Section 11.3 are performed
• ECDSA SigGen KAT (Curve P-256 with SHA2-256)
• ECDSA SigVer KAT (Curve P-256 with SHA2-256)
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-512 KAT
• HMAC-SHA3-256 KAT
• HMAC-SHA3-512 KAT
• KAS-ECC-SSC primitive Z value KAT
• KAS-FFC-SSC primitive Z value KAT
• RSA SigGen KAT (Modulus: 2048 with SHA2-256)
• RSA SigVer KAT (Modulus: 2048 with SHA2-256)
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-512 KAT

• SHA3-256 KAT
• SHA3-512 KAT In addition, below is a list of module’s entropy source health tests.
• ENT (NP) SP800-90B Start-Up Health Tests.
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT) Note: Please refer to SP800-90B, sections 4.4.1 and 4.4.2 for more information about the RCT and APT.
• ENT (NP) SP800-90B Continuous Health Tests:
• Repetition Count Test (RCT)
• Adaptive Proportion Test (APT) Conditional pair-wise consistency tests (PCT)
• RSA PCT
• ECDSA PCT
• KAS-ECC-SSC PCT
• KAS-FFC-SSC PCT An operator has no access to cryptographic functionality unless the library initialization succeeds and the cryptographic module self-tests pass. The module performs the firmware integrity check of the module’s firmware using verification of an HMAC-SHA-1 signature calculated over the module’s file image. Please note that the module performs the CASTs prior to Firmware Integrity Test. Should the module fail a self-test, the module will return an error and inhibit all cryptographic operations. Finally, an operator may invoke all CASTs at any time by power-cycling the GPC and then reloading the module or invoke self-test(s) on demand. Periodic self-test The module performs on-demand self-tests initiated by the operator, by power cycling or rebooting the tested platform. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. It is recommended that the User perform periodic testing of the module’s on-demand self-tests every 60 days to ensure all components are functioning correctly. Error handling If any of the above-mentioned self-tests fail, the module reports the cause of the error and enters an error state (there is only one 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 self-tests, 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. Table 12 below shows the different causes that lead to the Error State and the status indicators reported.

11. Life-cycle assurance The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-3 Level 1 module. General guidance The module meets all the Level 1 requirements for FIPS 140-3. The module functions entirely within the process space of the process that invokes it, and thus satisfies the FIPS 140-3 requirement for a single user mode of operation. During system start-up the OS will call the fipscrypto_init_func() function. The fipscrypto_init_func() function is the default entry point for the module. The function initiates all self-tests and does not return to the OS until all self-tests are completed successfully and the module is in an approved mode of operation. No other tasks are executed while the self-tests are performed so no data is passed and all cryptographic operations are prohibited. If a self-test fails, the module enters a critical error state and must be reloaded to clear the error state and retry the self-tests. End of life In addition, the module is not distributed as a standalone library and is only used in conjunction with the solution. The end user of the operating system is also responsible for SSPs zeroization based on the methods listed in Table 12.

12. Mitigation of other attacks The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for validation.