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 ISO/IEC 24759:2017 Section 6 FIPS 140-3 Section Title Security Level

1 General 1

2 Cryptographic module specification 1

3 Cryptographic module interfaces 1

4 Roles, services, and authentication 1

5 Software/Firmware security 1

6 Operational environment 1

7 Physical security 1

8 Non-invasive security N/A

9 Sensitive security parameter management 1

10 Self-tests 1

11 Life-cycle assurance 1

12 Mitigation of other attacks N/A

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 # Operating Systems Hardware Platform Processor (Acceleration) PAA/Acceleration

1 IOS-XE 17.12 Cisco Aggregated Services Router Intel Xeon E3-1125C v2 N/A15

(ASR) 1001-HX Table 3 below lists vendor affirmed operational environments. Table 3 - Vendor Affirmed Operational Environments # Operating System Hardware Platform

1 IOS-XE 17.12 Catalyst 9200 Series Switches

2 IOS-XE 17.12 Catalyst 9300 Series Switches

3 IOS-XE 17.12 Catalyst 9400 Series Switches

4 IOS-XE 17.12 Catalyst 9500 Series Switches

5 IOS-XE 17.12 Catalyst 9600 Series Switches

6 IOS-XE 17.12 Cisco Embedded Services 3300 Series Switch

7 IOS-XE 17.12 Cisco Embedded Services 9300 Series Switch

8 IOS-XE 17.12 Cisco Catalyst Industrial Ethernet 3000 Series Switch

9 IOS-XE 17.12 Cisco Catalyst Industrial Ethernet 9300 Series Switch

10 IOS-XE 17.12 Cisco C8500, C8500L Series Edge Platforms

11 IOS-XE 17.12 Cisco C8200, C8200L, C8300 Series Edge Platforms

12 IOS-XE 17.12 Cisco Aggregation Services Router (ASR) 1000 series

13 IOS-XE 17.12 Cisco Integrated Services Router (ISR) 4000 series

14 IOS-XE 17.12 Cisco Integrated Services Router (ISR) 1000 series

15 IOS-XE 17.12 Cisco C8000V Edge Software Router

16 IOS-XE 17.12 Cisco IR 1100, 1800, 8100, 8300 Series Industrial Routers

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 OS
• Operating System N/A
• Not Applicable © Cisco Systems, Inc. 5

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 CAVP Description/Key Algorithm/Standard Mode/Method Use/Function Cert Size(s)/Key strength(s)

A4354 AES AES-CBC ; Key Length: 128, 192, 256 Symmetric encryption [FIPS PUB18 197] bits and decryption [NIST SP 800-38A] A4354 AES AES-CFB20128; Key Length: 128, 192, 256 Symmetric encryption [FIPS PUB 197] bits and decryption [NIST SP 800-38A] A4354 AES AES-ECB21 Key Length: 128, 192, 256 Symmetric encryption [FIPS PUB 197] bits and decryption [NIST SP 800-38A] A4354 AES AES-CMAC22 Key Length: 128, 256 bits Authenticated [FIPS PUB 197] symmetric encryption [NIST SP 800-38B] and decryption A4354 AES AES-GCM23 Key Length: 128, 192, 256 Authenticated [FIPS PUB 197] bits symmetric encryption [NIST SP 800-38D] and decryption A4354 AES AES-GMAC24 Key Length: 128 bits Authenticated [FIPS PUB 197] symmetric encryption [NIST SP 800-38D] and decryption A4354 AES AES-KW25 Key Length: 128, 192, 256 Symmetric encryption [NIST SP 800-38F] (encrypt/decrypt) bits and decryption A4354 ECDSA ECDSA KeyGen Curves: P-256, P-384, P- ECDSA keypair [FIPS PUB 186-4] 521 generation CAVP

• Cryptographic Algorithm Validation Program AES
• Advanced Encryption Standard 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

