Cisco FIPS Object Module

Certificate

Approved Algorithms (78)

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

flowchart LR
  %% Deterministic review-risk graph for Cisco FIPS Object 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/>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/>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["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 Cisco FIPS Object 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/>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/>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,C3,C5,C6 clueLow;

Security Policy, page by page

Cisco Systems, Inc. For Cisco FIPS Object Module Last Updated: July 30, 2024, Version 1.3 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Object Module”, firmware version 7.3a by Cisco Systems, Inc. (hereinafter referred to as FOM or module). This Security Policy is provided in accordance with ISO/IEC 19790 Annex B, FIPS 140-3, and NIST SP800-140B. This Security Policy was prepared as part of the Level 1 FIPS The following table lists the level of validation for each area in the FIPS PUB 140-3. Table 1 - Security Levels The Cisco FIPS Object Module (FOM) cryptographic module is a hybrid firmware cryptographic library in a multi-chip standalone embodiment that allows for a vast array of Cisco's networking and collaboration products to use approved algorithms. The module is intended to run on the tested platforms listed in Table 2 and on other various host platforms, so the physical perimeter of the module is the tested platforms. The cryptographic module comprises Cisco’s FIPS Object Module (FOM) cryptographic module (Firmware Version: 7.3a) and the processors (only for algorithm acceleration) and only operates in the approved mode of operation. The module is validated according to FIPS 140-3 at overall security level 1. Please refer to Table 1 above for the individual areas. The cryptographic module provides the cipher operations and Key Derivation functions to support the following protocols: IKEv2/IPSec, sRTP, SSH, TLS and SNMPv3. Full implementations of these protocols are not supported by the module. The module has been tested on the following Operational Environments.

Table 2 - Tested Operational Environments 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. 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. By design, the module is only able to support approved mode of operations following the steps in Section 11 of this document. The module doesn’t claim the implementation of a degraded mode The table below lists all Approved security functions of the module, including specific key size(s) - in bits otherwise noted - employed for approved services, and implemented modes of operation. Only the algorithms, modes, and key sizes that are implemented by the module are shown in this table.

Table 4 - Approved Algorithms Notes: • The module’s AES-GCM implementation conforms to FIPS 140-3 IG C.H techniques 1,

• No parts of any protocols, other than the KDFs, have been tested by the CAVP and CMVP

• In accordance with SP 800-132 PBKDF iteration count runs 10-1000 Increment 1. Further in keeping with IG D.N. module used option 1a HMAC with various SHAs
• In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation as per scenario 1 of section 4 in SP800-133rev2. The resulting generated symmetric key and the seed used in the asymmetric key generation are 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 SP800-140B for the following categories are missing from this document:
• Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation
• Non-Approved Algorithms Allowed in the Approved Mode of Operation Cryptographic boundary The FOM cryptographic module (red dash box) is a non-modifiable, multi-chip standalone hybrid firmware cryptographic module providing cryptographic support which takes data in and out from the host application via the API. All processing is done on the listed processors in Table

2 above. The FOM performs no communications other than with the consuming application. 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 FOM (red dash box) and its interfaces with the operational environment. Tested Platform TOEPP

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 and physical interfaces provided by the module are mapped onto the FIPS 140-3 Table 5 - Ports and Interfaces

Service

Description

Approved Security Functions

Keys and/or SSPs

Roles

Access Rights to Keys

Indicator

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 The table 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 (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 = Zeroise: The module zeroises the SSP. N/A = The service does not access any SSP during its operation. Along with the global indicator, the return code obtained by `echo $?` can be used to determine whether the last command was successful or not. (0 = successful; anything else = unsuccessful).

Integrity Techniques The module is provided in the form of binary executable code. To ensure security, the module is protected by HMAC SHA-1 (HMAC Cert. #A4446) algorithm. The firmware integrity test key (Not an 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 SHA-1 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. The module does not support firmware loading. Integrity Test On-Demand

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.

The module is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The cryptographic 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 module’s firmware version running on each tested platform is 7.3a.

Per FIPS 140-3 classification, this is a multi-chip standalone cryptographic module. Cisco FIPS Object Module (v7.3a) is a hybrid firmware module, which runs on a production grade chassis.

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.

The module uses approved DRBG for the generation of random strings and passes them to the calling application only upon their request. The cryptographic module is passed a pointer to the cryptographic keys as API parameters, associated by memory location. The application calling does not perform storage of keys. All SSPs can be zeroized by power cycling the host. Note 1: Use of external IV with GCM is exclusively permitted for decryption operations or where the GCM is used to support the protocol specific implementation used to protect Note 2: The check for Key_1 ≠ Key_2 is done before using the keys in the XTS-AES algorithm Note 3: No parts of SSH, TLS, SNMPv3, sRTP and IKE protocols, other than the KDFs, have been tested by the CAVP and CMVP. 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 module. Prior to the module 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 self-test success or failure messages were logged, which functions 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. The module has one error state, called Hard error state. When a self-test fails, the module outputs “POST Failed” error. 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 selftests 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

• Firmware Integrity Test (HMAC-SHA-1) The module conducts HMAC-SHA-1 KAT self-test before the integrity test is performed. Conditional Self-Test
• Conditional Cryptographic Algorithm Self-Tests (CASTs)
• AES-ECB 128-bit Encrypt KAT
• AES-ECB 128-bit Decrypt KAT
• AES-CCM 128-bit Encrypt KAT
• AES-CCM 128-bit Decrypt KAT
• AES-CCM 192-bit Encrypt KAT
• AES-CCM 192-bit Decrypt KAT
• AES-GCM 256-bit Encrypt KAT
• AES-GCM 256-bit Decrypt KAT
• AES-CMAC 128-bit Encrypt KAT
• AES-CMAC 128-bit Decrypt KAT
• AES-CMAC 192-bit Encrypt KAT
• AES-CMAC 192-bit Decrypt KAT
• AES-CMAC 256-bit Encrypt KAT
• AES-CMAC 256-bit Decrypt KAT
• AES-XTS 128-bit Encrypt KAT
• AES-XTS 128-bit Decrypt KAT
• AES-XTS 256-bit Encrypt KAT
• AES-XTS 256-bit Decrypt KAT
• DRBG AES CTR 128-bit KAT (Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG AES CTR 192-bit KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG AES CTR 256-bit KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA-1KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA-224 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA-256 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA-384 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA-512 KAT(Health Tests: Generate, Reseed, Instantiate

functions per Section 11.3 of SP 800-90Arev1) o    DRBG Hash SHA-1 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1) o    DRBG Hash SHA-224 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1) o    DRBG Hash SHA-256 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1) o    DRBG Hash SHA-384 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1) o    DRBG Hash SHA-512 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1) o    FIPS 186-4 DSA 2048-bit Sign KAT o    FIPS 186-4 DSA 2048-bit Verify KAT o    FIPS 186-4 ECDSA P-256 Sign KAT o    FIPS 186-4 ECDSA P-256 Verify KAT o    FIPS 186-4 RSA 2048-bit Sign KAT o    FIPS 186-4 RSA 2048-bit Verify KAT o    RSA IFC 2048-bit Encrypt KAT o    RSA IFC 2048-bit Decrypt KAT o    SHA-1 KAT o    SHA3-256 KAT o    HMAC-SHA-1 KAT o    HMAC-SHA-224 KAT o    HMAC-SHA-256 KAT o    HMAC-SHA-384 KAT o    HMAC-SHA-512 KAT o    KAS-ECC-SSC Primitive Z KAT o    KAS-ECC-SSC Primitive Z KAT o    SP800-108 KDF (KBKDF) o    SP800-56Crev1 One Step KDF KAT o    SP800-56Crev1 HKDF KAT o    SP800-132 PBKDF KAT o    TLS 1.3 KDF KAT o    SP800-135rev1 KDF KAT  SSHv2  SNMPv3  sRTP  TLS1.2  IKEv2 Conditional Pair-Wise Consistency Test (PCTs): • RSA PCT. • ECDSA PCT • ECDH PCT

