Cisco Firepower Management Center Virtual Cryptographic Module

Certificate

Approved Algorithms (24)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Cisco Firepower Management Center Virtual 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>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>SSHv2 Session Encrypt/Decrypt<br/>TLSv1.2 Session Encrypt/Decrypt<br/>SNMPv3 Session Encrypt/Decrypt</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>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and 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["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["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 Cisco Firepower Management Center Virtual 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>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>SSHv2 Session Encrypt/Decrypt<br/>TLSv1.2 Session Encrypt/Decrypt<br/>SNMPv3 Session Encrypt/Decrypt</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>operating system<br/>linux<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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Cisco Systems, Inc Cisco Firepower Management Center Virtual Cryptographic Module Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2021-2026 Cisco Systems, Inc. Cisco Systems logo is registered trademark of Cisco Systems, Inc.

Center Virtual VMware Cryptographic Module (hereinafter referred to as the Module or FMCv) with firmware version 7.4.2. The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 and ISO/IEC 19790 for a Security Level 1 firmware The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic indicates the actual security levels for each area of the cryptographic module.

Purpose and Use: This module is a multi-chip standalone firmware hybrid cryptographic module deployed as the virtualized version of the Cisco Firepower Management Center with underlying operating system identified as Linux 4 (also referred to as Firepower eXtensible Operating System or FX-OS) throughout this document. The Module’s operational environment is non-modifiable. The module is the administrative nerve center for managing critical Cisco network security solutions. It provides complete and unified management over firewalls, application control, intrusion prevention, URL filtering, and advanced malware protection, quickly and easily go from managing a firewall to controlling applications to investigating and remediating malware outbreaks. It is a key part of the broad and integrated Cisco Secure portfolio, delivering in-depth © 2021-2026 Cisco Systems, Inc.

analysis, streamlined security management across the network and cloud, and accelerated incident investigation and response, working across Cisco and third-party technologies. The Firewall Management Center (FMC) discovers real-time information about changing network resources and operations. The Management Center is the centralized point for event and policy management for the following solutions:

• Cisco Firepower Next-Generation Firewall (NGFW)
• Cisco ASA with FirePOWER Services
• Cisco Firepower Next-Generation IPS (NGIPS)
• Cisco FirePOWER Threat Defense
• Cisco Advanced Malware Protection (AMP) Module Type: Firmware-hybrid Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The cryptographic module (red dash box) is a non-modifiable, multi-chip standalone firmware hybrid cryptographic module providing cryptographic support which takes data in and out from the host application via the API. The block diagram below shows the boundary of the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The cryptographic boundary is the module (red dash box) and its interfaces with the operational environment. Processor Host Platform API Hypervisor API FMC API FOM Figure 1 Block Diagram The Block Diagram above comprises the following components
• Processor: Chip on the tested platforms handle all processes.
• API: Host API between hypervisor and processor
• Hypervisor: VMWare ESXi 7.0
• API: Host API between hypervisor and the ASA Module
• FMC: Firepower Management Center © 2021-2026 Cisco Systems, Inc.

• API: Guest API between the FMC Module and FOM Crypto library FOM: Cisco FIPS Object Module (FOM)

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) HMACSHA2-512 Tested Module Identification
• Hybrid Disjoint Hardware: 1.0 7.0 Table 3: Tested Module Identification
• Hybrid Disjoint Hardware Tested Operational Environments - Software, Firmware, Hybrid: Linux 4 (FXOS) Table 4: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: Table 5: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid © 2021-2026 Cisco Systems, Inc. 7.4.2

N/A for this module. Modes List and Description: Table 6: Modes List and Description The module has one Approved mode of operation and does not implement a Non-Approved following the steps in section 11 of this document, the module will only operate in the Approved mode of operation. The module doesn’t claim the implementation of a degraded mode

Approved Algorithms: © 2021-2026 Cisco Systems, Inc.

Table 7: Approved Algorithms Implementation Reference N/A Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: © 2021-2026 Cisco Systems, Inc.

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.

AsymKeyPairKeyGen © 2021-2026 Cisco Systems, Inc.

Table 9: 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.
• In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation as per section 5 in SP800-133rev2. The resulting generated seed used in the asymmetric key generation is the unmodified output from SP800-90Arev1 DRBG.
• The module was algorithm tested based on the FIPS 186-4 standard Digital Signatures. According to IG C.K, this module is 186-5 compliant as all 186-4 CAVP tests performed are mathematically identical to the 186-5 CAVP tests. The Module does not support 1864 DSA or RSA X9.31 for Signature Generation or Signature Verification.