CAVP16 Description/Key Algorithm/Standard Mode/Method Use/Function Cert Size(s)/Key strength(s) A4354 ECDSA ECDSA KeyVer Curves: P-256, P-384, P- ECDSA keypair [FIPS PUB 186-4] 521 verification A4354 ECDSA ECDSA SigGen Curves: P-256, P-384, P- ECDSA signature [FIPS PUB 186-4] 521 generation A4354 ECDSA ECDSA SigVer Curves: P-256, P-384, P- ECDSA signature [FIPS PUB 186-4] 521 verification A4354 RSA26 RSA KeyGen: Modulus: 2048, 3072, 4096 RSA keypair generation [FIPS PUB 186-4] - Mode: B.3.4 - 2048/3072 bits with SHA2-256 A4354 RSA RSA SigGen: Modulus: RSA signature [FIPS PUB 186-4] - PKCSv1.5 2048, 3072, 4096 generation - 2048/3072 bits with SHA2-256/384/512 A4354 RSA RSA SigVer: Modulus: RSA signature [FIPS PUB 186-4] - PKCSv1.5 2048, 3072, 4096 verification - 2048/3072 bits with SHA2-256/384/512 A4354 KAS27-ECC-SSC28 KAS-ECC29-SSC Curves: P-256, P-384, P- Key establishment

[NIST SP 800-56Arev3] Scheme: between 128 and 256 dhEphem: bits of encryption KAS Role: initiator, strength responder A4354 KAS-FFC-SSC KAS-FFC30-SSC MODP-2048, MODP-3072, Key establishment [NIST SP 800-56Arev3] MODP-4096 methodology provides Scheme: between 112 and 152 dhEphem: bits of encryption KAS Role: initiator, strength responder A4354 Safe Primes Key Generation KeyGen for DH31 MODP-2048, MODP-3072, KAS-FFC Keypair [NIST SP 800-56Arev3] (CKG using MODP-4096 domain parameters method in Sections 4 generation and 5.1 of SP 800133rev2) A4354 KDF IKEv2 KDF IKEv2 N/A Key derivation function [NIST SP800-135rev1] used in IKEv2 (CVL) A4354 KDF SNMP KDF SNMP N/A Key derivation function [NIST SP800-135rev1] used in SNMPv3 (CVL) A4354 KDF SRTP KDF SRTP N/A Key derivation function [NIST SP800-135rev1] used in SRTP (CVL) A4354 KDF SSH KDF SSH N/A Key derivation function [NIST SP800-135rev1] used in SSHv2 (CVL) RSA

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

CAVP16 Description/Key Algorithm/Standard Mode/Method Use/Function Cert Size(s)/Key strength(s) A4354 TLSv1.2 KDF RFC7627 TLSv1.2 KDF N/A Key derivation in (CVL) RFC7627 TLSv1.2 with RFC 7627 KDF with Extended Master Secret A4354 TLS v1.3 KDF TLSv1.3 KDF N/A Key derivation function [RFC 8446] (CVL) used in TLSv1.3 A4354 HMAC HMAC-SHA-1 Key Length: 112-bits or Keyed hash [FIPS 198-1] greater A4354 HMAC HMAC-SHA2-256 Key Length: 112-bits or Keyed hash [FIPS 198-1] greater A4354 HMAC HMAC-SHA2-384 Key Length: 112-bits or Keyed hash [FIPS 198-1] greater A4354 HMAC HMAC-SHA2-512 Key Length: 112-bits or Keyed hash [FIPS 198-1] greater A4354 SHS SHA-1 N/A Message digest [FIPS PUB 180-4] Note: SHA-1 is not used for digital signature generation A4354 SHS SHA2-256 N/A Message digest [FIPS PUB 180-4] A4354 SHS SHA2-384 N/A Message digest [FIPS PUB 180-4] A4354 SHS SHA2-512 N/A Message digest [FIPS PUB 180-4] A4354 DRBG32 CTR33_DRBG (AES- 256 bits Random number [NIST SP 800-90Arev1] 256) generation Derivation Function Enabled: Yes Vendor CKG N/A N/A Symmetric and Affirmed [SP 800-133rev2] asymmetric key generation (Please refer to section “SSP Generation” in this document for more information) 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 HMAC symmetric keys in accordance with NIST SP 800-133r2, section
6. 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 Algorithm/Function Use/Function RSA Key establishment with PKCS1-v1.5 padding MD5 Message digest Triple-DES Encryption/decryption 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

• Data input
• Data output
• Control input
• Control output
• Status output Table 6 below provides a description of data that passes through each logical interface. Table 6
• Ports and Interfaces Physical Port Logical Interface Data that passes over port/interface N/A Data Input API input parameters
• plaintext and/or ciphertext data N/A Data Output API output parameters
• plaintext and/or ciphertext data N/A Control Input API input parameters
• function calls, or input arguments that specify commands and control data used to control the operation of the module N/A Control Output Not applicable N/A Status Output API return codes- function return codes, error codes, or output arguments that receive status information used to indicate the status of the module N/A Power Not applicable

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

