Cisco Firepower Cryptographic Module
FIPS 140-2 Non Proprietary Security Policy
Level 1 Validation
Version 0.3
July 11, 2017
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 ON ADAPTIVE SECURITY APPLIANCES .............................. 5
2.1 CRYPTOGRAPHIC MODULE CHARACTERISTICS ................................................................... 5
2.2 MODULE INTERFACES......................................................................................................... 6
2.3 ROLES AND SERVICES......................................................................................................... 7
2.4 USER SERVICES .................................................................................................................. 7
2.5 CRYPTO OFFICER SERVICES................................................................................................ 8
2.6 NON-FIPS MODE SERVICES ................................................................................................ 8
2.7 UNAUTHENTICATED SERVICES ........................................................................................... 9
2.8 CRYPTOGRAPHIC KEY/CSP MANAGEMENT........................................................................ 9
2.9 CRYPTOGRAPHIC ALGORITHMS ........................................................................................ 12
Approved Cryptographic Algorithms ................................................................................................................................ 12
Non-FIPS Approved Algorithms Allowed in FIPS Mode ................................................................................................. 13
Non-Approved Cryptographic Algorithms ........................................................................................................................ 13
2.10 SELF-TESTS ...................................................................................................................... 13
3 SECURE OPERATION ...................................................................................................... 14
3.1 CRYPTO OFFICER GUIDANCE - SYSTEM INITIALIZATION .................................................. 14
© Copyright 2017 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 a non-proprietary Cryptographic Module Security Policy for the Cisco Firepower
Cryptographic Module firmware 6.1 on the Cisco Adaptive Security Appliances. This security
policy describes how the 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 and 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 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/en/US/products/ps6120/index.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 2017 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 Cryptographic Module is referred to as Firepower
Cryptographic Module, Firepower 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 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 appliances. 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 2017 Cisco Systems, Inc. 5
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2 Cisco Firepower on Adaptive Security Appliances
Cisco® Firepower provides balanced security effectiveness with productivity. The module is
designed to help handle network traffic in a way that complies with an organization’s security
policy—guidelines for protecting a network. A security policy may also include an acceptable
use policy (AUP), which provides employees with guidelines of how they may use an
organization’s systems. The module running on Cisco Adaptive Security Appliances (ASA)
provides TLSv1.2 and SSHv2 security services.
2.1 Cryptographic Module Characteristics
The Firepower Cryptographic Module is defined as a multiple-chip standalone cryptographic
module. Deployed inline, the system can affect the flow of traffic using access control, which
allows the ability to specify, in a granular fashion, how to handle the traffic entering, exiting, and
traversing a network. The data collected about network traffic and all information gleaned from
it can be used to filter and control that traffic.
The module was tested in the lab on the following platforms running non-modifiable Linux, Fire
Linux OS 6.1:
# Platform Operating System
1 Cisco ASA 5506-X Fire Linux OS 6.1
2 Cisco ASA 5506H-X Fire Linux OS 6.1
3 Cisco ASA 5506W-X Fire Linux OS 6.1
4 Cisco ASA 5508-X Fire Linux OS 6.1
5 Cisco ASA 5516-X Fire Linux OS 6.1
6 Cisco ASA 5512-X Fire Linux OS 6.1
7 Cisco ASA 5515-X Fire Linux OS 6.1
8 Cisco ASA 5525-X Fire Linux OS 6.1
9 Cisco ASA 5545-X Fire Linux OS 6.1
10 Cisco ASA 5555-X Fire Linux OS 6.1
Table 2 Tested Platforms
© Copyright 2017 Cisco Systems, Inc. 6
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Diagram 1 Block Diagram
2.2 Module Interfaces
The physical interfaces provided by the Cisco ASA platforms are mapped to the following FIPS
140-2 defined logical interfaces: data input, data output, control input and status output. The
logical interfaces and their mapping are described in the following table:
FIPS 140-2 Logical Interface Logical Interface Physical Interface
Data Input Interface API input parameters Mgmt port
Console Port
Ethernet Ports
Data Output Interface API output parameters Mgmt port
Console Port
Ethernet Ports
Control Input Interface API function calls Mgmt port
Console Port
Ethernet Ports
Status Output Interface API return codes Mgmt port
Console Port
Ethernet Ports
Table 3 Module Interfaces
Intel Processor
Firepower
CM
Mgmt Port Console Port
API
Data Port
FMC FOM
Crypto
© Copyright 2017 Cisco Systems, Inc. 7
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.3 Roles and Services
The module can be accessed via the API which connects to Console port, Data ports and Mgmt
port by using one the following security services:
 HTTPS/TLS
 SSH v2
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 appliances that
operators may assume: Crypto Officer role and User role. The administrator of the security
appliances 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 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, the RSA key pair has a modulus size of 2048
bits, thus providing 112 bits of strength. Assuming the low end of that range, 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 1.8x1021
attempts per minute, which far exceeds the operational capabilities of the module to support.
2.4 User Services
After entering the system via the API, the User is prompted for the 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
zeroize/delete (d) – and which role accesses the CSPs are listed below:
Services and Access Description Keys and CSPs
Status Functions View state of interfaces, protocols and
firepower firmware version currently running.
Operator password (r)
Terminal Functions Adjust the terminal session (e.g., lock the
terminal, adjust flow control).
Operator password (r)
Directory Services Display directory of files kept in flash memory. Operator password (r)
Self-Tests Execute the FIPS 140 start-up tests on demand. N/A
SSH v2 Functions Negotiation and encrypted data transport via
SSH.
Operator password, DH private DH public key, DH Shared Secret,
ECDH private ECDH public key, ECDH Shared Secret, SSH RSA
private key, SSH RSA public key, SSH session key, DRBG Seed,
DRBG entropy input, DRBG V, DRBG Key (r, w, d)
TLS v1.2 Functions Negotiation and encrypted data transport via
TLS.
ECDSA private key, ECDSA public key, TLS RSA private key,
TLS RSA public key, TLS pre-master secret, TLS traffic keys
DRBG entropy input, DRBG Seed, DRBG V, DRBG Key (r, w, d)
Table 4 User Services
© Copyright 2017 Cisco Systems, Inc. 8
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.5 Crypto Officer Services
The Crypto Officer role is responsible for the configuration of the module. After entering the
system via the API, the CO is prompted for username and password. If the password is correct,
the CO role is allowed entry to the module management functionality. The services available to
the Crypto Officer role accessing the CSPs, the type of access – read (r), write (w) and
zeroize/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 module will support, enable
interfaces and network services, set system date and time, and
load authentication information.
ECDSA private key, ECDSA public key, TLS
RSA private key, TLS RSA public key, TLS
pre-master secret, TLS traffic keys, DRBG
Seed, DRBG entropy input, DRBG V, DRBG
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.
Operator password, Enable password (r, w, d)
TLS v1.2 Functions Configure 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 traffic keys, DRBG
entropy input, DRBG Seed, DRBG V, DRBG
Key (r, w, d)
SSH v2 Configure SSH v2 parameter, provide entry and output of
CSPs.
DH private DH public key, DH Shared Secret,
ECDH private ECDH public key, ECDH Shared
Secret, SSH RSA private key, SSH RSA public
key, SSH session key, DRBG entropy input,
DRBG Seed, DRBG V, 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)
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 exists. 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 services in Section 2.6, the Crypto Officer
must zeroize all CSPs which places the module into the non-FIPS mode of operation.
© Copyright 2017 Cisco Systems, Inc. 9
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
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.
All services available can be found at http://www.cisco.com/c/en/us/support/security/asa-5500-
series-next-generation-firewalls/products-installation-and-configuration-guides-list.html
2.7 Unauthenticated Services
The service for someone without an authorized role is to cycle power the module.
2.8 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.
The Crypto Officer needs to be authenticated to store keys. All Diffie-Hellman (DH)/ECDH keys
agreed upon for individual sessions are directly associated with that specific session. The
/dev/urandom device extracts bits from the urandom pool. This output is used directly to seed
the NIST SP 800-90A CTR_DRBG.
Name CSP Type Size Description/Generation Storage Zeroization
DRBG entropy
input
SP800-90A
CTR_DRBG
384-bits This is the entropy for SP 800-
90A CTR_DRBG. Software
based entropy source used to
construct seed.
DRAM
(plaintext)
Power cycle the
device
DRBG Seed SP800-90A
CTR_DRBG
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 a software -based
entropy source.
DRAM
(plaintext)
Power cycle the
device
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 2017 Cisco Systems, Inc. 10
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Name CSP Type Size Description/Generation Storage Zeroization
DRBG V SP800-90A
CTR_DRBG
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
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, 3072, 4096
bits
The shared secret used in
Diffie-Hellman (DH)
exchange. Established per the
Diffie-Hellman key
agreement.
DRAM
(plaintext)
Power cycle the
device
Diffie Hellman
private key
DH 224, 256, 384 bits The private key used in Diffie-
Hellman (DH) exchange. This
key is generated by calling
SP800-90A DRBG.
DRAM
(plaintext)
Power cycle the
device
Diffie Hellman
public key
DH 2048, 3072, 4096
bits
The public key used in Diffie-
Hellman (DH) exchange. This
key is derived per the Diffie-
Hellman key agreement.
DRAM
(plaintext)
Power cycle the
device
EC Diffie-
Hellman Shared
Secret
EC DH Curves:
P-256,P-384,P-521
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
EC DH Curves:
P-256,P-384,P-521
The private key used in EC
Diffie-Hellman (DH)
exchange. This key is
generated by calling SP800-
90A DRBG.
DRAM
(plaintext)
Power cycle the
device
EC Diffie
Hellman public
key
EC DH Curves:
P-256,P-384,P-521
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
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
© Copyright 2017 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
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
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)
Reset to factory
defaults
SSHv2 Public
Key
RSA 2048 bits modulus The SSHv2 public key used in
SSHv2 connection. This key is
internally generated by the
module.
NVRAM
(plaintext)
Reset to factory
defaults
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)
Automatically when
SSH session is
terminated
ECDSA private
key
ECDSA Curves:
P-256,P-384,P-521
Key pair generation, signature
generation/Verification. Used
in TLS connections. This key
is generated by calling SP 800-
90A DRBG.
NVRAM
(plaintext)
Reset to factory
defaults
ECDSA public
key
ECDSA Curves:
P-256,P-384,P-521
Key pair generation, signature
generation/Verification. This
key is generated by calling SP
800-90A DRBG.
NVRAM
(plaintext)
Reset to factory
defaults
TLS RSA private
keys
RSA 2048 bits Identity certificates for the
security appliance itself and
also used in TLS negotiations.
This key was generated by
calling FIPS approved DRBG.
NVRAM
(plaintext)
Reset to factory
defaults
TLS RSA public
keys
RSA 2048 bits Identity certificates for the
security appliance itself and
also used in TLS negotiations.
This key was generated by
calling FIPS approved DRBG.
NVRAM
(plain text)
Reset to factory
defaults
TLS pre-master
secret
Shared Secret At least eight
characters
Shared secret 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.
© Copyright 2017 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
TLS traffic keys Triple-DES/AES
128/192/256
HMAC-
SHA1/256/384/512
192 bits Triple-
DES or
128/192/256 bits
AES
Used in HTTPS connections.
Generated using TLS protocol.
This key was derived in the
module.
DRAM
(plain text)
Automatically when
TLS session is
terminated
Integrity test key RSA-2048 Public
key
2048 bits A hard coded key used for
firmware power-up/load
integrity verification.
Hard coded
for
firmware
integrity
testing
Zeroized by erase
flash (or replacing),
write to startup
config, followed by
a module reboot
Table 7 Cryptographic Keys and CSPs
Note: For key generation, the generated random value to be used in the asymmetric key
generation is an unmodified output from the DRBG (Cert. #1337). Please refer to SP800-133,
section 5 for more information.
2.9 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 Implementations
AES (128/192/256 CBC, GCM) 4266
Triple-DES (CBC, 3-key) 2307
SHS (SHA-1/256/384/512) 3512
HMAC (SHA-1/256/384/512) 2811
RSA (PKCS1_V1_5; KeyGen, SigGen, SigVer; 2048 bits) 2297
ECDSA (KeyGen, SigGen, SigVer; P-256, P-384, P-521) 995
DRBG (AES256 CTR) 1337
CVL Component (TLS and SSH) 1008
Table 8 Approved Cryptographic Algorithms and Associated Certificate Number
Note:
 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.
 Per SP800-67 rev1, the user is responsible for ensuring the module’s limit to 2^32
encryptions with the same Triple-DES key while being used in SSH or TLS protocol.
 The module's AES-GCM implementation conforms to IG A.5 scenario #1 following RFC
5288 for TLS. The module uses basically a 96-bit IV, which is comprised of a 4 byte salt
unique to the crypto session and a deterministic, 8 byte monotonically increasing counter.
The module rekeys prior to the IV hitting its maximum number of 2^64
-1. The module
generates new AES-GCM keys if the module loses power.
© Copyright 2017 Cisco Systems, Inc. 13
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
 The SSH and TLS protocols have not been reviewed or 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:
 Diffie-Hellman (key agreement; key establishment methodology provides between 112
and 150 bits of encryption strength)
 EC Diffie-Hellman ((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
 HMAC MD5 is allowed in FIPS mode strictly for TLS
 MD5 is allowed in FIPS mode strictly for TLS
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
Note: The non-approved algorithms HMAC MD5 and MD5 are not allowed in FIPS mode when
not used with TLS.
2.10 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 Known Answer Tests (Separate encrypt and decrypt)
o AES-GCM Known Answer Tests (Separate encrypt and decrypt)
o DRBG Known Answer Test (Note: DRBG Health Tests as specified in SP800-
90A Section 11.3 are performed)
o FIPS 186-4 ECDSA Sign/Verify Test
o HMAC Known Answer Tests
© Copyright 2017 Cisco Systems, Inc. 14
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
 HMAC-SHA1 Known Answer Test
 HMAC-SHA256 Known Answer Test
 HMAC-SHA384 Known Answer Test
 HMAC-SHA512 Known Answer Test
o FIPS 186-4 RSA Known Answer Tests (Separate KAT for signing; Separate KAT
for verification)
o SHA-1 Known Answer Test
o Firmware Integrity Test (HMAC-SHA512)
o Triple-DES Known Answer Tests (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 module’s interfaces; this prevents the security module 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 via the API and followed by a 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
The Cisco Firepower Cryptographic Module version 6.1 was validated using the firmware image
asasfr-5500x-boot-6.1.0-330.img and Cisco_Network_Sensor_Patch-6.1.0.3-41.sh. Only the
approved/allowed algorithms listed above and these images shall be used for FIPS-approved
mode.
The Crypto Officer must configure and enforce the following initialization steps:
Step 1: Login to the device and accept the End User Agreement
Step 2: Change the default password
Step 3: Configure network settings, create default SSL policy
Step 4: Log out and reboot the module.