IOS Common Cryptographic Module (IC2M)

Certificate

Approved Algorithms (32)

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

flowchart LR
  %% Deterministic review-risk graph for IOS Common Cryptographic Module (IC2M)
  %% 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/>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"]
    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 IOS Common Cryptographic Module (IC2M)
  %% 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/>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 C3,C5,C6 clueLow;

Security Policy, page by page

ISO/IEC 19790 and FIPS 140-3 for IOS Common Cryptographic Module (IC2M) Firmware Version: Rel5b Last Updated: August 6, 2024 Version 1.4 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

(IC2M) with firmware version Rel5b (herein referred to as “IC2Mrel5b” or the “module”). The following details how this module meets the security requirements of FIPS 1 140-3, NIST 2 SP 3 800-140, and ISO4/IEC5 19790 for a Security Level 1 Firmware cryptographic module. The security requirements cover areas related to the design and implementation of a cryptographic module. Table 1 below indicates the security level for each area of the module. Table 1 - Security Levels The overall security level of the module is 1. FIPS

• Federal Information Processing Standards NIST
• National Institute of Standards and Technology SP
• Special Publication ISO
• International Organization of Standardization IEC
• International Electrotechnical Commission © Cisco Systems, Inc. 4

IC2Mrel5b is a single binary object file (sub_crypto_ic2m_k9.o) and is classified as a multi-chip standalone firmware module. IC2Mrel5b is a cryptographic library that supports cryptographic operations executed by a calling application. The calling application leverages the module’s well-defined API6 to initialize the module and call cryptographic algorithms for encryption/decryption, key generation, signature generation/verification, and hashing. The cryptographic library does not implement any protocols, but does provide the cryptographic primitives for IPsec7/IKE8v2, SNMP9v3, SRTP10, SSH11v2, and TLS12 v1.2/v1.3. No SSP13s are stored within the cryptographic boundary of the module. The module is intended for use on any Cisco device that runs the IOS-XE OS14, so the physical perimeter of the module is the testing platform. The module’s operational environment is non-modifiable. Table 2 below lists the tested operational environments. Table 2

• Tested Operational Environments Table 3 below lists vendor affirmed operational environments. Table 3 - Vendor Affirmed Operational Environments APIs
• Application Programming Interface IPsec
• IP Security IKE
• Internet Key Exchange SNMP
• Simple Network Management Protocol SRTP
• Secure Real-time Transport Protocol SSH
• Secure Shell TLS
• Transport Layer Security SSP
• Sensitive Security Parameters N/A
• Not Applicable

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 supports both approved and non-approved mode of operation. The module will be in approved mode when all pre-operational self-tests have completed successfully and only approved algorithms/services are invoked. Table 4 and Table 7 below for a list of the supported approved/allowed algorithms/services. The non-approved mode is entered when a non-approved algorithm/non-approved service is invoked. See Table 5 and Table 9 below for a list of non-approved algorithms/non-approved services. The Approved mode of operation can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 9 - Non-Approved Services. The following tables list 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. Table 4 - Approved Algorithms

17 19

CAVP

• Cryptographic Algorithm Validation Program PUB - Publication CBC
• Cipher-Block Chaining CFB
• Cipher Feedback ECB
• Electronic Codebook CMAC
• Cipher-based Message Authentication Code GCM
• Galois Counter Mode GMAC
• Galois Message Authentication Code KW
• Key Wrap © Cisco Systems, Inc. 6

RSA

• Rivest, Shamir, and Adleman SSC
• Shared Secret Computation ECC
• Elliptic Curve Cryptography FFC
• Finite Field Cryptography DH
• Diffie-Hellman © Cisco Systems, Inc. 7

NOTES:

• There are algorithms, modes, and key moduli sizes that have been CAVP-tested but are not used by any approved services of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in the tables above are used by an approved service of the module.
• The module supports generation of ECDSA, RSA, ECDH34, and DH asymmetric key pairs in accordance with NIST SP 800-133r2, section 5. The module supports generation of AES and DRBG
• Deterministic Random Bit Generator CTR - Counter © Cisco Systems, Inc. 8

• No parts of IPsec/IKEv2, SNMPv3, SRTP SSH, and TLS protocols, other than the KDFs, have been tested by the CAVP and CMVP. Table 5 below lists all non-Approved algorithms not allowed in the approved mode of operation implemented by the module. Table 5
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation In addition, the module does not implement Non-Approved Algorithms Allowed in Approved Mode of Operation and Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed. Cryptographic Boundary Figure 1 below depicts the cryptographic boundary (red dashed line) and physical perimeter (solid red line). The cryptographic boundary is defined as the cryptographic library. The physical perimeter is the Tested Operational Environment’s Physical Perimeter (TOEPP) on which the module runs. IC2M Crypto Module Calling Application API Cryptographic Algorithms Operating System Figure 1
• Module’s boundary

The module’s physical perimeter encompasses the case of the tested platform mentioned in section 2 above. No data passes in or out of these physical ports. The module provides logical interfaces via welldefined APIs. The logical interfaces provided by the module are mapped to the following FIPS 140-3 interfaces: © Cisco Systems, Inc. 9

