Cisco Network Convergence System 1001 Cryptographic
Module
FIPS 140-2 Non-Proprietary Security Policy
Level 2 Validation
Documentation Version 1.5
December 10, 2020
Table of Contents
CISCO NETWORK CONVERGENCE SYSTEM 1001 CRYPTOGRAPHIC MODULE ... 1
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 NETWORK CONVERGENCE SYSTEM 1001 APPLIANCE ........................... 5
2.1 VALIDATED CONFIGURATION ............................................................................................. 5
2.2 CRYPTOGRAPHIC BOUNDARY............................................................................................. 6
2.3 MODULE INTERFACES......................................................................................................... 6
2.4 CISCO NCS 1001 FRONT AND REAR PANELS...................................................................... 7
3. ROLES, SERVICES, AND AUTHENTICATION ........................................................... 10
3.1 USER SERVICES ................................................................................................................ 10
3.2 CRYPTO OFFICER SERVICES.............................................................................................. 11
3.3 NON-FIPS MODE SERVICES .............................................................................................. 12
3.4 UNAUTHENTICATED SERVICES ......................................................................................... 12
4. CRYPTOGRAPHIC KEY/CSP MANAGEMENT........................................................... 13
5. CRYPTOGRAPHIC ALGORITHMS............................................................................... 16
5.1 APPROVED CRYPTOGRAPHIC ALGORITHMS ...................................................................... 16
5.2 NON-FIPS APPROVED ALGORITHMS ALLOWED IN FIPS MODE ....................................... 16
5.3 NON-APPROVED CRYPTOGRAPHIC ALGORITHMS ............................................................. 16
6. SELF-TESTS........................................................................................................................ 17
7. PHYSICAL SECURITY...................................................................................................... 17
8. SECURE OPERATION ...................................................................................................... 21
8.1 INITIAL SETUP .................................................................................................................. 21
© Copyright 2020 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 Network
Convergence System 1001 Cryptographic Module running with firmware version IOS XR 7.0.1.
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 with the specification of the security rules listed in Table 1 above, under
which the Cisco Network Convergence System 1001 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
https://www.cisco.com/c/en/us/support/optical-networking/network-convergence-system-
1001/model.html
For answers to technical or sales related questions please refer to the contacts listed on the Cisco
Systems website at www.cisco.com.
© Copyright 2020 Cisco Systems, Inc. 4
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
The NIST Validated Modules website (https://csrc.nist.gov/projects/cryptographic-module-
validation-program/validated-modules) contains contact information for answers to technical or
sales-related questions for the module.
1.4 Terminology
In this document, the Cisco Network Convergence System 1001 Cryptographic Module is
referred to as NCS1K, NCS 1001, Cryptographic Module, CM, Module, Appliances or Systems.
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 Network Convergence System 1001
Cryptographic Module s 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 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. 5
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2 Cisco Network Convergence System 1001 Appliance
Rapid capacity growth in the data center and between data centers has driven the need for cloud-
scale networking solutions that allow for quick and simple turn-up with enhanced monitoring,
deliver performance optimization for capacity scale through modulation and baud-rate
innovations, and effectively support multiple vendors’ transponder solutions. The Cisco®
Network Convergence System 1001 (NCS 1001) delivers all this and more. The Cisco NCS 1001
is a dense wavelength-division multiplexing (DWDM) line system that is mechanically
optimized for data center environments; is performance optimized for maximum capacity; and
provides complete automation of installation and configuration with real-time and fine-grained
monitoring.
The Cisco NCS 1001 (Figure 1) is a 1RU system that is capable of supporting up to three
pluggable network interface modules. The modules can be amplifiers or protection switch
modules. The Cisco NCS 1001 (Figure 1) is mechanically optimized to maximize capacity at
minimum space and power footprint. Three network interface module detailed information are
available in Figures 6, 7 and 8 in this document.
Figure 1: NCS 1001
2.1 Validated configuration
The validated platforms consist of the following components and configurations:
• Chassis:
o NCS1001-K9=
• Controller Card:
o NCS1K-CNTLR2
• Network Interface Cards
o NCS1K-EDFA
o NCS1K-PSM
o NCS1K-OTDR
• FIPS Kit:
o AIR-AP-FIPSKIT=
The switches can be configured as follows while in the FIPS mode
Chassis Controller Card Network Interface Cards
NCS1001-K9= NCS1K-CNTLR2 • NCS1K-EDFA
• NCS1K-PSM
• NCS1K-OTDR
Figure 2: Module Configurations
© Copyright 2020 Cisco Systems, Inc. 6
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
2.2 Cryptographic Boundary
The module is a hardware, multi-chip standalone crypto module. The cryptographic boundary is
defined as encompassing the "top," "front," "left," "right," "rear," and "bottom" surfaces of the
case. All of the functionality described in this publication is provided by components within this
cryptographic boundary. The module consists of a production grade enclosure as well as
components. The detailed configuration can be seen in Figure 2 above.
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 module provides
no power to external devices and takes in its power through normal power input/cord. The
logical interfaces and their mapping are described in the following table:
Physical Interfaces FIPS 140-2 Logical Interfaces
Network Interface Module Card :
• OSC SFP port
• OTDR XFP port
• Optical TX/RX
Controller Card :
• User Data Channel port
• 10/10/100 LAN Electrical Management port
• 10/10/100 LAN Optical Management port
• Console Port
Data Input Interface
Network Interface Module Card :
• OSC SFP port
• OTDR XFP port
• Optical TX/RX
Controller Card:
• User Data Channel port
• 10/10/100 LAN Electrical Management port
• 10/10/100 LAN Optical Management port
• Console Port
Data Output Interface
Controller Card:
• User Data Channel port
• 10/10/100 LAN Electrical Management port
• 10/10/100 LAN Optical Management port
• Console Port
Control Input Interface
Network Interface Module Card :
• OSC SFP port
• OTDR XFP port
• Optical TX/RX
Controller Card:
• User Data Channel ports
• 10/10/100 LAN Electrical Management port
• 10/10/100 LAN Optical Management port
• Console Port
• LEDs
Status Output Interface
Table 2: NCS 1001 Interfaces
© Copyright 2020 Cisco Systems, Inc. 7
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Note:
1. The USB ports (4) on the Controller Card were covered by the Tamper Evident Label (TEL) and shall not
be used in FIPS mode.
2.4 Cisco NCS 1001 Front and Rear Panels
Figure 3: Front of NCS 1001 without Network Interface Modules
Figure 4: NCS 1001 Controller
© Copyright 2020 Cisco Systems, Inc. 8
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 5: NCS 1001 Rear Panel
Figure 6: NCS 1001 Optical Amplifier Module
© Copyright 2020 Cisco Systems, Inc. 9
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Figure 7: NCS 1001 Protection Switching Module
Figure 8: NCS 1001 Optical Time Domain Refloctometer
© Copyright 2020 Cisco Systems, Inc. 10
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
3. Roles, Services, and Authentication
The module can be accessed in one of the following ways:
• Console port
• SSHv2
• SNMPv3
• TLS v1.2
The cryptographic module supports Identity-based authentication. There are two roles in the
Switch that may be assumed the Crypto Officer (CO) role and the User role. The administrator of
the module assumes the Crypto Officer role and associated services in order to configure and
maintain the module, while the Users exercise only the basic User services.
The User and Crypto Officer passwords and all other shared secrets must each be at least eight
(8) characters long, including at least one six (6) alphabetic characters, (1) integer number and
one (1) special character in length (enforced procedurally). See the Secure Operation section for
more information. Given these restrictions, the probability of randomly guessing the correct
sequence is one (1) in 6,326,595,092,480 (this calculation is based on the assumption that the
typical standard American QWERTY computer keyboard has 10 Integer digits, 52 alphabetic
characters, and 32 special characters providing 94 characters to choose from in total). The
calculation should be 52x52x52x52x52x52x32x10 = 6,326,595,092,480. Therefore, the
associated probability of a successful random attempt is approximately 1 in 6,326,595,092,480,
which is less than the 1 in 1,000,000 required by FIPS 140-2.
In addition, for multiple attempts to use the authentication mechanism during a one-minute
period, under the optimal modern network condition, if an attacker would only get 60,000
guesses per minute. Therefore, the associated probability of a successful random attempt during
a one-minute period is 60,000/ 6,326,595,092,480 = 1/105,443,251, which is less than 1 in
100,000 required by FIPS 140-2.
Additionally, when using RSA based authentication, RSA key pair has modulus size of 2048
bits, thus providing 112 bits of strength, which means an attacker would have a 1 in 2^112
chance of randomly obtaining the key, which is much stronger than the one in a million chances
required by FIPS 140-2. Similarly, for multiple attempts to use the authentication mechanism
during a one-minute period, under the optimal modern network condition, an attacker would
probably get 60,000 guesses per minute. Therefore, the associated probability of a successful
random attempt during a one-minute period is 60,000/ 2^112 = 1/8.67x10^28, which is less than
1 in 100,000 required by FIPS 140-2.
3.1 User Services
A User enters the system by accessing the Console port, SSHv2, TLSv1.2 or SNMPv3. The User
role can be authenticated via either User Name/Password or RSA based authentication method.
The module prompts the User for username and password. If the password is correct, the User is
allowed entry to the module management functionality. The services available to the User role
accessing the CSPs, the type of access – read (r), write (w) and zeroized/delete (d) – and which
role accesses the CSPs are listed below.
© Copyright 2020 Cisco Systems, Inc. 11
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
The services available to the User role consist of the following:
Services Description Keys and CSPs Access
Status Functions View the module configuration, routing tables, active
sessions health, and view physical interface status.
User password (r, w, d)
Terminal Functions Adjust the terminal session (e.g., lock the terminal,
adjust flow control).
User password (r, w, d)
Network Functions Connect to other nodes and initiate diagnostic
network services (i.e., ping, mtrace).
User password (r, w, d)
Self-Tests Execute the FIPS 140 start-up tests on demand. N/A
SSHv2 Functions Negotiation and encrypted data transport via SSHv2. User password, SSHv2 private key, SSHv2 public key, SSHv2 integrity
key and SSHv2 session key, DRBG entropy input, DRBG seed, DRBG
V and DRBG key (r, w, d)
TLSv1.2 Functions Negotiation and encrypted data transport via
TLSv1.2.
User password, DRBG entropy input, DRBG Seed, DRBG V, DRBG
Key, TLS private key, TLS public key, TLS pre-master secret, TLS
master secret, TLS encryption key and TLS integrity key (r, w, d)
SNMPv3 Functions Monitor device using SNMPv3 SNMPv3 engineID, SNMPv3 password and SNMPv3 session key (r, w,
d)
Table 3: User Services (r = read, w = write, d = delete)
3.2 Crypto Officer Services
During initial configuration of the module, the Crypto Officer password is defined. A Crypto
Officer can 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. A CO role enters the
system by accessing the Console port, SSHv2, TLSv1.2 or SNMPv3. The User role can be
authenticated via either User Name/Password or RSA based authentication method. 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:
The Crypto Officer services consist of the following:
Services Description Keys and CSPs Access
Configure the module Define network interfaces and settings, enable interfaces
and network services, set system date and time, and load
authentication information.
DRBG seed, DRBG entropy input, DRBG V and DRBG key,
DH private DH public key, DH shared secret, ECDH private
ECDH public key, ECDH shared secret, User password,
Crypto Officer (CO) password , SSHv2 private key, SSHv2
public key, SSHv2 session integrity key, SSHv2 session key,
TLS private key, TLS public key, TLS pre-master secret, TLS
master secret, TLS encryption key, TLS integrity key,
SNMPv3 engineID, SNMPv3 Password and SNMPv3 session
key (r, w, d)
Define Rules and Filters Create packet Filters that are applied to User data streams
for each node.
User 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.
User password, Crypto Officer (CO) password (r, w, d)
Manage the Module Log off users, shutdown or reload the module, erase the
memory, view complete configurations, manager user
rights, perform firmware updates, and restore
configurations.
Crypto Officer (CO) password (r, w, d)
© Copyright 2020 Cisco Systems, Inc. 12
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
TLSv1.2 Functions Configure TLSv1.2 parameters, provide entry and output of
CSPs.
DRBG entropy input, DRBG Seed, DRBG V, DRBG Key,
TLS private key, TLS public key, TLS pre-master secret, TLS
master secret, TLS encryption key and TLS integrity key (r, w,
d)
SSHv2 Functions Configure SSHv2 parameter, provide entry and output of
CSPs.
Diffie-Hellman private key, Diffie-Hellman public key, Diffie-
Hellman Shared Secret, EC Diffie-Hellman private key, EC
Diffie-Hellman public key, EC Diffie-Hellman Shared Secret,
SSHv2 private key, SSHv2 public key, SSHv2 session
integrity key and SSHv2 session key, DRBG entropy input,
DRBG seed, DRBG V and DRBG key (r, w, d)
SNMPv3 Functions Device configuration of monitoring services and
monitoring by the CO using SNMPv3
SNMPv3 engineID, SNMPv3 password and SNMPv3 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 (r = read, w = write, d = delete)
3.3 Non-FIPS mode Services
The cryptographic module in addition to the above listed FIPS mode of operation can operate in
a non-FIPS mode of operation. This is not a recommended operational mode but because the
associated RFC’s for the following protocols allow for non-approved algorithms and non-
approved key sizes a non-approved mode of operation exist. So those services listed above with
their FIPS approved algorithms in addition to the following services with their non-approved
algorithms and non-approved keys sizes are available to the User and the Crypto Officer. Prior
to using any of the Non-Approved services in Section 3.3, 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
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.
3.4 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.
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. 13
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
4. 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 secret whereas protocols such as TLS and SSH are used for electronic
distribution.
All 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 other keys are 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/Derivation Storage Zeroization
DRBG entropy
input
SP800-90A
CTR_DRBG
(AES-256)
384-bits This is the entropy for SP 800-90A
CTR_DRBG. Used to construct the
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. Established
per the Diffie-Hellman key agreement.
DRAM
(plaintext)
Power cycle the
device
Diffie-Hellman
private key
DH 224-379 bits The private key used in Diffie-Hellman
(DH) exchange. This key is generated
by using FIPS 186-4 Key generation
method, and the seed used to generate
asymmetric key-pairs 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. This key is derived per
the Diffie-Hellman key agreement.
DRAM
(plaintext)
Power cycle the
device
© 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/Derivation 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
The private key used in Elliptic Curve
Diffie-Hellman (ECDH) exchange. This
key is generated by using FIPS 186-4
Key generation method, and the seed
used to generate asymmetric key-pairs is
generated by calling SP800-90A
DRBG.
DRAM
(plaintext)
Power cycle the
device
EC Diffie-
Hellman public
key
ECDH P-256, P-384,
P-521 Curves
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
User password Password 8-25 characters The password of the User role. This
CSP is entered by the User.
NVRAM
(plaintext)
Overwrite with
new password
Crypto Officer
(CO) password
Password 8-25 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
using FIPS 186-4 Key generation
method, and the seed used to generate
asymmetric key-pairs is generated by
calling SP800-90A DRBG.
NVRAM
(plaintext)
Zeroized by RSA
keypair deletion
command
SSHv2 public
key
RSA 2048 bits modulus The SSHv2 public key used in SSHv2
connection. This key is derived in
compliance with FIPS 186-4 RSA key
pair generation method in the module.
NVRAM
(plaintext)
Zeroized by RSA
keypair deletion
command
SSHv2 integrity
key
HMAC-SHA-
1/256
160-256 bits Used for SSHv2 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
SSHv2 session
key
AES AES 128/192/256
bits
This is the SSHv2 session key. It is used
to protect the traffic through the SSHv2
tunnel. This key is derived via key
derivation function defined in SP800-
135 KDF (SSH).
DRAM
(plaintext)
Automatically
when SSH
session is
terminated
© Copyright 2020 Cisco Systems, Inc. 15
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
Name CSP Type Size Description/Generation/Derivation Storage Zeroization
TLS private key RSA 2048 bits Identity certificates for the security
appliance itself and also used in
TLSv1.2 negotiations. This key is
generated by using FIPS 186-4 Key
generation method, and the seed used to
generate asymmetric key-pairs is
generated by calling SP800-90A
DRBG.
NVRAM
(plaintext)
Zeroized by RSA
keypair deletion
command
TLS public key RSA 2048 bits Identity certificates for the security
appliance itself and also used in
TLSv1.2 negotiations. This key is
internally generated 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 48 Bytes Keying material used to derive TLS
master secret during the TLSv1.2
session. This secret is internally
generated by calling SP800-90A
DRBG.
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
TLS master
secret
keying material 48 Bytes Keying material used to derive other
TLS keys. This key was derived from
TLS pre-master secret during the
TLSv1.2 session establishment.
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
TLS encryption
key
AES AES 128/192/256
bits
Used in TLSv1.2 connections to protect
the session traffic. This key is derived in
the module.
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
TLS integrity
key
HMAC-SHA
256/384/512
256-512 bits Used for TLSv1.2 integrity to assure the
traffic integrity. This key is derived in
the module.
DRAM
(plaintext)
Automatically
when TLS
session is
terminated
SNMP v3
password
Password 32 bytes This password is used to conduct the
authentication for SNMPv3 operator.
NVRAM
(plaintext)
Overwrite with
new password
SNMPv3
engineID
Shared Secret 32 bits Unique string to identify the SNMP
engine. This secret is entered into the
module by the Crypto Officer.
NVRAM
(plaintext)
Overwrite with
new engine ID
SNMPv3
session key
AES 128 bits Encrypts SNMPv3 traffic. This key is
derived via key derivation function
defined in SP800-135 KDF (SNMPv3).
DRAM
(plaintext)
Automatically
when SNMP
session is
terminated
Table 6: Cryptographic Keys and CSPs
© Copyright 2020 Cisco Systems, Inc. 16
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
5. Cryptographic Algorithms
The module implements a variety of approved and non-approved algorithms.
5.1Approved Cryptographic Algorithms
Cisco FIPS Object Module
Implementation
AES (AES-CBC, AES-CTR); Key Length: 128, 192, 256 Cert. #C910
SHS (SHA-1, SHA-256, SHA-384, SHA-512) Cert. #C910
HMAC (HMAC SHA-1, HMAC SHA-256, HMAC SHA-384, HMAC SHA-512) Cert. #C910
RSA (PKCS1_V1_5; KeyGen, SigGen, SigVer; 2048 bits) Cert. #C910
DRBG (AES-256 CTR_DRBG) Cert. #C910
CVL Components (TLSv1.2, SSHv2 and SNMPv3) Cert. #C910
CKG (vendor affirmed) N/A
Table 7: 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.
• No parts of the SSH, TLS and SNMP protocols, other than the KDF, 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.
5.2Non-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. #C910, key agreement; key establishment methodology
provides between 112 and 150 bits of encryption strength)
• EC Diffie-Hellman (CVL Cert. #C910, 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)
5.3Non-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
© Copyright 2020 Cisco Systems, Inc. 17
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
• HMAC MD5
• MD5
• RC4
• HMAC-SHA1 is not allowed with key size under 112-bits
6. 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 ensure all components are
functioning correctly.
Power On Self-Tests
• Cisco FIPS Object Module Algorithm Implementation POSTs
o AES-CBC (encrypt/decrypt) KATs
o DRBG KAT (Note: DRBG Health Tests as specified in SP800-90A Section 11.3
are performed)
o SHA-1 KAT
o HMAC (HMAC-SHA-1/256/384/512) KATs
o RSA KAT (separate KAT for signing; separate KAT for verification) KATs
• Firmware Integrity Test (HMAC-SHA-1)
Conditional Tests
• Cisco FIPS Object Module Algorithm Implementation Conditional Tests
• CRNGT to DRBG
• CRNGT to NDRNG
• PWCT to RSA
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 module’s interfaces; this prevents the 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 on the console followed by a security appliance reboot.
7. Physical Security
The module natively meets the FIPS 140-2 opacity requirements. However, tamper evident labels
are required to meeting the FIPS 140-2 tamper evidence requirements.
Chassis Models Number Tamper labels Tamper Evidence Labels
NCS1001-K9= 15 AIR-AP-FIPSKIT=
Table 8: Tamper Evidence Labels
Tamper Evidence Label (TEL) placement
The tamper evident labels (TELs) shall be installed on 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. Once the module has been
© Copyright 2020 Cisco Systems, Inc. 18
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
configured to meet FIPS 140-2 Level 2 requirements, the module cannot be physically accessed
without signs of tampering. Any attempt to open the module units will damage the tamper evidence
seals or the material of the module cover. Tamper evidence seals can be inspected for signs of
tampering, which include the following: curled corners, bubbling, crinkling, rips, tears, and slices.
Should the CO have to remove, change or replace TELs 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 by unauthorized operators such as tearing, misconfiguration,
removal, change, replacement or any other change in the TELs from its original configuration as
depicted below 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 TELs as depicted below and any
additional requirement per the site security policy which are out of scope of this Security Policy.
To seal the system, apply tamper-evidence labels as depicted in the figures below. The module has a
total of 15 TELS places in different locations.
View NCS1001 – TEL Placement and Numbering
Front
Back
1 2 4
6
3
5
7
See bottom view
© Copyright 2020 Cisco Systems, Inc. 19
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
View NCS1001 – TEL Placement and Numbering
Bottom
Rear
8
9
10
11
7
Front
1
2
4
© Copyright 2020 Cisco Systems, Inc. 20
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
View NCS1001 – TEL Placement and Numbering
Top
Left
Right
Table 9: NCS1001 TEL Placement
Applying Tamper Evidence Labels
Step 1: Turn off and unplug the module 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 module as shown in the figures above.
The tamper evident labels are produced from a special thin gauge vinyl with self-adhesive
backing. Any attempt to open the module will damage the tamper evident labels or the material
of the security appliance cover. Because the tamper evident labels have non-repeated serial
numbers, they may be inspected for damage and compared against the applied serial numbers to
3
Front
5
Rear
6
13
12
14 15
© Copyright 2020 Cisco Systems, Inc. 21
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
verify that the security appliance has not been tampered with. Tamper evident labels can also be
inspected for signs of tampering, which include the following: curled corners, rips, and slices.
The word “FIPS” or “OPEN” may appear if the label was peeled back.
Inspection of the tamper seals should be incorporated into facility security to include how often
to inspect and any recording of the inspection. It is recommended inspection of TELs occur at
least every 30 days but this is the facilities Security Manager decision.
8. Secure Operation
The Cisco Network Convergence System 1001 Cryptographic Module meets all the Level 2
requirements for FIPS 140-2. The module is shipped only to authorized operators by the vendor,
and the 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.
The module was validated with firmware version IOS XR 7.0.1 It is the only allowed firmware
version for FIPS-approved mode of operation. The Crypto Officer must configure and enforce
the following initialization steps.
8.1 Initial Setup
1. The Crypto Officer must apply tamper evidence labels as described in of this document.
Please be aware that the USB ports (Four on each Controller Card) were disabled by a
tamper evident label and shall not be used while in FIPS mode. All configuration will be
done from the CLI.
2. Configure Password
To be considered FIPS compliant, the Crypto Officer shall follow up the requirements
from section 3 in this document to update the default password by using the following
command
• ios# username <username> password <password>
3. Enable FIPS mode
• ios# configure
• ios# crypto fips-mode
• ios# commit
4. Configure SNMPv3 by using only FIPS-approved algorithms.
• ios# configure
• ios# snmp-server view
• ios# snmp-server group
• ios# snmp-server user username groupname v3 auth sha auth-password priv aes
priv-password
© Copyright 2020 Cisco Systems, Inc. 22
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.
5. Configure SSHv2
• ios# configure
• ios# ssh server v2
6. Configure Syslog over TLSv1.2
• ios# configure
• ios# crypto ca trustpoint
• ios# subject-name
• ios# enrollment url
• ios# enrollment retry count
• ios# enrollment retry period
• ios# rsakeypair
• ios# crypto ca authenticate
• ios# logging tls-server syslogserver
• ios# severity debugging
• ios# address ipv4
• ios# debug crypto pki errors
• ios# debug crypto pki messages
• ios# debug crypto pki transactions
7. Verify FIPS mode is enabled
• ios# show running-config
• output:
crypto fips-mode
end
Note: For more configuration and guidance options, please refer to the links below.
• Configuration Guide for Cisco NCS 1001, IOS XR Release 7.0.1
https://www.cisco.com/c/en/us/td/docs/optical/ncs1001/701/b-ncs1001-configuration-
guide-70x.html (Updated: June 12, 2020)
• Command Reference for Cisco NCS 1001
https://www.cisco.com/c/en/us/td/docs/optical/ncs1001/command/reference/ncs1001-cli-
reference.html (Updated: August 12, 2020)