Adaptive Security Appliance Virtual Cryptographic Module

Certificate

Approved Algorithms (48)

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

flowchart LR
  %% Deterministic review-risk graph for Adaptive Security Appliance 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<br/>upgrade</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</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 Adaptive Security Appliance 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<br/>upgrade</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status</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/>IKEV</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. ISO/IEC 19790 and FIPS 140-3 Non-Proprietary Security Policy for Adaptive Security Appliance Virtual Cryptographic Module Last Updated: June 17, 2024, Version 0.4 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Table of Content List of Figures List of Tables

Virtual Cryptographic Module (hereinafter referred to as ASAv or the Module), software version 9.16.4. The following details how this module meets the security requirements of FIPS 140-3, The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic actual security levels for each area of the cryptographic module. N/A N/A 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 Threat Defense which houses ASA, FX-OS and Firepower solutions with underlying operating system identified as Linux 4 (also referred to as Firepower eXtensible Operating System or FX-OS throughout this document). This solution offers the combination of the industry's most deployed stateful firewall with a comprehensive range of next-generation network security services, intrusion prevention system (IPS), content security, secure unified communications, TLSv1.2, SSHv2, IPSec/IKEv2 and Cryptographic Cipher Suite B, which delivers enterprise-class security for business-to-enterprise networks in a virtual environment. The module has been tested on the following Operational Environments.

# Table 2 Tested Operational Environment Figure 1 UCS C220 M5 front view with Bezel Figure 2 UCS C220 M5 front view without Bezel Figure 3 UCS C220 M5 rear view Figure 4 ENCS 5412 front view1 Figure 5 ENCS 5412 rear view

1 https://www.cisco.com/c/dam/global/da_dk/assets/training/seminaria-materials/enterprise_network_compute_system_encs_.pdf

# Table 3 Vendor Affirmed Operational Environments 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 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 unless 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. N/A N/A N/A N/A

N/A N/A N/A N/A Table 4 Approved Algorithms Notes:

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

• The module uses RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES GCM encryption keys are derived. 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, TLS and IKE protocols, other than the KDFs, have been tested by the CAVP and CMVP. As the module can only be operated in the Approved mode of operation, and any algorithms not listed in Table 4 above will be rejected by the module while in the approved mode, the tables defined in SP800-140B 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 / ASA API FOM Figure 6 Block Diagram Note: Block Diagram above is comprised of the following components:
• Processor. Chip handling all processes.
• API = calling between hypervisor and processor

• Hypervisor = VMWare ESXi 6.7, 7.0 or NFVIS 4.4 Guess OS/ASA = Linux 4 (FX-OS) API = calling between the ASA and FOM library FOM = Cisco FIPS Object Module (FOM Crypto Library) Cryptographic module 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 logical interfaces N/A N/A N/A N/A N/A N/A Table 5 Ports and Interfaces Roles, services, and authentication 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

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. N/A = The service does not access any SSP during its operation. Perform SelfSelf-Tests Tests (Preoperational selftests and Conditional SelfTests) N/A N/A N/A N/A N/A Access rights to N/A N/A Z N/A N/A N/A N/A N/A N/A W, E