Table 10: Entropy Certificates © 2021-2026 Cisco Systems, Inc.

NonPhysical Table 11: Entropy Sources A2810 (SHA3256) The module employs a Deterministic Random Bit Generator (DRBG) implementation based on SP800-90Arev1. This DRBG is used internally by the module (e.g. to generate symmetric keys, seeds for asymmetric key pairs, and random numbers for security functions). The DRBG implemented is an AES-256 Counter DRBG, seeded by the entropy source described in the table above. The Counter DRBG utilizes the Derivation Function and employs prediction resistance. The DRBG is instantiated with a 384-bits long entropy input (corresponding to 384 bits of entropy). Additionally, the DRBG is reseeded with a 256-bits long entropy input (corresponding

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800- 133r2. When random values are required, they are obtained from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. The following methods are implemented:

• Direct generation of symmetric keys: compliant with SP 800-133rev2, Section 6.1. Safe primes key pair generation: compliant with SP 800-133rev2, Section 5.2, which maps to SP 800-56Arev3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used. RSA key pair generation: compliant with SP 800-133rev2, Section 5.1, which maps to FIPS 186-4. The method described in Appendix B.3 of FIPS 186-4 (“Probable Primes”) is used. ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix B.4 of FIPS 186-4 (“Testing Candidates”) is used. Note that this generation method is also used to generate ECDH key pairs. Additionally, the module implements the following key derivation methods:
• SNMPv3, SSHv2 KDF, TLS 1.2 KDF: compliant with SP 800-135r1. These implementations shall only be used to generate secret keys in the context of the SNMPv3, SSHv2 and TLSv1.2 protocols, respectively. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service © 2021-2026 Cisco Systems, Inc.

The module provides the following key/SSP establishment services in the approved mode of 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.
• The module supports the use of the safe primes defined in RFC 4419 (SSH) and RFC

7919 (TLS). Note that the module only implements domain parameter generation, key

pair generation and verification, and shared secret computation.

• SSH (RFC 4419):  MODP-2048 (ID = 14)  MODP-3072 (ID = 15)  MODP-4096 (ID = 16)
• TLS (RFC 7919):  ffdhe2048 (ID = 256)  ffdhe3072 (ID = 257)  ffdhe4096 (ID = 258) 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 also provides the following key transport mechanisms:
• Key wrapping using AES-GCM with a security strength of 128 or 256 bits.
• Key wrapping using AES-CBC with a security strength of 128 or 256 bits with HMACSHA-1, HMAC-SHA2-256 or HMAC-SHA2-384.

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

N/A N/A Table 12: Ports and Interfaces The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data input, data output, control input, control output and status output) as follows.

Table 13: Roles The module supports Crypto Officer (CO) role. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested.

The following tables detail the types of approved services available to each role in approved mode of operation, the types of access for each role and the Keys or SSPs they affect.

• Generate G
• Read Access R
• Write Access W
• Execute Access E
• Zeroize Z n © 2021-2026 Cisco Systems, Inc.

SelfTests n n. (Preoperationa l SelfTests) n. ondemand SelfTests. the selftests © 2021-2026 Cisco Systems, Inc. Z Z Z

n n. n. © 2021-2026 Cisco Systems, Inc. with AESGCM) with AESGCM) G,W,E G,R,W G,W,E G,R,W G,W,E G,W,E G,W,E G,W,E G,R,W G,W,E G,R,W

n e n. with AESGCM) with AESGCM) © 2021-2026 Cisco Systems, Inc. G,W,E G,W,E G,W,E W,E G,W,E G,W,E G,R,W G,W,E G,W,E G,R,W

n © 2021-2026 Cisco Systems, Inc. with AESGCM) n G,W,E G,R,W G,W,E G,W,E G,R,W W,E G,W,E G,W,E G,R,W G,W,E G,R,W G,W,E

The module is provided in the form of binary executable code. To ensure the firmware security, the module is protected by HMAC-SHA2-512 (HMAC Certs. #A4595) algorithm. The firmware integrity test key (non-SSP) was preloaded to the module’s binary the factory and used for firmware integrity test only at the pre-operational self-test. At Module’s initialization, the integrity of the runtime executable is verified using a HMAC-SHA2-512 digest which is compared to a value computed at build time. If at the load time the MAC does not match the stored, known MAC value, the module would enter to an Error state with all crypto functionality inhibited.

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 firmware integrity test on-demand.

Type of Operational Environment: Non-Modifiable The module is a firmware hybrid module, which is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The module’s firmware version running on each tested platform is 7.4.2. The module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevent unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators.

The module is running on the multi-chip standalone production grade platform to meet physical security requirements from FIPS 140-3 level

1. The module’s Tested Operational Environment’s Physical Perimeter (TOEPP) is drawn at the casing of the tested platforms in Table
2. The module’s tested platforms consist of production-grade components.

N/A for this module. © 2021-2026 Cisco Systems, Inc.

with AESGCM) with AESGCM) Table 16: SSP Input-Output Methods