• Roles, Service Commands, Input and Output Role Service Input Output CO Initialize module None Module loaded CO Show status API command Module’s current status CO Perform self-test API command Output display on each algorithm running self-test and pass/fail indicator CO Show version information API command Displays the module’s name/ID and versioning information CO Symmetric cipher operation API commands, key, and Plaintext or ciphertext plaintext/ciphertext data CO Asymmetric cipher operation API commands, keys, and Signature and plaintext/ciphertext ciphertext/plaintext data CO Key exchange/agreement component API commands, asymmetric keys Asymmetric key or key (NIST SP 800-56Arev3) agreement component CO Key wrapping (KW) API commands, wrapping key, key Wrapped key CO Key derivation function IKEv2 (existing application specific): KDF shared secret data IKEv2 parameters SNMPv3 (existing application KDF shared secret data specific): SNMPv3 parameters SRTP (existing application specific): KDF shared secret data SRTP parameters CO
• Crypto Officer © Cisco Systems, Inc. 10

Role Service Input Output SSH (existing application specific): KDF shared secret data SSH parameters TLS (KDF, existing application KDF shared secret data specific): TLS parameters CO Keyed hashing function API commands, HMAC key, plaintext MAC value CO Message digest API commands, plaintext Hash value CO Random number generation API commands Random bits CO Zeroization API command None 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.
• R = Read: The SSP is read from the module.
• W = Write: The SSP is updated, imported, or written to the module.
• E = Execute: The module uses the SSP in performing a cryptographic operation.
• Z = Zeroize: The module zeroizes the SSP.
• N/A = The service does not access any SSP during its operation. Table 8 - Approved Services Service Description Approved Security Keys and/or Roles Access Indicator Function SSPs Rights Initialize module Initialization occurs when None None CO R N/A the module is loaded Show status Display running status of N/A None CO N/A N/A the module Perform self-test Perform Self-Tests (Pre- AES-CBC; Firmware CO R API return operational self-tests and AES-CMAC; integrity key value Conditional Self-Tests) AES-GCM; (non-SSP) CTR-DRBG; ECDSA SigGen; ECDSA SigVer; HMAC-SHA2-256; KAS-FFC-SSC; KAS-ECC-SSC; RSA SigGen; RSA SigVer; SHA-1; SHA2-256; SHA2-512; KDF IKEv2; KDF SNMP; KDF SRTP; KDF SSH; TLS v1.2 KDF with RFC7627; TLS v1.3 KDF Show version Provide module’s name and N/A None CO N/A N/A information version information Symmetric cipher Perform CKG; DRBG CO G, R, API return operation encryption/decryption of DRBG; entropy W, E value data AES-CBC; input; AES-CFB128; DRBG seed; AES-ECB; © Cisco Systems, Inc. 11

Service Description Approved Security Keys and/or Roles Access Indicator Function SSPs Rights AES-CMAC; DRBG AES-GMAC; internal AES-GCM state V value; DRBG key; AES EDK Asymmetric cipher Perform signature CKG; DRBG CO G, R, API return operation generation/verification and DRBG; entropy W, E value key generation RSA KeyGen; input; RSA SigGen; DRBG seed; RSA SigVer; DRBG ECDSA KeyGen; internal ECDSA KeyVer; state V ECDSA SigGen; value; ECDSA SigVer DRBG key; RSA SGK; RSA SVK; ECDSA SGK; ECDSA SVK Key Perform key agreement CKG; DRBG CO G, R, API return exchange/agreement primitives on behalf of the DRBG; entropy W, E value component calling application (does not KAS-ECC-SSC; input; establish keys into the KAS-FFC-SSC; DRBG seed; module) Safe Primes Key DRBG Generation internal state V value; DRBG key; DH public key; DH private key; ECDH public key; ECDH private key Key wrapping (KW) Encrypt a key value on CKG; DRBG CO G, R, API return behalf of the calling DRBG; entropy W, E value application AES-KW input; DRBG seed; DRBG internal state V value; DRBG key; AES KWK KDF IKEv2 Derive keys for IKEv2 KDF IKEv2 IKEv2 KDF CO G, R, API return function protocol Secret W, E value KDF SNMPv3 Derive keys for SNMPv3 KDF SNMP SNMP KDF CO G, R, API return function protocol secret W, E value KDF SRTP function Derive keys for SRTP KDF SRTP SRTP KDF CO G, R, API return protocol secret W, E value © Cisco Systems, Inc. 12

