CiscoSSL FIPS Provider

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for CiscoSSL FIPS Provider
  %% 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["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</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/>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 CiscoSSL FIPS Provider
  %% 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["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</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/>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 CiscoSSL FIPS Provider Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

FIPS Provider, firmware version 8.0. This Security Policy is provided in accordance with ISO/IEC 19790 Annex B, FIPS 140-3, and SP 800-140B. This Security Policy was prepared as part of the Level 1 FIPS 140-3 validation of the CiscoSSL FIPS provider, and the module meets the overall Level 1 requirements. The following table lists the level of validation for each area in the FIPS PUB 140-3.

Purpose and Use: The CiscoSSL FIPS Provider is a firmware library that provides cryptographic services to a vast array of Cisco's networking and collaboration products. The cryptographic module provides the cipher operations and Key Derivation functions to support the following protocols: IKEv2/IPSec, sRTP, SSH, TLS, SNMPv3, ANS X9.42, and ANS X.9.63. Full implementations of these protocols are not supported by the module. No parts of the protocols, other than the KDF, have been tested by the CAVP or CMVP. The tested module version is 8.0. The overall security level is 1. The object code in the object module file is incorporated into the runtime executable application at the time the binary executable is generated. The module is provided in an executable form

(as fips.so shared object). The module performs no communications other than with the consuming host application (the process that invokes the module services via the module’s API), which can be considered as the host for the module. Module Type: Firmware Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The cryptographic boundary of the module is the CiscoSSL FIPS Provider, a dynamically loadable library. The module is comprised of a single object module file called fips.so. The module performs no communication other than with the calling application via APIs that invoke the module. Tested Operational Environment’s Physical Perimeter (TOEPP): The module’s TOEPP is the physical perimeter of the tested platforms listed in Table “Tested Operational Environments - Software, Firmware, Hybrid” below. The components of the TOEPP include: Hardware components [Cisco UCS, Storage, RAM, Network Interface Cards]. The module’s block diagram is shown in Figure 1 below. The dashed orange border in the figure denotes the cryptographic boundary of the module. The green border denotes the TOEPP of the module. TOEPP Figure 1: Block Diagram

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) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A N/A Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

There are no components excluded from the module.

Modes List and Description: Table 5: Modes List and Description The module supports both approved and non-approved modes of operation. The module will only enter the approved mode if the module is reloaded and the call to SELF_TEST_post() succeeds, and only approved services are invoked. The module enters non-approved mode when a non-approved service is invoked. Mode Change Instructions and Status: When a non-approved service is invoked while in approved mode of operation, the module implicitly transitions to a non-approved mode. Similarly, when a call to an approved service is made while in non-approved mode of operation, the module transitions to approved mode of operation. The mode can be identified by the indicator, as listed in the table “Modes List and Description” above.

Table 6: Approved Algorithms - PAA Non-PAA

Table 7: Approved Algorithms - Non-PAA The module implements the cryptographic algorithms listed in the above tables. The module also supports RSA KeyGen, SigGen and SigVer with modulus size greater than 4096, where CAVP testing is not available. Vendor-Affirmed Algorithms:

Table 8: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. There are no non-approved and allowed algorithms, hence the table is excluded. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. There are no algorithms that are non-approved but allowed with no security claimed, hence the table is excluded. Non-Approved, Not Allowed Algorithms: Table 9: Non-Approved, Not Allowed Algorithms

D.G). Table 10: Security Function Implementations

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 module is compatible with TLS 1.2 protocol and provides the primitives to support the AES GCM cipher suites from SP 800-52 rev1 Section 3.3.1. 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.
2. IKEv2: The module’s AES-GCM implementation 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 implementation 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 approved mode of operation, AES GCM, IVs are generated both internally and deterministically and are a minimum of 96-bits in length 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. Note: Externally generated IVs are not allowed for AES-GCM encryption. PBKDF In line with the requirements of SP 800-132 and FIPS 140-3 IG D.N, keys generated using the approved PBKDF must only be used for storage applications. The algorithm uses option 1a as specified in SP 800-132 Section 5.4. 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 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 contain enough entropy to reflect the security strength required for the key being generated. AES-XTS

