Cisco Firepower Next-Generation IPS Virtual (NGIPSv)
Cryptographic Module
FIPS 140-2 Non Proprietary Security Policy
Level 1 Validation
Documentation Version 0.6
Last Update: February 1, 2021
© Copyright 2021 Cisco Systems, Inc. 2
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Table of Contents
1 INTRODUCTION.................................................................................................................. 3
1.1 PURPOSE............................................................................................................................. 3
1.2 MODULE VALIDATION LEVEL ............................................................................................ 3
1.3 REFERENCES....................................................................................................................... 3
1.4 TERMINOLOGY ................................................................................................................... 4
1.5 DOCUMENT ORGANIZATION ............................................................................................... 4
2 CISCO FIREPOWER NEXT-GENERATION IPS VIRTUAL (NGIPSV) ..................... 5
2.1 CRYPTOGRAPHIC BOUNDARY............................................................................................. 5
2.2 MODULE INTERFACES......................................................................................................... 6
2.3 ROLES, SERVICES, AND AUTHENTICATION ......................................................................... 7
2.4 USER SERVICES .................................................................................................................. 7
2.5 CRYPTO OFFICER SERVICES................................................................................................ 8
2.6 NON-FIPS MODE SERVICES ................................................................................................ 9
2.7 UNAUTHENTICATED SERVICES ........................................................................................... 9
2.8 OPERATIONAL ENVIRONMENT.......................................................................................... 10
2.9 CRYPTOGRAPHIC KEY/CSP MANAGEMENT...................................................................... 10
2.10 CRYPTOGRAPHIC ALGORITHMS ........................................................................................ 13
Approved Cryptographic Algorithms ................................................................................................................................ 13
Non-FIPS Approved Algorithms Allowed in FIPS Mode ................................................................................................. 13
Non-Approved Cryptographic Algorithms ........................................................................................................................ 14
2.11 SELF-TESTS ...................................................................................................................... 14
3 SECURE OPERATION ...................................................................................................... 15
3.1 CRYPTO OFFICER GUIDANCE - SYSTEM INITIALIZATION/CONFIGURATION....................... 15
© Copyright 2021 Cisco Systems, Inc. 3
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
1 Introduction
1.1 Purpose
This is the non-proprietary Cryptographic Module Security Policy for Cisco Firepower Next-
Generation IPS Virtual (NGIPSv) Cryptographic Module running software version 6.4. This
security policy describes how this module meets the security requirements of FIPS 140-2 Level 1
and how to run the module in a FIPS 140-2 mode of operation. This Security Policy may be
freely distributed.
FIPS 140-2 (Federal Information Processing Standards Publication 140-2 — Security
Requirements for Cryptographic Modules) details the U.S. Government requirements for
cryptographic modules. More information about the FIPS 140-2 standard and validation program
is available on the NIST website at https://csrc.nist.gov/groups/computer-security-
division/security-testing-validation-and-measurement.
1.2 Module Validation Level
The following table lists the level of validation for each area in the FIPS PUB 140-2.
No. Area Title Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 3
4 Finite State Model 1
5 Physical Security N/A
6 Operational Environment 1
7 Cryptographic Key management 1
8 Electromagnetic Interface/Electromagnetic Compatibility 1
9 Self-Tests 1
10 Design Assurance 2
11 Mitigation of Other Attacks N/A
Overall module validation level 1
Table 1 Module Validation Level
1.3 References
This document deals only with the operations and capabilities of the Cisco Firepower Next-
Generation IPS Virtual (NGIPSv) Cryptographic Module outlined in Table 1 above as it relates
to the technical terms of a FIPS 140-2 cryptographic module. Additional information can be
found at the following Cisco sites:
http://www.cisco.com/c/en/us/products/index.html
http://www.cisco.com/c/en/us/products/collateral/security/firepower-7000-series-
appliances/datasheet-c78-733165.html
http://www.cisco.com/c/en/us/td/docs/security/firepower/60/quick_start/ngips_virtual/NGIPSv-
quick/setup-ngipsv.html
For answers to technical or sales related questions please refer to the contacts listed on the Cisco
Systems website at www.cisco.com.
© Copyright 2021 Cisco Systems, Inc. 4
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
The NIST Validated Modules website (https://csrc.nist.gov/projects/cryptographic-module-
validation-program/validated-modules) contains contact information for answers to technical or
sales-related questions for the module.
1.4 Terminology
In this document, the Cisco Firepower Next-Generation IPS virtual (NGIPSv) Cryptographic
Module is referred to as NGIPS virtual, NGIPSv, Module or the System.
1.5 Document Organization
The Security Policy document is part of the FIPS 140-2 Submission Package. In addition to this
document, the Submission Package contains:
Vendor Evidence document
Finite State Machine
Other supporting documentation as additional references
This document provides an overview of the Cisco Firepower Next-Generation IPS Virtual
(NGIPSv) Cryptographic Module identified in section 1.1 above and explains the secure layout,
configuration and operation of the module. This introduction section is followed by Section 2,
which details the general features and functionality of the module. Section 3 specifically
addresses the required configuration for the FIPS-mode of operation.
With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation
Submission Documentation is Cisco-proprietary and is releasable only under appropriate non-
disclosure agreements. For access to these documents, please contact Cisco Systems.
© Copyright 2021 Cisco Systems, Inc. 5
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2 Cisco Firepower Next-Generation IPS Virtual (NGIPSv)
The NGIPSv Cryptographic Module is the virtualized offering of the industry-leading threat
protection Cisco Firepower Next-Generation IPS (NGIPS) solution. This highly effective
intrusion prevention system provides reliable performance and a low total cost of ownership.
Threat protection can be expanded with optional subscription licenses to provide Advanced
Malware Protection (AMP), application visibility and control, and URL filtering capabilities.
Cisco FirePOWER module sets the industry benchmark for threat detection effectiveness,
inspected throughput, and value as measured by studies conducted by NSS Labs, the world's
leading information security research and advisory company.
NGIPS virtual provides cryptographic functionality and services for TLSv1.2 and SSHv2.
For the purposes of this validation, the module was tested in the lab on the following operational
environment:
OS Platform Hypervisor Processor
FXOS version 2 Cisco UCS C220 M5 VMware ESXi 6.0 Intel Xeon Silver 4110
FXOS version 2 Cisco UCS C220 M5 VMware ESXi 6.5 Intel Xeon Silver 4110
Table 2 Module Validation Level
Cisco does not restrict the use of any hypervisor. Along with supporting ESXi listed above,
Cisco also supports the use of KVM’s and AWS (cloud service) on Cisco UCS platform.
Additionally, 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.
2.1 Cryptographic Boundary
The cryptographic module is a multi-chip standalone software module. The NGIPSv’s logical
boundary (represented by the red dash square) encompasses its virtual guest image, while its
physical boundary is defined as the hard case enclosure around the Server on which all software
executes (including the NGIPS virtual module, hypervisor, API and processor). Please see
Diagram 1 below for the details.
© Copyright 2021 Cisco Systems, Inc. 6
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Diagram 1 Block Diagram
Note: Block Diagram above comprises the following components
• Processor: Chip handling all processes.
• API: Application programming interface between hypervisor and processor
• Hypervisor: VMWare ESXi 6.0 or 6.5
• Guest OS/NGIPS: NGIPS module running on FXOS version 2 (Guest OS)
• API: Application programming interface between the module and FOM library
• FOM: Cisco FIPS Object Module (a Cisco proprietary crypto library)
2.2 Module Interfaces
The module provides a number of physical and logical interfaces to the device, and the physical
interfaces provided by the module are mapped to the following FIPS 140-2 defined logical
interfaces: data input, data output, control input, status output, and power. The module provides
no power to external devices and takes in its power through normal power input/cord. The
logical interfaces and their mapping are described in the following table:
Physical Port/Interface NGIPS Virtual Ports FIPS 140-2 Interface
Host System Ethernet (10/100/1000) Ports; Host
System Serial Port
Virtual Ethernet Ports,
Virtual Serial Port
Data Input Interface
Host System Ethernet (10/100/1000) Ports; Host
System Serial Port
Virtual Ethernet Ports,
Virtual Serial Port
Data Output Interface
Host System Ethernet (10/100/1000) Ports; Host
System Serial Port
Virtual Ethernet Ports,
Virtual Serial Port
Control Input Interface
Host System Ethernet (10/100/1000) Ports; Host
System Serial Port
Virtual Ethernet Ports,
Virtual Serial Port
Status Output Interface
Table 3 Hardware/Physical Boundary Interfaces
Physical boundary
Processor
Hypervisor
Guest OS / NGIPS
API
API
FOM
© Copyright 2021 Cisco Systems, Inc. 7
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.3 Roles, Services, and Authentication
The virtual appliance can be accessed in one of the following ways:
• SSHv2
• TLSv1.2
Authentication is identity-based. Each user is authenticated by the module upon initial access to
the module. As required by FIPS 140-2, there are two roles in the security module that operators
may assume: Crypto Officer role and User role. The administrator of the security module
assumes the Crypto Officer role in order to configure and maintain the module using Crypto
Officer services, while the Users exercise only the basic User services.
The User and Crypto Officer passwords and all other shared secrets must each be at least eight
(8) characters long, including at least one six (6) alphabetic characters, (1) integer number and
one (1) special character in length (enforced procedurally). See the Secure Operation section for
more information. Given these restrictions, the probability of randomly guessing the correct
sequence is one (1) in 6,326,595,092,480 (this calculation is based on the assumption that the
typical standard American QWERTY computer keyboard has 10 Integer digits, 52 alphabetic
characters, and 32 special characters providing 94 characters to choose from in total). The
calculation should be 52x52x52x52x52x52x32x10 = 6,326,595,092,480. Therefore, the
associated probability of a successful random attempt is approximately 1 in 6,326,595,092,480,
which is less than the 1 in 1,000,000 required by FIPS 140-2.
In addition, for multiple attempts to use the authentication mechanism during a one-minute
period, under the optimal modern network condition, if an attacker would only get 60,000
guesses per minute. Therefore, the associated probability of a successful random attempt during
a one-minute period is 60,000/ 6,326,595,092,480 = 1/105,443,251, which is less than 1 in
100,000 required by FIPS 140-2.
Additionally, when using RSA based authentication, RSA key pair has modulus size of 2048
bits, thus providing 112 bits of strength, which means an attacker would have a 1 in 2^112
chance of randomly obtaining the key, which is much stronger than the one in a million chances
required by FIPS 140-2. Similarly, for multiple attempts to use the authentication mechanism
during a one-minute period, under the optimal modern network condition, an attacker would
probably get 60,000 guesses per minute. Therefore, the associated probability of a successful
random attempt during a one-minute period is 60,000/ 2^112 = 1/8.67x10^28, which is less than
1 in 100,000 required by FIPS 140-2.
2.4 User Services
A User enters the system by accessing either virtual serial port, SSHv2 or HTTPS/TLSv1.2 via
the virtual ethernet port. The User role can be authenticated via either Username/Password or
RSA based authentication method. The module prompts the User for username and password. If
the password is correct, the User is allowed entry to the module management functionality. The
services available to the User role accessing the CSPs, the type of access – read (r), write (w) and
zeroized/delete (d) – and which role accesses the CSPs are listed below:
© Copyright 2021 Cisco Systems, Inc. 8
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Services and Access Description Keys and CSPs
Status Functions View state of interfaces and protocols, version of NGIPSv N/A
Terminal Functions Adjust the terminal session (e.g., lock the terminal, adjust
flow control)
N/A
Directory Services Display directory of files kept in flash memory N/A
Self-Tests Execute the FIPS 140 start-up tests on demand N/A
SSHv2 Functions Negotiation and encrypted data transport via SSHv2 Operator password, Diffie-Hellman private key,
Diffie-Hellman public key, Diffie-Hellman shared
secret, EC Diffie-Hellman private key, EC Diffie-
Hellman public key, EC Diffie-Hellman shared
secret, SSHv2 private key, SSHv2 public key, SSHv2
integrity key, SSHv2 session key, DRBG entropy
input, DRBG seed, DRBG V and DRBG key (r, w, d)
HTTPS/TLS (TLSv1.2)
Functions
Negotiation and encrypted data transport via
HTTPS/TLSv1.2
Operator password, ECDSA private key, ECDSA
public key, TLS RSA private key, TLS RSA public
key, TLS pre-master secret, TLS master secret, TLS
encryption keys, TLS integrity key, DRBG entropy
input, DRBG seed, DRBG V and DRBG key (r, w, d)
Table 4 User Services
2.5 Crypto Officer Services
A Crypto Officer (CO) enters the system by accessing either virtual serial port, SSHv2, or
HTTPS/TLSv1.2 via the virtual ethernet port. The CO role can be authenticated via either
Username/Password or RSA based authentication method. The Crypto Officer is responsible for
the configuration of the module. The services available to the Crypto Officer role accessing the
CSPs, the type of access – read (r), write (w) and zeroized/delete (d) – and which role accesses
the CSPs are listed below:
Services Description Keys and CSPs Access
Configure the Security Define network interfaces and settings, create command
aliases, set the protocols the module will support, enable
interfaces and network services, set system date and time, and
load authentication information.
DRBG entropy input, DRBG seed, DRBG V,
DRBG key, Diffie-Hellman private key, Diffie-
Hellman public key, Diffie-Hellman shared secret,
EC Diffie-Hellman private key, EC Diffie-Hellman
public key, EC Diffie-Hellman shared secret,
SSHv2 private key, SSHv2 public key, SSHv2
integrity key, SSHv2 session key, ECDSA private
key, ECDSA public key, TLS RSA private key,
TLS RSA public key, TLS pre-master secret, TLS
master secret, TLS encryption keys, TLS integrity
key (r, w, d)
Define Rules and Filters Create packet Filters that are applied to User data streams on
each interface. Each Filter consists of a set of Rules, which
define a set of packets to permit or deny based on
characteristics such as protocol ID, addresses, ports, TCP
connection establishment, or packet direction.
Operator password, Enable password - (r, w, d)
View Status Functions View the module configuration, routing tables, active sessions,
health, temperature, memory status, voltage, packet statistics,
review accounting logs, and view physical interface status.
N/A
Software Integrity Verification Execute software integrity verification. Integrity test key (r, w, d)
HTTPS/TLS (TLSv1.2)
Functions
Configure HTTPS/TLS parameters, provide entry and output
of CSPs.
ECDSA private key, ECDSA public key, TLS RSA
private key, TLS RSA public key, TLS pre-master
secret, TLS master secret, TLS encryption keys,
TLS integrity key, DRBG entropy input, DRBG
seed, DRBG V and DRBG key (r, w, d)
SSHv2 Functions Configure SSHv2 parameter, provide entry and output of
CSPs.
Diffie-Hellman private key, Diffie-Hellman public
key, Diffie-Hellman shared secret, EC Diffie-
Hellman private key, EC Diffie-Hellman public
key, EC Diffie-Hellman shared secret, SSHv2
private key, SSHv2 public key, SSHv2 integrity
© Copyright 2021 Cisco Systems, Inc. 9
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Table 5 Crypto Officer Services
2.6 Non-FIPS mode Services
The cryptographic module in addition to the above listed FIPS mode of operation can operate in
a non-FIPS mode of operation. This is not a recommended operational mode but because the
associated RFC’s for the following protocols allow for non-approved algorithms and non-
approved key sizes a non-approved mode of operation exist. So those services listed above with
their FIPS approved algorithms in addition to the following services with their non-approved
algorithms and non-approved keys sizes are available to the User and the Crypto Officer. Prior
to using any of the Non-Approved algorithms with the listed services in Section 2.6, the Crypto
Officer must zeroize all CSPs. The use of any of the non-approved algorithms constitutes
placing the module into a non-FIPS mode of operation.
Services 1
Non-Approved Algorithms
SSH
Hashing: MD5
MACing: HMAC-MD5
Symmetric: DES
Asymmetric: 768-bit/1024-bit RSA (key transport), 1024-bit Diffie-Hellman
TLS Symmetric: DES, RC4
Asymmetric: 768-bit/1024-bit RSA (key transport), 1024-bit Diffie-Hellman
Table 6 Non-approved algorithms in the Non-FIPS mode services
Neither the User nor the Crypto Officer are allowed to operate any of these services while in
FIPS mode of operation.
To put the module back into the FIPS mode from the non-FIPS mode, the CO must zeroize all
Keys/CSPs used in non-FIPS mode, and then strictly follow up the steps in section 3 of this
document to put the module into the FIPS mode.
All services available can be found at Firepower Management Center Configuration Guide,
Version 6.4 (Last Modified: 2020-08-03), which lists the configuration guidance.
https://www.cisco.com/c/en/us/td/docs/security/firepower/640/configuration/guide/fpmc-config-
guide-v64.html.
2.7 Unauthenticated Services
The only service available to someone without an authorized role is to cycle the power.
1
These approved services become non-approved when using any non-approved algorithms or non-approved key or
curve sizes. When using approved algorithms and key sizes these services are approved.
key, SSHv2 session key, DRBG entropy input,
DRBG seed, DRBG V and DRBG key (r, w, d)
Self-Tests Execute the FIPS 140 start-up tests on demand. N/A
User services The Crypto Officer has access to all User services. Operator password (r, w, d)
Zeroization Zeroize cryptographic keys/CSPs by running the zeroization
methods classified in table 7, Zeroization column.
All CSPs (d)
© Copyright 2021 Cisco Systems, Inc. 10
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.8 Operational Environment
This module will operate in a modifiable operational environment per the FIPS 140-2 definition.
The operating system shall be restricted to a single operator mode of operation (i.e., concurrent
operators are explicitly excluded). The external application that makes calls to the cryptographic
module is the single user of the module, even when the application is serving multiple clients.
2.9 Cryptographic Key/CSP Management
The module administers both cryptographic keys and other critical security parameters such as
passwords. All keys and CSPs are protected by the password-protection of the Crypto Officer role
login, and can be zeroized by the Crypto Officer. Zeroization consists of overwriting the memory
that stored the key or refreshing the volatile memory.
All secrets are associated with the CO that created the keys, and the CO is protected by a
password. Therefore, the CO password is associated with all the pre-shared keys. The Crypto
Officer needs to be authenticated to store keys. Only an authenticated Crypto Officer can view
the keys. The module is a software module that contains an approved DRBG that is seeded
exclusively from one known entropy source located within the operational environment inside
the module’s physical boundary but the outside the logical boundary, which is complaint with
FIPS 140-2 IG 7.14 #1 (b). The module provides at least 256 bits entropy to instantiate the
DRBG.
Name CSP Type Size Description/Generation Storage Zeroization
DRBG entropy
input
SP800-90A
CTR_DRBG
(AES-256)
384 bits This is the entropy for SP 800-90A
CTR_DRBG used to construct seed.
DRAM
(plaintext)
Power cycle
the device
DRBG seed SP800-90A
CTR_DRBG
(AES-256)
384 bits Input to the DRBG that determines the
internal state of the DRBG. Generated
using DRBG derivation function that
includes the entropy input from hardware-
based entropy source.
DRAM
(plaintext)
Power cycle
the device
DRBG V SP800-90A CTR
_DRBG (AES-
256)
128 bits The DRBG V is one of the critical values
of the internal state upon which the
security of this DRBG mechanism
depends. Generated first during DRBG
instantiation and then subsequently
updated using the DRBG update function.
DRAM
(plaintext)
Power cycle
the device
DRBG key SP800-90A
CTR_DRBG
(using AES-256)
256 bits Internal critical value used as part of SP
800-90A CTR_DRBG. Established per
SP 800-90A CTR_DRBG.
DRAM
(plaintext)
Power cycle
the device
Diffie-Hellman
Shared Secret
DH 2048 - 4096 bits The shared secret used in Diffie-Hellman
(DH) exchange (as part of SSH and TLS).
Established per the Diffie-Hellman key
agreement.
DRAM
(plaintext)
Power cycle
the device
Diffie-Hellman
private key
DH 224-384 bits The private key used in Diffie-Hellman
(DH) exchange (as part of SSH and TLS).
This key is generated by calling SP800-
90A DRBG.
DRAM
(plaintext)
Power cycle
the device
© Copyright 2021 Cisco Systems, Inc. 11
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Name CSP Type Size Description/Generation Storage Zeroization
Diffie-Hellman
public key
DH 2048 - 4096 bits The public key used in Diffie-Hellman
(DH) exchange (as part of SSH and TLS).
This key is derived per the Diffie-
Hellman key agreement. Note that the
public key is a cryptographic key, but not
considered a CSP.
DRAM
(plaintext)
Power cycle
the device
EC Diffie-
Hellman Shared
Secret
EC DH Curves:
P-256, 384, 521
The shared secret used in EC Diffie-
Hellman (ECDH) exchange. Established
per the EC Diffie-Hellman key
agreement.
DRAM
(plaintext)
Power cycle
the device
EC Diffie-
Hellman private
key
ECDH Curves:
P-256, 384, 521
The private key used in EC Diffie-
Hellman (ECDH) exchange. This key is
generated by calling SP800-90A DRBG.
DRAM
(plaintext)
Power cycle
the device
EC Diffie-
Hellman public
key
ECDH Curves:
P-256, 384, 521
The public key used in Elliptic Curve
Diffie-Hellman (ECDH) exchange. This
key is established per the EC Diffie-
Hellman key agreement. This key is
derived per the EC Diffie-Hellman key
agreement. Note that the public key is a
cryptographic key, but not considered a
CSP.
DRAM
(plaintext)
Power cycle
the device
Operator
password
Password 8 plus
characters
The password of the User role. This CSP
is entered by the User.
NVRAM
(plaintext)
Procedurally
erase the
password
Enable
password
Password 8 plus
characters
The password of the CO role. This CSP is
entered by the Crypto Officer.
NVRAM
(plaintext)
Procedurally
erase the
password
SSHv2 private
key
RSA 2048 bits
modulus
The SSHv2 private key used in SSHv2
connection. This key is generated by
calling SP 800-90A DRBG.
NVRAM
(plaintext)
Zeroized by
RSA keypair
deletion
command
SSHv2 public
key
RSA 2048 bits
modulus
The SSHv2 public key used in SSHv2
connection. This key is derived in
compliance with FIPS 186-4 RSA key
pair generation method in the module.
Note that the public key is a
cryptographic key, but not considered a
CSP.
NVRAM
(plaintext)
Zeroized by
RSA keypair
deletion
command
SSHv2 session
key
Triple-DES/AES Triple-DES 192
bits or AES
128/192/256
bits
This is the SSHv2 session key. It is used
to protect the SSHv2data traffics. This
key is derived via key derivation function
defined in SP800-135 KDF (SSH).
DRAM
(plaintext)
Automatically
when SSH
session is
terminated
SSHv2 integrity
key
HMAC-SHA-1 160 bits Used for SSH connections integrity to
assure the traffic integrity. This key is
derived via key derivation function
defined in SP800-135 KDF (SSH).
DRAM
(plaintext)
Automatically
when SSH
session is
terminated
© Copyright 2021 Cisco Systems, Inc. 12
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Name CSP Type Size Description/Generation Storage Zeroization
ECDSA private
key
ECDSA Curves: P-
256,384,521
Key pair generation, signature
generation/Verification (used in TLS).
This key is generated by calling SP 800-
90A DRBG.
NVRAM
(plaintext)
Zeroized by
ECDSA
keypair
deletion
command
ECDSA public
key
ECDSA Curves: P-
256,384,521
Key pair generation, signature
generation/Verification (used in TLS).
This key is derived in compliance with
FIPS 186-4 ECDSA key pair generation
method in the module. Note that the
public key is a cryptographic key, but not
considered a CSP.
NVRAM
(plaintext)
Zeroized by
ECDSA
keypair
deletion
command
TLS RSA
private keys
RSA 2048 bits Identity certificates for the security
appliance itself and also used in TLS
negotiation. This key is generated by
calling SP 800-90A DRBG.
NVRAM
(plaintext)
Zeroized by
RSA keypair
deletion
command
TLS RSA
public keys
RSA 2048 bits Identity certificates for the security
appliance itself and also used in TLS
negotiation. This key is derived in
compliance with FIPS 186-4 RSA key
pair generation method in the module.
Note that the public key is a
cryptographic key, but not considered a
CSP.
NVRAM
(plaintext)
Zeroized by
RSA keypair
deletion
command
TLS pre-master
secret
keying material At least eight
characters
Keying material used to derive TLS
master key during the TLS session
establishment. This key entered into the
module in cipher text form, encrypted by
RSA public key.
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
TLS master
secret
keying material 48 Bytes Keying material used to derive other
HTTPS/TLS keys. This key was derived
from TLS pre-master secret during the
TLS session establishment
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
TLS encryption
keys
Triple-
DES/AES/AES-
GCM
Triple-DES 192
bits or AES
128/192/256
bits
Used in TLS connections to protect the
session traffic. This key is derived via key
derivation function defined in SP800-135
KDF (TLS).
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
TLS integrity
key
HMAC-SHA
256/384
256-384 bits Used for TLS integrity to assure the
traffic integrity. This key is derived via
key derivation function defined in SP800-
135 KDF (TLS).
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
Integrity test
key
HMAC-SHA-512 512 bits A hard coded key used for software
power-up integrity verification.
Hard coded
for
software
integrity
testing
Uninstall the
module
Table 7 Cryptographic Keys and CSPs
© Copyright 2021 Cisco Systems, Inc. 13
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.10 Cryptographic Algorithms
The module implements a variety of approved and non-approved algorithms.
Approved Cryptographic Algorithms
The module supports the following FIPS 140-2 approved algorithm implementations:
Algorithms Algorithm Implementation
NGIPS Virtual
AES (128/192/256 CBC, GCM) 5008
Triple-DES (CBC, 3-key) 2584
SHS (SHA-1/256/384/512) 4074
HMAC (SHA-1/256/384/512) 3329
RSA (KeyGen, SigGen, SigVer, PKCS1_V1_5; 2048 bits
with SHA-256/384/512)
2703
ECDSA (KeyGen, SigGen, SigVer; P-256, P-384, P-521) 1277
DRBG (AES256_CTR) 1828
CVL Component (KDF from TLSv1.2 or SSHv2) 1561
CKG (vendor affirmed)
Table 8 Approved Cryptographic Algorithms and Associated Certificate Number
Notes:
• There are some algorithm modes that were tested but not implemented by the module. Only
the algorithms, modes, and key sizes that are implemented by the module are shown in this
table.
• The module’s AES-GCM implementation conforms to IG A.5 scenario #1 following RFC
5288 for TLS. The module is compatible with TLSv1.2 and provides support for the
acceptable GCM cipher suites from SP 800-52 Rev1, Section 3.3.1. The operations of one of
the two parties involved in the TLS key establishment scheme were performed entirely
within the cryptographic boundary of the module being validated. The counter portion of the
IV is set by the module within its cryptographic boundary. When the nonce_explicit part of
the IV exhausts the maximum number of possible values for a given session key, the client
or server that encounters this condition will trigger a handshake to establish a new
encryption key. In case the module’s power is lost and then restored, a new key for use with
the AES GCM encryption/decryption shall be established.
• Each of TLS and SSH protocols governs the generation of the respective Triple-DES keys.
Refer to RFC 5246 (TLS) and RFC 4253 (SSH) for details relevant to the generation of the
individual Triple-DES encryption keys. The user is responsible for ensuring the module
limits the number of encryptions with the same key to 220
.
• In accordance with FIPS 140-2 IG D.12, the cryptographic module performs Cryptographic
Key Generation as per section 6 in SP800-133. The resulting generated seed used in the
asymmetric key generation are the unmodified output from SP800-90A DRBG.
• No parts of the SSH and TLS protocols, other than the KDFs, have been tested by the
CAVP and CMVP.
Non-FIPS Approved Algorithms Allowed in FIPS Mode
The module supports the following non-FIPS approved algorithms which are permitted for use in
the FIPS approved mode:
© Copyright 2021 Cisco Systems, Inc. 14
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
• Diffie-Hellman (CVL Cert. #1561, key agreement; key establishment methodology provides
between 112 and 150 bits of encryption strength)
• EC Diffie-Hellman (CVL Cert. #1561, key agreement; key establishment methodology
provides between 128 and 256 bits of encryption strength)
• RSA (key wrapping; key establishment methodology provides 112 of encryption strength)
• NDRNG
Non-Approved Cryptographic Algorithms
The module supports the following non-approved cryptographic algorithms that shall not be used
in FIPS mode of operation:
• DES
• Diffie-Hellman (key agreement; non-compliant less than 112 bits of encryption strength)
• HMAC-MD5
• HMAC-SHA-1 is not allowed with key size under 112-bits
• MD5
• RC4
• RSA (key wrapping; non-compliant less than 112 bits of encryption strength)
2.11 Self-Tests
The module includes an array of self-tests that are run during startup and periodically during
operations to prevent any secure data from being released and to insure all components are
functioning correctly.
Self-tests performed
• POST tests
o AES-CBC KATs (Separate encrypt and decrypt)
o AES-GCM KATs (Separate encrypt and decrypt)
o DRBG KATs (Note: DRBG Health Tests as specified in SP800-90A Section 11.3
are performed)
o ECDSA (Sign and Verify) Power on Self-Test
o HMAC-SHA-1/256/384/512 KATs
o RSA Known Answer Tests (Separate KAT for signing; Separate KAT for
verification)
o SHA-1 Known Answer Test
o Software Integrity Test (HMAC-SHA-512)
o Triple-DES-CBC Known Answer Test (Separate encrypt and decrypt)
▪ Conditional tests
o RSA pairwise consistency test
o ECDSA pairwise consistency test
o CRNGT for SP800-90A DRBG
o CRNGT for NDRNG
The module performs all power-on self-tests automatically when the power is applied. All
power-on self-tests must be passed before a User/Crypto Officer can perform services. The
power-on self-tests are performed after the module is initialized but prior to the initialization of
the virtual LAN’s interfaces; this prevents the security module from passing any data during a
© Copyright 2021 Cisco Systems, Inc. 15
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
power-on self-test failure. In the unlikely event that a power-on self-test fails, an error message is
displayed on the virtual serial port followed by a security module reboot.
3 Secure Operation
The module meets all the Level 1 requirements for FIPS 140-2. The module is shipped only to
authorized operators by the vendor, and the module is shipped in Cisco boxes with Cisco
adhesive, so if tampered with the recipient will notice. Follow the setting instructions provided
below to place the module in FIPS-approved mode. Operating this module without maintaining
the following settings will remove the module from the FIPS approved mode of operation.
3.1 Crypto Officer Guidance - System Initialization/Configuration
The Cisco Firepower Next-Generation IPS Virtual (NGIPSv) Cryptographic Module version 6.4
was validated with Cisco Firepower Management Center. This is the only allowable software
image for FIPS-approved mode of operation.
The Crypto Officer must configure and enforce the following steps:
Step 1: To complete the initial setup, the Crypto Officer needs to log into the external Cisco
Firepower Management Center’s (FMC) web interface and specify the initial configuration
options on a setup page. The administrator default password must be changed, specifying
network settings if not already completed, and accepting the EULA.
Log in using factory default password (admin as the username and Admin123 as the password).
Change the password - use a strong password that is at least eight alphanumeric characters of
mixed case and includes at least one numeric character. Avoid using words that appear in a
dictionary.
After completing the initial setup, the only user on the system is the admin user, which has the
Administrator role and access.
Step 2: Choose System > Configuration (Choose SSH or HTTPS or a combination of these
options to specify which ports you want to enable for these IP addresses). For more details, see
Firepower Management Center Configuration Guide, Version 6.4, Updated: September 30, 2020
https://www.cisco.com/c/en/us/td/docs/security/firepower/640/configuration/guide/fpmc-config-
guide-v64.html
Step 3: System>Licenses>Smart Licenses, add and verify licenses (Firepower Management
Center Configuration Guide, Version 6.4 provides more detailed information)
Install Triple-DES/AES SMART license to use Triple-DES and AES (for data traffic and SSH).
Step 4: System > Configuration; Devices > Platform Settings; STIG Compliance, choose Enable
STIG Compliance; Click on save.
Step 5: Reboot the security module.