Service Description Approved Security Keys and/or Roles Access Indicator Function SSPs Rights KDF SSHv2 Derive keys for SSHv2 KDF SSH SSH KDF CO G, R, API return function protocol secret W, E value KDF TLS v1.2 Derive keys for TLS v1.2 TLSv1.2 KDF RFC TLS v1.2 CO G, R, API return function protocol 7627 KDF W, E value extended master secret KDF TLS v1.3 Derive keys for TLS v1.3 TLSv1.3 KDF TLS v1.3 CO G, R, API return function protocol KDF secret W, E value Keyed hashing Generate keyed hash CKG; DRBG CO G, R, API return function DRBG; entropy W, E value HMAC-SHA-1; input; HMAC-SHA2-256; DRBG seed; HMAC-SHA2-384; DRBG HMAC-SHA2-512; internal state V value; DRBG key; HMAC key Message digest Generate message digest SHA-1; None CO G, R, API return (secure hashing function) SHA2-256; W, E value SHA2-384; SHA2-512; Random number Provide random data for key CTR-DRBG DRBG CO G, R, API return generation generation entropy W, E value input; DRBG seed; DRBG internal state V value; DRBG key Zeroization Zeroize all SSPs stored in None All SSPs CO Z N/A allocated memory. Cleanup is the responsibility of the calling application. © Cisco Systems, Inc. 13

Table 9 below lists non-Approved services supported by the module. Table 9 - Non-Approved Services Service Description Algorithm Accessed Role Indicator Message digest Generate message digest MD5 CO API return value Asymmetric cipher Perform signature RSA (PKCS1-v1.5 padding) CO API return value operation generation/verification Symmetric cipher Perform decryption of ciphertext data Triple-DES CO API return value operation

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 implemented in the module. Table 10 - SSPs Keys/ SSP Strength Security Generation Import/ Establish- Storage Zeroization Use and Name/Type Function and Export ment released keys Cert Number AES EDK 128-256 CKG; Internally generated Import: N/A N/A: The Automatic Symmetric (CSP) bits DRBG; conformant to NIST SP No module does zeroization when encryption/ AES-CBC; 800-133r2 (CKG), not provide the tested platform decryption AES-CFB128; section 6 for Symmetric Export: persistent is powered down AES-ECB; Key Generation No keys/SSPs AES-CMAC; method, and the random storage AES-GCM; value used in key AES-GMAC; generation is generated using SP 800-90Arev1 Cert: A4354 DRBG. AES KWK 128-256 CKG; Internally generated Import: N/A Stored outside Zeroized via API Key wrapping (CSP) bits DRBG; conformant to NIST SP No the module in command outside AES-KW 800-133r2 (CKG), the host OS the module; section 6 for Symmetric Export: Power cycle Cert: A4354 Key Generation No method, and the random value used in key generation is generated using SP 800-90Arev1 DRBG. RSA SGK 112-152 CKG; Internally generated Import: N/A N/A: The Automatic Digital (CSP) bits DRBG; conformant to NIST SP No module does zeroization when signature RSA KeyGen; 800-133r2 (CKG) using not provide the tested platform generation RSA SigVer FIPS 186-4 RSA key Export: persistent is powered down generation method, and No keys/SSPs Cert: A4354 the random value used storage in the key generation is generated using SP 80090Arev1 DRBG. RSA SVK 112-152 RSA SigVer; Internally derived Import: MD/EE N/A: The Automatic Digital (PSP36) bits conformant to FIPS No module does zeroization when signature Cert: A4354 186-4 RSA key not provide the tested platform verification generation method Export: persistent is powered down Via module keys/SSPs API storage ECDSA 128-192 CKG; Internally generated Import: N/A N/A: The Automatic Digital SGK bits DRBG; conformant to NIST SP No module does zeroization when signature (CSP) ECDSA 800-133r2 not provide the tested platform generation KeyGen; (CKG) using FIPS 186- Export: persistent is powered down ECDSA 4 ECDSA key No keys/SSPs KeyVer; generation method, and storage ECDSA the random value used SigGen; in key generation is generated using SP 800Cert: A4354 90Arev1 DRBG ECDSA 128-192 ECDSA Internally derived Import: No MD/EE N/A: The Automatic Digital SVK bits SigVer; conformant to FIPS module does zeroization when signature (PSP) 186-4 ECDSA key Export: not provide the tested platform verification Cert: A4354 generation method Via module persistent is powered down API keys/SSPs storage DH public 112-152 KAS-FFC-SSC; Internally derived Import: No N/A N/A: The Automatic Key agreement key bits conformant to SP 800- module does zeroization when (PSP) 56A rev3 DH key Export: not provide the tested platform Cert: A4354 generation method No persistent is powered down PSP

