Cisco ASA and ISA Firepower Threat Defense Cryptographic Modules
FIPS 140-2 Security Policy
Level 2 Validation
Version 1.1
November 11, 2020
© Copyright 2020 Cisco Systems, Inc. 2
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
1 Introduction
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy for the Cisco ASA and ISA
Firepower Threat Defense Cryptographic Modules. The firmware version running on each
module is 6.4. This security policy describes how this module meets the security requirements of
FIPS 140-2 Level 2 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/projects/cryptographic-module-
validation-program.
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 2
2 Cryptographic Module Ports and Interfaces 2
3 Roles, Services, and Authentication 3
4 Finite State Model 2
5 Physical Security 2
6 Operational Environment N/A
7 Cryptographic Key management 2
8 Electromagnetic Interface/Electromagnetic Compatibility 2
9 Self-Tests 2
10 Design Assurance 2
11 Mitigation of Other Attacks N/A
Overall module validation level 2
Table 1 Module Validation Level
1.3 References
This document deals only with the operations and capabilities of the module listed in section 1.1
above as it relates to the technical terms of a FIPS 140-2 cryptographic module security policy.
More information is available from the following sources:
The Cisco Systems website contains information on the full line of Cisco Systems security. Please
refer to the following websites:
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 (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.
© Copyright 2020 Cisco Systems, Inc. 3
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
1.4 Terminology
In this document, the Firepower Threat Defense Cryptographic Module is referred to as FTD,
Cryptographic Module or Module.
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 ASA and ISA Firepower Threat Defense
Cryptographic Modules 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 2020 Cisco Systems, Inc. 4
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2 Cisco ASA and ISA Firepower Threat Defense Cryptographic Modules
The module provides cryptographic services to a solution which offers the combination of the
industry's most deployed stateful firewall with a comprehensive range of next-generation network
security services, intrusion prevention system (IPS), content security, secure unified
communications, TLSv1.2, SSHv2, IPSec/IKEv2, and Cryptographic Cipher Suite B.
The Firepower eXtensible Operating System (FX-OS), is a next-generation network and content
security solution. The FX-OS is part of the Firepower Threat Defense (FTD) and provides an
agile, open, built for scalability, consistent control, and simplified management. This makes it
easy to configure platform settings and interfaces, provision devices, and monitor system status.
The module runs on the following Cisco ASA 5500/ISA 3000 platform models:
• ASA 5508-X
• ASA 5516-X
• ISA 3000-4C
• ISA 3000-2C2F
2.1 Cryptographic Module Physical Characteristics
The module is an integrated network security module, which is designed to integrate into the
versatile units (ASA 5508-X, ASA 5516-X, ISA 3000-4C, and ISA 3000-2C2F).
2.2 Cryptographic Boundary
The module is a multiple-chip standalone cryptographic module. The cryptographic boundary is
defined as the entire modules’ chassis unit encompassing the "top," "front," "left," "right," “rear”
and "bottom" surfaces of the case along with associated opacity shields.
Diagram 1 Block Diagram
C
a
v
i
u
m
Mgmt
Port Ethernet
SFP
FMC Ethernet
over SFP
Console
Port
Intel
Atom
Octeon
C
a
vi
u
m
Process Manager
FTD 6.4
© Copyright 2020 Cisco Systems, Inc. 5
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
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
ASA 5508-X, ASA 5516-X, ISA 3000-4C, ISA 3000-2C2F
Physical Interface
Data Input
Interface
Ethernet ports
MGMT Port
Console Port
Data Output
Interface
Ethernet ports
MGMT Port
Console Port
Control Input
Interface
Ethernet ports
MGMT Port
Console Port
Reset Pin/Switch/Button
Status Output
Interface
Ethernet ports
MGMT Port
LEDs
Console Port
Power Interface Power Plug
Unused Interface USB Port (USB Type A port and mini-USB Type B Console port)
Table 2 Hardware/Physical Boundary Interfaces
2.4 Platform Overview
Figure 1 ASA 5508-X and ASA 5516-X Appliances Front Panel
Figure 2 ASA 5508-X and ASA 5516-X Appliances Rear Panel
1 Power Switch Standard power on/off switch
2 Power cord socket Chassis power-supply socket
3 Status LEDS LED status indicator
4 Network data ports Eight gigabit ethernet RJ-45 network I/O interface.
Each port includes pair of LED status.
5 Management port A gigabit Ethernet interface restricted to network
management access only
© Copyright 2020 Cisco Systems, Inc. 6
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
6 Console port Serial ports, mini USB and standard RJ-45 are
provided for management access. USB is not
allowed in FIPS mode
7 USB port Disallowed in FIPS mode
8 Reset button Small recessed button that is pressed for longer than
three seconds resets the unit.
9 SSD LED Status light for installed solid-state drive.
10 SSD bay Covered slot for SSD installation.
Table 3 ASA 5508-X and 5516-X rear panel description
Figure 3: ISA 3000-4C (Left) and ISA 3000-2C2F (Right) Appliance Front 2F
1 Reset Pinhole Access 10 RJ45 10/100/100 BaseT Connectors 1&2
2 Console LED 11 On the ISA-3000-2C2F SKU, these are
the SFP sockets.
On the ISA-3000-4C SKU, these are
RJ45 10/100/100 BaseT Connectors 3&4,
3 System LED 12 SD Card Slots
4 Console connector (RJ-45) 13 Alarm Connectors
5 Console connector (mini-USB) 14 Grounding Point
6 USB connectors 15 Alarm LEDs
7 Management Interface 16 DC Power LEDs
8 DC power connection A 17 Gig Ethernet LEDs
9 DC power connection B 18 Management LED
Table 4 ISA 3000-4C and ISA 3000-2C2F front panel description
Note: Item 11 in Figue 3 above is the only difference in between.
11
© Copyright 2020 Cisco Systems, Inc. 7
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.5 Roles and Services
The appliances can be accessed in one of the following ways:
• Console Port
• IPSec/IKEv2
• SSHv2
• HTTPS/TLSv1.2
Authentication is identity-based. As required by FIPS 140-2, there are two roles that operators
may assume: 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.
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 2112
chance of
randomly obtaining the key, which is much stronger than the one in a million chances 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.6 User Services
A User enters the system by either Console port, SSHv2 or HTTPS/TLSv1.2. 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 other means of accessing the console is via an
IPSec/IKEv2 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:
© Copyright 2020 Cisco Systems, Inc. 8
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Services Description Keys and CSPs Access
Status Functions View state of interfaces and protocols,
version of the firmware currently running.
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 encrypt key, IKE session
authentication key, ISAKMP preshared, IKE
authentication private Key, IKE authentication
public key, IPsec encryption key and IPsec
authentication key (r, w, d)
SSHv2 Functions Negotiation and encrypted data transport via
SSHv2.
Operator password, DRBG entropy input, DRBG
seed, DRBG V, DRBG key, SSHv2 private key,
SSHv2 public key, SSHv2 session key and SSHv2
integrity key (r, w, d)
HTTPS Functions
(TLSv1.2)
Negotiation and encrypted data transport via
HTTPS/TLS(TLSv1.2).
Operator password, DRBG entropy input, DRBG
seed, DRBG V, DRBG 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 and TLS
integrity key (r, w, d)
Table 5 User Services
2.7 Crypto Officer Services
A Crypto Officer (CO) enters the system by accessing the Console port, SSH v2 or
HTTPS/TLSv1.2. The CO role can be authenticated via either Username/Password or RSA based
authentication method. The other means of accessing the console is via an IPSec/IKEv2 session.
This session is authenticated either using a shared secret or RSA digital signature authentication
mechanism. A Crypto Officer may assign permission to access the Crypto Officer role to
additional accounts, thereby creating additional Crypto Officers.
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 and Access Description Keys and CSPs
Configure the Security Define network interfaces and settings, create
command aliases, set the protocols the router 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
session key, SSHv2 integrity 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, 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)
© Copyright 2020 Cisco Systems, Inc. 9
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Firmware Initialization Conduct the firmware initialization. N/A
Configure External
Authentication Server
Configure RADIUS or TACACS+ authentication
server
• RADIUS: Remote Authentication Dial-In
User Service.
• TACACS+: Terminal Access Controller
Access-Control System
RADIUS secret, TACACS+ secret (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 router 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)
Configure
Encryption/Bypass
Set up the configuration tables for IP tunneling. Set
preshared keys and algorithms to be used for each IP
range or allow plaintext packets to be set from
specified IP address. Setup the rules for Bypass
operation.
DRBG entropy input, DRBG seed, DRBG V,
DRBG key, ISAKMP preshared, Operator
password, Enable password, SKEYSEED, IKE
session encrypt key, IKE session authentication key,
IKE authentication private Key, IKE authentication
public key, IPsec encryption key and IPsec
authentication key (r, w, d)
TLS VPN (TLSv1.2) Configure SSL VPN parameters, provide entry and
output of CSPs.
DRBG entropy input, DRBG seed, DRBG V,
DRBG 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 and TLS integrity key (r, w, d)
SSHv2 Function Configure SSHv2 parameter, provide entry and
output of CSPs.
DRBG entropy input, DRBG seed, DRBG V,
DRBG key, SSHv2 private key, SSHv2 public key.
SSHv2 session key and SSHv2 integrity key (r, w,
d)
IPsec VPN Function Configure IPsec VPN parameters, provide entry and
output of CSPs.
DRBG entropy input, DRBG seed, DRBG V DRBG
key, ISAKMP preshared, SKEYSEED, IKE session
encrypt key, IKE session authentication key, IKE
authentication private Key, IKE authentication
public key, IPsec encryption key and IPsec
authentication 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)
Local Certificate
Authority
Allows the module to be configured as a Root
Certificate Authority and issue user certificates for
SSL VPN use (AnyConnect and Clientless). The
ASA can then be configured to require client
certificates for authentication.
N/A
Zeroization Zeroize cryptographic keys/CSPs by running the
zeroization methods classified in table 7, Zeroization
column.
All CSPs (d)
Table 6 Crypto Officer Services
2.8 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 2020 Cisco Systems, Inc. 10
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.8, the Crypto Officer must zeroize all
CSPs which places the module into the 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
IPSec
Hashing: MD5
MACing: HMAC-SHA-1, 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 7 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
https://www.cisco.com/c/en/us/td/docs/security/firepower/640/fdm/fptd-fdm-config-guide-
640/fptd-fdm-advanced.html. This site lists all configuration guides.
2.9 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.10 Operational Environment
The module is a hardware module. The Cisco operating system provides a proprietary and non-
modifiable operating system. Thus, the requirements from FIPS 140-2 level 2, section 4.6.1, are
not applicable to the module.
2.11 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 IKEv2, TLSv1.2, and SSHv2 are used for electronic
distribution. The entropy source used by the module falls into IG 7.14, Scenario #1a: A hardware
module with an entropy-generating NDRNG inside the module’s cryptographic boundary. The
module provides at least 256 bits entropy to instantiate the DRBG.
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 2020 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
DRBG entropy
input
SP800-90A
CTR_DRBG
(AES-256)
384-bits This is the entropy input 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 the 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
(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, 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. 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
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. Note that the public
key is a cryptographic key, but not
considered a CSP.
DRAM
(plaintext)
Power cycle the
device
© Copyright 2020 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
SKEYSEED Keying material 160 bits Keying material 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)
Power cycle the
device
IKE session
encrypt key
Triple-DES/AES Triple-DES 192 bits
or AES 128/192/256
bits
The IKE session (IKE Phase I) encrypt key.
This key is derived via key derivation
function defined in SP800-135 KDF
(IKEv2).
DRAM
(plaintext)
Power cycle the
device
IKE session
authentication
key
HMAC-SHA-
256/384/512
256-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)
Power cycle the
device
ISAKMP
preshared
Pre-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)
Overwrite with
new secret
IKE
authentication
private Key
RSA/ECDSA RSA (2048 bits) or
ECDSA (Curves:
P-256/P-384/512)
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
IKE
authentication
public key
RSA/ECDSA RSA (2048 bits) or
ECDSA (Curves:
P-256/P-384/512)
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.
Note that the public key is a cryptographic
key, but not considered a CSP.
NVRAM
(plaintext)
Zeroized by
RSA/ECDSA
keypair deletion
command
IPsec encryption
key
Triple-DES, AES
or 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)
Power cycle the
device
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)
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)
Erase password
Enable password Password 8 plus characters The password of the CO role. This CSP is
entered by the Crypto Officer.
NVRAM
(plaintext)
Erase 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)
Erase 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)
Erase secret
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
© Copyright 2020 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 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 192 bits Triple-DES
or 128/192/256 bits
AES
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)
Power cycle the
device
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
ECDSA private
key
ECDSA Curves:
P-256,384,521
Key pair generation, signature
generation/Verification. 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
Key pair generation, signature
generation/Verification. 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.
DRAM
(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 IPSec, TLS, and SSH
negotiations. This key was generated by
calling FIPS approved 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 negotiations. 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
or AES-GCM
Triple-DES 192 bits
or AES 128/192/256
bits
Used in HTTPS/TLS connections. Generated
using TLS protocol. This key is derived via
key derivation function defined in SP800-135
KDF (TLSv2).
DRAM
(plaintext)
Automatically
when TLS session
is terminated
© Copyright 2020 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 Integrity
Key
HMAC-
SHA256/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 (TLSv2)
DRAM
(plaintext)
Automatically
when TLS session
is terminated
Table 8 Cryptographic Keys and CSPs
2.12 Cryptographic Algorithms
The module implements a variety of approved and non-approved algorithms.
2.11.1 Approved Cryptographic Algorithms
The module supports the following FIPS 140-2 approved algorithm implementations:
Table 9 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 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 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. The operations of one of the two
parties involved in the IKE key establishment scheme shall be performed entirely within
the cryptographic boundary of the module being validated. 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
Algorithm
Cisco Security Crypto
(Firmware on each module)
Cavium Octeon III
(Only on ASA5508-X and 5516-X)
AES (128/192/256 CBC, GCM) 4905 3301
Triple-DES (CBC, 3-key) 2559 1881
SHS (SHA-1/256/384/512) 4012 2737
HMAC (SHA-1/256/384/512) 3272 2095
RSA (KeyGen, SigGen and SigVer; PKCS1_V1_5; 2048bits
with SHA-256/384/512)
2678
ECDSA (PKG, SigGen and SigVer; P-256, P-384, P-521) 1254
CTR_DRBG (AES-256) 1735 819
CVL Component (IKEv2, TLSv1.2, SSHv2) 1521
CKG (vendor affirmed)
© Copyright 2020 Cisco Systems, Inc. 15
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
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, 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
.
• No parts of the SSH, TLS and IPSec protocols, other than the KDFs, have been tested by
the CAVP and CMVP.
• 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 seed used in the asymmetric key generation are the unmodified output from
SP800-90A DRBG.
2.11.2 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 (entropy source)
2.11.3 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.13 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 ensure all components are
functioning correctly. The FIPS power-on self-tests are run regardless of the FIPS mode setting.
© Copyright 2020 Cisco Systems, Inc. 16
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Self-tests performed
• POSTs – Cisco Security Crypto (Firmware on each module)
o AES CBC Encrypt/Decrypt KATs
o AES GCM KATs
o DRBG KAT (Note: DRBG Health Tests as specified in SP800-90A Section 11.3
are performed)
o ECDSA (sign and verify) Power On Self-Test
o Firmware Integrity Test (SHA-512)
o HMAC (SHA-1/256/384/512) Known Answer Tests
o SHA-1/256/384/512 KATs
o Triple-DES CBC Encrypt/Decrypt KATs
• POSTs - On-board Hardware (only on ASA 5508-X and 5516-X)
o AES CBC Encrypt/Decrypt KATs
o DRBG KAT (Note: DRBG Health Tests as specified in SP800-90A Section 11.3
are performed)
o HMAC (SHA-1/256/384/512) Known Answer Tests
o SHA-1/256/384/512 KATs
o Triple-DES CBC Encrypt/Decrypt KATs
• Conditional Tests - Cisco Security Crypto (Firmware on each module)
o RSA PWCT
o ECDSA PWCT
o Conditional Bypass test
o CRNGT for SP800-90A DRBG
o CRNGT for NDRNG
• Conditional Tests - On-board Hardware (only on ASA 5508-X and 5516-X)
o CRNGT for SP800-90A DRBG
o CRNGT for NDRNG
Note: DRBGs will not be available should the NDRNG become unavailable. This will in turn
make the associated security service/CSP outlined above in Table 8 non-available.
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 cryptographic systems are initialized but prior to the
initialization of the LAN’s interfaces; this prevents the security appliances 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.
2.14 Physical Security
The FIPS 140-2 level 2 physical security requirements for the modules are met by the use of opacity
shields covering the front panels of modules to provide the required opacity and tamper evident
seals to provide the required tamper evidence.
© Copyright 2020 Cisco Systems, Inc. 17
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.14.1 Opacity Shield Security
The following table shows the tamper labels and opacity shields that shall be installed on the
modules to operate in a FIPS approved mode of operation. The CO is responsible for using,
securing and having control at all times of any unused tamper evident labels. Actions to be taken
when any evidence of tampering should be addressed within site security program.
ASA Models Number
Tamper
labels
Tamper Evident Labels Number
Opacity
Shields
Opacity Shields
ASA 5508-X 5 AIR-AP-FIPSKIT= 1 ASA5508-FIPS-KIT=
ASA 5516-X 5 AIR-AP-FIPSKIT= 1 ASA5516-FIPS-KIT=
ISA 3000-4C and ISA 3000-
2C2F
4 AIR-AP-FIPSKIT= 0 None
Table 10 Tamper Labels and Opacity Shield Quantities
ASA 5508-X and ASA 5516-X Opacity Shield
To install an opacity shield on the ASA 5508-X or ASA 5516-X rear, follow these steps:
Step 1: Power off the ASA.
Step 2: Remove the two screws.
Step 3: Place the shield over the vent areas and insert the screws.
Figure 4 ASA 5508-X and ASA 5516-X Opacity Shield Placement
2.14.2 Tamper Evidence Labels (TELs)
The tamper evident seals (hereinafter referred to as tamper evident labels (TEL)) shall be installed
on the security devices containing the module prior to operating in FIPS mode. TELs shall be
applied as depicted in the figures below. Any unused TELs must be securely stored, accounted
for, and maintained by the CO in a protected location.
Should the CO have to remove, change or replace TELs (tamper-evidence labels) for any reason,
the CO must examine the location from which the TEL was removed and ensure that no residual
debris is still remaining on the chassis or card. If residual debris remains, the CO must remove
the debris using a damp cloth.
Any deviation of the TELs placement such as tearing, misconfiguration, removal, change,
replacement or any other change in the TELs from its original configuration as depicted below by
unauthorized operators shall mean the module is no longer in FIPS mode of operation. Returning
the system back to FIPS mode of operation requires the replacement of the TEL as depicted below
© Copyright 2020 Cisco Systems, Inc. 18
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
and any additional requirement per the site security policy which are out of scope of this Security
Policy.
The Crypto Officer shall inspect the seals for evidence of tamper as determined by their deployment
policies (every 30 days is recommended). If the seals show evidence of tamper, the Crypto Officer
shall assume that the modules have been compromised and contact Cisco accordingly.
To seal the system, apply tamper-evidence labels as depicted in the figures below.
Figure 5 ASA 5508-X Front View
Figure 6 ASA 5508-X Right Side TEL Location
Figure 7 ASA 5508-X Left Side TEL Location
Figure 8 ASA 5508-X Rear TEL Location
2
1
2
1
3
5
4
© Copyright 2020 Cisco Systems, Inc. 19
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 1 ASA 5508-X Top TEL Location
Figure 10 ASA 5508-X Bottom TEL Location
Figure 11 ASA 5516-X Front View
1
2
3
4
5
1 2
© Copyright 2020 Cisco Systems, Inc. 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 12 ASA 5516-X Right Side TEL Location
Figure 13 ASA 5516-X Left Side TEL Location
Figure 14 ASA 5516-X Rear TEL Location
Figure 15 ASA 5516-X Top TEL Location
2
1
4
3
5
3
2
1
© Copyright 2020 Cisco Systems, Inc. 21
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 16 ASA 5516-X Bottom TEL Location
Figure 17 ISA 3000 (both 3000-4C and 3000-2C2F) Front TEL Location
4
5
1
© Copyright 2020 Cisco Systems, Inc. 22
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 18 ISA 3000 (both 3000-4C and 3000-2C2F) Right Side View
Figure 19 ISA 3000 (both 3000-4C and 3000-2C2F) Left Side View
© Copyright 2020 Cisco Systems, Inc. 23
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 20 ISA 3000 (both 3000-4C and 3000-2C2F) Rear TEL Location
Figure 21 ISA 3000 (both 3000-4C and 3000-2C2F) Top TEL Location
2
3
4
4
© Copyright 2020 Cisco Systems, Inc. 24
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 22 ISA 3000 (both 3000-4C and 3000-2C2F) Bottom TEL Location
Appling Tamper Evidence Labels
Step 1: Turn off and unplug the system before cleaning the chassis and applying labels.
Step 2: Clean the chassis of any grease, dirt, or oil before applying the tamper evident labels.
Alcohol-based cleaning pads are recommended for this purpose.
Step 3: Apply a label to cover the security appliance as shown in figures above.
The tamper evident seals are produced from a special thin gauge vinyl with self-adhesive backing.
Any attempt to open the device will damage the tamper evident seals or the material of the
security appliance cover. Because the tamper evident seals have non-repeated serial numbers,
they may be inspected for damage and compared against the applied serial numbers to verify that
the security appliance has not been tampered with. Tamper evident seals can also be inspected for
signs of tampering, which include the following: curled corners, rips, and slices. The tamper
evidence shall appear if the label was peeled back.
3 Secure Operation
The module meets all the Level 2 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 instructions provided below to
place the module in FIPS-approved mode. Operating this module without maintaining the
following settings prevents the module from being placed into FIPS approved mode of operation.
3.1 Crypto Officer Guidance - System Initialization
The module was validated with FTD version 6.4. This is the only allowable image for FIPS-
approved mode of operation.
The Crypto Officer must configure and enforce the following initialization steps:
2 3
© Copyright 2020 Cisco Systems, Inc. 25
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
1. The Crypto Officer must install opacity shields as described in Section 2.14 of this
document.
2. The Crypto Officer must apply tamper evidence labels as described in Section 2.14 of this
document.
3. Power on the systems. Then when prompted, enter the default username “admin”
and the password “Admin123”. After that, the CO needs to replace the default
password with a new password.
4. Configure the management IP and answer all the prompt questions. After this is done you
have set up the configure file. It will ask if you want to manage it locally. This will mean
you are managing it through FDM (Firepower Device Manager) for local or FMC
(Firepower Management Center).
Note: ASA/ISA with FTD can be managed by FMC or FDM.
5. Install Triple-DES/AES licenses to require the security appliances to use
Triple-DES and AES.
6. Enable “FIPS Mode” to allow the module to internally enforce FIPS-compliant
behavior.
7. 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.
8. Configure the module such that any remote connections via Telnet are secured
through IPSec.
9. Configure the module such that only FIPS-approved algorithms are used for
IPSec tunnels.
10. Configure the module such that error messages can only be viewed by Crypto
Officer.
11. Disable the TFTP server.
12. 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.
13. Ensure that installed digital certificates are signed using FIPS approved
algorithms.
14. Reboot the module.