| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Firmware-hybrid |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 7/31/2029 |
| Caveat | No assurance of the minimum strength of generated SSPs (e.g., keys). |
| Vendor | Cisco Systems, Inc. |
flowchart LR
%% Deterministic review-risk graph for Cisco FIPS Object Module
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status<br/>self-test</i>"]
C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
end
subgraph Risk["Reviewer question"]
R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C5 --> I5 --> R5 --> E5
C6 --> I6 --> R6 --> E6
classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
class C2,C3,C5,C6 clue;
class I2,I3,I5,I6 infer;
class R2,R3,R5,R6 risk;
class E2,E3,E5,E6 evidence;flowchart LR
%% Deterministic clue tier for Cisco FIPS Object Module
%% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
subgraph CMVP["CMVP-disclosed clues (deterministic)"]
C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status<br/>self-test</i><br/>src: text:keyword"]
C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
end
classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
class C2,C3,C5,C6 clueLow;Cisco Systems, Inc. For Cisco FIPS Object Module Last Updated: July 30, 2024, Version 1.3 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
| # | Section | Page |
|---|
Object Module”, firmware version 7.3a by Cisco Systems, Inc. (hereinafter referred to as FOM or module). This Security Policy is provided in accordance with ISO/IEC 19790 Annex B, FIPS 140-3, and NIST SP800-140B. This Security Policy was prepared as part of the Level 1 FIPS 140-3 validation of the module. The following table lists the level of validation for each area in the FIPS PUB 140-3. ISO/IEC 24759 FIPS 140-3 Section Title Security Section 6. Level
Overall Level 1 Table 1 - Security Levels
The Cisco FIPS Object Module (FOM) cryptographic module is a hybrid firmware cryptographic library in a multi-chip standalone embodiment that allows for a vast array of Cisco's networking and collaboration products to use approved algorithms. The module is intended to run on the tested platforms listed in Table 2 and on other various host platforms, so the physical perimeter of the module is the tested platforms. The cryptographic module comprises Cisco’s FIPS Object Module (FOM) cryptographic module (Firmware Version: 7.3a) and the processors (only for algorithm acceleration) and only operates in the approved mode of operation. The module is validated according to FIPS 140-3 at overall security level 1. Please refer to Table 1 above for the individual areas. The cryptographic module provides the cipher operations and Key Derivation functions to support the following protocols: IKEv2/IPSec, sRTP, SSH, TLS and SNMPv3. Full implementations of these protocols are not supported by the module. The module has been tested on the following Operational Environments.
# Operating System Hardware Processor PAA/Acceleration Platform
1 Linux 4.5 Cisco Unified Intel Xeon Gold 6244 With PAA
Computing (Cascade Lake) with System (UCS) AES-NI
2 Linux 5.4 ISR 4321 Intel Atom C2558 With PAA
3 Linux 4.4 Cisco Catalyst Intel Xeon D-1526 With PAA
Table 2 - Tested Operational Environments In addition to the platforms listed in Table 2, Cisco has also tested the module on the following platforms and claims vendor affirmation on them. # Operating System Hardware Platform
Table 3 - Vendor Affirmed Operational Environments The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Modes of Operation By design, the module is only able to support approved mode of operations following the steps in Section 11 of this document. The module doesn’t claim the implementation of a degraded mode operation. The table below lists all Approved security functions of the module, including specific key size(s) - in bits otherwise noted - employed for approved services, and implemented modes of operation. Only the algorithms, modes, and key sizes that are implemented by the module are shown in this table. CAVP Cert Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A4446 AES [FIPS 197, CBC, ECB, CTR, Key Length: 128, 192 Block cipher providing SP800-38A] CFB 1/8/128, OFB and 256 bits encryption/decryption with data confidentiality from the modes of operation.
A4446 AES [FIPS 197, CCM Key Length: 128, 192 Block cipher providing SP800-38C] and 256 bits confidentiality an authentication through Counter with Cipher Block ChainingMessage Authentication Code A4446 AES [FIPS 197, CMAC Key Length: 128, 192 A cipher (AES) based SP800-38B] and 256 bits MAC providing authentication, encryption and decryption A4446 AES [FIPS 197, GCM, GMAC Key Length: 128, 192 Authentication and SP800-38D] and 256 bits encryption. Providing confidentiality of data thru Authentication, encryption and decryption. A4446 AES [SP800-38F] KW, KWP Key Length: 128, 192 Key wrap/unwrap. and 256 bits Key establishment methodology provides between 128 and 256 bits of encryption strength A4446 AES [FIPS 197, XTS Key Length: 128 and Authenticated SP800-38E] 256 bits Symmetric Encryption and Decryption; XTS mode is only approved for storage applications per SP800-38E. A4446 SHS [FIPS 180-4] SHA-1, SHA-224, N/A Message Digest; nonSHA-256, digital-signature and SHA-384, SHA-512 legacy use for SHA1, all other SHAs acceptable for hash functions applications. A4446 HMAC [FIPS 198- HMAC-SHA-1, Key Length: 112 bits or Integrity based on secret 1] HMAC-SHA2-224, greater key. Using standard HMAC-SHA2-256, SHA HASH with secret HMAC-SHA2-384, key for calculations and HMAC-SHA2-512, verification. HMAC-SHA2512/224, HMACSHA2-512/256, HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512 A4446 CTR_DRBG AES-128/192/256 N/A Deterministic Random [SP800-90Arev1] Derivation Function Bit Generators Enabled; (DRBG); uses an Prediction algorithm to produce Resistance: Yes random output
A4446 Hash_DRBG SHA- N/A Deterministic Random [SP800-90Arev1] 1/224/256/384/512 Bit Generators (DRBG); uses an algorithm to produce random output A4446 HMAC_DRBG HMAC-SHA-1, N/A Deterministic Random [SP800-90Arev1] HMAC-SHA-224, Bit Generators HMAC-SHA-256, (DRBG); uses an HMAC-SHA-384 algorithm to produce and HMAC-SHA- random output A4446 DSA DSA KeyGen Key lengths: 2048, DSA key generation [FIPS 186-4] 3072 bits A4446 DSA DSA PQGGen Key lengths: 2048, DSA domain parameter [FIPS 186-4] 3072 bits generation A4446 DSA DSA PQGVer Key lengths: 2048, DSA domain parameter [FIPS 186-4] 3072 bits verification (PQGVer has Key Length 1024 with SHA-1) A4446 DSA DSA SigGen Key lengths: 2048, DSA Signature [FIPS 186-4] 3072 bits Generation A4446 DSA DSA SigVer Key lengths: 2048, DSA signature [FIPS 186-4] 3072 bits verification (SigVer has Key Length 1024 with SHA-1) A4446 ECDSA ECDSA KeyGen Curves: B-233, B-283, Deterministic ECDSA [FIPS 186-4] B-409, B-571, K-233, digital signature key K-283, K-409, K-571, pair generation P-224, P-256, P-384, P-521 A4446 ECDSA ECDSA KeyVer Curves: B-233, B-283, Deterministic ECDSA [FIPS 186-4] B-409, B-571, K-233, digital signature key K-283, K-409, K-571, pair verification, P-224, P-256, P-384, P-521 A4446 ECDSA ECDSA SigGen Curves: B-233, B-283, Deterministic ECDSA [FIPS 186-4] B-409, B-571, K-233, digital signature K-283, K-409, K-571, generation P-224, P-256, P-384, P-521 A4446 ECDSA ECDSA SigVer Curves: B-233, B-283, Deterministic ECDSA [FIPS 186-4] B-409, B-571, K-233, digital signature K-283, K-409, K-571, verification, Accept or P-224, P-256, P-384, reject the signature P-521 A4446 RSA RSA KeyGen: Modulus: Digital signature key [FIPS 186-4] - Mode: B.3.4 2048/3072/4096 bits pair consists of an RSA private key, which is
- 2048/3072/4096 used to compute a with SHA-256 digital signature, and an RSA public key, which is used to verify a digital signature. Key pair shall not be used for other purposes A4446 RSA RSA SigGen: Modulus: Private key to generate [FIPS 186-4] - PKCS1-v1.5 2048/3072/4096 bits a digital signature - 2048/3072/4096 bits with SHA224/256/384/512 A4446 RSA RSA SigVer: Modulus: RSA signature [FIPS 186-4] - PKCS1-v1.5 1024/2048/3072/4096 verification, accept or - 2048/3072/4096 bits reject the signature bits with SHA1/224/256/384/512 A4446 KAS (ECC) KAS (ECC): KAS (ECC): Key Agreement Scheme [SP800-56Arev3] Scheme: per SP800-56Arev3 ephemeralUnified Curves: B-233, B-283, with key derivation KAS Role: initiator, B-409, B-571, K-233, function (SP800responder K-283, K-409, K-571, 135rev1) P-224, P-256, P-384, KAS (KAS-SSC P-521with TLSv1.2 Note: The module’s Cert. #A4446) KDF (SP800-135rev1) KAS (ECC) implementation is FIPS 140-3 IG D.F Scenario
A4446 KAS-ECC CDH KAS-ECC CDH Curves: B-233, B-283, ECC CDH Primitive Component [SP B-409, B-571, K-233, used in shared secret 800-56Arev3] K-283, K-409, K-571, computation P-224, P-256, P-384, P-521 A4446 KAS-SSC (ECC) KAS-ECC-SSC: KAS-ECC-SSC: Key establishment [SP 800-56Arev3] Scheme: methodology provides ephemeralUnified: Curves: P-224, P-256, between 112 and 256 KAS Role: initiator, P-384, P-521 bits of encryption responder strength A4446 KAS-SSC (FFC) KAS-FFC-SSC: KAS-FFC-SSC: FB, Key establishment [SP 800-56Arev3] Scheme: dhEphem: FC, ffdhe2048, methodology provides KAS Role: initiator, ffdhe3072, ffdhe4096, between 112 and 200 responder ffdhe6144, ffdhe8192, bits of encryption modp-2048, modp- strength 3072, modp-4096, modp-6144, modp8192 A4446 KAS-SSC (IFC) KAS-IFC-SSC KAS-IFC-SSC: Key establishment [SP 800-56Brev2] MODP- methodology provides 2048/3072/4096 between 112 and 152 bits of encryption strength A4446 CVL [SP800- SSHv2 KDF (SSH- N/A Key Derivation 135rev1] KDF), TLS v1.2 function. SNMPv3, KDF RFC7627 (SSH-TLS)
sRTP, TLS, SSHv2, IKEv2 A4446 KDA HKDF SHA2-224, SHA2- Key Length: 2048 Subset of Two-Step [SP800-56Crev1] 256, SHA2-384, Key Derivation SHA2-512, SHA2512/224, SHA2512/256, SHA3-224, SHA3-256, SHA3384, SHA3-512 A4446 KDA OneStep SHA2-224, SHA2- Key Length: 2048 Mode of the JSON Key [SP800-56Crev1] 256, SHA2-384, Derivation SHA2-512, SHA2512/224, SHA2512/256, SHA3-224, SHA3-256, SHA3384, SHA3-512, HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512, HMAC-SHA2512/224, HMAC-SHA2512/256, HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512 A4446 KDF IKEv2 SHA-1 Diffie-Hellman Shared Key Derivation [SP800-135rev1] Secret Length: 2048 Function for IKEv2 Derived Keying Material Length: 3072 A4446 KDF SNMP Shared password Length 64, 256 Key Derivation [SP800-135rev1] Function for SNMP A4446 KDF SP800-108 HMAC-SHA-1, Key Length: 112 bits or Key Derivation HMAC-SHA2-224, greater Function using HMAC HMAC-SHA2-256, for pseudorandom HMAC-SHA2-384, functions (PRF) HMAC-SHA2-512 A4446 KDF SRTP AES Key Length: 128, 192, Key Derivation [SP800-135rev1] 256 Function for SRTP A4446 KDF SSH AES Key Length:128, 192, Key Derivation [SP800-135rev1] 256 Function for SSH A4446 KTS-IFC [SP800- RSA Modulus: 2048, 3072, Key Generation and 56Brev2] 4096 transport A4446 PBKDF [SP800- HMAC Algorithm: N/A Password based Key 132] SHA-1, SHA2-224, Derivation SHA2-256, SHA2384, SHA2-512,
SHA3-224, SHA3256, SHA3-384, SHA3-512, A4446 SHS [FIPS 180-4] SHA-1, SHA2-224, N/A Message Digest; nonSHA2-256, SHA2- digital-signature and 384, SHA2-512 legacy use for SHA1, SHA2-512/224, all other SHAs SHA2-512/256, acceptable for hash SHA3-224, SHA3- functions applications. 256, SHA3-384, SHA3-512 A4446 Safe Prime Key Generation ffdhe2048, ffdhe3072, Key Generation ffdhe4096, ffdhe6144, ffdhe8192, modp-2048, modp-3072, modp4096, modp-6144, modp-8192 A4446 Safe Prime Key Verification ffdhe2048, ffdhe3072, Key Verification ffdhe4096, ffdhe6144, ffdhe8192, modp-2048, modp-3072, modp4096, modp-6144, modp-8192 A4446 Shake Shake-128, Shake- Key Length: 128 and Message digest, [FIPS 202] 256 256 extendable-output function (XOF) output can be extended to any desired length A4446 TLS v1.2 KDF SHA2-256, SHA2- N/A Key Derivation RFC7627 384, SHA2-512 Function for TLS A4446 TLS v1.3 KDF HMAC SHA2-256, Key Length: 112 bits or Key Derivation HMAC SHA3-384 greater Function for TLS A4446 Triple-DES CBC, Keying option 1 Only for legacy decrypt CFB1/CFB8/CFB64, operation. CTR, ECB, OFB, CMAC None CKG N/A N/A Key Generation. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation as per scenario 1 of section 4 in SP800-133rev2. Table 4 - Approved Algorithms Notes:
2 above. The FOM performs no communications other than with the consuming application. The
block diagram below shows the boundary of the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The cryptographic boundary is the FOM (red dash box) and its interfaces with the operational environment. Tested Platform TOEPP
The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical and physical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data input, data output, control input, control output and status output) as follows. Physical Logical Interface Data that passes over port/interface Port Input registers Data Input Interface Arguments for an API call that provide the data to be used or processed by the module. Output Data Output Interface Arguments output from an API call. registers Control Control Input Interface Arguments for an API call used to control and configure module registers operation. Status Status Output Interface Return values, and or log messages. registers Power N/A Host platform power supply. Table 5 - Ports and Interfaces The control output interface does not apply to the module.
The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services to the Crypto Officer. Role Service Input Output Crypto Officer Show Status API commands Module’s current status (“FIPS Mode: ON”) Crypto Officer Perform Self-Tests Power cycle the host Output on each algorithm running self-test platform and pass or fail Crypto Officer Show Version API commands Output the version Crypto Officer Configure Security API commands Output each approved algorithm available Crypto Officer Configure Symmetric API commands, FOM followed by the Encryption/Decryption keys/data encryption/decryption in use and ciphertext/plaintext data Crypto Officer Shared Secret API commands, FOM followed by the shared secret Computation keys/data Crypto Officer Configure Signature API commands, FOM followed by the signature/message Generation/Verification keys/message/signature Crypto Officer Configure Key API commands, keys FOM followed by the key pair, status Generation/Verification Crypto Officer Configure Key Derivation API commands, FOM followed by the keys Function secrets/passphrase Crypto Officer Key Wrapping API commands, FOM followed by the crypto key in use wrapping key, key being wrapped Crypto Officer Configure Keyed Hash API commands, FOM followed by the hash in use and keys/data keyed hash output Crypto Officer Configure Message API commands, data FOM followed by the digest in use and Digest hashed output Crypto Officer Configure Random API commands FOM followed by the random strings in Number Generation use Crypto Officer Perform Zeroisation API commands N/A. Table 6 - Roles, Service Commands, Input and Output The table below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A = The service does not access any SSP during its operation. Along with the global indicator, the return code obtained by `echo $?` can be used to determine whether the last command was successful or not. (0 = successful; anything else = unsuccessful). Service Description Approved Keys and/or Roles Access Indicator Security SSPs Rights Functions to Keys
and/or SSPs Show Status Provide N/A N/A Crypto N/A Global Indicator module’s Officer API output as current status designed by (status HOST system message) using the FOM Perform Self- Execute the N/A AES Key, Crypto E Global Indicator Test FIPS 140 CAST Authentication Officer API output as and Health tests designed by outlined in HOST system Section 10 using the FOM below and output pass or fail Show Provide N/A N/A Crypto N/A Global Indicator Version module’s name Officer API output as and version designed by information HOST system using the FOM and output version, OS and hardware Configure Configure AES (CBC, AES key Crypto W,E,Z Global Indicator Symmetric Symmetric CFB1, CFB8, Officer API output as Encryption cipher operation CFB128, CTR, designed by and ECB, OFB, KW, HOST system Decryption KWP) XTS-AES using the FOM A4446 Shared Secret Configure and KAS-ECC-SSC, Diffie-Hellman Crypto W,E,Z Global Indicator Computation derive Shared KAS-FFC-SSC, Public Key, Officer API output as Secret and KAS-ECC CDH Diffie-Hellman designed by related Keys A4446 Private Key, EC HOST system Diffie-Hellman using the FOM Public Key, EC Diffie-Hellman Private Key, Diffie-Hellman Shared Secret, EC Diffie-Hellman Shared Secret Configure Configure HMAC SHA-1/ Authentication Crypto W,E,Z Global Indicator Keyed Hash HMAC, 224/256/384/ Officer API output as CMAC, GMAC 512, AES designed by usage 128/192/256 HOST system A4446 using the FOM Configure Configure SHS SHA- None Crypto N/A Global Indicator Message usage 1/224/256/384/5 Officer API output as Digest 12, SHA3- designed by 224/256/384/512 HOST system A4446 using the FOM Configure Configure DRBG entropy Crypto W, E, Z Global Indicator Random DRBG Usage input Officer API output as
Number DRBG (Hash, DRBG Seed, Crypto G, E, Z designed by Generation HMAC or AES DRBG V and C, Officer HOST system CTR) DRBG Key using the FOM A4446 Configure Configure Key KDA HKDF, Key Derivation Crypto G, E, Z Global Indicator Key Derivation IKEv2 KDF, Function (KDF) Officer API output as Derivation SNMP KDF, secret values designed by Function SP800-108 KDF, HOST system SRTP KDF, SSH using the FOM KDF, PBKDF, TLSv1.2/1.3 KDF A4446 Configure Configure Key DSA, ECDSA, DSA Public Key, Crypto G, E, Z Global Indicator Key Generation and RSA DSA Private Key, Officer API output as Generation Verification A4446 ECDSA Public designed by and Key, ECDSA HOST system Verification Private Key, RSA using the FOM Public Key, RSA Private Key Key Configure key AES-KW, AES- AES Key Crypto W,G, E, Global Indicator Wrapping wrapping KWP Officer Z API output as A4446 designed by HOST system using the FOM. Configure Configure DSA, ECDSA, DSA Public Key, Crypto W,G, E, Global Indicator Signature Signature RSA DSA Private Key, Officer Z API output as Generation Generation and A4446 ECDSA Public designed by and Verification Key, RSA Private HOST system Verification Key, RSA Public using the FOM Key, RSA Private Key Perform Perform N/A All SSPs Crypto Z None Zeroization Zeroization Officer Table 7 - Approved Services
Integrity Techniques The module is provided in the form of binary executable code. To ensure security, the module is protected by HMAC SHA-1 (HMAC Cert. #A4446) algorithm. The firmware integrity test key (Not an SSP) was preloaded to the module’s binary the factory and used for firmware integrity test only at the Pre-Operational Self-Test. At module’s initialization, the integrity of the runtime executable is verified using a HMAC SHA-1 digest which is compared to a value computed at build time. If at the load time the MAC does not match the stored, known MAC value, the module would enter to an Error state with all crypto functionality inhibited. The module does not support firmware loading. Integrity Test On-Demand
Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can power-cycle or reboot the tested platform to initiate the firmware integrity test on-demand.
The module is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The cryptographic module has control over its own SSPs. The process and memory management functionality of the host device’s OS prevents unauthorized access to plaintext private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators. The module’s firmware version running on each tested platform is 7.3a.
Per FIPS 140-3 classification, this is a multi-chip standalone cryptographic module. Cisco FIPS Object Module (v7.3a) is a hybrid firmware module, which runs on a production grade chassis.
Currently, non-invasive security is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module.
The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number DRBG >112 bits N/A Obtained Import to N/A N/A: Zeroized Random entropy from the the The when the Number input Entropy module module tested Generation Source within via does not platform is TOEPP (GPS module’s provide powered INT API persiste down Pathways) nt
Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number Export: keys/SS No Ps storage. DRBG 384 bits SP800- Generated Import: N/A N/A: Crypto_free_r Internal Seed 90Arev1 using DRBG No The ng() state of the CTR_DR derivation module or Power DRBG. BG, function that Export: does not cycle the DRBG_H includes the No provide device ASH, entropy input. persiste DRBG_H nt MAC keys/SS Cert. Ps #A4446 storage. DRBG V 128 SP800- Generated Import: Generated N/A: Crypto_free_r Internal 90Arev1 first during No internally The ng() state of the CTR_DR DRBG module or Power DRBG. 440/888 BG, instantiation Export: does not cycle the bits DRBG_H and then No provide device ASH, subsequently persiste DRBG_H updated using nt 160/256/3 MAC the DRBG keys/SS 84/512 Cert. update Ps bits #A4446 function. storage. DRBG C 128/192/2 SP800- Generated Import: Generated N/A: Crypto_free_r Internal
56 90Arev1 first during No internally The ng() state of the
CTR_DR DRBG module or Power DRBG. 440/888 BG, instantiation Export: does not cycle the bits DRBG_H and then No provide device ASH subsequently persiste Cert. updated using nt #A4446 the DRBG keys/SS update Ps function. storage. DRBG 128/192/2 SP800- Established Import: Generated N/A: Crypto_free_r Internal Key 56 bits 90Arev1 per SP 800- No internally The ng() state of the CTR_DR 90Arev1 module or Power DRBG. BG, CTR_DRBG Export: does not cycle the 160/256/3 DRBG_H and No provide device 84/512 MAC HMAC_DRB persiste bits Cert. G nt #A4446 keys/SS Ps storage. AES Key 128,192,2 AES Generated Import: Generated N/A: Crypto_free_ AES
56 bits (CBC, externally Yes externally The cipher() session
CCM, and passed module crypto_free_a key, XTS CFB1, does not blkcipher() mode is
Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number CFB128, into the Export: provide crypto_free_b only CFB8, module. No persiste lkcipher() approved CMAC, nt crypto_free_s for storage CTR, keys/SS kcipher() application ECB, Ps crypto_free_a s per GCM, storage. ead() SP800GMAC, or Power 38E. KW, cycle the KW/KWP KWP, device mode is OFB, used for XTS)Cert. key #A4446 wrapping (KTS). AES 96-bit AES Generated Import: Generated N/A: Power cycle Initializatio GCM IV GCM internally or Yes internally The the module n vector for Cert. generated or module AES GCM #A4446 externally in Export: externally does not compliance No provide with industry persiste standards nt then passed keys/SS into the Ps module. storage. RSA 112, 128, RSA Cert. Internally Import: Generated N/A: FIPS_openssl Signature Public 152 bits #A4446 generated or Yes internally The _cleanse() verification Key externally or module function or generated and Export: externally does not power cycle passed into No provide the module. persiste nt keys/SS Ps storage. RSA 112, 128, RSA Cert. Internally Import: Generated N/A: FIPS_openssl Signature Private 152 bits #A4446 generated or Yes internally The _cleanse() generation Key externally or module function or generated and Export: externally does not power cycle passed into No provide the module. persiste nt keys/SS Ps storage. DSA 112, 128 DSA Cert. Internally Import: Generated N/A: FIPS_openssl DSA Public bits #A4446 generated or Yes internally The _cleanse() signature Key externally or module function or verification generated and Export: externally does not power cycle passed into No provide the module. persiste nt
Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number keys/SS Ps storage. DSA 112, 128 DSA Cert. Internally Import: Generated N/A: FIPS_openssl DSA Private bits #A4446 generated or Yes internally The _cleanse() signature Key externally or module function or generation generated and Export: externally does not power cycle passed into No provide the module. persiste nt keys/SS Ps storage. ECDSA 112, 128, ECDSA Internally Import: Generated N/A: FIPS_openssl ECDSA Public 192, 256 Cert. generated or Yes internally The _cleanse() signature Key bits #A4446 externally or module function or verification generated and Export: externally does not power cycle passed into No provide the module. persiste nt keys/SS Ps storage. ECDSA 112, 128, ECDSA Internally Import: Generated N/A: FIPS_openssl ECDSA Private 192, 256 Cert. generated or Yes internally The _cleanse() signature Key bits #A4446 externally or module function or generation generated and Export: externally does not power cycle passed into No provide the module. persiste nt keys/SS Ps storage. Diffie- 112, 128, KAS-SSC Internally Import: N/A N/A: Zeroized Used to Hellman 152, 176, (FFC) generated Yes The when the derive Private 200 bits conformant to module tested DiffieKey KAS-SSC SP800-133r2 Export: does not platform is Hellman Cert. (CKG) using No provide powered Shared #A4446 SP800-56A persiste down Secret rev3 Diffie- nt keys/ Hellman key SSPs generation storage. method, and the random value used in key generation is generated using SP80090Arev1 DRBG
Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number Diffie- 112, 128, KAS-SSC Internally Import: N/A N/A: Zeroized Used to Hellman 152, 176, (FFC) derived Yes The when the derive Public 200 bits internally per module tested DiffieKey KAS-SSC the Diffie- Export: does not platform is Hellman Cert. Hellman key No provide powered Shared #A4446 agreement persiste down Secret (SP800- nt keys/ 56Arev3) SSPs storage. Diffie- N/A KAS-SSC Internally Import: N/A N/A: Zeroized Used to Hellman (FFC) generated Yes The when the derive Shared KAS-SSC using SP800- module tested SSH, TLS Secret Cert. 56Arev3 DH Export: does not platform is or #A4446 shared secret No provide powered IPSec/IKE computation persiste down related nt keys keys/SS Ps storage. EC Diffie- 112, 128, KAS-SSC Internally Import: N/A N/A: Zeroized Used to Hellman 192, 256 (ECC) generated Yes The when the derive EC Private bits conformant to module tested DiffieKey KAS-SSC SP800-133r2 Export: does not platform is Hellman Cert. (CKG) using No provide powered Shared #A4446 SP800-56A persiste down Secret rev3 EC nt keys/ Diffie- SSPs Hellman key storage. generation method, and the random value used in key generation is generated using SP80090Arev1 DRBG EC Diffie- 112, 128, KAS-SSC Internally Import: N/A N/A: Zeroized Used to Hellman 192, 256 (ECC) derived Yes The when the derive EC Public bits internally per module tested DiffieKey KAS-SSC the EC Export: does not platform is Hellman Cert. Diffie- No provide powered Shared #A4446 Hellman key persiste down Secret agreement nt keys/ (SP800- SSPs 56Arev3) storage. EC Diffie- N/A KAS-SSC Internally Import: N/A N/A: Zeroized Used to Hellman (ECC) generated Yes The when the derive TLS Shared using SP800- module tested or Secret 56Arev3 does not platform is IPSec/IKE
Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number KAS-SSC ECDH shared Export: provide powered related Cert. secret No persiste down keys #A4446 computation nt keys/SS Ps storage. RSA Key 112, 128, RSA Cert. Generated Import: Generated N/A: FIPS_openssl RSA Key Wrapping/ 152 bits #A4446 externally Yes externally The _cleanse() Transport/ Transport and passed module function or Wrapping Key into the Export: does not power cycle module. No provide persiste nt keys/SS Ps storage. Authentic 128 to 256 HMAC Generated Import: Generated N/A: Crypto_free_ Integrity ation bits (SHA1, externally Yes externally The shash() assurance SHA224, and passed module crypto_free_a SHA256, into the Export: does not hash() SHA384, module. No provide or Power SHA512), persiste cycle the AES- nt device CMAC, keys/SS AES- Ps GMAC storage. Cert. #A4446 Key N/A IKEv2, Generated Import: Generated N/A: FIPS_openssl Deriving Derivation SNMP, internally No internally The _cleanse() keys per Function SRTP, module function or SP800(KDF) SSH,800- Export: does not power cycle 135rev1 secret 108 KDF No provide and SP800values Cert. persiste 56Crev1 #A4446 nt keys/SS Ps storage Firmware 128 bits HMAC- Pre-loaded at Import: N/A Stored This key is Used for Integrity SHA-1 the factory (in No in the used for firmware Key Cert. the module’s module firmware integrity (not a #A4446 binary) Export: binary integrity test test. This is SSP) No comput and not not a SSP ed subject to key during zeroization build. requirements according to FIPS140-3 IG 9.7.B. Table 8 - SSPs
The module uses approved DRBG for the generation of random strings and passes them to the calling application only upon their request. The cryptographic module is passed a pointer to the cryptographic keys as API parameters, associated by memory location. The application calling the cryptographic module passes keys in plaintext within the physical perimeter. The module does not perform storage of keys. All SSPs can be zeroized by power cycling the host. Note 1: Use of external IV with GCM is exclusively permitted for decryption operations or where the GCM is used to support the protocol specific implementation used to protect connections to the calling applications. Note 2: The check for Key_1 ≠ Key_2 is done before using the keys in the XTS-AES algorithm to process data and is in accordance with IG C.I requirements. Note 3: No parts of SSH, TLS, SNMPv3, sRTP and IKE protocols, other than the KDFs, have been tested by the CAVP and CMVP. Entropy sources Minimum Details number of bits of entropy Entropy within the At least 112 bits While operating in the approved mode, the entropy and seeding material for the TOEPP was SP800-90Arev1 DRBG are provided by the external calling application (and not passively loaded by the module) which is outside the module’s cryptographic boundary but into the module to contained within the module’s Tested Operational Environment’s Physical seed the 800- Perimeter (TOEPP) boundary. The module receives a LOAD command with 90Arev1 DRBG by entropy obtained from the entropy source (Intel CPU processor with instructions the Operating RDRand) inside the TOEPP. The minimum effective strength of the SP 800System 90Arev1 DRBG seed is required to be at least 112 bits when used in an approved mode of operation, therefore the minimum number of bits of entropy requested when the module makes a call to the SP 800-90Arev1 DRBG is at least 112 bits. Per the IG 9.3.A Entropy Caveats, the following caveat applies: No assurance of the minimum strength of generated SSPs (e.g., keys). Table 9 - Non-Deterministic Random Number Generation Specification
When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs Pre-Operational Self-Tests. The operating system is responsible for the initialization process and loading of the module. Prior to the module providing any data output via the data output interface, the module would perform and pass the Pre-Operational Self-Tests. Following the successful Pre-Operational Self-Tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs). The self-test success or failure messages were logged, which functions as the self-test status indicator. If any one of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. The module has one error state, called Hard error state. When a self-test fails, the module outputs “POST Failed” error. While the
module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All selftests must be completed successfully before the module transitions to the operational state. Below are the details of the self-tests conducted by the module. Pre-Operational Self-Tests
functions per Section 11.3 of SP 800-90Arev1)
Secure Operation The tested operating systems segregate user processes into separate process spaces. Each process space is an independent virtual memory area that is logically separated from all other processes by the operating system software and hardware. The module functions entirely within the process space of the process that invokes it. The module operates only in approved mode of operation. There is no non-approved mode of operation for the module. Secure Initialization The Operating System loads the module into its user space. The initialization sequence starts with a check of the integrity of the runtime executable using a HMAC-SHA1 digest computed at build time. If this computed HMAC-SHA1 digest matches the stored known digest then the POSTs, consisting of the algorithm specific Known Answer Tests, are performed. If any component of the POST fails an internal global error flag is set to prevent subsequent invocation of any cryptographic function calls. Any such POST failure is a hard error that can only be recovered by reinstalling the module. Upon loading the cryptographic module, the consuming application must enable the approved mode of operation by calling the “FIPS_mode_set()” function. This function call verifies the POST outcome and returns a “1” for success and “0” for failure; interpretation of this return code is the responsibility of the host application. The function call “. /openssl version -a” returns the name, version of the module and approved mode status. The module is installed using one of the sets of instructions in the ‘README.Cisco’ document appropriate to the target system available in the repository with the source code. The module does not support Non-Compliant state. User Guidance AES GCM IV Generation
In the case of AES-GCM, the IV generation method is user-selectable, and the value can be computed in more than one manner as follows:
The module supports internal IV generation using the module’s Approved DRBG. The IV is at least 96 bits in length per section 8.2.2 of NIST SP 800-38D. Per NIST SP 800-38D and scenario
5 of FIPS 140-3 IG C.H, the DRBG generates outputs such that the (key/IV) pair collision
probability is less than 2-32. In the event that power to the module is lost and subsequently restored, the calling application must ensure that any AES-GCM keys used for encryption or decryption are re-distributed. PBKDF In line with the requirements for SP 800-132, keys generated using the approved PBKDF must only be used for storage applications. Any other use of the approved PBKDF is non-conformant. In approved mode the module enforces that any password used must encode to at least 14 bytes (112 bits) and that the salt is at least 16 bytes (128 bits) long. The iteration count associated with the PBKDF should be as large as practical. As the module is a general-purpose hybrid firmware module, it is not possible to anticipate all the levels of use for the PBKDF, however a user of the module should also note that a password should at least contain enough entropy to be unguessable and also contain enough entropy to reflect the security strength required for the key being generated. The module uses PBKDF option 1a from section 5.4 of NIST SP 800-132.
The requirements under INCITS+ISO+IEC 19790+2012[2014], section 7.12 “Mitigation of other attacks”, are not applicable to the module since the module currently doesn’t support any mitigation of other attacks services.