• DH PCT
• DSA PCT FIPS_mode_set() is a function that checks the initialization sequence and the aforementioned selftests have completed successfully. 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 through power cycling the host. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.

Secure Operation The tested operating systems segregate user processes into separate process spaces. Each process space is an independent virtual memory area that is logically separated from all other processes by the operating system software and hardware. The module functions entirely within the process space of the process that invokes it. The module operates only in approved mode of operation. There is no non-approved mode of operation for the module. Secure Initialization The Operating System loads the module into its user space. The initialization sequence starts with a check of the integrity of the runtime executable using a HMAC-SHA1 digest computed at build time. If this computed HMAC-SHA1 digest matches the stored known digest then the POSTs, consisting of the algorithm specific Known Answer Tests, are performed. If any component of the POST fails an internal global error flag is set to prevent subsequent invocation of any cryptographic function calls. Any such POST failure is a hard error that can only be recovered by reinstalling the module. Upon loading the cryptographic module, the consuming application must enable the approved mode of operation by calling the “FIPS_mode_set()” function. This function call verifies the POST outcome and returns a “1” for success and “0” for failure; interpretation of this return code is the responsibility of the host application. The function call “. /openssl version -a” returns the name, version of the module and approved mode status. The module is installed using one of the sets of instructions in the ‘README.Cisco’ document appropriate to the target system available in the repository with the source code. The module does not support Non-Compliant state. User Guidance AES GCM IV Generation

