Cisco Firepower Threat Defense on 4K/9K Cryptographic
Module
FIPS 140-2 Non Proprietary Security Policy
Level 1 Validation
Version 1.2
August 31, 2018
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 4100 AND 9300 SERIES OVERVIEW......................................... 5
2.1 CRYPTOGRAPHIC MODULE CHARACTERISTICS ................................................................... 5
2.2 CRYPTOGRAPHIC BOUNDARY............................................................................................. 5
2.3 MODULE INTERFACES......................................................................................................... 6
2.4 ROLES AND SERVICES......................................................................................................... 6
2.5 USER SERVICES .................................................................................................................. 7
2.6 CRYPTO OFFICER SERVICES................................................................................................ 8
2.7 NON-FIPS MODE SERVICES ................................................................................................ 8
2.8 UNAUTHENTICATED SERVICES ........................................................................................... 9
2.9 CRYPTOGRAPHIC KEY/CSP MANAGEMENT........................................................................ 9
2.10 CRYPTOGRAPHIC ALGORITHMS ........................................................................................ 14
Approved Cryptographic Algorithms ................................................................................................................................ 14
Non-FIPS Approved Algorithms Allowed in FIPS Mode ................................................................................................. 15
Non-Approved Cryptographic Algorithms ........................................................................................................................ 15
2.11 SELF-TESTS ...................................................................................................................... 15
3 SECURE OPERATION ...................................................................................................... 16
3.1 CRYPTO OFFICER GUIDANCE - SYSTEM INITIALIZATION .................................................. 17
© Copyright 2018 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 the Cisco Firepower Threat
Defense on 4K/9K Cryptographic Module. The firmware version is 6.2. 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 http://csrc.nist.gov/groups/STM/index.html.
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 1
6 Operational Environment N/A
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 with the specification of the security rules listed in Table 1 above, under
which the Cisco Firepower Threat Defense on 4K/9K Cryptographic Module will operate,
including the rules derived from the requirements of FIPS 140-2, FIPS 140-2 IG and additional
rules imposed by Cisco Systems, Inc. More information is available on the module from the
following sources:
The Cisco Systems website contains information on the full line of Cisco Systems security.
Please refer to the following website:
http://www.cisco.com/c/en/us/products/index.html
http://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/roadmap/fxos-roadmap.html
For answers to technical or sales related questions please refer to the contacts listed on the Cisco
Systems website at www.cisco.com.
The NIST Validated Modules website (http://csrc.nist.gov/groups/STM/cmvp/validation.html)
contains contact information for answers to technical or sales-related questions for the module.
© Copyright 2018 Cisco Systems, Inc. 4
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
1.4 Terminology
In this document, the Cisco Firepower Threat Defense on 4K/9K Cryptographic Module
identified is referred to as CM, FTD CM, 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 Threat Defense on 4K/9K
Cryptographic Module identified 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 appliance. 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 2018 Cisco Systems, Inc. 5
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2 Cisco Firepower Threat Defense Cryptographic Module Overview
Cisco Firepower Threat Defense (FTD) which consolidates the ASA, Firepower and FX-OS
providing next-generation firewall services, including stateful firewalling, routing, Next-
Generation Intrusion Prevention System (NGIPS), Application Visibility and Control (AVC),
URL filtering, and Advanced Malware Protection (AMP). A Threat Defense can be used in
single context mode, and in routed or transparent mode to support TLSv1.2, SSHv2, IKEv2 and
Cryptographic Cipher Suite B. All using Cisco FIPS Object module for cryptographic support.
The Cisco Firepower Threat Defense (FTD) runs on the Application Blade houses inside Cisco
Firepower 4100 and Cisco Firepower 9300 Series. This Security Policy detail the FIPS
compliance for the FTD comprising the following platforms:
 FPR4110-ASA-K9
 FPR4120-ASA-K9
 FPR4140-ASA-K9
 FPR4150-ASA-K9
 FPR9K-SM24 (SM-24)
 FPR9K-SM36 (SM-36)
 FPR9K-SM44 (SM-44)
2.1 Cryptographic Module Characteristics
The Cisco FTD CM is an integrated network security module housed in a single blade
architecture, which is designed to integrate into the Cisco Firepower 4100 or 9300 Series
Appliances. Once integrated, the module provides enhanced security, reliability, and
performance. Delivering industry-leading firewall data rates, this module provides exceptional
scalability to meet the needs of today's dynamic organizations.
Image 1 Application Blade
2.2 Cryptographic Boundary
The module is a multi-chip embedded hardware crypto module. The cryptographic boundary is
defined as the physical perimeter of the application blade running inside the 4K/9K series chassis
unit.
© Copyright 2018 Cisco Systems, Inc. 6
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Diagram 1 Block Diagram
2.3 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 logical interfaces
and their mapping are described in the following table:
FIPS 140-2 Logical Interface Module Physical Interface
Data Input SFP Ethernet Ports
PCI port
Data Output SFP Ethernet Ports
PCI port
Control Input SFP Ethernet Ports
PCI port
Status Output SFP Ethernet Ports
PCI port
LED
Table 2 Hardware/Physical Boundary Interfaces
2.4 Roles and Services
The appliance can be accessed in one of the following ways:
 SSHv2
 HTTPS/TLSv1.2
 IPSec/IKEv2
Authentication is identity-based. As required by FIPS 140-2, there are two roles that operators
may assume: a Crypto Officer role and User role. The module upon initial access to the module
authenticates both of these roles. The module also supports RADIUS and TACACS+ as another
means of authentication, allowing the storage of usernames and passwords on an external server
as opposed to using the module’s internal database for storage.
ASA
FX-OS
Firepower
Cav
ium
Application
Blade
Mgmt
Port
Console Port
Data via
SFP
Mgmt
over SFP
Xeon E5
CN3550
Process
Manager
PCI
Po
rt
© Copyright 2018 Cisco Systems, Inc. 7
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
The User and Crypto Officer passwords and all shared secrets must each be at a minimum eight
(8) characters long. There must be at least one special character and at least one number
character (enforced procedurally) along with six additional characters taken from the 26 upper
case, 26 lower case, 10 numbers and 32 special characters. See the Secure Operation section for
more information. If six (6) special/alpha/number characters, one (1) special character and one
(1) number are used without repetition for an eight (8) digit value, the probability of randomly
guessing the correct sequence is one (1) in 187,595,543,116,800. This is calculated by
performing 94 x 93 x 92 x 91 x 90 x 89 x 32 x 10. In order to successfully guess the sequence in
one minute would require the ability to make over 3,126,592,385,280 guesses per second, which
far exceeds the operational capabilities of the module.
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 2112
chance
of randomly obtaining the key, which is much stronger than the one in a million chance required
by FIPS 140-2. To exceed a one in 100,000 probability of a successful random key guess in one
minute, an attacker would have to be capable of approximately 8.65x1031
(2112
/60 = 8.65 x 1031
)
attempts per second, which far exceeds the operational capabilities of the module to support.
2.5 User Services
A User enters the system by either SSH or HTTPS/TLS. 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 other means of accessing the console is via an IPSec session.
This session is authenticated either using a shared secret or RSA digital signature authentication
mechanism. 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:
Services Description Keys and CSPs Access
Status Functions View the module configuration, routing tables, active
sessions health, and view physical interface status.
Operator password (r, w, d)
Terminal Functions Adjust the terminal session (e.g., lock the terminal,
adjust flow control).
Operator password (r, w, d)
Directory Services Display directory of files kept in flash memory. Operator password (r, w, d)
Self-Tests Execute the FIPS 140 start-up tests on demand. N/A
IPSec VPN Negotiation and encrypted data transport via IPSec
VPN.
Operator password, DRBG entropy input, DRBG Seed,
DRBG V, DRBG key, skeyid, skeyid_d, SKEYSEED,
IKE session encryption key, IKE session authentication
key, ISAKMP preshared, IKE authentication private
Key, IKE authentication public key, IPSec encryption
key, IPSec authentication key (r, w, d)
SSHv2 Functions Negotiation and encrypted data transport via SSH. Operator password, DRBG entropy input, DRBG Seed,
DRBG V and DRBG key, SSH RSA private key, SSH
RSA public key and SSH session key (r, w, d)
HTTPS Functions
(TLSv1.2)
Negotiation and encrypted data transport via HTTPS. Operator password, DRBG entropy input, DRBG Seed,
DRBG V, DRBG C, ECDSA private key, ECDSA
public key, TLS RSA private key, TLS RSA public key,
TLS pre-master secret, TLS master secret, TLS
encryption keys and TLS integrity key (r, w, d)
Table 3 User Services
© Copyright 2018 Cisco Systems, Inc. 8
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.6 Crypto Officer Services
A Crypto Officer enters the module by accessing the console port with a terminal program or
SSHv2 session to a LAN port or the 10/100/1000 management Ethernet port. The Crypto Officer
authenticates in the same manner as a User.
The Crypto Officer role 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 appliance 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,
DRBG C, 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
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,
ISAKMP preshared, skeyid, skeyid_d, SKEYSEED, IKE
session encryption key, IKE session authentication key, IKE
authentication private Key, IKE authentication public key,
IPSec encryption key and IPSec authentication key (r, w, d)
Firmware Installation Install the firmware during the System Initialization. N/A
Configure External
Authentication Server
Configure Client/Server authentication RADIUS secret, TACACS+ secret
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 appliance configuration, routing tables, active
sessions health, temperature, memory status, voltage, packet
statistics, review accounting logs, and view physical
interface status.
Operator password, Enable password (r, w, d)
HTTPS/TLS
(TLSv1.2)
Configure HTTPS/TLS parameters, provide entry and output
of CSPs.
DRBG entropy input, DRBG seed, DRBG V, DRBG key,
DRBG C, ECDSA private key, ECDSA public key, TLS pre-
master secret, TLS master secret, TLS encryption keys and
TLS integrity key (r, w, d)
IPSec VPN Configure IPSec VPN parameters, provide entry and output
of CSPs.
DRBG entropy input, DRBG seed, DRBG V, DRBG key,
DRBG C, ISAKMP preshared, skeyid, skeyid_d, SKEYSEED,
IKE session encryption key, IKE session authentication key,
IKE authentication private Key, IKE authentication public key,
IPSec encryption key and IPSec authentication key (r, w, d)
SSHv2 Function Configure SSH v2 parameter, provide entry and output of
CSPs.
DRBG entropy input, DRBG seed, DRBG V, DRBG key,
DRBG C, SSHv2 Private Key, SSHv2 Public Key and SSHv2
session 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 6, Zeroization column.
All CSPs (d)
Table 4 Crypto Officer Services
2.7 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
© Copyright 2018 Cisco Systems, Inc. 9
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
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 services in Section 2.7, the Crypto Officer must zeroize all
CSPs which places the module into the non-FIPS mode of operation.
Services1
Non-Approved Algorithms
SSH
Hashing: MD5
MACing: HMAC MD5
Symmetric: DES
Asymmetric: 768-bit/1024-bit RSA (key transport), 1024-bit Diffie-Hellman
IPsec
Hashing: MD5
MACing: HMAC MD5
Symmetric: DES, RC4
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 5 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.
All services available can be found at
http://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-
guide-v60.pdf. This site lists all configuration guides.
2.8 Unauthenticated Services
The services for someone without an authorized role are to view the status output from the
module’s LED pins and cycle power.
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. Keys are both manually and
electronically distributed but entered electronically. Persistent keys with manual distribution are
used for pre-shared keys whereas protocols such as IKE, TLS and SSH are used for electronic
distribution.
All pre-shared keys are associated with the CO role that created the keys, and the CO role 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. All Diffie-Hellman (DH)/ECDH keys agreed upon for individual tunnels are
directly associated with that specific tunnel only via the IKE protocol. All other keys are
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.
© Copyright 2018 Cisco Systems, Inc. 10
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
associated with the user/role that entered them. The entropy source (NDRNG) within the module
provides at least 256 bits of entropy to seed SP800-90a DRBG for use in key generation.
Name CSP Type Size Description/Generation Storage Zeroization
DRBG entropy
input
SP800-90A
CTR_DRBG
(AES-256) or
HASH_DRBG
(SHA-512)
384 bits/512bits This is the entropy input for SP 800-
90A CTR_DRBG and
HASH_DRBG, used to construct
seed.
DRAM
(plaintext)
Power cycle the
device
DRBG seed SP800-90A
CTR_DRBG
(AES-256) or
HASH_DRBG
(SHA-512)
384 bits/888
bits
Input to the DRBG that determines
the internal state of the DRBG.
Generated using DRBG derivation
function that includes the entropy
input from the entropy source.
DRAM
(plaintext)
Power cycle the
device
DRBG V SP800-90A
CTR _DRBG
(AES-256) or
HASH_DRBG
(SHA-512)
128 bits/888
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
DRBG C SP800-90A
HASH_DRBG
(SHA-512)
888 bits Internal critical value used as part of
SP 800-90A HASH_DRBG.
Established per SP 800-90A
HASH_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, IKE/IPSec, 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, IKE/IPSec, and TLS). This key
is generated by calling SP800-90A
DRBG.
DRAM
(plaintext)
Power cycle the
device
Diffie Hellman
public key
DH 2048 – 4096
bits
The public key used in Diffie-
Hellman (DH) exchange (as part of
SSH, IKE/IPSec, and TLS). This key
is derived per the Diffie-Hellman key
agreement.
DRAM
(plaintext)
Power cycle the
device
© Copyright 2018 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
EC Diffie-
Hellman shared
Secret
ECDH P-256, P-384,
P-521 Curves
The shared secret used in Elliptic
Curve Diffie-Hellman (ECDH)
exchange. Established per the
Elliptic Curve Diffie-Hellman
(ECDH) protocol.
DRAM
(plaintext)
Power cycle the
device
EC Diffie-
Hellman private
key
ECDH P-256, P-384,
P-521 Curves
Used in establishing the session key
for an IPSec session. The private key
used in Elliptic Curve Diffie-
Hellman (ECDH) exchange. This
key is established per the EC Diffie-
Hellman key agreement
DRAM
(plaintext)
Power cycle the
device
EC Diffie-
Hellman public
key
ECDH P-256, P-384,
P-521 Curves
Used in establishing the session key
for an IPSec session. The public key
used in Elliptic Curve Diffie-
Hellman (ECDH) exchange. This
key is established per the EC Diffie-
Hellman key agreement
DRAM
(plaintext)
Power cycle the
device
skeyid Keying material 160 bits A shared secret known only to IKE
peers. It was established via key
derivation function defined in
SP800-135 KDF and it will be used
for deriving other keys in IKE
protocol implementation.
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
skeyid_d Keying material 160 bits A shared secret known only to IKE
peers. It was derived via key
derivation function defined in
SP800-135 KDF (IKEv2) and it will
be used for deriving IKE session
authentication key.
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
SKEYSEED Keying material 160 bits A shared secret known only to IKE
peers. It was derived via key
derivation function defined in
SP800-135 KDF (IKEv2) and it will
be used for deriving IKE session
authentication key.
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
ISAKMP
preshared
Shared Secret Variable 8 plus
characters
The secret used to derive IKE skeyid
when using preshared secret
authentication. This CSP is entered
by the Crypto Officer.
NVRAM
(plaintext)
Zeroized by
replacing a new
secret
IKE
authentication
private Key
RSA/ECDSA RSA (2048 bits)
or ECDSA
(Curves:
P-256/P-384)
RSA/ECDSA private key used in
IKE authentication. This key is
generated by calling SP800-90A
DRBG.
NVRAM
(plaintext)
Zeroized by
RSA/ECDSA
keypair deletion
command
© Copyright 2018 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
IKE
authentication
public key
RSA/ECDSA RSA (2048 bits)
or ECDSA
(Curves:
P-256/P-384)
RSA/ECDSA public key used in IKE
authentication. The key is derived in
compliance with FIPS 186-4
RSA/ECDSA key pair generation
method in the module.
NVRAM
(plaintext)
Zeroized by
RSA/ECDSA
keypair deletion
command
IKE session
encryption key
Triple-
DES/AES
192 bits Triple-
DES or
128/192/256
bits AES
The IKE session (IKE Phase I)
encrypt key. This key is derived via
key derivation function defined in
SP800-135 KDF (IKEv2).
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
IKE session
authentication
key
HMAC-SHA-
1/256/384/512
160-512 bits The IKE session (IKE Phase I)
authentication key. This key is
derived via key derivation function
defined in SP800-135 KDF (IKEv2).
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
IPSec
encryption key
Triple-DES,
AES and AES-
GCM
Triple-DES 192
bits or AES
128/192/256
bits
The IPSec (IKE phase II) encryption
key. This key is derived via a key
derivation function defined in
SP800-135 KDF (IKEv2).
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
IPSec
authentication
key
HMAC-SHA-
1/256/384/512
160-512 bits The IPSec (IKE Phase II)
authentication key. This key is
derived via a key derivation function
defined in SP800-135 KDF (IKEv2).
DRAM
(plaintext)
Automatically
when IPSec/IKE
session is
terminated
Operator
password
Password 8 plus
characters
The password of the User role. This
CSP is entered by the User.
NVRAM
(plaintext)
Overwrite with
new password
Enable
password
Password 8 plus
characters
The password of the CO role. This
CSP is entered by the Crypto Officer.
NVRAM
(plaintext)
Overwrite with
new password
RADIUS secret Shared Secret 16 characters The RADIUS shared secret. Used for
RADIUS Client/Server
authentication. This CSP is entered
by the Crypto Officer.
NVRAM
(plaintext)
Overwrite with
new secret
TACACS+
secret
Shared Secret 16 characters The TACACS+ shared secret. Used
for TACACS+ Client/Server
authentication. This CSP is entered
by the Crypto Officer.
NVRAM
(plaintext)
Overwrite with
new secret
SSHv2 RSA
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 RSA
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.
NVRAM
(plaintext)
Zeroized by RSA
keypair deletion
command
© Copyright 2018 Cisco Systems, Inc. 13
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Name CSP Type Size Description/Generation Storage Zeroization
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 encrypt all SSHv2 data
traffics traversing between the
SSHv2 Client and SSHv2 Server.
This key is derived via key
derivation function defined in
SP800-135 KDF (SSH).
DRAM
(plaintext)
Automatically
when SSH session
is terminated
ECDSA private
key
ECDSA Curves:
P-256, 384, 521
Signature generation used in
IKE/IPSec and TLS. This key is
generated by calling SP 800-90A
DRBG.
DRAM
(plaintext)
Zeroized by
ECDSA keypair
deletion command
ECDSA public
key
ECDSA Curves:
P-256, 384, 521
Signature verification used in
IKE/IPSec and TLS. This key is
derived in compliance with FIPS
186-4 ECDSA key pair generation
method in the module.
DRAM
(plaintext)
Zeroized by
ECDSA keypair
deletion command
Enable secret Shared Secret At least eight
characters
The obfuscated password of the CO
role. However, the algorithm used to
obfuscate this password is not FIPS
approved. Therefore, this password is
considered plaintext for FIPS
purposes. This password is zeroized
by overwriting it with a new
password. The Crypto Officer
configures the module to obfuscate
the Enable password. This CSP is
entered by the Crypto Officer.
NVRAM
(plaintext)
Overwrite with
new password
TLS RSA
private key
RSA 2048 bits Identity certificates for the security
appliance itself and also used in TLS
negotiations. This key is generated
by calling SP 800-90A DRBG.
NVRAM
(plaintext)
Zeroized by RSA
keypair deletion
command
TLS RSA
public key
RSA 2048 bits Identity certificates for the security
appliance itself and also used in TLS
negotiations. This key is derived in
compliance with FIPS 186-4 RSA
key pair generation method in the
module.
NVRAM
(plaintext)
Zeroized by RSA
keypair deletion
command
TLS pre-master
secret
keying material At least eight
characters
Keying material created/derived
using asymmetric cryptography from
which new HTTPS session keys can
be created. 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
© Copyright 2018 Cisco Systems, Inc. 14
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Name CSP Type Size Description/Generation Storage Zeroization
TLS encryption
keys
Triple-
DES/AES/AES-
GCM
Triple-DES 192
bits or AES
128/192/256
bits
Used in HTTPS/TLS connections to
protect the session traffic. This key
was derived in the module.
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 was
derived in the module.
DRAM
(plaintext)
Automatically
when TLS session
is terminated
Table 6 Cryptographic Keys and CSPs
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:
Table 6 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 and RFC 7296 for IPSec/IKEv2. 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 counter portion of the IV is set by the module within its cryptographic boundary. When the
IV exhausts the maximum number of possible values for a given session key, the first party,
client or server, to encounter this condition will trigger a handshake to establish a new
encryption key. In case the module’s power is lost and then restored, a new key for use with
the AES GCM encryption/decryption shall be established. The module uses RFC 7296
compliant IKEv2 to establish the shared secret SKEYSEED from which the AES GCM
encryption keys are derived. When the IV exhausts the maximum number of possible values
for a given session key, the first party, client or server, to encounter this condition will trigger a
handshake to establish a new encryption key. In case the module’s power is lost and then
restored, a new key for use with the AES GCM encryption/decryption shall be established.
Algorithms
Cisco Security
Crypto (Firmware)
On-board Chip
(Cavium Nitrox III)
AES (128/192/256 CBC, GCM) 4905 2034/2035
Triple-DES (CBC, 3-key) 2559 1311
SHS (SHA-1/256/384/512) 4012 1780
HMAC (SHA-1/256/384/512) 3272 1233
RSA (KeyGen, SigGen and SigVer; PKCS1_V1_5; 2048bits) 2678
ECDSA (PKG, SigGen and SigVer; P-256, P-384, P-521) 1254
CTR_DRBG (AES-256) 1735
HASH_DRBG (SHA-512) 197
CVL Component (IKEv2, TLSv1.2, SSHv2) 1521
CKG (vendor affirmed)
© Copyright 2018 Cisco Systems, Inc. 15
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
 No parts of the SSH, TLS and IPSec protocols, other than the KDFs, have been tested by the
CAVP and CMVP.
 Each of TLS, SSH and IPSec protocols governs the generation of the respective Triple-DES
keys. Refer to RFC 5246 (TLS), RFC 4253 (SSH) and RFC 6071 (IPSec) 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 scenario 1 of section 5 in SP800-133. The resulting generated
symmetric key and the seed used in the asymmetric key generation are the unmodified output
from SP800-90A DRBG.
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:
 Diffie-Hellman (CVL Cert. #1521, key agreement; key establishment methodology
provides between 112 and 150 bits of encryption strength)
 EC Diffie-Hellman (CVL Cert. #1521, key agreement; key establishment methodology
provides between 128 and 256 bits of encryption strength)
 RSA (key wrapping; key establishment methodology provides 112 bits of encryption
strength)
 NDRNG (non-deterministic random number generator)
Non-Approved Cryptographic Algorithms
The module supports the following non-approved cryptographic algorithms that shall not be used
in FIPS mode of operation:
 Diffie-Hellman (key agreement; key establishment methodology less than 112 bits of
encryption strength; non-compliant)
 RSA (key wrapping; key establishment methodology less than 112 bits of encryption
strength; non-compliant)
 DES
 HMAC MD5
 MD5
 RC4
 HMAC-SHA1 is not allowed with key size under 112-bits