• Public Security Parameter © Cisco Systems, Inc. 15

Keys/ SSP Strength Security Generation Import/ Establish- Storage Zeroization Use and Name/Type Function and Export ment released keys Cert Number keys/SSPs storage DH private 112-152 CKG; Internally generated Import: N/A N/A: The Automatic Key agreement key bits DRBG; conformant to NIST SP No module does zeroization when (CSP) KAS-FFC-SSC 800-133r2 (CKG) using not provide the tested platform SP 800-56Arev3 DH Export: persistent is powered down Cert: A4354 key generation method, No keys/SSPs and the random value storage used in the key generation is generated using SP 800-90Arev1 DRBG ECDH 128-256 KAS-ECC- Internally derived Import: No N/A N/A: The Automatic Key agreement public key bits SSC; conformant to SP 800- module does zeroization when (PSP) 56A rev3 EC Diffie- Export: not provide the tested platform Cert: A4354 Hellman key generation No persistent is powered down method keys/SSPs storage ECDH 128-256 CKG; Internally generated Import: N/A N/A: The Automatic Key agreement private key bits DRBG; conformant to NIST SP No module does zeroization when (CSP) KAS-ECC- 800-133r2 (CKG) using not provide the tested platform SSC; SP 800-56Arev3 ECDH Export: persistent is powered down key generation method, No keys/SSPs Cert: A4354 and the random value storage used in the key generation is generated using SP 800-90Arev1 DRBG HMAC key 112 bits CKG; Internally generated Import: N/A N/A: The Automatic MAC (CSP) or DRBG; conformant to NIST SP No module does zeroization when generation greater HMAC-SHA-1; 800-133r2 (CKG), not provide the tested platform HMAC-SHA2- section 6 for Symmetric Export: persistent is powered down 256; Key Generation method, No keys/SSPs HMAC-SHA2- and the random value storage