In the case of AES-GCM, the IV generation method is user-selectable, and the value can be computed in more than one manner as follows:

1. TLS 1.2: The module’s AES-GCM implementation conforms to IG C.H, scenario #1, following RFC 5288. 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 accordance with RFC 5246 for TLS 1.2, respectively. The module supports ciphersuites acceptable per SP 800-52rev2.
2. IKEv2: The module’s AES-GCM implementations conforms to IG C.H, scenario #1 following RFC 7296 for IPSec/IKEv2. The AES GCM IV is generated according to RFC5282. 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.
3. TLS 1.3: The module’s AES-GCM implementations conforms to IG C.H Scenario#5. The module is compatible with TLS v1.3 and provides support for the acceptable GCM cipher suites from Section 8.4 of RFC 8446 and confirms that the IV is generated and used within the protocol’s implementation. The counter portion of the IV is set by the module within its cryptographic boundary. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption must be established.
4. Non-protocol specific usage: The module’s AES-GCM implementation conforms to IG C.H, scenario #3, when operating in an approved mode of operation, AES GCM, IVs are generated both internally and deterministically and are a minimum of 96-bits in length, which contain a nonce of 32-bits as specified in SP 800-38D, Section 8.2.1. The selection of the IV construction method is the responsibility of the user of this cryptographic module. Counter mechanism set during IV initialization. When it gets to 95% the protocol gets notified. At 100% the connection is blocked. AES GCM encryption is used in the context of the TLS protocol versions 1.2 and 1.3. To meet the AES GCM (key/IV) pair uniqueness requirements from NIST SP 800-38D, the module generates the IV as follows: For TLS v1.2, the module supports acceptable AES GCM cipher suites from section 3.3.1 of NIST SP 800-52rev2. Per scenario 1 in FIPS 140-3 IG C.H, the mechanism for IV generation is compliant with RFC 5288. The implementation of the nonce_explicit management logic inside the module shall ensure that when the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key (e.g., a 64-bit counter starting from 0 and increasing, when it reaches the maximum value of 264 -1), either party (the client or the server) that encounters this: • module operator (i.e., the first party, client, or server) to trigger this handshake in accordance with RFC 5246 when this condition is encountered.

The module supports internal IV generation using the module’s Approved DRBG. The IV is at least 96 bits in length per section 8.2.2 of NIST SP 800-38D. Per NIST SP 800-38D and scenario

5 of FIPS 140-3 IG C.H, the DRBG generates outputs such that the (key/IV) pair collision

probability is less than 2-32. In the event that power to the module is lost and subsequently restored, the calling application must ensure that any AES-GCM keys used for encryption or decryption are re-distributed. PBKDF In line with the requirements for SP 800-132, keys generated using the approved PBKDF must only be used for storage applications. Any other use of the approved PBKDF is non-conformant. In approved mode the module enforces that any password used must encode to at least 14 bytes (112 bits) and that the salt is at least 16 bytes (128 bits) long. The iteration count associated with the PBKDF should be as large as practical. As the module is a general-purpose hybrid firmware module, it is not possible to anticipate all the levels of use for the PBKDF, however a user of the module should also note that a password should at least contain enough entropy to be unguessable and also contain enough entropy to reflect the security strength required for the key being generated. The module uses PBKDF option 1a from section 5.4 of NIST SP 800-132. • The iteration count shall be selected as large as possible, as long as the time required to generate the resultant key is acceptable for module operators. The iteration count shall be

• The length of the passphrase used in the PBKDF shall be 14 up to 128, and shall consist of lower-case, upper-case, and numeric characters.
• Passphrases (used as an input for the PBKDF) shall not be used as cryptographic keys. AES-XTS The length of a single data unit encrypted or decrypted with the AES-XTS shall not exceed 2²⁰ AES blocks; that is, 16 MB of data per AES-XTS instance. An XTS instance is defined in Section 4 of NIST SP 800-38E. The AES-XTS mode shall only be used for the cryptographic protection of data on storage devices. The AES-XTS shall not be used for other purposes, such as the encryption of data in transit. The module implements the check to ensure that the two AES keys used in the XTS-AES algorithm are not identical.

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.