2.11 Self-Tests
The modules include 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
 Cisco Security Crypto POSTs (Firmware)
o AES Encrypt/Decrypt KATs
o DRBG KAT (Note: DRBG Health Tests as specified in SP800-90A Section 11.3 are
performed)
© Copyright 2018 Cisco Systems, Inc. 16
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
o Firmware Integrity Test (SHA-512)
o ECDSA (Sign and Verify) Power on Self-Test
o HMAC-SHA-1 KAT
o HMAC-SHA-256 KAT
o HMAC-SHA-384 KAT
o HMAC-SHA-512 KAT
o RSA KATs (separate KAT for signing; separate KAT for verification)
o SHA-1 KAT
o SHA-256 KAT
o SHA–384 KAT
o SHA-512 KAT
o Triple-DES Encrypt/Decrypt KATs
 On-board Chip POSTs (Hardware)
o AES Encrypt/Decrypt KATs
o DRBG KAT (Note: DRBG Health Tests as specified in SP800-90A Section 11.3 are
performed)
o HMAC-SHA-1 KAT
o HMAC-SHA-256 KAT
o HMAC-SHA-384 KAT
o HMAC-SHA-512 KAT
o SHA-1 KAT
o Triple-DES Encrypt/Decrypt KATs
 Conditional tests - Cisco Security Crypto