In line with the requirements of SP 800-38E and FIPS 140-3 IG C.I, the keys are generated independently according to Section 6.3 of SP 800-133 rev2 and verification of the keys (key1 ≠ key2) is performed before using them in the AES-XTS algorithm. Key Agreement The module implements the following CAVP tested key agreement methods: SP 800-56A rev3 KAS-ECC-SSC (FIPS 140-3 IG D.F Scenario 2 path

1. SP 800-56A rev3 KAS-FFC-SSC (FIPS 140-3 IG D.F Scenario 2 path
2. SP 800-56B rev2 KAS-IFC-SSC (FIPS 140-3 IG D.F Scenario 1 path
3. SHA3 and SHAKE Per FIPS 140-3 IG C.C, all SHA3 and SHAKE functions are tested on all the operational environments. The higher-level algorithms using SHA3 (HMAC-SHA3) are also tested on all the operational environments. RSA Per FIPS 140-3 IG C.F, RSA SigGen is tested with 2048, 3072, 4096-bit modulus and RSA SigVer is tested with 1024, 2048, 3072, 4096-bit modulus. The module also supports RSA KeyGen, SigGen and SigVer with modulus size greater than 4096, for which CAVP testing is not available. Legacy use algorithms Per SP 800-131A rev2, TDES-CBC/TDES-ECB Decrypt, TDES-CMAC Verification, DSA/ECDSA/RSA SigVer using SHA-1 is allowed for legacy use.

N/A for this module. Table 11: Entropy Sources N/A for this module. The module passively receives entropy from outside the boundary. The caveat “No assurance of the minimum strength of generated SSPs (e.g., keys)” applies to this module. Applications shall use entropy sources that meet the security strength required for the random number generation mechanism as shown in [SP 800-90A rev1] Table 2 (Hash_DRBG, HMAC_DRBG, CTR_DRBG). A minimum of 112-bits of entropy must be supplied. This entropy

is supplied by means of callback functions. Those functions must return an error if the minimum entropy strength cannot be met.

The module generates symmetric and asymmetric keys following the sections of SP 800-133 rev2 as specified in Table “Vendor-Affirmed Algorithms” above. Private and secret keys as well as seeds and entropy input are provided to the module by the calling application and are destroyed when released by the appropriate API function calls. Keys residing in internally allocated data structures (during the lifetime of an API call) can only be accessed using the module defined API. The operating system protects application space from unauthorized access. Only the calling application that creates or imports keys can use or export such keys. All API functions (Module Services) are executed by the calling application invoking an API. Each API either succeeds or fails and is logically non-interruptible from the point of view of the calling application. The module supports generation of ECDSA, RSA, DSA, EC Diffie-Hellman and Diffie-Hellman key pairs per Section 5 in SP 800-133 rev2. The output of SP 800-90A rev1 random bit generator is used for generating the seed used in asymmetric key generation. The module also complies with Sections 6.1 and 6.2 of SP 800-133 rev2.

The module implements key agreement methods per FIPS 140-3 IG D.F and key transport methods per FIPS 140-3 IG D.G (SP 800-38F AES-KW and AES-KWP, SP 800-56B rev2 KTSIFC). Detailed information is provided in Table “Security Function Implementations” Section above.

In reference to FIPS 140-3 IG D.C, the module implements the KDFs of SSH, TLS, IKE, SRTP, SNMP, ANS X9.42 and ANS X9.63 but no parts of the protocols other than the approved cryptographic algorithms and the KDFs have been tested by the CAVP and CMVP.

Table 12: Ports and Interfaces

The logical interface is a C-language application program interface (API). The Data Input interface consists of the input parameters of the API functions. The Data Output interface consists of the output parameters of the API functions. The Control Input interface consists of the actual API functions. The Status Output interface includes the return values of the API

Please note that the module does not support a control output interface and is not applicable for this module.

N/A for this module. The module does not implement authentication mechanisms and does not allow concurrent operators.

Table 13: Roles The module meets all FIPS 140-3 level 1 requirements for Roles. The Module implements both a User Role (User) as well as the Crypto Officer (CO) role. The User and Crypto Officer roles are implicitly assumed by the application accessing services implemented by the Module.

n) Table 14: Approved Services The module meets all FIPS 140-3 level 1 requirements for Services. The initialization process is described in the Secure Distribution, Operation, and User Guidance section of this document. CO services with associated input and output are listed in the above table. All the services provided by the module can be accessed by both the User and the Crypto Officer roles. The User Role (User) can load the module and call any of the API functions. The Crypto Officer Role (CO) is responsible for installation of the module on the host computer system and calling of any API functions.

Table 15: Non-Approved Services The module implements non-approved services mentioned in the above table. For these specific services, the service indicators ‘3, ED25519, ED448, X25519, X448’ indicates that the service is non-approved.

Not Applicable for this module.

The module runs a HMAC SHA2-256 integrity verification on the shared object file (fips.so) during initialization by the host application. The module also runs the self-test for HMAC SHA2-

The operator can initiate on-demand integrity test by calling SELF_TEST_post() or rebooting the host platform.

The public verification key used for firmware integrity test is not an SSP.

Type of Operational Environment: Non-Modifiable

How Requirements are Satisfied: The module was tested on the platforms listed in Table 2 for the purposes of this FIPS 140-3 validation. The module is expected to execute correctly on any production grade CPU with commonly used operating system. No operational environment restrictions are required for operation in the approved mode. CiscoSSL FIPS Provider is a Firmware module and classified as a non-modifiable OE. The requirements under ISO/IEC 19790, section 7.6 “Operational environment”, are met by the module for Level 1 firmware requirements.

Not Applicable for this module.

Not Applicable for this module.

Table 16: Storage Areas The module stores DRBG state values for the lifetime of the DRBG instance. The module uses CSPs passed in by the calling application on the stack. The module does not store any CSP persistently (beyond the lifetime of an API call), except for DRBG state values used for the module’s default key generation service. The module implements SP 800-90A rev1 compliant DRBG services for creation of symmetric keys, and for generation of DSA, elliptic curve, and RSA keys as shown in Table 4. The calling application is responsible for storage of generated keys returned by the module.

Table 17: SSP Input-Output Methods

All CSPs enter the module’s boundary in plaintext as API parameters, associated by memory location. However, none crosses the physical parameter. The module does not output CSPs, other than as explicit results of key generation services or keys passed into the module by the calling application.

Table 18: SSP Zeroization Methods Zeroization of sensitive data is performed automatically by API function calls for temporarily stored CSPs. The calling application is responsible for parameters passed in and out of the module. Successful completion of the zeroization service is determined by clean execution of OPENSSL_cleanse() without any errors being returned or a successful reboot of the host platform. s

Table 21: Pre-Operational Self-Tests (CASTs) before it is operational. The module is single threaded and will not return to the calling application until the CASTs are complete. If the self-tests fail, the module goes to an error state and subsequent calls to the module will fail and thus no further cryptographic operations are possible. The CO can clear the error state by restarting the host platform.

d n n n n Table 22: Conditional Self-Tests The SELF_TEST_post() function performs all self-tests listed above with no operator intervention required when the module loads. The module returns a “1” if all self-tests succeed, and a “0” otherwise. The pre-operational and conditional self-tests may also be performed ondemand by calling this function and interpretation of the return code is the responsibility of the calling application. Table 23: Pre-Operational Periodic Information

Table 24: Conditional Periodic Information

Table 25: Error States If any self-test fails, an internal flag is set to prevent subsequent invocation of any cryptographic function calls. The module will only enter the Approved mode if the module is reloaded and the call to SELF_TEST_post() succeeds. The CAST used to perform the approved integrity technique is passed before the execution of the pre-operational firmware integrity test (HMACSHA2-256).

The operator can initiate the self-tests by calling SELF_TEST_post() or rebooting the host platform.

Per FIPS 140-3 classification, this is a multi-chip standalone cryptographic module. CiscoSSL FIPS Provider 8.0 is a C language-based firmware module that runs on production grade chassis. A complete revision history of the source code is collaborated by Bitbucket, and version controlled by Git. Code changes are tracked by commits tied to a username. All User

documents are tracked in Cisco Document Central which requires username/password and access permission. Coverity runs static analysis on the source code before committing to the secure repository. Secure Distribution The module is distributed only for use by Cisco personnel and as such is accessible only from the secure Cisco internal repository. Only authorized Cisco personnel have access to the module. The SHA512 fingerprint of the validated distribution tarball file can be obtained by contacting Cisco. Secure Initialization The module is ready to use after extracting it from the distribution tarball. 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-SHA2-256 digest computed at build time. If the computed HMAC-SHA2-256 digest matches the stored known digest, then the cryptographic algorithm self-tests are performed. If any self-test fails, an internal global error flag is set to prevent subsequent invocation of any cryptographic function calls. Any such failure is a hard error that can only be recovered by reloading the module. Upon encountering a failure, the module will return an integer of 0. The module will only enter the Approved mode if the module is reloaded and the call to SELF_TEST_post() succeeds. The function call “. /openssl list providers” returns the name and the version of the module. 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 firmware and hardware. The module functions entirely within the process space of the process that invokes it. Additional information on switching between approved and non-approved mode is provided under “Mode Change Instructions and Status” in Section 2.4 of this SP.

An additional guidance document, if required, can be obtained by contacting Cisco Systems, Inc. using the information posted on the validation certificate.

Not Applicable for this module.

If CTR_DRBG is used, then the caller shall ensure that the derivation function is enabled.

The module implements two mitigations against timing-based side-channel attacks, namely Constant time Implementations and Blinding.

Constant-time Implementations protect cryptographic implementations in the Module against timing analysis since such attacks exploit differences in execution time depending on the cryptographic operation, and constant-time implementations ensure that the variations in execution time cannot be traced back to the key, CSP or secret data. Numeric Blinding protects the RSA, DSA and ECDSA algorithms from timing attacks. These algorithms are vulnerable to such attacks since attackers can measure the time of signature operations or RSA decryption. To mitigate this the Module generates a random blinding factor which is provided as an input to the decryption/signature operation and is discarded once the operation has completed and resulted in an output. This makes it difficult for attackers to attempt timing attacks on such operations without the knowledge of the blinding factor and therefore the execution time cannot be correlated to the RSA/DSA/ECDSA key.