Cisco Integrated Services Router (ISR) 4351 and 4331 (with SM-ES3X- 16-P, SM-ES3X-24-P, SM-D-ES3X-48-P, PVDM4-32, PVDM4-64, PVDM4- 128 and PVDM4-256) and Cisco Integrated Services Router (ISR) 4321 (with PVDM4-32, PVDM4-64, PVDM4-128 and PVDM4-256) FIPS 140-2 Non Proprietary Security Policy Level 1 Validation Version 1.0 Date: December 22, 2015 Table of Contents 1 Introduction ................................................................................................................. 1 1.1 References ............................................................................................................ 1 1.2 FIPS 140-2 Submission Package.......................................................................... 1 2 Module Description .................................................................................................... 2 2.1 Cisco ISR 4351, 4331, and 4321 .......................................................................... 2 2.2 Packet Voice Digital Signal Processor Module (PVDM) .................................... 3 2.3 Next Generation Etherswitch (SM-ES) ................................................................ 4 2.4 Module Validation Level ..................................................................................... 5 3 Cryptographic Boundary............................................................................................. 5 4 Cryptographic Module Ports and Interfaces ............................................................... 6 5 Physical Security......................................................................................................... 6 6 Roles, Services, and Authentication ........................................................................... 6 6.1 User Services ........................................................................................................ 7 6.2 Cryptographic Officer Services ............................................................................ 8 6.3 Non-FIPS mode Services ..................................................................................... 9 6.4 Unauthenticated User Services........................................................................... 11 7 Cryptographic Key/CSP Management ...................................................................... 11 8 Cryptographic Algorithms ........................................................................................ 16 8.1 Approved Cryptographic Algorithms ................................................................ 16 8.2 Non-Approved Algorithms allowed for use in FIPS-mode ............................... 17 8.3 Non-Approved and Non-Allowed Algorithms ................................................... 17 8.4 IPsec protocol IV Generation ............................................................................. 18 8.5 Self-Tests ............................................................................................................ 18 9 Secure Operation ....................................................................................................... 19 i 9.1 System Initialization and Configuration ............................................................ 19 9.2 IPsec Requirements and Cryptographic Algorithms .......................................... 21 9.3 SSLv3.1/TLS Requirements and Cryptographic Algorithms ............................ 21 9.4 Remote Access ................................................................................................... 22 9.5 Cisco Unified Border Element (CUBE) TLS Configuration ............................. 22 9.6 Remote Access ................................................................................................... 22 ii 1 Introduction This is a non-proprietary Cryptographic Module Security Policy for the Cisco Integrated Services Router (ISR) 4351 and 4331 (with SM-ES3X-16-P, SM-ES3X-24-P, SM-D- ES3X-48-P, PVDM4-32, PVDM4-64, PVDM4-128 and PVDM4-256) and the Cisco Integrated Services Router (ISR) 4321 (with PVDM4-32, PVDM4-64, PVDM4-128 and PVDM4-256) from Cisco Systems, Inc., referred to in this document as the modules, routers, or by their specific model name. This security policy describes how modules meet the security requirements of FIPS 140-2 and how to run the modules in a FIPS 140- 2 mode of operation. 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/cmvp/index.html. 1.1 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: The Cisco Systems website (http://www.cisco.com) contains information on the full line of products from Cisco Systems. The NIST Cryptographic Module Validation Program website (http://csrc.nist.gov/groups/STM/cmvp/index.html) contains contact information for answers to technical or sales-related questions for the module. 1.2 FIPS 140-2 Submission Package The security policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the submission package includes: Vendor Evidence Finite State Machine Other supporting documentation as additional references With the exception of this non-proprietary security policy, the FIPS 140-2 validation documentation is proprietary to Cisco Systems, Inc. and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Cisco Systems, Inc. See "Obtaining Technical Assistance" section for more information. Page 1 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2 Module Description 2.1 Cisco ISR 4351, 4331, and 4321 Image 1: ISR 4351 Front and Back Image 2: ISR 4331 Front and Back Image 3: ISR 4321 Front and Back The Cisco ISR 4351, 4331 and 4321 design are based on Cisco ISR 4451-X but scaled down to a single CPU (SOC). The IOS-XE software architecture enables high performance and scalability through leverage of multi-core CPUs, feature inheritance, modularity, fault isolation, and restartability. Page 2 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 1. ISR 4351 will address the aggregated 600Mbps space and/or customers requiring density of services appropriate for two Service Module slots or a Double Wide Service Module. 2. ISR 4331 will address the aggregated 400Mbps space and/or customers requiring density of services appropriate for a Service Module slot. 3. ISR 4321 will address the aggregated 200Mbps market space for customers who desire rich services including support for Unified Communication. IKE/IPsec Used for securing data plane traffic RADIUS Used for external authentication SNMPv3 Used for remote management SSHv2 Used for secure configuration TACACS+ Used for external authentication TLS (HTTPS) Used for secure configuration GetVPN Used for data plane traffic Cube/sRTP Used for securing data traffic Table 1: Supported Services 2.2 Packet Voice Digital Signal Processor Module (PVDM) The Cisco Fourth-Generation Packet Voice Digital Signal Processor Module (PVDM4) enables Cisco 4351, 4331 and 4321 Integrated Services Router (ISR) to provide rich- media capabilities such as high-density voice connectivity, conferencing, transcoding, media optimization, translating, and secure voice in Cisco Unified Communications Solutions. The fourth-generation packet voice digital-signal-processor (DSP) modules are available in four densities listed under hardware configuration. http://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services- routers-isr/data_sheet_c78-728307.html Page 3 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2.3 Next Generation Etherswitch (SM-ES) SM-ES3X-16-P, SM-ES3X-24-P, SM-D-ES3X-48-P are the next Generation Layer 3 Etherswitch Service Modules (ESM) for 29XX/ 39XX/43XX/44XX ISR product families with 16 port, 24 port and 48 port. It is based off of the ESTG's Catalyst 3560-X series switches, with Power Over Ethernet Plus (POE+) providing up to 30 watts of power per port. Additional improvements include IEEE 802.3ae Media Access Control Security (MACSec) port-based, and hop-to-hop. MACSec cannot be used while in FIPS mode of operation. http://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services- routers-isr/datasheet-c78-730357.html The validated platforms comprise the main system (Product Model) along with any of the following listed ESM or PVDM4 modules in any configuration. The different configurations only affect the number of ports available. FIPS testing was conducted with each model and the PVDM4 housed. Product Firmware Crypto Etherswitch Packet Voice Digital Signal Processor Model Image Name Service Modules Module (PVDM4) (ESM) SM-ES3X-16-P PVDM4-32: 32-channel DSP Module ISR SM-ES3X-24-P PVDM4-64: 64-channel DSP Module IOS-XE 3.13.2 IC2M(Rel 5) 4351 SM-D-ES3X-48-P PVDM4-128: 128-channel DSP Module PVDM4-256: 256-channel DSP Module PVDM4-32: 32-channel DSP Module ISR SM-ES3X-16-P PVDM4-64: 64-channel DSP Module IOS-XE 3.13.2 IC2M(Rel 5) 4331 SM-ES3X-24-P PVDM4-128: 128-channel DSP Module SM-D-ES3X-48-P PVDM4-256: 256-channel DSP Module PVDM4-32: 32-channel DSP Module ISR PVDM4-64: 64-channel DSP Module IOS-XE 3.13.2 IC2M(Rel 5) 4321 PVDM4-128: 128-channel DSP Module PVDM4-256: 256-channel DSP Module Table 2: Module configuration Page 4 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2.4 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 3 11 Mitigation of Other Attacks N/A Overall Overall module validation level 1 Table 3: Module Validation Level 3 Cryptographic Boundary The cryptographic boundary for the Cisco Integrated Services Router (ISR) 4351, 4331 and 4321 is defined as encompassing the "front", "back", "top", "bottom", "left," and "right" surfaces of the case. Intel Processor Processor Data Plane Control/Service Plane Crypto Engine IOS Code/Data ports IC2M Page 5 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Diagram 1- Block Diagram (Cryptographic boundary and Physical boundary in red) 4 Cryptographic Module Ports and Interfaces Each module provides a number of physical and logical interfaces to the device, and the physical interfaces provided by the module are mapped to four 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 tables: 10/100/1000 RJ-45 Ethernet port Data Input USB port Console Port AUX port 10/100/1000 RJ-45 Ethernet port Output Interface USB port Console Port AUX port 10/100/1000 RJ-45 Ethernet port Control Input USB port Console Port AUX port Power Switch 10/100/1000 RJ-45 Ethernet port Status Output USB port Interface Console Port AUX port Power Plug Power Interface Table 4: ESG 4351, 4331, and 4221 5 Physical Security The Module is a multi-chip embedded cryptographic module and conforms to Level 1 requirements for physical security. The cryptographic module consists of production- grade components in that the components have standard industry acceptable coating applied to them. 6 Roles, Services, and Authentication Page 6 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Authentication is identity-based. Each user is authenticated upon initial access to the module. There are two main roles in the router that operators may assume: the Crypto Officer role and the User role. The administrator of the router assumes the Crypto Officer role in order to configure and maintain the router using Crypto Officer services, while the Users exercise only the basic User services. The module supports RADIUS and TACACS+ for authentication. A complete description of all the management and configuration capabilities of the modules can be found in the Cisco ISR 4400 Integrated Services Routers Software Configuration Guide (which covers ISR 4400 and ISR 4300 Series) and in the online help for the modules. The User and Crypto Officer passwords and all shared secrets must each be at least eight (8) characters long, including at least one letter and at least one number character, in length (enforced procedurally). See the Secure Operation section for more information. If six (6) integers, one (1) special character and one (1) alphabet are used without repetition for an eight (8) digit PIN, the probability of randomly guessing the correct sequence is one (1) in 4,488,223,369,069,440 (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. Since it is claimed to be for 8 digits with no repetition, then the calculation should be 94 x 93 x 92 x 91 x 90 x 89 x 88 x 87). In order to successfully guess the sequence in one minute would require the ability to make over 74,803,722,817,824 guesses per second, which far exceeds the operational capabilities of the module. Additionally, when using RSA based authentication, 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 5.19x1028 attempts per minute, which far exceeds the operational capabilities of the modules to support. P-256 and P-384 curves are supported for ECDSA based authentication. ECDSA P-256 provides 128 bits of equivalent security, and P-384 provides 192 bits of equivalent security. Assuming the low end of that range, the associated probability of a successful random attempt during a one-minute period is 1 in 2^128, which is less than 1 in 100,000 required by FIPS 140-2. 6.1 User Services A User enters the system by accessing the console/auxiliary port with a terminal program or SSH v2 session to a LAN port or the 10/100 management Ethernet port. The module prompts the User for their username/password combination. If the username/password combination is correct, the User is allowed entry to the module management Page 7 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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: Services and Access Description Keys and CSPs Status Functions (r) View state of interfaces and protocols, version of IOS currently running. User password Terminal Functions (r) Adjust the terminal session (e.g., lock the terminal, adjust flow control). User password Directory Services (r) Display directory of files kept in flash memory. User password Self-Tests (r) Execute the FIPS 140 start-up tests on demand N/A IPsec VPN (r, w, d) Negotiation and encrypted data transport via IPSec VPN User password GetVPN (GDOI) (r, w, d) Negotiation and encrypted data transport via GetVPN User password SSH Functions(r, w, d) Negotiation and encrypted data transport via SSH User password HTTPS Functions (TLS) Negotiation and encrypted data transport via HTTPS User password (r, w, d) SNMPv3 Functions(r, w, Negotiation and encrypted data transport via SNMPv3 User password d) CUBE/sRTP Functions (r, Negotiation and encrypted data transport via CUBE/sRTP User password w, d) Table 5 - User Services 6.2 Cryptographic Officer Services A Crypto Officer enters the system by accessing the console/auxiliary port with a terminal program or SSH v2 session to a LAN port or the 10/100 management Ethernet port. The Crypto Officer authenticates in the same manner as a User. The Crypto Officer is identified by accounts that have a privilege level 15 (versus the privilege level 1 for users). 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 router. The services available to the User role accessing the CSPs, the type of access ­ read (r), write (w) and zeroized/delete (d) ­ and which role accesses the CSPs are listed below: Services and Access Description Keys and CSPs Configure the router (r,w) Define network interfaces and settings, create command ISAKMP pre-shared keys, IKE aliases, set the protocols the router will support, enable Authentication key, IKE Encryption Key, interfaces and network services, set system date and time, IPSec authentication keys, IPSec traffic and load authentication information. keys, User passwords, Enable password, Enable secret, Define Rules and Filters (r,w,d) Create packet Filters that are applied to User data streams password Page 8 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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. View Status Functions (r) View the router configuration, routing tables, active password sessions, use gets to view SNMP MIB statistics, health, temperature, memory status, voltage, packet statistics, review accounting logs, and view physical interface status. Manage the router (r,w,d) Log off users, shutdown or reload the router, erase the password flash memory, manually back up router configurations, view complete configurations, manager user rights, and restore router configurations. SNMPv3 (r) Non security-related monitoring by the CO SnmpEngineID, SNMP v3 password, SNMP session key using SNMPv3. Configure Encryption/Bypass Set up the configuration tables for IP tunneling. Set ISAKMP pre-shared keys, IKE (r,w,d) preshared keys and algorithms to be used for each IP range Authentication key, IKE Encryption Key, or allow plaintext packets to be set from specified IP IPSec authentication keys, IPSec traffic address. keys, Enable secret, TLS VPN (TLSv1.0) (r,w,d) Configure SSL VPN parameters, provide entry and output of TLS pre-master secret, TLS Traffic Keys CSPs. SSH v2 (r, w, d) Configure SSH v2 parameter, provide entry and output of SSH Traffic Keys CSPs. sRTP/CUBE (r, w, d) Configure CUBE/sRTP parameter, provide entry and output CUBE/sRTP Traffic Keys of CSPs. IPsec VPN (r, w, d) Configure IPsec VPN parameters, provide entry and output skeyid, skeyid_d, SKEYSEED, IKE session of CSPs. encryption key, IKE session authentication key, ISAKMP pre-shared, IKE authentication private Key, IKE authentication public key, IPSec encryption key, IPSec authentication key GetVPN (GDOI) (r, w, d) Configure GetVPN parameters, provide entry and output of GDOI key encryption key (KEK), GDOI traffic CSPs. encryption key (TEK), GDOI TEK integrity key Self-Tests (r) Execute the FIPS 140 start-up tests on demand N/A User services (r,w,d) The Crypto Officer has access to all User services. Password Zeroization (d) Zeroize cryptographic keys/CSPs by running the zeroization All CSPs methods classified in table 7, Zeroization column. Table 6 - Crypto Officer Services 6.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 Page 9 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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 6.3 the Crypto Officer must zeroize all CSPs which places the module into the non-FIPS mode of operation. Non-Approved Non-Approved Algorithms and non-approved key/curve sizes2 Service 1 Hashing: MD5, IPsec MACing: HMAC-SHA-1, MD5 Symmetric: Triple-DES, AES, DES, RC4 Asymmetric: RSA (key transport), ECDSA, Diffie- Hellman, EC Diffie-Hellman Hashing: MD5, SSH MACing: HMAC MD5 Symmetric: Triple-DES, AES, DES Asymmetric: RSA (key transport), Diffie-Hellman, EC Diffie-Hellman Hashing: MD5, TLS MACing: HMAC-SHA-1, MD5 Symmetric: AES, DES, RC4 Asymmetric: RSA (key transport), Diffie-Hellman, EC Diffie-Hellman Hashing: MD5, SNMP MACing: HMAC-SHA-1, MD5 Symmetric: AES, DES, RC4 Asymmetric: RSA (key transport), Diffie-Hellman, EC Diffie-Hellman 1 These approved services become non-approved when using any of non-approved algorithms or non- approved key or curve sizes. When using approved algorithms and key sizes these services are approved. 2 When using a non-approved keys as part of a non-Approved function or service approved algorithms like AES and Triple-DES become non-approved by association to these Non-Approved keys. The other algorithms listed are non-approved FIPS algorithms. Page 10 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Symmetric: AES MACSec Key Derivation: NIST SP 800-108 KBKDF Table 7 ­ Non-FIPS Services Neither the User nor the Crypto Officer are allowed to operate any of these services while in FIPS mode of operation. The Crypto Officer must zeroize all CSPs prior to utilizing the MACSec services in Table 7. All services available can be found in the ISR data sheet; along with instructions on configuration can be found in ISR software configuration guide. 6.4 Unauthenticated User Services The services for someone without an authorized role are to view the status output from the module's LED pins and cycle power. 7 Cryptographic Key/CSP Management The module securely administers both cryptographic keys and other critical security parameters such as passwords. All keys are also protected by the password-protection on the Crypto Officer login, and can be zeroized by the Crypto Officer. All zeroization consists of overwriting the memory that stored the key. Keys are exchanged and entered electronically or via Internet Key Exchange (IKE). Keys/CSPs can be zeroized by running the zeroization methods classified in table 7, Zeroization column. The module supports the following critical security parameters (CSPs): Name CSP Type Size Description/Generation Storage Zeroization DRBG entropy SP800-90 DRBG_CTR 256-bits This is the entropy for SP 800- DRAM Power cycle the input (using AES-256) 90 CTR_DRBG. (plaintext) device HW (onboard Cavium cryptographic processor) based entropy source used to construct seed. Page 11 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Name CSP Type Size Description/Generation Storage Zeroization DRBG Seed SP800-90 DRBG_CTR 384-bits Input to the DRBG that DRAM Power cycle the determines the internal state of (plaintext) device the DRBG. Generated using DRBG derivation function that includes the entropy input from hardware-based entropy source. DRBG V SP800-90 DRBG_CTR 128-bits The DRBG V is one of the DRAM Power cycle the critical values of the internal (plaintext) device state upon which the security of this DRBG mechanism depends. Generated first during DRBG instantiation and then subsequently updated using the DRBG update function. DRBG Key SP800-90 DRBG_CTR 256-bits Internal Key value used as part DRAM Power cycle the of SP 800-90 CTR_DRBG. (plaintext) device Established per SP 800-90A CTR_DRBG. Diffie-Hellman DH 2048 ­ 4096 bits The shared secret used in DRAM Power cycle the Shared Secret Diffie-Hellman (DH) exchange. (plaintext) device Established per the Diffie- Hellman key agreement. Diffie Hellman DH 224-379 bits The private key used in Diffie- DRAM Power cycle the private key Hellman (DH) exchange. This (plaintext) device key is generated by calling SP800-90 DRBG. Diffie Hellman DH 2048 ­ 4096 bits The public key used in Diffie- DRAM Power cycle the public key Hellman (DH) exchange. This (plaintext) device key is derived per the Diffie- Hellman key agreement. EC Diffie- ECDH Curves: P-256/P- Used in establishing the session DRAM Hellman 384 key for an IPSec session. The (plaintext) Power cycle the private key private key used in Elliptic device Curve Diffie-Hellman (ECDH) exchange. This key is generated by calling SP800-90 DRBG. Page 12 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Name CSP Type Size Description/Generation Storage Zeroization EC Diffie- ECDH Curves: P-256/P- Used in establishing the session DRAM Hellman public 384 key for an IPSec session. The (plaintext) Power cycle the key public key used in Elliptic device Curve Diffie-Hellman (ECDH) exchange. This key is established per the EC Diffie- Hellman key agreement. EC Diffie- ECDH Curves: P-256/P- The shared secret used in DRAM Hellman 384 Elliptic Curve Diffie-Hellman (plaintext) Power cycle the shared secret (ECDH) exchange. Established device per the Elliptic Curve Diffie- Hellman (ECDH) protocol. skeyid Shared Secret 160 bits A shared secret known only to DRAM Power cycle the IKE peers. It was established (plaintext) device via key derivation function defined in SP800-135 KDF (IKEv1) and it will be used for deriving other keys in IKE protocol implementation. skeyid_d Shared Secret 160 bits A shared secret known only to DRAM Power cycle the IKE peers. It was derived via (plaintext) device key derivation function defined in SP800-135 KDF (IKEv1) and it will be used for deriving IKE session authentication key. SKEYSEED Shared Secret 160 bits A shared secret known only to DRAM Power cycle the IKE peers. It was derived via (plaintext) device key derivation function defined in SP800-135 KDF (IKEv2) and it will be used for deriving IKE session authentication key. IKE session Triple-DES/AES 168 bit Triple- The IKE session (IKE Phase I) DRAM Power cycle the encrypt key DES or encrypt key. This key is derived (plaintext) device 128/192/256 bits via key derivation function AES defined in SP800-135 KDF (IKEv1/IKEv2). IKE session HMAC SHA-1 160 bits The IKE session (IKE Phase I) DRAM Power cycle the authentication authentication key. This key is (plaintext) device key derived via key derivation function defined in SP800-135 KDF (IKEv1/IKEv2). Page 13 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Name CSP Type Size Description/Generation Storage Zeroization ISAKMP Pre-shared key Variable 8 plus The secret used to derive IKE NVRAM By running `# preshared characters skeyid when using preshared (plaintext) no crypto secret authentication. This CSP isakmp key' is entered by the Crypto command Officer. IKE RSA/ ECDSA RSA (2048 ­ RSA/ECDSA private key used NVRAM By running authentication 3072 bits) or in IKE authentication. This key (plaintext) `#crypto key private Key ECDSA (Curves: is generated by calling SP800- zeroize' P-256/P-384) 90 DRBG. command IKE RSA/ ECDSA RSA (2048 ­ RSA/ECDSA public key used NVRAM By running authentication 3072 bits) or in IKE authentication. (plaintext) `#crypto key public key ECDSA (Curves: Internally generated by the zeroize' P-256/P-384) module command IPsec encrypt- Triple-DES/AES 168 bits Triple- The IPsec (IKE phase II) DRAM Power cycle the ion key DES or encryption key. This key is (plaintext) device 128/192/256 bits derived via a key derivation AES function defined in SP800-135 KDF (IKEv1/IKEv2). IPsec HMAC SHA-1 160-bits The IPsec (IKE Phase II) DRAM Power cycle the authentication authentication key. This key is (plaintext) device key derived via a key derivation function defined in SP800-135 KDF (IKEv1/IKEv2). Operator Password 8 plus characters The password of the User role. NVRAM Overwrite with password This CSP is entered by the (plaintext) new password Crypto Officer. Enable Password 8 plus characters The password of the CO role. NVRAM Overwrite with password This CSP is entered by the (plaintext) new password Crypto Officer. RADIUS Shared Secret 16 characters The RADIUS shared secret. NVRAM By running `# secret Used for RADIUS (plaintext), no radius-server Client/Server authentication. key' command This CSP is entered by the Crypto Officer. TACACS+ Shared Secret 16 characters The TACACS+ shared secret. NVRAM By running `# secret Used for TACACS+ (plaintext), no tacacs-server Client/Server authentication. key' command This CSP is entered by the Crypto Officer. Page 14 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Name CSP Type Size Description/Generation Storage Zeroization SSHv2 Private RSA 2048 ­ 3072 bits The SSHv2 private key used in NVRAM By running `# Key modulus SSHv2 connection. This key is (plaintext) crypto key generated by calling SP800-90 zeroize rsa' DRBG. command SSHv2 Public RSA 2048 ­ 3072 bits The SSHv2 public key used in NVRAM By running `# Key modulus SSHv2 connection. This key is (plaintext) crypto key internally generated by the zeroize rsa' module. command SSHv2 Session Triple-DES/AES 168 bits Triple- This is the SSHv2 session key. DRAM Power cycle the Key DES or It is used to encrypt all SSHv2 (plaintext) device 128/192/256 bits data traffics traversing between AES the SSHv2 Client and SSHv2 Server. This key is derived via key derivation function defined in SP800-135 KDF (SSH). GDOI Data Triple-DES/AES 168 bits Triple- Generate by calling SP800-90 DRAM Power cycle the Security Key DES or/ DRBG in the module. It is used (plaintext) device (TEK) 128/192/256 bits to encrypt data traffic between AES Get VPN (GDOI) peers. GDOI Group Triple-DES/AES 168 bits Triple- Generate by calling SP800-90 DRAM Power cycle the Key DES or/ DRBG in the module. It is used (plaintext) device Encryption 128/192/256 bits protect Get VPN (GDOI) Key (KEK) AES rekeying data. GDOI TEK HMAC SHA-1 160 bits Generate by calling SP800-90 DRAM Power cycle the integrity key DRBG in the module. It is used (plaintext) device to ensure data traffic integrity between Get VPN (GDOI) peers. snmpEngineID Shared Secret 32 bits A unique string used to identify NVRAM Overwrite with the SNMP engine. This key is (plaintext) new engine ID entered by Crypto Officer. SNMPv3 Shared Secret 256 bits The password use to setup NVRAM Overwrite with password SNMP v3 connection. This key (plaintext) new password is entered by Crypto Officer. SNMPv3 AES 128 bits Encryption key used to protect Power cycle the session key SNMP traffic. This key is DRAM device derived via key derivation (plaintext) function defined in SP800-135 KDF (SNMPv3). Page 15 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Name CSP Type Size Description/Generation Storage Zeroization sRTP Master AES 128/196/256 bits This key is transported into the Power cycle the Key module protected by a TLS DRAM device session. This Key is used to (plaintext) derived sRTP Encryption key and sRTP Authentication keys. sRTP AES 128/196/256 bits Derived from sRTP Master Key Power cycle the Encryption key via key derivation function DRAM device defined in SP800-135 KDF (plaintext) (sRTP). This key is used to encrypt/decrypt sRTP packets. sRTP HMAC SHA-1 160 bits Derived from sRTP Master Key Power cycle the Authentication via key derivation function DRAM device key defined in SP800-135 KDF (plaintext) (sRTP). This key is used to authenticate sRTP packets. Table 8: CSP Table 8 Cryptographic Algorithms 8.1 Approved Cryptographic Algorithms The Cisco Integrated Services Router (ISR) 4351, 4331 and 4321 supports many different cryptographic algorithms. However, only FIPS approved algorithms may be used while in the FIPS mode of operation. The following table identifies the approved algorithms included in the ISR 4351, 4331 and 4321 for use in the FIPS mode of operation. Algorithm Cert. # IC2M(IOS XE) IOS Common Crypto Module/Common Crypto Module-Extended2 AES 2817 DRBG 481 ECDSA 493 HMAC SHA (1, 256, 1764 384, and 512) CVL(SP800-56A KAS) 252 CVL(SP800-135 KDF) 253 Page 16 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Algorithm Cert. # RSA 1471 SHS (SHA-1, 256, 384, 2361 and 512) Triple-DES 1688/1671 Intel Rangeley AES 3032 Table 9: FIPS-Approved Algorithms for use in FIPS Mode Note: Each of Triple-DES certs (#1688 and #1671) supports two-key and three-key Triple-Des options, but only three-key Triple-DES is used in FIPS mode. 8.2 Non-Approved Algorithms allowed for use in FIPS-mode The cryptographic module implements the following non-Approved algorithms that are allowed for use in FIPS-mode: Diffie-Hellman (key establishment methodology provides between 112 and 150 bits of encryption strength; non-compliant less than 112 bits of encryption strength) RSA (key wrapping; key establishment methodology provides between 112 and 150 bits of encryption strength; non-compliant less than 112 bits of encryption strength) EC Diffie-Hellman (key establishment methodology provides 128 or 192 bits of encryption strength) NDRNG 8.3 Non-Approved and Non-Allowed Algorithms The cryptographic module can implement the following non-Approved and non-Allowed algorithms for use outside of FIPS-mode: AES (non-Approved)3 MD5 DES 3 The validated AES algorithm implantation is considered non-Approved when utilized in with the MACSec protocol. Page 17 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. HMAC MD5 RC4 Diffie-Hellman (non-Approved)4 RSA key transport (non-Approved)5 SP 800-108 Key-Based Key Derivation Function (non-Approved) 8.4 IPsec protocol IV Generation The IV is constructed in compliance with the IPSec protocol and is only used in the context of the AES GCM mode encryption within the IPSec protocol. Furthermore this IV Generation is in compliance with the IPsec specifications outlined in RFC 6071. Additionally the IKEv2 protocol (RFC 7296) is used to establish the shared secret SKEYSEED from which the AES GCM encryption keys are derived. All of this is IKE key establishment is performed entirely within the cryptographic boundary of the module. 8.5 Self-Tests The modules include an array of self-tests that are run during startup and periodically during operations to prevent any secure data from being released and to insure all components are functioning correctly. The modules implement the following power-on self-tests: IC2M(IOS XE) o POSTs - IOS Common Crypto Module Firmware Integrity Test (HMAC SHA-256) AES (encrypt and decrypt) KATs AES GCM KAT AES-CMAC KAT DRBG KAT ECDSA Pair-Wise Consistency Test HMAC (SHA-1,SHA-256, SHA-384, SHA-512) KATs RSA (sign and verify) KAT Triple-DES (encrypt and decrypt) KATs o POSTs - IOS Common Crypto Module-Extended2 4 The allowed Diffie-Hellman implementation is considered non-Approved when utilizing key sizes which provide less than 112-bits of encryption strength 5 The validated RSA implementation is considered non-Approved when utilizing key sizes which provide less than 112-bits of encryption strength Page 18 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Triple-DES (encrypt and decrypt) KATs Rangeley AES (encrypt and decrypt) KAT The modules perform all power-on self-tests automatically at boot. All power-on self- tests must be passed before any operator can perform cryptographic services. The power- on self-tests are performed after the cryptographic systems are initialized but prior any other operations; this prevents the module from passing any data during a power-on self- test failure. In addition, the modules also provide the following conditional self-tests: IC2M(IOS XE) o Conditional IPsec Bypass test o Continuous Random Number Generator test for the FIPS-approved DRBG (SP800-90a DRBG) o Continuous Random Number Generator test for the non-approved RNG o Pair-Wise Consistency Test for RSA o Pair-Wise Consistency Test for ECDSA 9 Secure Operation 9.1 System Initialization and Configuration System setup is detailed in "Cisco 4000 Series ISRs Software Configuration Guide "Cisco 4400 Series ISRs and Cisco 4300 Series ISRs Software Configuration Guide" Step1 - The Crypto Officer must disable IOS Password Recovery by executing the following commands: configure terminal no service password-recovery end show version NOTE: Once Password Recovery is disabled, administrative access to the module without the password will not be possible. Step 2 - The value of the boot field must be 0x0102. This setting disables break from the console to the ROM monitor and automatically boots. From the "configure terminal" command line, the Crypto Officer enters the following syntax: Page 19 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Router# configure terminal Router(config)#config-register 0x2102 Router(config)#exit Router# show run | include boot Router# copy running-config startup-config Router# reload after install is complete Router>enable Router#show version Step 3 - The Crypto Officer must create the "enable" password for the Crypto Officer role. Procedurally, the password must be at least 8 characters, including at least one letter and at least one number, and is entered when the Crypto Officer first engages the "enable" command. The Crypto Officer enters the following syntax at the "#" prompt: Router> fips enable Router# configure terminal Router (config)# Router (config) # enable secret [PASSWORD] Example: Router(config)# enable secret cr1ny5ho Step 4 - The Crypto Officer must set up the operators of the module. The Crypto Officer enters the following syntax at the "#" prompt: Username [USERNAME] Password [PASSWORD] Step 5 ­ For the created operators, the Crypto Officer must always assign passwords (of at least 8 characters, including at least one letter and at least one number) to users. Identification and authentication on the console/auxiliary port is required for Users. From the "configure terminal" command line, the Crypto Officer enters the following syntax: Router(config)# line console 0 Router(config-line)# password [PASSWORD] Router(config-line)# login Step 6 - The Crypto Officer may configure the module to use RADIUS or TACACS+ for authentication. Configuring the module to use RADIUS or TACACS+ for authentication is optional. If the module is configured to use RADIUS or TACACS+, the Crypto-Officer must define RADIUS or TACACS+ shared secret keys that are at least 8 characters long, including at least one letter and at least one number. Page 20 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Step 7 - In service software upgrade is not allowed. The operator should not perform in service software upgrade of a validated firmware image Step 8 - Use of the debug.conf file is not allowed while in FIPS mode of operation. NOTE: The keys and CSPs generated in the cryptographic module during FIPS mode of operation cannot be used when the module transitions to non-FIPS mode and vice versa. While the module transitions from FIPS to non-FIPS mode or from non-FIPS to FIPS mode, all the keys and CSPs are to be zeroized by the Crypto Officer. 9.2 IPsec Requirements and Cryptographic Algorithms Step 1 - The only type of key management that is allowed in FIPS mode is Internet Key Exchange (IKE). Step 2 - Although the IOS implementation of IKE allows a number of algorithms, only the following algorithms are allowed in a FIPS 140-2 configuration: ah-sha-hmac esp-sha-hmac esp-3des esp-aes esp-aes-192 esp-aes-256 Step 3 - The following algorithms shall not be used: MD-5 for signing MD-5 HMAC DES 9.3 SSLv3.1/TLS Requirements and Cryptographic Algorithms When negotiating TLS cipher suites, only FIPS approved algorithms must be specified. All other versions of SSL except version 3.1 must not be used in FIPS mode of operation. The following algorithms are not FIPS approved and should not be used in the FIPS-approved mode: MD5 RC4 DES When the Crypto Office sets fips enable during the initial set-up. Diffie-Hellman negotiations will not accept any key sizes less than 2048. Negotiations with key sizes offered with less than 2048 will not be complete. Page 21 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 9.4 Remote Access 1 Telnet access to the module is only allowed via a secure IPSec tunnel between the remote system and the module. The Crypto officer must configure the module so that any remote connections via telnet are secured through IPSec, using FIPS- approved algorithms. Note that all users must still authenticate after remote access is granted. 2 SSH v2 access to the module is only allowed if SSH v2 is configured to use a FIPS-approved algorithm. The Crypto officer must configure the module so that SSH v2 uses only FIPS-approved algorithms. Note that all users must still authenticate after remote access is granted. 3 SNMP access is only allowed via when SNMP v3 is configured with AES encryption. 9.5 Cisco Unified Border Element (CUBE) TLS Configuration When configuring CUBE TLS connections, the following configuration command option must be executed to limit the TLS session options to FIPS-approved algorithms. sip-ua crypto signaling [strict-cipher] 9.6 Remote Access SSH access to the module is allowed in FIPS approved mode of operation, using SSH v2 and a FIPS approved algorithm. Page 22 of 20 © Copyright 2015 Cisco Systems, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice.