Firepower Management Center Virtual VMware Cryptographic Module

Certificate

Approved Algorithms (42)

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

flowchart LR
  %% Deterministic review-risk graph for Firepower Management Center Virtual VMware Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status<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>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Firepower Management Center Virtual VMware Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status<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>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 C3,C5,C6 clueLow;

Security Policy, page by page

ISO/IEC 19790 and FIPS 140-3 Non-Proprietary Security Policy for Firepower Management Center Virtual VMware Cryptographic Module Last Updated: June 14, 2024, Version 0.3 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Table of Content List of Figures List of Tables

VMware Cryptographic Module (hereinafter referred to as the Module or FMCv) with software version 7.0.5. 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 Software cryptographic module. The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module interfaces; roles, services, and authentication; software/firmware security; operational environment; physical security; noninvasive security; sensitive security parameter management; self-tests; life-cycle assurance; and mitigation of other attacks. Table 1 below indicates the actual security levels for each area of the cryptographic module. ISO/IEC 24759:2017 ISO/IEC 24759:2017 and FIPS 140-3 Level Section 6 Section Title

1 General 1

2 Cryptographic module specification 1

3 Cryptographic module interfaces 1

4 Roles, services, and authentication 1

5 Software/Firmware security 1

6 Operational environment 1

7 Physical security N/A

8 Non-invasive security N/A

9 Sensitive security parameter management 1

10 Self-tests 1

11 Life-cycle assurance 1

12 Mitigation of other attacks N/A

Table 1 Security Levels The module has an overall security level of 1.

The Module is a multi-chip standalone software 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 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) The module has been tested on the following Operational Environments. # Operating System Hardware Platform Processor PAA/Acceleration

1 Linux 4 (FX-OS) on UCS C220 M5 SFF Intel Xeon Gold 6128 With PAA

VMware ESXi 6.7 Server (Skylake)

2 Linux 4 (FX-OS) on UCS C220 M5 SFF Intel Xeon Gold 6128 Without PAA

VMware ESXi 6.7 Server (Skylake)

3 Linux 4 (FX-OS) on UCS C220 M5 SFF Intel Xeon Gold 6128 With PAA

VMware ESXi 7.0 Server (Skylake)

4 Linux 4 (FX-OS) on UCS C220 M5 SFF Intel Xeon Gold 6128 Without PAA

VMware ESXi 7.0 Server (Skylake) Table 2 Tested Operational Environment Figure 1 UCS C220 M5 Front view without Bezel (top) and with Bezel (bottom)1 Figure 2 UCS C220 M5 Rear view In addition to the platforms listed in Table 2, Cisco has also tested the module on the following platforms and claims vendor affirmation on them. # Operating System Hardware Platform