N/A N/A Access rights to N/A As the module can only be operated in the Approved mode of operation, and as such any algorithms not listed in Table 4 above will be rejected by the module while in the approved mode, the required table defined in SP800-140B for Non-Approved Services is missing from this document. Software/Firmware security Integrity techniques The module is provided in the form of binary executable code. To ensure the software security, the module is protected by RSA 2048 bits with SHA2-512 (RSA and SHA2-512 Cert. #A2952 and #A3376) algorithm. The software integrity test key (non-SSP) was preloaded to the module’s binary by/at the factory and used for software integrity test only at the pre-operational self-test. At crypto module library initialization, the signature is recalculated and compared to the hardcoded build-time generated signature value. If at load time the signature does not match, the crypto module library exits with error. If failure occurs during self-test, all crypto functionality is disabled. Integrity test on-demand Integrity test is performed as part of the pre-operational self-test. It is automatically executed at power-on. The operator can power cycle or reboot the tested platform to initiate the software integrity test on-demand.

Operational environment 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 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. Physical security The FIPS 140-3 physical security requirements do not apply to the Module since it is a software Non-invasive security 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. Sensitive security parameters management The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. N/A DiffieHellman by SP80090Arev1 MODP2048 KAS-FFCSSC; N/A N/A N/A DiffieHellman

DiffieHellman Peer DiffieHellman MODP2048 MODP2048 KAS-FFCSSC; (SP80056Arev3) N/A DiffieHellman MODP2048 EC DiffieHellman and P521 EC DiffieHellman and P521 N/A DiffieHellman N/A DiffieHellman EC DiffieHellman (SP80056Arev3) N/A N/A N/A EC DiffieHellman

DiffieHellman and P521 N/A EC DiffieHellman and P521 and P521 and P521 N/A EC DiffieHellman N/A N/A N/A N/A N/A

HMAC-SHA2256; HMAC-SHA2384; N/A N/A N/A N/A N/A

N/A N/A HMAC-SHA2256; HMAC-SHA2384; HMAC-SHA2521; N/A N/A N/A Table 8 SSPs

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: When operated in approved mode. 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 pre-operational self-tests. The operating system is responsible for the initialization process and loading of the library. 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 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 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 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. Below are the details of the self-tests conducted by the module. Pre-Operational Self-Tests: Pre-operational software integrity test

• RSA 2048 bits with SHA2-512 SigVer KAT
• Software Integrity Test (RSA 2048 bits with SHA2-512)
• Pre-operational Bypass test 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: 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

o o o o o o o o o o

• HMAC-SHA2-256 KAT HMAC-SHA2-384 KAT HMAC-SHA2-512 KAT KAS-ECC-SSC Primitive Z KAT KAS-FFC-SSC Primitive Z KAT RSA 2048 bits with SHA2-512 SigGen KAT RSA 2048 bits with SHA2-512 SigVer KAT SHA-1 KAT KDF IKEv2 KAT KDF SSH KAT TLS v1.2 KDF RFC7627 KAT
• Conditional pair-wise consistency tests (PCTs):
• RSA PCT
• ECDSA PCT
• KAS-ECC PCT
• KAS-FFC PCT
• Conditional bypass test
• Conditional bypass test Periodic/On-Demand Self-Tests 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. 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.

Secure operations The module meets all the Level 1 requirements for FIPS 140-3. The validated Module’s package asav9-16-4.zip (for VMware ESXi system), or asav9-16-4.qcow2 (for NFVIS system) is the only allowable software image running on the respective tested platform listed in Table 2 above while in the approved mode. The Crypto Officer must configure and enforce the following initialization steps: Step 1: Install AES licenses to require the module to use AES (for data traffic and SSH). Step 2: Issue “fips enable” to allow the module to internally enforce approved compliant services. (config)# fips enable Step 3: Disable password recovery. (config)#no service password-recovery Step 4: Set the configuration register to bypass ROMMON prompt at boot.

(config)# config-register 0x10011 Step 5: Configure the TLS protocol when using HTTPS to protect administrative functions. Due to known issues relating to the use of TLS with certain versions of the Java plugin, we require that you upgrade to JRE 1.5.0_05 or later. The following configuration settings are known to work when launching ASDM in a TLS-only environment with JRE 1.5.0_05: a. Configure the device to allow only TLSv1.2 packets using the following command: (config)# ssl server-version tlsv2-only (config)# ssl client-version tlsv2-only b. Check TLS v1.2.0 in both the web browser and JRE security settings. Step 6: Configure the module to use SSHv2. Note that all operators must still authenticate after remote access is granted. (config)# ssh version 2 Step 7: Configure the module such that any remote connections via Telnet are secured through IPSec. Step 8: Configure the module such that only approved algorithms are used for IPSec tunnels. Step 9: Configure the IPSec/IKE secure tunnel, including the Access-list (ACL) which classifies the data transferred through the data path to be cryptographic processed or be in Bypass capability. Step 10: Configure the module such that error messages can only be viewed by a Crypto Officer. Step 11: Disable the TFTP server. Step 12: Disable HTTP for performing system management in approved mode of operation. HTTPS with TLS should always be used for Web-based management. Step 13. Save the configuration. Step 14: Reboot the Module.

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 does not support any mitigation of other attacks services.

Referenced URLs

• https://www.cisco.com/c/dam/global/da_dk/assets/training/seminaria-materials/enterprise_network_compute_system_encs_.pdf