Table 6 below provides a description of data that passes through each logical interface. Table 6 – Ports and Interfaces

The module supports the CO35 role. The module does not provide any authentication methods. The module does not allow concurrent operators. The CO role is implicitly assumed based on the service requested. The module provides the services in Table 8 below to the CO. Table 7 below provides roles, service commands, input, and output for the module. CO – Crypto Officer © Cisco Systems, Inc. 10

Table 8 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.
• 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. Table 8 - Approved Services © Cisco Systems, Inc. 11

Table 9 below lists non-Approved services supported by the module. Table 9 - Non-Approved Services

Integrity techniques The IC2Mrel5b cryptographic module is a binary file (sub_crypto_ic2m_k9.o) statically linked within the IOS-XE OS. To ensure firmware security, the module is protected by an HMAC-SHA2-256 (HMAC Cert. #A4354) algorithm. The firmware integrity test key (non-SSP) was preloaded to the module’s binary at the factory and used only for the pre-operational firmware integrity self-test. During initialization of the module, the integrity of the runtime executable is verified using an HMAC-SHA2-256 which is compared to a value computed at build time. If at load time the MAC does not match the stored, known MAC value, the module enters a critical error state where all crypto functionality inhibited. The module must be reloaded to attempt the integrity test again. Integrity test on-demand The 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 integrity test ondemand.

The module is operated in a non-modifiable operational environment per ISO/IEC 19790, section 7.6, level

1 specifications. The module is delivered as part of the IOS-XE OS. The OS is restricted to a single

operator mode of operation (i.e., concurrent operators are explicitly excluded). The application that makes calls to the module is the single user of the module. The module’s firmware version running on each tested platform is Rel5b.

Per ISO/IEC 19790, section 7.7, the module is defined as a multi-chip standalone firmware cryptographic module. The module runs on a host appliance made of production-grade components with standard passivation techniques.

At the time of publication of this Security Policy, non-invasive security is not required for FIPS 140-3 certification (see NIST SP 800-140F). The requirements of this area are not applicable to the module. © Cisco Systems, Inc. 14

Table 10 below provides information for the SSPs that are used by the cryptographic services Table 10 - SSPs © Cisco Systems, Inc. 15

Table 11 below specifies the modules entropy sources. Table 11 - Non-Deterministic Random Number Generation Specification © Cisco Systems, Inc. 17

Random Number Generation The Approved DRBG for random number generation is a NIST SP 800-90Arev1 CTR_DRBG using AES-

256 with derivation function and without prediction resistance. The numbers used for key generation are

all generated by the CTR_DRBG within the module. Per NIST SP 800-90Arev1, section 10.2.1.1, the internal state is the values of V and Key. Refer to Table 4 above for the CAVP certificate of the validated DRBG algorithm. SSP Generation The module generates RSA, ECDSA, ECDH, and DH asymmetric key pairs compliant with FIPS 186-4, using a NIST SP 800-90Arev1 CTR_DRBG for random number generation. In accordance with FIPS 140-

3 IG D.H, the cryptographic module performs CKG for asymmetric keys as per section 5 of NIST SP 800-

133rev2 (vendor affirmed) by obtaining a random bit string directly from an approved DRBG. The random bit string supports the required security strength requested by the calling application (without any V, as described in Additional Comments 2 of IG D.H.). The module generates AES symmetric keys compliant with FIPS PUB 197 and HMAC key compliant with FIPS PUB 198. All symmetric key generation is performed using a NIST SP 800-90Arev1 CRT_DRBG for rando number generation. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs CKG for symmetric keys as per section 6 of NIST SP 800-133rev2. SSP Entry and Output The module does not support manual SSP entry or intermediate key generation output. SSPs are not output through physical ports on the TOEPP. SSPs are input in plaintext form via API from the calling application to the module. SSPs are output in plaintext form from the module to the calling application within TOEPP. Per ISO/IEC 19790, section 7.9.5, the module performs two independent internal actions to prevent the inadvertent output of sensitive information:

1. The module internally requests the random number generation service, confirming it executes successfully.
2. Once keys are generated, the module performs the PCT to verify the keys are correctly generated. Once both actions are successfully completed, the module outputs the SSP to the calling application via the output API. SSP Storage The module does not provide persistent storage of SSPs. SSP storage is performed by the tested platform. Zeroization The module does not possess persistent storage of SSPs. The SSP value only exists in volatile memory of the host appliance and that value vanishes when the module is powered off. The procedure for secure sanitization of the module at the end of life is simply to power off the tested platform. © Cisco Systems, Inc. 18

The module performs Pre-Operational Self-Tests and CASTs 37 before entering an approved mode of operation. The module is single threaded and will not return to the calling application until all self-tests are complete. If any of the pre-operational self-tests or conditional cryptographic algorithm self-tests fail, the module enters a critical error state and sends an error to the OS. The module supports two Error states, critical error state and soft error state. Following is an example of the error message displayed on the console of the host appliance in a critical error state: %CRYPTO-0-SELF_TEST_FAILURE: Encryption self-test failed (<failing test description>) In a critical error state no cryptographic operations are performed and data output is prohibited. The CO can clear the error state by restarting the module. If a PCT fails, the module enters a soft error state, deletes the key, logs an error, and returns to the approved mode of operation. In the approved mode of operation the service may be retried or a new service may be performed. Following is an example of the error message displayed on the console of the host appliance in a soft error state: %CRYPTO-3-RSA_SELFTEST_FAILED: Generated RSA key failed self test If the module fails to retrieve enough entropy, the module enters a soft error state. The module deletes the DRBG value, then reseeds and reinitializes the DRBG. Pre-operational self-tests: Pre-operational firmware integrity test:

• HMAC-SHA2-256 KAT38
• Firmware integrity test (using HMAC-SHA2-256) Conditional self-tests: Conditional cryptographic algorithm tests (CASTs):
• AES ECB (128-bit) Encrypt KAT
• AES ECB (128-bit) Decrypt KAT
• AES-GCM (256-bit) Encrypt KAT
• AES-GCM (256-bit) Decrypt KAT
• AES GMAC (256-bit) KAT
• CTR_DRBG Instantiate KAT
• CTR_DRBG Generate KAT
• CTR_DRBG Reseed KAT Note: DRBG Health Tests as specified in NIST SP 800-90Arev1 Section 11.3 are performed.
• HMAC-SHA2-256 KAT
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-512 KAT CAST - Cryptographic Algorithm Self-Tests KAT
• Known Answer Test © Cisco Systems, Inc. 19

• ECDSA P-256 with SHA2-256 SigGen KAT
• ECDSA P-256 with SHA2-256 SigVer KAT
• RSA 2048-bit modulus with SHA2-256 SigGen KAT
• RSA 2048-bit modulus with SHA2-256 SigVer KAT
• KAS-FFC-SSC (shared secret computation) using MODP-2048 Primitive ‘Z’ KAT
• KAS-ECC-SSC (shared secret computation) using P-256 Primitive ‘Z’ KAT
• KDF IKEv2 KAT
• KDF SNMP KAT
• KDF SRTP KAT
• KDF SSH KAT
• TLSv1.2 KDF with RFC7627 KAT
• TLSv1.3 KDF KAT Conditional pair-wise consistency tests (PCT):
• ECDSA PCT
• RSA PCT Periodic/Self-Tests On-Demand In addition to the automatic execution of self-tests at cryptographic module initialization, the CO can manually initiate self-tests on demand by executing the “test crypto self-test” command through the console of the host appliance. This command calls the “crypto_engine_nist_run_self_tests() function”. Self-tests can be executed on demand by power-cycling the module.

The module meets all the Level 1 requirements for FIPS 140-3. The module is completely and permanently embedded into Host Device IOS-XE OS. There are no installation considerations besides the loading of the IOS-XE OS. The module cannot be modified, replaced, or upgraded except by loading a new Host Device IOS-XE version in its entirety. The module functions entirely within the process space of the process that invokes it, and thus satisfies the FIPS 140-3 requirement for a single user mode of operation. AES-GCM IV: The CO shall consider the following requirements and restrictions when using the module. • The AES-GCM IV is constructed in compliance with IG C.H, scenario 1 (TLS v1.2), scenario 2 (IPsec-v3), and scenario 5 (TLS v1.3). Users should consult IG C.H specific scenarios for all the © Cisco Systems, Inc. 20

requirements using AES-GCM mode. The TLS and IPsec/IKE protocols have not been reviewed or tested by the CAVP and CMVP.

• The AES-GCM IV generation follows RFC 5288 and shall only be used for the TLS protocol v1.2. The counter portion of the IV is set by the module within its cryptographic boundary. The module does not implement the TLS protocol. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values.
• The AES-GCM IV generation follows RFC 4106 and shall only be used for the IPsec-v3 protocol version 3. The counter portion of the IV is set by the module within its cryptographic boundary. The module does not implement the IPsec protocol. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the IPsec protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values.
• The AES-GCM IV generation follows RFC 8446 and shall only be used for the TLS protocol v1.3. The counter portion of the IV is set by the module within its cryptographic boundary. The module does not implement the TLS protocol. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values.
• In these protocols if the module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be re-distributed. This condition is not enforced by the module; however, it is met implicitly. The module does not retain any state when power is lost. The AESGCM key/IVs are not persistently stored during power off: therefore, there is no re-connection possible when the power is restored with re-generation of the key used for AES-GCM. After restoration of the power, the user of the module (e.g., TLS, IKE) along with User application that implements the protocol, must perform a complete new key establishment operation using new random numbers (Entropy input string, DRBG seed, DRBG internal state V and Key, shared secret values that are not retained during power cycle) and subsequent KDF operations to establish a new AES-GCM key/IV pair on either side of the network communication channel.

The module does not support mitigation of other attacks as defined under ISO/IEC 19790, section 7.12. © Cisco Systems, Inc. 21

Appendix A – Acronyms and Terms Table 12 below provides a list of acronyms and terms used throughout this Security Policy. Table 12 - Acronyms and Terms © Cisco Systems, Inc. 22