is generated using SP Cert: A4354 800-90Arev1 DRBG DRBG 112 bits N/A Obtained from the Import: Via N/A: The Automatic Random entropy input or Entropy Source within module N/A module does zeroization when number (CSP) greater TOEPP (GPS INT API not provide the tested platform generation Pathways persistent is powered down Export: keys/SSPs No storage DRBG seed, 384 bits CTR_DRBG Internally Derived from Import: No N/A N/A: The Automatic Random (CSP) entropy input string as module does zeroization when number Cert: A4354 defined by NIST SP Export: No not provide the tested platform generation 800-90Arev1 persistent is powered down keys/SSPs storage DRBG 384 bits CTR_DRBG Internally Derived from Import: No N/A N/A: The Automatic Random internal entropy input string as module does zeroization when number state V Cert: A4354 defined by NIST SP Export: No not provide the tested platform generation value, 800-90Arev1 persistent is powered down (CSP) keys/SSPs storage DRBG key 384 bits CTR_DRBG Internally Derived from Import: No N/A N/A: The Automatic Random (CSP) entropy input string as module does zeroization when number Cert: A4354 defined by NIST SP Export: No not provide the tested platform generation 800-90Arev1 persistent is powered down keys/SSPs storage IKEv2 KDF 112-256 KDF IKEv2 Internally derived per Import: MD/EE N/A: The Automatic Keying material secret bits the KDF defined in No module does zeroization when used to derive (CSP) Cert: A4354 NIST SP 800-135 KDF not provide the tested platform other (IKEv2) Export: persistent is powered down IPSec/IKEv2 keys © Cisco Systems, Inc. 16

Keys/ SSP Strength Security Generation Import/ Establish- Storage Zeroization Use and Name/Type Function and Export ment released keys Cert Number As part of keys/SSPs agreement storage scheme SNMPv3 112-256 KDF SNMP Internally derived per Import: MD/EE N/A: The Automatic Keying material KDF secret bits the KDF defined in No module does zeroization when used to derive (CSP) NIST SP 800-135 KDF not provide the tested platform other SNMPv3 Cert: A4354 (SNMPv3) Export: persistent is powered down keys As part of keys/SSPs agreement storage scheme SRTP KDF 112-256 KDF SRTP Internally derived per Import: MD/EE N/A: The Automatic Keying material secret bits the KDF defined in No module does zeroization when used to derive (CSP) NIST SP 800-135 KDF not provide the tested platform other SRTP Cert: A4354 (SRTP) Export: persistent is powered down keys As part of keys/SSPs agreement storage scheme SSH KDF 112-256 KDF SSH Internally derived per Import: MD/EE N/A: The Automatic Keying material secret (CSP) bits the KDF defined in No module does zeroization when used to derive NIST SP 800-135 KDF not provide the tested platform other SSHv2 Cert: A4354 (SSHv2) Export: persistent is powered down keys As part of keys/SSPs agreement storage scheme TLSv1.2 112-256 TLSv1.2 KDF Internally derived per Import: MD/EE N/A: The Automatic Keying material KDF bits with RFC 7627 the KDF defined in No module does zeroization when used to derive extended NIST SP 800-135 KDF not provide the tested platform other TLSv1.2 master secret (TLSv1.2 with RFC Export: persistent is powered down keys (CSP) Cert: A4354 7627) As part of keys/SSPs agreement storage scheme TLSv1.3 112-256 KDF TLSv1.3 Internally derived per Import: MD/EE N/A: The Automatic Keying material KDF secret bits the KDF defined in No module does zeroization when used to derive (CSP) Cert: A4354 NIST SP 800-135 KDF not provide the tested platform other TLSv1.3 (TLSv1.3 with RFC Export: persistent is powered down keys 8446) As part of keys/SSPs agreement storage scheme RBG entropy source Table 11 below specifies the modules entropy sources. Table 11 - Non-Deterministic Random Number Generation Specification Entropy sources Minimum number Details of bits of entropy The OS At least 112 bits While in the approved mode of operation, the entropy and seeding material for the passively loads NIST SP 800-90Arev1 DRBG are provided by the external calling application (and entropy within not by the module) which is outside the module’s cryptographic boundary but the TOEPP into contained within the module’s physical perimeter. The module receives a LOAD the module to command with entropy obtained from the entropy source inside the TOEPP. The seed the NIST minimum effective strength of the NIST SP 800-90Arev1 DRBG seed is required SP 800-90Arev1 to be at least 112-bits when used in an approved mode of operation; therefore the DRBG minimum number of bits of entropy requested when the Module makes a call to the NIST SP 800-90Arev1 DRBG is at least 112-bits. Per the IG 9.3.A Entropy Caveats, the following caveat applies: No assurance of the minimum strength of generated SSPs (e.g., keys). © 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. During system start-up, the IOS-XE OS will call module’s ic2m_init() function. The ic2m_init() function is the default entry point for the module. The ic2m_init() function initiates all self-tests and does not return to the IOS-XE OS until all self-tests are completed successfully and the module is in an approved mode of operation. No other tasks are executed while the self-tests are performed so no data is passed and all cryptographic operations are prohibited. If a self-test fails, the module enters a critical error state and must be reloaded to clear the error state and retry the self-tests. 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 Term/Acronym Definition AES Advanced Encryption Standard API Application Programming Interface ASR Aggregated Services Router CAST Cryptographic Algorithm Self-Tests CAVP Cryptographic Algorithm Validation Program CBC Cipher-Block Chaining CFB Cipher Feedback CKG Cryptographic Key Generation CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CO Crypto Officer CSP Critical Security Parameter CTR Counter CVL Component Validation List DH Diffie-Hellman DRBG Deterministic Random Bit Generator ECB Electronic Codebook ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm FFC Finite Field Cryptography FIPS Federal Information Processing Standards GCM Galois Counter Mode GMAC Galois Message Authentication Code HMAC (keyed)-Hashed Message Authentication Code IEC International Electrotechnical Commission IG Implementation Guidance IKE Internet Key Exchange IPsec IP Security ISO International Organization of Standardization KAS Key Agreement Scheme KAT Known Answer Test KDF Key Derivation Function N/A Not Applicable NIST National Institute of Standards and Technology OS Operating System PCT Pairwise Consistency Test PSP Public Security Parameter PUB Publication RFC Request for Comment RSA Rivest, Shamir, and Adleman SHA Secure Hash Algorithm SHS Secure Hash Standard SSC Shared Secret Computation SSH Secure Shell SNMP Simple Network Transfer Protocol SP Special © Cisco Systems, Inc. 22

Term/Acronym Definition SRTP Secure Real-time Protocol SSP Sensitive Security Parameters TLS Transport Layer Security TOEPP Tested Operational Environment’s Physical Perimeter © Cisco Systems, Inc. 23