Table 3 Vendor Affirmed Operational Environments https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/c220m5-sffspecsheet.pdf

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. Mode of operation The module has one approved mode of operation and is always in the approved mode of operation after initial operations are performed (See Section 11). The module does not claim implementation of a degraded mode of operation. Section 4 provides details on the service indicator implemented by the module. The table 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. 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. CAVP Algorithm and Mode/Method Description / Key Use/Function Cert Standard Size(s) / Key Strength(s) A2952 and AES CBC Key Length: 128 and 256 Symmetric Encryption and A3376 [FIPS 197; bits Decryption. SP800-38A] A2952 and AES GCM Key Length: 128 and 256 Authenticated Symmetric A3376 [FIPS 197; bits Encryption and Decryption SP 800-38D] A2952 and KDF SSH KDF SSH N/A Key derivation function A3376 [SP 800-135rev1] used in SSHv2 (CVL) A2952 and TLS v1.2 KDF TLS v1.2 KDF RFC7627 N/A Key derivation in TLSv1.2 A3376 RFC7627 with RFC7627 KDF with [RFC7627] Extended Master Secret (CVL) A2952 and CTR_DRBG AES-256 N/A Random number A3376 [SP 800-90Arev1] Derivation Function generation Enabled; Prediction Resistance: Yes A2952 and ECDSA ECDSA KeyGen Curves: P-256, P-384, P- ECDSA keypair A3376 [FIPS 186-4] 521 generation A2952 and ECDSA ECDSA KeyVer Curves: P-256, P-384, P- ECDSA keypair A3376 [FIPS 186-4] 521 verification A2952 and ECDSA ECDSA SigGen Curves: P-256, P-384, P- ECDSA signature A3376 [FIPS 186-4] 521 generation A2952 and ECDSA ECDSA SigVer Curves: P-256, P-384, P- ECDSA Signature A3376 [FIPS 186-4] 521 verification A2952 and HMAC HMAC-SHA-1 Key Length: 112 bits or Keyed Hash A3376 [FIPS 198-1] greater A2952 and HMAC HMAC-SHA2-256 Key Length: 112 bits or Keyed Hash A3376 [FIPS 198-1] greater A2952 and HMAC HMAC-SHA2-384 Key Length: 112 bits or Keyed Hash A3376 [FIPS 198-1] greater A2952 and HMAC HMAC-SHA2-512 Key Length: 112 bits or Keyed Hash A3376 [FIPS 198-1] greater A2952 and KAS-SSC KAS-ECC-SSC: Curves: P-256, P-384, P- KAS-ECC shared secret A3376 [SP 800-56Arev3] Scheme: 521; computation ephemeralUnified: KAS Role: initiator, Key establishment responder methodology provides between 128 and 256

CAVP Algorithm and Mode/Method Description / Key Use/Function Cert Standard Size(s) / Key Strength(s) bits of encryption strength A2952 and KAS KAS (ECC): Curves: P-256, P-384 and Key Agreement Scheme A3376 [SP 800-56Arev3] Scheme: ephemeralUnified P-521; per SP800-56Arev3 KAS Role: initiator, with key derivation responder Key establishment function (SP800-135rev1) methodology provides KAS-SSC Cert. #A2952, between 128 and 256 Note: The module’s KAS TLSv1.2 KDF RFC7627 bits of encryption (ECC) implementation is Cert. #A2952; strength FIPS140-3 IG D.F Scenario 2 (path

2. KAS-SSC Cert. #A3376, compliant TLSv1.2 KDF RFC7627 Cert. #A3376 A2952 and KAS-SSC KAS-FFC-SSC: MODP-2048; KAS-FFC shared secret A3376 [SP 800-56Arev3] Scheme: dhEphem: computation KAS Role: initiator, Key establishment responder methodology provides between 112 bits of encryption strength A2952 and KAS KAS (FFC): MODP-2048; Key Agreement Scheme A3376 [SP 800-56Arev3] Scheme: dhEphem per SP800-56Arev3 KAS Role: initiator, Key establishment with key derivation responder methodology provides function (SP800-135rev1) between 112 bits of KAS-SSC #A2952, KDF encryption strength Note: The module’s KAS SSH Cert. #A2952; (FFC) implementation is FIPS140-3 IG D.F KAS-SSC Cert. #A3376, Scenario 2 (path
3. KDF SSH Cert. #A3376 compliant A2952 and RSA RSA KeyGen: Modulus: 2048/3072 bits RSA keypair generation A3376 [FIPS 186-4] - Mode: B.3.4 - 2048/3072 Modulus A2952 and RSA RSA SigGen: Modulus: 2048/3072 bits RSA signature generation A3376 [FIPS 186-4] - PKCSv1.5 - 2048/3072 Modulus with SHA2-256/384/512 A2952 and RSA RSA SigVer: Modulus: 2048/3072 bits RSA signature verification A3376 [FIPS 186-4] - PKCSv1.5 - 2048/3072 Modulus with SHA2-256/384/512 A2952 and Safe Primes Key KeyGen for KAS-SSC Safe Prime Groups: KAS-FFC Keypair domain A3376 Generation (FFC) MODP-2048 parameters generation [SP 800-56Arev3] A2952 and SHS SHA-1 N/A Message Digest A3376 [FIPS 180-4] A2952 and SHS SHA2-256 N/A Message Digest A3376 [FIPS 180-4] A2952 and SHS SHA2-384 N/A Message Digest A3376 [FIPS 180-4] A2952 and SHS SHA2-512 N/A Message Digest A3376 [FIPS 180-4]