Table 17: SSP Zeroization Methods n h MODP2048, MODP3072, MODP2048, MODP3072, © 2021-2026 Cisco Systems, Inc. KASFFC

n h MODP2048, MODP3072, MODP2048, MODP3072, © 2021-2026 Cisco Systems, Inc. KASECC

n h n 8, 2, 8, 2, © 2021-2026 Cisco Systems, Inc. KASFFC )

n h 8, 2, 8, 2, © 2021-2026 Cisco Systems, Inc. KASECC )

n h Table 18: SSP Table 1 n © 2021-2026 Cisco Systems, Inc.

SHA-1 The module includes an implementation of SHA-1 for hashing and digital signature verification. This implementation will be non-Approved for all uses starting January 1, 2031 FIPS 186-4/186-5 As of February 5, 2024, the CMVP does not accept module submissions that implement DSA or RSA X9.31 in the approved mode, other than for signature verification which is approved for legacy use. This module does not implement DSA or RSA X9.31 for signature generation and therefore is unaffected by the current transition from 186-4 to 186-5. As detailed in section 2.7, the CAVP testing performed on the 186-4 algorithms is mathematically similar to the testing performed on the 186-5 algorithms and therefore this module claims compliance with 186-5. This means that no timeline exists in which any of the implemented algorithms will transition from approved to non-approved.

Table 20: Pre-Operational Self-Tests © 2021-2026 Cisco Systems, Inc. HMACSHA2-512

The module performs the following self-tests, including Pre-operational and Conditional selftests. Prior to the module providing any data output via the data output interface, the module performs and passes the pre-operational self-tests. Following the successful pre-operational self-tests, the module executes the Conditional Cryptographic Algorithm Self-tests (CASTs). The self-test success or failure results are an output of the return value of the library load API call, which is functioning as the self-test status indicator. If anyone of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state.

s d s T T T T T SHA2256 SHA2256 T T T N/A © 2021-2026 Cisco Systems, Inc.

s d s T N/A T N/A T N/A T N/A SHA2224 T N/A SHA2256 T N/A SHA2384 T N/A SHA2512 T N/A Curve P256 T MODP2048 T N/A T N/A © 2021-2026 Cisco Systems, Inc.

s d N/A T SHA2256 SHA2256 N/A T T T SHA2256 SHA2256 MODP2048 © 2021-2026 Cisco Systems, Inc. s N/A N/A N/A N/A

s d Table 21: Conditional Self-Tests s

Table 22: Pre-Operational Periodic Information © 2021-2026 Cisco Systems, Inc.

N/A N/A N/A Table 23: Conditional Periodic Information © 2021-2026 Cisco Systems, Inc. N/A

The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.

Table 24: Error States If any of the above-mentioned self-tests fail, the module reports the error and enters the 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 selftests, including the pre-operational integrity test and the conditional CASTs. The module will only enter into the operational state after successfully passing the pre-operational integrity test and the conditional CASTs.

The module meets all the Level 1 requirements for FIPS 140-3. The Crypto Officer must configure and enforce the following initialization steps: Step 1: Log in with the default username admin and the password Admin123. Step 2: The first time you log in to the Module, you are prompted to accept the End User License Agreement (EULA) and to change the admin password. You will be prompted with the CLI setup wizard. Answer the prompts to configure the network settings. Step 3: Use a web browser to navigate to the Modules Firewall Management Center IP address you configured in Step 2. Step 4: Navigate to System > Configuration > Access List (Choose SSH or HTTPS or a combination of these options to specify which ports you want to enable for these IP addresses). Step 5: Navigate to System > Licenses > Smart Licenses, add and verify licenses Install AES SMART license to use AES (for data traffic and SSH). Step 6: Navigate to System > Configuration > UCAPL/CC Compliance, choose “CC” from the drop down; Click on save. © 2021-2026 Cisco Systems, Inc.

Step 8: Check the Module’s name, version and approved service status by using the following commands/ procedure: Output the modules name/version: > show version Output the modules approved mode of operation status by navigating to System > Configuration > UCAPL/CC Compliance, and confirming the “CC” option is selected.

No specific Administrator guidance.

No specific Non-Administrator guidance.

N/A for this module. © 2021-2026 Cisco Systems, Inc.