o RSA pairwise consistency test
o ECDSA pairwise consistency test
o Conditional IPSec Bypass test
o Continuous Random Number Generator test for SP800-90A DRBG
o Continuous Random Number Generator test for NDRNG
 Conditional tests - On-board Chip
o Continuous Random Number Generator test for SP800-90A DRBG
The security appliance 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 cryptographic systems are initialized but prior to the
initialization of the LAN’s interfaces; this prevents the security appliance from passing any data
during a power-on self-test failure. In the unlikely event that a power-on self-test fails, an error
message is displayed on the console followed by a security appliance 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 modules are 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.
© Copyright 2018 Cisco Systems, Inc. 17
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
3.1 Crypto Officer Guidance - System Initialization
The Cisco Firepower Threat Defense on 4K/9K Cryptographic Module was validated with FTD
version 6.2 (Firmware file name cisco-ftd.6.2.2.81.SPA.csp with patch file
cisco_FTD_SSP_Patch-6.2.2.3-66.sh.REL.tar). These are the only allowable images for FIPS-
approved mode of operation.
The Crypto Officer must configure and enforce the following initialization steps:
Step 1: Install Smart Licensing for Triple-DES/AES licenses to require the module to use
Triple-DES and AES.
Step 2: Enable “FIPS Mode” to allow the module to internally enforce FIPS-compliant
behavior by using the following commands
firepower# scope security
firepower /security # [enable | disable] fips-mode
firepower /security # [enable | disable] enable fips-mode
firepower /security # commit-buffer
firepower /security # connect local-mgmt
firepower(local-mgmt)# reboot
Step 3: Issue the following command to verify the FIPS mode:
firepower /security # show fips-mode
Note: the output from ‘show fips-mode’ should be “FIPS Mode Admin State: Enabled”
Step 4: Configure the module to use SSHv2. Note that all operators must still
authenticate after remote access is granted. The CO shall only use FIPS
approved/Allowed cryptographic algorithms listed above for SSHv2 configuration.
Step 5: If using a RADIUS/TACACS+ server for authentication, please configure an
IPSec/TLS tunnel to secure traffic between the module and the RADIUS/TACACS+
server. The RADIUS/TACACS+ shared secret must be at least 8 characters long.
Step 6: Configure the module such that any remote connections via Telnet are secured
through IPSec.
Step 7: Configure the module such that only FIPS-approved algorithms are used for
IPSec tunnels.
Step 8: Configure the module such that error messages can only be viewed by Crypto
Officer.
Step 9: Disable the TFTP server.
Step 10: Disable HTTP for performing system management in FIPS mode of operation.
HTTPS with TLS should always be used for Web-based management. The CO shall only
use FIPS approved/Allowed cryptographic algorithms listed above for TLS configuration.
Step 11: Ensure that installed digital certificates are signed using FIPS approved
algorithms.
Step 12: Reboot the module.