CAVP Algorithm and Mode/Method Description / Key Use/Function Cert Standard Size(s) / Key Strength(s) Vendor CKG Section 5.1, Section 5.2 Cryptographic Key Key Generation. Affirmed (SP800-133rev2) Generation; SP 800133rev2 and IG D.H. Note: The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 5 in SP800133rev2 (vendor affirmed). A seed (i.e., the random value) used in asymmetric key generation is a direct output from SP800-90Arev1 CTR_DRBG. Table 4 Approved Algorithms Notes:

• Algorithm Cert. #A2952 was tested for the OE with PAA
• Algorithm Cert. #A3376 was tested for the OE without PAA
• The module’s AES-GCM implementation conforms to FIPS 140-3 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 SSH and TLS protocols, other than the KDFs, have been tested by the CAVP and CMVP.
• 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. As the module can only be operated in the Approved mode of operation, and any algorithms not listed in the table 4 above will be rejected by the module while in the approved mode, the tables defined in SP800140B 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 Cryptographic boundary The module is defined as a multi-chip standalone software module (inside red dashed area). The cryptographic boundary includes all of the module’s software components, including Guest OS, API and FOM Crypto Library (Cisco FIPS Object Module). The physical perimeter is the Tested Operational Environment’s Physical Perimeter (TOEPP) on which the module runs.

Tested Platform TOEPP Processor API Hypervisor Guest OS / FMC API FOM Figure 3 Block Diagram Note: Block Diagram above comprises the following components:

• Processor = Chip on the tested platform to handle all processes.
• API = Host API between hypervisor and processor
• Hypervisor = VMWare ESXi 6.7 and 7.0
• Guest OS/FMC = Linux 4 (FX-OS)
• API = Guest API between the FMC Module and FOM Crypto library
• FOM = Cisco FIPS Object Module (FOM) Crypto Library

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 module’s logical interfaces provided by the module are mapped onto the FIPS 140-3 logical interfaces (data input, data output, control input, control output and status output) as follows. Physical Logical Interface Data that passes over port/interface Port N/A Data Input Interface Arguments for an API call that provide the data to be used or processed by the module. N/A Data Output Interface Arguments output from an API call. N/A Control Input Interface Arguments for an API call used to control and configure module operation. N/A Control Output Interface N/A N/A Status Output Interface Return values, and or log messages. Table 5 Ports and Interfaces

The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services to the Crypto Officer.

Role Service Input Output Crypto Officer Show Status API command to show status Module’s current status Crypto Officer Show Version API commands to show version Module’s name/ID and versioning information Crypto Officer Perform Self-Tests API commands to conduct on- Status of the self-tests results demand Self-Tests Crypto Officer Perform Zeroization API commands to conduct Status of the SSPs zeroization Zeroization operation or Power down the tested platform Crypto Officer Configure Network API Commands to configure Status of the completion of network the module related configuration Crypto Officer Configure SSHv2 API commands to configure Status of the completion of SSHv2 Function SSHv2 configuration Crypto Officer Configure HTTPS over API commands to configure Status of the completion of HTTPS over TLSv1.2 Function HTTPS over TLSv1.2 TLSv1.2 configuration Crypto Officer Run SSHv2 Function API commands to execute Status of SSHv2 secure tunnel SSHv2 service establishment Crypto Officer Run HTTPS over API commands to execute Status of HTTPS over TLSv1.2 secure TLSv1.2 Function HTTPS over TLSv1.2 service tunnel establishment Table 6 Roles, Service Commands, Input and Output Table 7 below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module. 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. N/A = The service does not access any SSP during its operation. Services Description Approved Keys and /or SSPs Roles Access Indicator Security rights to Functions Keys and/or SSPs Show Provide Module’s N/A N/A Crypto N/A None Status current status Officer Show Provide Module’s N/A N/A Crypto N/A None Version name/ID and Officer versioning information Perform Perform Self- N/A N/A Crypto N/A None Self-Tests Tests (Pre- Officer operational selftests and Conditional SelfTests) Perform Perform N/A All SSPs Crypto Z None Zeroization Zeroization Officer Configure Sets configuration N/A N/A Crypto N/A None Network of the systems Officer Configure Configure SSHv2 AES-CBC; Diffie-Hellman Private Crypto W, E Global SSHv2 Function CKG; Key; Officer Indicator and Function SSHv2

Services Description Approved Keys and /or SSPs Roles Access Indicator Security rights to Functions Keys and/or SSPs KDF SSH; Diffie-Hellman Public success log CTR_DRBG; Key; message HMAC-SHA-1; Peer Diffie-Hellman HMAC-SHA2- Public Key; 256; Diffie-Hellman Shared HMAC-SHA2- Secret; 384; RSA Private Key; HMAC-SHA2- RSA Public Key; 512; SSH Session Integrity KAS-FFC-SSC; Key; KAS (FFC); SSH Session Key RSA KeyGen; RSA SigGen; RSA SigVer; Safe Primes Key Generation; SHA-1; SHA2-256; SHA2-384; SHA2-512 Configure Configure HTTPS AES-CBC; EC Diffie-Hellman Crypto W, E Global HTTPS over TLSv1.2 AES-GCM; Private Key; Officer Indicator and over Function CKG; EC Diffie-Hellman HTTPS over TLSv1.2 TLS v1.2 KDF Public Key; TLSv1.2 Function RFC7627; Peer EC Diffie-Hellman success log CTR_DRBG; Public Key; message ECDSA KeyGen; EC Diffie-Hellman ECDSA KeyVer; Shared Secret; ECDSA SigGen; ECDSA Private Key; ECDSA SigVer; ECDSA Public Key; HMAC-SHA-1; RSA Private Key; HMAC-SHA2- RSA Public Key; 256; TLS master secret; HMAC-SHA2- TLS Session Key; 384; TLS Session Integrity HMAC-SHA2- Key 512; KAS-ECC-SSC; KAS (ECC); RSA KeyGen; RSA SigGen; RSA SigVer; SHA-1; SHA2-256; SHA2-384; SHA2-512 Run Execute SSHv2 AES-CBC; DRBG entropy input; Crypto W, E Global SSHv2 Function CKG; DRBG Seed, Internal Officer Indicator and Function KDF SSH; State V value, and SSHv2 CTR_DRBG; Key; success log HMAC-SHA-1; Diffie-Hellman Private message HMAC-SHA2- Key; 256;

Services Description Approved Keys and /or SSPs Roles Access Indicator Security rights to Functions Keys and/or SSPs HMAC-SHA2- Diffie-Hellman Public 384; Key; HMAC-SHA2- Peer Diffie-Hellman 512; Public Key; KAS-FFC-SSC; Diffie-Hellman Shared KAS (FFC); Secret; RSA KeyGen; RSA Private Key; RSA SigGen; RSA Public Key; RSA SigVer; SSH Session Integrity Safe Primes Key Key; Generation; SSH Session Key SHA-1; SHA2-256; SHA2-384; SHA2-512 Run Execute HTTPS AES-CBC; DRBG entropy input; Crypto W, E Global HTTPS over TLSv1.2 CKG; DRBG Seed, Internal Officer Indicator and over Function TLS v1.2 KDF State V value, and HTTPS over TLSv1.2 RFC7627; Key; TLSv1.2 Function CTR_DRBG; EC Diffie-Hellman success log ECDSA KeyGen; Private Key; message ECDSA KeyVer; EC Diffie-Hellman ECDSA SigGen; Public Key; ECDSA SigVer; Peer EC Diffie-Hellman HMAC-SHA-1; Public Key; HMAC-SHA2- EC Diffie-Hellman 256; Shared Secret; HMAC-SHA2- ECDSA Private Key; 384; ECDSA Public Key; HMAC-SHA2- RSA Private Key; 512; RSA Public Key; KAS-ECC-SSC; TLS master secret; KAS (ECC); TLS Session Key; RSA KeyGen; TLS Session Integrity RSA SigGen; Key RSA SigVer; SHA-1; SHA2-256; SHA2-384; SHA2-512 Table 7 Approved Services As the module can only be operated in the Approved mode of operation, as such any algorithms not listed in Table 4 above will be rejected by the module while in the approved mode, the table required defined in SP800-140B for Non-Approved Services is missing from this document. The module doesn’t support self-initiated cryptographic output capability and cryptographic Bypass capability services.

Integrity techniques The module is provided in the form of binary executable code. To ensure the software security, the module is protected by HMAC-SHA2-512 (HMAC Certs. #A2952 or #A3376) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary the factory and used for software 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 on-demand Integrity test is performed as part of the pre-operational self-tests. It is automatically executed at poweron. The operator can power-cycle or reboot the tested platform to initiate the software integrity test ondemand.

The module is a software module, which is operated in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module’s software version running on each tested platform is 7.0.5. The module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevents 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 FIPS 140-3 physical security requirements do not apply to the Module since it is a software module.

Currently, non-invasive security is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module.

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. Key/SSP Strength Security Generation Import/ Esta Storage Zeroization Use & Name Function Export blish related Type and Cert ment Keys Number DRBG 384 bits CTR_DRBG Obtained from Import to the N/A: The Automatic Random entropy the Entropy module via N/A module zeroization Number input #A2952 or Source within Module’s does not when the Generation (CSP) #A3376 API provide tested

Key/SSP Strength Security Generation Import/ Esta Storage Zeroization Use & Name Function Export blish related Type and Cert ment Keys Number TOEPP (GPS Export: No persistent platform is INT Pathways) keys/SSPs powered storage. down DRBG 256 bits CTR_DRBG Internally Import: No N/A N/A: The Automatic Random Seed, Derived from module zeroization Number Internal #A2952 or entropy input Export: No does not when the Generation State V #A3376 string as provide tested value, and defined by persistent platform is Key SP800- keys/SSPs powered (CSP) 90Arev1 storage. down Diffie- MODP- CKG; Internally Import: No N/A N/A: The Automatic Used to Hellman 2048 CTR_DRBG; generated module zeroization derive Private KAS (FFC); conformant to Export: No does not when the DiffieKey KAS-FFC- SP800-133r2 provide tested Hellman (CSP) SSC; (CKG) using persistent platform is Shared Safe Primes SP800-56A keys/ powered Secret Key rev3 Diffie- SSPs down Generation Hellman key storage. generation #A2952 or method, and #A3376 the random value used in key generation is generated using SP80090ARev1 DRBG Diffie- MODP- KAS (FFC); Internally Import: No N/A N/A: The Automatic Used to Hellman 2048 KAS-FFC- derived per the module zeroization derive Public Key SSC; Diffie- Export: to the does not when the Diffie(PSP) Safe Primes Hellman key SSH Peer provide tested Hellman Key agreement application persistent platform is Shared Generation (SP800- keys/ powered Secret 56Arev3) SSPs down #A2952 or storage. #A3376 Peer MODP- N/A N/A Import: to the N/A N/A: The Automatic Used to Diffie- 2048 Module via module zeroization derive Hellman API does not when the DiffiePublic Key provide tested Hellman (PSP) Export: No persistent platform is Shared keys/SSPs powered Secret storage. down Diffie- MODP- KAS-FFC- Internally Import: No N/A N/A: The Automatic Used to Hellman 2048 SSC generated module zeroization derive SSH Shared using SP800- Export: No does not when the session Secret #A2952 or 56Arev3 DH provide tested related (CSP) #A3376 shared secret persistent platform is keys computation keys/SSPs powered storage. down

Key/SSP Strength Security Generation Import/ Esta Storage Zeroization Use & Name Function Export blish related Type and Cert ment Keys Number EC Diffie- P-256, P- CKG; Internally Import: No N/A N/A: The Automatic Used to Hellman 384 and CTR_DRBG; generated module zeroization derive EC Private P-521 KAS (ECC); conformant to Export: No does not when the DiffieKey KAS-ECC- SP800-133r2 provide tested Hellman (CSP) SSC (CKG) using persistent platform is Shared SP800-56A keys/ powered Secret #A2952 or rev3 EC SSPs down #A3376 Diffie- storage. Hellman key generation method, and the random value used in key generation is generated using SP80090Arev1 DRBG EC Diffie- P-256, P- KAS (ECC); Internally Import: No N/A N/A: The Automatic Used to Hellman 384 and KAS-ECC- derived per the module zeroization derive EC Public Key P-521 SSC EC Diffie- Export: to the does not when the Diffie(PSP) Hellman key TLS Peer provide tested Hellman #A2952 or agreement application persistent platform is Shared #A3376 (SP800- keys/ powered Secret 56Arev3) SSPs down storage. Peer EC P-256, P- N/A N/A Import: to the N/A N/A: The Automatic Used to Diffie- 384 and Module via module zeroization derive EC Hellman P-521 API does not when the DiffiePublic Key provide tested Hellman (PSP) Export: No persistent platform is Shared keys/SSPs powered Secret storage. down EC Diffie- P-256, P- KAS-ECC- Internally Import: No N/A N/A: The Automatic Used to Hellman 384 and SSC generated module zeroization derive TLS Shared P-521 using SP800- Export: No does not when the session Secret #A2952 or 56Ar3 ECDH provide tested related (CSP) #A3376 shared secret persistent platform is keys computation keys/SSPs powered storage. down ECDSA P-256, P- CKG; Internally Import: No N/A N/A: The Automatic Signature Private 384 and CTR_DRBG; generated module zeroization generation Key P-521 ECDSA conformant to Export: No does not when the and (CSP) KeyGen; SP800-133r2 provide tested Verification ECDSA (CKG) using persistent platform is used in TLS KeyVer; FIPS 186-4 keys/SSPs powered ECDSA ECDSA key storage. down SigGen; generation method, and #A2952 or the random #A3376 value used in key generation is generated using SP800-

Key/SSP Strength Security Generation Import/ Esta Storage Zeroization Use & Name Function Export blish related Type and Cert ment Keys Number 90Arev1 DRBG ECDSA P-256, P- ECDSA Internally Import: No N/A N/A: The Automatic Signature Public Key 384 and KeyGen; derived per the module zeroization generation (PSP) P-521 ECDSA FIPS 186-4 Export: No does not when the and KeyVer; ECDSA key provide tested Verification ECDSA generation persistent platform is used in TLS SigVer; method keys/SSPs powered storage. down #A2952 or #A3376 RSA 2048 and CKG; Internally Import: No N/A N/A: The Automatic Signature Private 3072 bits CTR_DRBG; generated module zeroization generation Key RSA conformant to Export: No does not when the and (CSP) KeyGen; SP800-133r2 provide tested Verification RSA SigGen; (CKG) using persistent platform is used in SSH FIPS 186-4 keys/SSPs powered or TLS #A2952 or RSA key storage. down #A3376 generation method, and the random value used in the key generation is generated using SP80090Arev1 DRBG RSA 2048 and KeyGen; Internally Import: No N/A N/A: The Automatic Signature Public Key 3072 bits RSA SigVer; derived per the module zeroization generation (PSP) FIPS 186-4 Export: No does not when the and #A2952 or RSA key provide tested Verification #A3376 generation persistent platform is used in SSH method keys/SSPs powered or TLS storage. down SSH 160 bits KDF SSH; Internally Import: No N/A N/A: The Automatic Used for Session HMAC-SHA- Derived per module zeroization SSH Integrity 1 the key Export: No does not when SSH session Key derivation provide session is integrity (CSP) #A2952 or function persistent terminated or protection. #A3376 defined in keys/SSPs when the SP800-135 storage. tested KDF (KDF- platform is SSH). powered down SSH 128/256 AES-CBC; Internally Import: No N/A N/A: The Automatic Used for SSH Session bits KDF SSH; Generated via module zeroization session Key key derivation Export: No does not when SSH confidentiality (CSP) #A2952 or function provide session is protection #A3376 defined in persistent terminated or SP800-135 keys/SSPs when the KDF (KDF- storage. tested SSH) platform is

Key/SSP Strength Security Generation Import/ Esta Storage Zeroization Use & Name Function Export blish related Type and Cert ment Keys Number powered down TLS 48 Bytes Keying Internally Import: No N/A N/A: The Automatic Keying Master Material Derived per module zeroization material Secret the key Export: No does not when TLS used to (CSP) derivation provide session is derive function persistent terminated or other TLS defined in keys/SSPs when the keys SP800-135 storage. tested KDF (KDF- platform is TLS v1.2 powered RFC7627) down TLS 128/256 AES-CBC; Internally Import: No N/A N/A: The Automatic Used for TLS Session bits AES-GCM; Derived per module zeroization session Key TLS v1.2 the key Export: No does not when TLS confidentiality (CSP) KDF derivation provide session is protection RFC7627; function persistent terminated or defined in keys/SSPs when the #A2952 or SP800-135 storage. tested #A3376 KDF (KDF- platform is TLS v1.2 powered RFC7627) down TLS 256-384 TLS v1.2 Internally Import: No N/A N/A: The Automatic Used for Session bits KDF Derived per module zeroization TLS Integrity RFC7627; the key Export: No does not when TLS session Key HMAC- derivation provide session is integrity (CSP) SHA2-256; function persistent terminated or protection HMAC- defined in keys/SSPs when the SHA2-384; SP800-135 storage. tested KDF (KDF- platform is #A2952 or TLS v1.2 powered #A3376 RFC7627) down Table 8 SSPs

RBG entropy source Entropy sources Minimum Details number of bits of entropy Entropy within At least 112 bits While operating in the approved mode, the entropy and seeding material the TOEPP was for the SP800-90Arev1 DRBG are provided by the external calling passively Load application (and not by the Module) which is outside the module’s Into the module to cryptographic boundary but contained within the module’s Tested seed the 800- Operational Environment’s Physical Perimeter (TOEPP) boundary. The 90Arev1 DRBG module receives a LOAD command with entropy obtained from the by the Operating entropy source (Intel CPU processor with instructions RDRand) inside System. the TOEPP. The minimum effective strength of the SP 800-90Arev1 DRBG seed is required to be at least 112 bits when used in an approved mode of operation, therefore the minimum number of bits of entropy requested when the Module makes a call to the SP 800-90Arev1 DRBG is at least 112 bits. Per the IG 9.3.A Entropy Caveats, the following caveat applies: No assurance of the minimum strength of generated SSPs (e.g., keys). Table 9 Non-Deterministic Random Number Generation Specification

When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs preoperational self-tests. The operating system is responsible for the initialization process and loading of the Module. The module is designed with a default entry point (DEP) which ensures that the self-tests are initiated automatically when the module is loaded. Prior to the module providing any data output via the data output interface, the module would perform and pass the pre-operational self-tests. A software integrity test is performed on the runtime image of the module with HMAC-SHA2-512 algorithm. Prior to the firmware integrity test, the module conducts a HMAC-SHA2-512 Cryptographic Algorithm Self-test (CAST). If the CAST on the HMAC-SHA2-512 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value pre-computed at compilation time. Following the successful pre-operational self-tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs) for all approved cryptographic algorithms implemented by the module during powerup as well. The self-test success or failure messages (e.g., Error: Signature RSA test failure or ECDH P-256 test failure) were logged, which is functioning as the self-test status indicator. If any one 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 only method to recover from the error state is to power cycle the device which results in the module being reloaded into memory and reperforming the pre-operational software integrity test and the Conditional CASTs. The module will only enter into the operational state after successfully passing the preoperational software integrity test and the Conditional CASTs. Below are the details of the self-tests conducted by the module. Pre-operational self-tests:

• Pre-operational software integrity test
• HMAC-SHA-512 KAT
• Software Integrity Test (using HMAC-SHA-512) Please note that the module conducts HMAC-SHA-512 KAT self-test before the integrity test is performed.

Conditional self-test

• Conditional cryptographic algorithm self-tests (CASTs)
• AES-CBC 256 bits Encrypt KAT
• AES-CBC 256 bits Decrypt KAT
• AES-GCM 256 bits Authenticated Encrypt KAT
• AES-GCM 256 bits Authenticated Decrypt KAT
• CTR_DRBG Instantiate KAT
• CTR_DRBG Generate KAT
• CTR_DRBG Reseed KAT Note: CTR_DRBG Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1
• ECDSA P-256 with SHA-256 SigGen KAT
• ECDSA P-256 with SHA-256 SigVer KAT
• HMAC-SHA-1 KAT
• HMAC-SHA-256 KAT
• HMAC-SHA-384 KAT
• HMAC-SHA-512 KAT
• KAS-ECC-SSC Primitive Z KAT
• KAS-ECC-SSC Primitive Z KAT
• RSA 2048 bits modulus with SHA-256 SigGen KAT
• RSA 2048 bits modulus with SHA-256 SigVer KAT
• SHA-1 KAT
• KDF-SSH KAT
• KDF-TLS KAT The module generates RSA, ECDSA, KAS-ECC and KAS-FFC asymmetric keys and performs all required pair-wise consistency tests on the newly generated key pairs as detailed below.
• Conditional pair-wise consistency tests (PCTs)
• RSA PCT
• ECDSA PCT
• KAS-ECC PCT
• KAS-FFC PCT Periodic/Self-tests on-demand 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. In addition, it is recommended for the Crypto Officer to perform the periodic tests a minimum of once every 60 days to ensure all components are functioning correctly.

The module meets all the Level 1 requirements for FIPS 140-3. The validated Module’s executable file Cisco_Firepower_Mgmt_Center_Virtual300_VMware-7.0.5-72-disk1.vmdk is the only allowable software image file running on the respective test platform listed in the Table 2 above while in the approved mode. The Crypto Officer must configure and enforce the following initialization steps:

Step 1: For all Management Centers, the setup process must be completed by logging into the Management Center’s web interface and specifying initial configuration options on a setup page. Step 2: Choose System > Configuration (Choose SSH or HTTPS or a combination of these options to specify which ports you want to enable for these IP addresses). Step 3: System>Licenses>Smart Licenses, add and verify licenses (Firepower Management Center Configuration Guide provides more detailed information). Install AES SMART license to use AES (for data traffic and SSH). Step 4: System > Configuration; Devices > Platform Settings; STIG Compliance, choose Enable STIG Compliance; Click on save. This sets the approved mode of operation. The CO shall only use approved cryptographic algorithms listed in Section 2.2 above. Step 5: Reboot the security appliances.

The requirements under INCITS+ISO+IEC 19790+2012[2014], section 7.12 “Mitigation of other attacks”, are not applicable to the module since the module currently doesn’t support any mitigation of other attacks services.