Cisco 5915 Embedded Services Routers FIPS 140-2 Non Proprietary Security Policy Level 1 Validation Version 1.2 April 9, 2013 © Copyright 2013 Cisco Systems, Inc. 1 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 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 5915 EMBEDDED SERVICES ROUTERS ........................................................... 5  2.1  THE 5915 EMBEDDED SERVICE ROUTER CRYPTOGRAPHIC MODULE PHYSICAL CHARACTERISTICS ........................................................................................................................ 5  2.2  MODULE INTERFACES ......................................................................................................... 6  These interfaces are depicted in the figures below: .................................................. 7  2.3  ROLES AND SERVICES ......................................................................................................... 9  2.3.1  User Services ................................................................................................ 9  2.3.2  Crypto Officer Services................................................................................ 10  2.3.3  Maintenance Role ....................................................................................... 11  2.3.4  Unauthenticated Services............................................................................ 11  2.3.5  Strength of Authentication ........................................................................... 11  2.4  PHYSICAL SECURITY ........................................................................................................ 12  2.5  CRYPTOGRAPHIC ALGORITHMS ........................................................................................ 12  2.5.1  Approved Cryptographic Algorithms ............................................................ 12  2.5.2  Non-FIPS Approved Algorithms Allowed in FIPS Mode .............................. 12  2.5.3  Non-Approved Cryptographic Algorithms .................................................... 12  2.6  CRYPTOGRAPHIC KEY MANAGEMENT .............................................................................. 13  2.7  SELF-TESTS ...................................................................................................................... 16  2.7.1  Self-tests performed by the IOS and Hardware ........................................... 17  3  SECURE OPERATION OF THE CISCO 5915 ESR ....................................................... 18  3.1  INITIAL SETUP .................................................................................................................. 18  3.2  SYSTEM INITIALIZATION AND CONFIGURATION ................................................................ 18  3.3  IPSEC REQUIREMENTS AND CRYPTOGRAPHIC ALGORITHMS ............................................ 19  3.4  PROTOCOLS ...................................................................................................................... 20  3.5  REMOTE ACCESS .............................................................................................................. 20  3.6  HTTPS/TLS MANAGEMENT IS NOT ALLOWED IN FIPS MODE. .......................................... 20  3.7  IDENTIFYING OPERATION IN AN APPROVED MODE ........................................................... 20  © Copyright 2013 Cisco Systems, Inc. 2 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 1 Introduction 1.1 Purpose This document is the non-proprietary Cryptographic Module Security Policy for the Cisco 5915 Embedded Services Router (ESR). This security policy describes how the Cisco 5915 Embedded Services Routers (Hardware Versions: Cisco 5915 ESR air-cooled card and Cisco 5915 ESR conduction-cooled card; Firmware Version: 1.0) meet the security requirements of FIPS 140-2, and how to operate the router with on-board crypto enabled in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the Cisco 5915 Embedded Services Routers. 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 1 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 only with operations and capabilities of the Cisco 5915 Embedded Services routers in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the routers from the following sources: • The Cisco Systems website contains information on the full line of Cisco Systems routers. Please refer to the following website: http://www.cisco.com/en/US/products/hw/routers/index.html © Copyright 2013 Cisco Systems, Inc. 3 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. • The Cisco 5915 Embedded Services Routers is part of the family of Mobile Internet Routers: http://www.cisco.com/en/US/products/hw/routers/products.html#N390A6E • 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. 1.4 Terminology In this document, the Cisco 5915 Embedded Services Routers are referred to as the 5915 ESR, router, the module, or the system. 1.5 Document Organization The Security Policy document is part of the FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: • Vendor Evidence document • Finite State Machine • Other supporting documentation as additional references This document provides an overview of the Cisco 5915 Embedded Services Router and explains the secure configuration and operation of the module. This introduction section is followed by Section 2, which details the general features and functionality of the router. 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 2013 Cisco Systems, Inc. 4 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2 Cisco 5915 Embedded Services Routers The Cisco 5915 is a high-performance, ruggedized router. With onboard hardware encryption, the Cisco 5915 offloads encryption processing from the router to provide highly secure yet scalable video, voice, and data services for mobile and embedded outdoor networks. The Cisco 5915 Embedded Services Routers provide scalable, secure, manageable router functionality that meets FIPS 140-2 Level 1 requirements. This section describes the general features and functionality provided by the routers. The Cisco 5915 Router Card uses industrial-grade components and is optimized for harsh environments that require Cisco IOS Software routing technology. The following subsections describe the physical characteristics of the routers. 2.1 The 5915 Embedded Service Router Cryptographic Module Physical Characteristics Figure 1 Cisco 5915 Air Cooled Router © Copyright 2013 Cisco Systems, Inc. 5 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 2 Cisco 5915 Conduction Cooled Router Cisco 5915 Embedded Services Router is a multiple-chip embedded cryptographic module. The router card is compliant with the PCI-104 specification. These cards are then inserted into a ruggedized enclosure (outside the cryptographic boundary) to protect against the elements. The physical boundary of the Cisco 5915 Embedded Services Router card is the cryptographic boundary. All of the functionality discussed in this document is provided by components within this cryptographic boundary. 2.2 Module Interfaces The module features the following interfaces: 1. One RS-232 serial console port (via edge fingers) 2. 2 Routed Fast Ethernet and 3 Switched Fast Ethernet interfaces (via edge fingers) 3. Power (via PCI stacking connector) 4. JTAG interface (via edge fingers) 5. LED signals (via edge fingers) © Copyright 2013 Cisco Systems, Inc. 6 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. These interfaces are depicted in the figures below: The interface for the router is located on the PCI fingers as shown in Figure 3 and Figure 4, respectively. Figure 3: 5915 Air cooled side view © Copyright 2013 Cisco Systems, Inc. 7 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Figure 4: 5915 Conduction cooled, side view The LED signals are located on the edge fingers. The card, itself, does not contain any LEDs. A system integrator is responsible for connecting the LED signals to actual LEDs: Name Description System LED OFF—No power BLINKING—Boot up phase or in ROMMON mode. SOLID—Steady state, IOS load completed and running. Temperature LED OFF—Thermal reading is within range BLINKING—Thermal reading is out-of-range. Port link status OFF—Link is down SOLID—Link is up Port activity status OFF—No activity BLINKING—Link is transmitting or receiving Factory default LED OFF—Not activated BLINKING—Signal assertion is detected. Factory default procedure is initiated. ON—Unit restored to Factory default state Table 2 – 5915 ESR LED Indicators © Copyright 2013 Cisco Systems, Inc. 8 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Each 5915 ESR provides a number of physical and logical interfaces to the device, and the physical interfaces provided by the module are mapped to the following FIPS 140-2 defined logical interfaces: data input, data output, control input, status output, and power. The logical interfaces and their mapping are described in the following table: Router Physical Interface FIPS 140-2 Logical Interface Edge fingers Data Input Interface Edge fingers Data Output Interface Edge fingers Control Input Interface Edge fingers Status Output Interface PCI Stacking connector Power Interface Table 3 – 5915 ESR FIPS 140-2 Logical Interfaces 2.3 Roles and Services Authentication in Cisco 5915 ESR is role-based. There are two main roles in the router that operators can assume: the Crypto Officer role and the User role. There is also a maintenance role available through the JTAG connector. 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 configuration of the encryption and decryption functionality is performed only by the Crypto Officer after authentication to the Crypto Officer role by providing a valid Crypto Officer username and password. Once the Crypto Officer configured the encryption and decryption functionality, the User can use this functionality after authentication to the User role by providing a valid User username and password. The Crypto Officer can also use the encryption and decryption functionality after authentication to the Crypto Officer role. The module supports RADIUS and TACACS+ for authentication. The RSA digital signature authentication mechanism is used to authenticate the User role via IPSec/IKE (IKEv1 and IKEv2) protocol implementation. The maintenance role does not include authentication, and it has the capability to read and write memory, reset the board, program the Complex Programmable Logic Device (CPLD), and debug Rommon. 2.3.1 User Services Users can access the system in two ways: 1. By accessing the console port with a terminal program or via IPSec protected telnet or SSH session to an Ethernet port. Please note that the PC used for the console connection is a non-networked PC. The IOS prompts the User for username and password. If the password is correct, the User is allowed entry to the IOS executive program. © Copyright 2013 Cisco Systems, Inc. 9 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2. Via an IPSec session. This session is authenticated either using a shared secret or RSA digital signature authentication mechanism. The services available to the User role consist of the following: View state of interfaces and protocols, version of IOS currently Status Functions running. Connect to other network devices and initiate diagnostic network Network Functions services (i.e., ping, mtrace). Adjust the terminal session (e.g., lock the terminal, adjust flow Terminal Functions control). Display directory of files kept in flash memory. Directory Services Negotiation and encrypted data transport via Get VPN GetVPN Perform the FIPS 140 start-up tests on demand Perform Self-Tests Zeroize cryptographic keys stored in Dynamic Random Access Zeroization Services Memory (DRAM) via power cycling 2.3.2 Crypto 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 as a User and then authenticates as the Crypto Officer role. During initial configuration of the router, the Crypto Officer password (the “enable” 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 and maintenance of the router. The Crypto Officer services consist of the following: Define network interfaces and settings, create command aliases, set Configure the router the protocols the router will support, enable interfaces and network services, set system date and time, and load authentication information. 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. View the router configuration, routing tables, active sessions, use View Status Functions gets to view SNMP MIB statistics, health, temperature, memory status, voltage, packet statistics, review accounting logs, and view physical interface status. © Copyright 2013 Cisco Systems, Inc. 10 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Log off users, shutdown or reload the router, erase the flash Manage the router memory, manually back up router configurations, zeroize all cryptographic keys or CSPs, view complete configurations, manager user rights, and restore router configurations. In addition, Crypto Officer also has access to all User services. Set up the configuration tables for IP tunneling. Set preshared keys Set Encryption/Bypass and algorithms to be used for each IP range or allow plaintext packets to be set from specified IP address. Perform the FIPS 140 start-up tests on demand Perform Self-Tests 2.3.3 Maintenance Role The module supports a Maintenance role while operating in FIPS mode of operation. The maintenance role can be accessed via the JTAG connector. The services available to this role include reading and writing memory, resetting the board, programming the Complex Programmable Logic Device (CPLD), and debugging Rommon. The entity entering the maintenance role must zeroize all plaintext keys and CSPs before entering and exiting the Maintenance role. 2.3.4 Unauthenticated Services The services available to unauthenticated users are: • Viewing the status output from the module’s LEDs • Perform bypass services • Powering the module on and off using the power switch on the third-party chassis 2.3.5 Strength of Authentication The security policy stipulates that all user passwords and shared secrets must be a minimum of 8 alphanumeric characters, so the password space is 2.8 trillion possible passwords. The possibility of randomly guessing a password is thus far less than one in one million. To exceed a one in 100,000 probability of a successful random password guess in one minute, an attacker would have to be capable of 28 million password attempts per minute, which far exceeds the operational capabilities of the module to support. When using RSA based authentication, RSA key pair has modulus size of 1024 bit to 2048 bit, thus providing between 80 bits and 112 bits of strength. Assuming the low end of that range, an attacker would have a 1 in 280 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 modules to support. © Copyright 2013 Cisco Systems, Inc. 11 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2.4 Physical Security The module is being validated at physical security level 1. As such apart from using production grade material, the module does not implement any physical security mechanisms. 2.5 Cryptographic Algorithms The module implements a variety of approved and non-approved algorithms. 2.5.1 Approved Cryptographic Algorithms The routers support the following FIPS-2 approved algorithm implementations: Algorithm Algorithm Certificate Number IOS (Freescale MPC8358E) Freescale MPC8358E AES 2031 962 and 1535 Triple-DES 1310 757 SHS 1779 933 HMAC 1232 537 DRBG 196 N/A RSA 1055 N/A Table 4: Approved Cryptographic Algorithms 2.5.2 Non-FIPS Approved Algorithms Allowed in FIPS Mode • Diffie-Hellman (key establishment methodology provides between 80 and 112 bits of encryption strength) • RSA key transport (key establishment methodology provides between 80 and 112 bits of encryption strength) • GDOI (key wrapping; key establishment methodology provides between 112 and 256 bits of encryption strength) 2.5.3 Non-Approved Cryptographic Algorithms The module supports the following non-approved cryptographic algorithms that shall not be used in FIPS mode of operation: • DES • DES MAC • HMAC MD4 • HMAC MD5 © Copyright 2013 Cisco Systems, Inc. 12 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. • MD4 • MD5 • RC4 2.6 Cryptographic Key Management The module securely administers both cryptographic keys and other critical security parameters such as passwords. The module supports the following types of key management schemes: • Internet Key Exchange Key Establishment (IKEv1/IKEv2) • GDOI Group Key Management Protocol All keys are also protected by the password-protection on the Crypto Officer role login, and can be zeroized by the Crypto Officer. The zeroization method for each individual keys or CSPs can be found in table 5 below. All cryptographic keys are exchanged and entered electronically or via Internet Key Exchange (IKE)/Group Domain of Interpretation (GDOI), and all CSPs are entered into the module by the Crypto Officer role. The module supports the following keys and critical security parameters (CSPs): ID Algorithm Size Description Storage Zeroization Method DRBG V SP 800-90A 128-bits Generated by entropy source via the SP 800- DRAM Automatically when CTR_DRBG 90A CTR_DRBG derivation function. It is (plaintext) the router is power stored in DRAM with plaintext form cycled DRBG key SP 800-90A 256-bits This is the 256-bit DRBG key used for SP DRAM Automatically when CTR_DRBG 800-90A CTR_DRBG (plaintext) the router is power cycled DRBG entropy SP 800-90A 256-bits HW based entropy source used to construct DRAM Automatically when input CTR_DRBG seed (plaintext) the router is power cycled DRBG seed SP 800-90A 384-bits Generated by entropy source via the SP 800- DRAM Automatically when CTR_DRBG 90A CTR_DRBG derivation function. Input (plaintext) the router is power to the DRBG to determine the internal state cycled of the DRBG Diffie-Hellman Diffie-Hellman 1024 The private exponent used in Diffie-Hellman DRAM Automatically after private exponent /1536/ (DH) exchange. Generate by the module. (plaintext) shared secret 2048 bits Zeroized after DH shared secret has been generated. generated. Diffie-Hellman Diffie-Hellman 1024/1536 Shared secret derived by the Diffie-Hellman DRAM Automatically after Shared Secret /2048-bits Key exchange (plaintext) session is terminated Skeyid Keyed SHA-1 160-bits Value derived from the shared secret within DRAM Automatically after IKE exchange. Zeroized when IKE session is (plaintext) IKE session terminated. terminated. skeyid_d Keyed SHA-1 160-bits The IKE key derivation key for non DRAM Automatically after ISAKMP security associations. (plaintext) IKE session terminated. © Copyright 2013 Cisco Systems, Inc. 13 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. IKE session Triple-DES/AES 168- The IKE session encrypt key. Derived in the DRAM Automatically after encryption key bits/256- module (plaintext) IKE session bits terminated. IKE session SHA-1 HMAC 160-bits The IKE session authentication key. Derived DRAM Automatically after authentication key in the module. (plaintext) IKE session terminated. ISAKMP Secret At least The key used to generate IKE skeyid during NVRAM “# no crypto isakmp preshared eight preshared-key authentication. It is entered by (plaintext or key” characters the Crypto Officer. “no crypto isakmp key” encrypted) command zeroizes it. This key can have two forms based on whether the key is related to the hostname or the IP address. IKE RSA RSA 1024/1536 RSA private key for IKE authentication. NVRAM “# crypto key zeroize Authentication /2048-bits Generated by the module, set as IKE RSA (plaintext) rsa" private Key Authentication Key with the “crypto keyring” or “ca trust-point” command. IPSec encryption Triple-DES/AES 168- The IPSec encryption key. Derived in the DRAM Automatically when key bits/256- module . Zeroized when IPSec session is (plaintext) IPSec session bits terminated. terminated. IPSec SHA-1 HMAC 160-bits The IPSec authentication key. Derived in the DRAM Automatically when authentication key module. The zeroization is the same as (plaintext) IPSec session above. terminated. GDOI Key Triple-DES/AES Triple- This key is generated by using the DRAM Automatically when encryption Key DES (168- “GROUPKEY-PULL” registration protocol (plaintext) session terminated. (KEK) bits)/AES with GDOI. Generate by the module. It is (128/192/ used protect GDOI rekeying data.” 256-bits) GDOI Traffic Triple-DES/AES Triple- This key is generated by using the DRAM Automatically when Encryption Key DES (168- “GROUPKEY-PULL” registration protocol (plaintext) session terminated. (TEK) bits)/AES and updated using the “GROUPKEY- (128/192/ PUSH” registration protocol with GDOI. 256-bits) Generate by the module. It is used to encrypt data traffic between Get VPN peers GDOI TEK HMAC SHA-1 160-bits This key is generated by using the DRAM Automatically when Integrity key “GROUPKEY-PULL” registration protocol (plaintext) session terminated. and updated using the “GROUPKEY- PUSH” registration protocol with GDOI. Generate by the module. It is used to ensure data traffic integrity between Get VPN peers. SSH RSA private RSA 1024/1536 This key is used for message signing when NVRAM “# crypto key zeroize key /2048 bits performing SSH authentication. Generated (plaintext or rsa” by the module. encrypted) SSH session key TDES /AES TDES This is the SSH session key. It is used to DRAM Automatically when (Key Size encrypt all SSH data traffics traversing (plaintext) SSH session 168 between the SSH client and SSH server. It is terminated bits)/AES derived in the module. (Key Size 128/192/2 56 bits) SSH session HMAC-SHA-1 160 bits This key is used to perform the DRAM Automatically when authentication key authentication between the SSH client and (plaintext) SSH session SSH server. It is derived in the module. terminated © Copyright 2013 Cisco Systems, Inc. 14 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. User password Shared 8 -32 The password of the User role. It is entered NVRAM Overwrite with new Secret characters by Crypto Officer. This password is zeroized (plaintext or password by overwriting it with a new password. encrypted) Enable password Shared 8 -32 The plaintext password of the CO role. It is NVRAM Overwrite with new Secret characters entered by the Crypto Officer. This (plaintext or password password is zeroized by overwriting it with a encrypted) new password. Enable secret Shared 8 -32 The ciphertext password of the CO role. NVRAM Overwrite with new Secret characters However, the algorithm used to encrypt this (plaintext or password password is not FIPS approved. Therefore, encrypted) this password is considered plaintext for FIPS purposes. It is entered by the Crypto Officer. This password is zeroized by overwriting it with a new password. RADIUS secret Shared At least The RADIUS shared secret. It is entered by NVRAM “# no radius-server Secret eight the Crypto Officer. This shared secret is (plaintext or key” characters zeroized by executing the “no radius-server encrypted), key” command. DRAM (plaintext) TACACS+ secret Shared At least The TACACS+ shared secret. It is entered NVRAM “# no tacacs-server Secret eight by the Crypto Officer. This shared secret is (plaintext or key” characters zeroized by executing the “no tacacs-server encrypted), key” command. DRAM (plaintext) TLS Server RSA RSA 1024/1536 Identity certificates for module itself and NVRAM Automatically when private key /2048-bits also used in TLS negotiations. This CSP is (plaintext or session terminated bits used for both SSL VPN and SIP Gateway encrypted) Signaling Over TLS Transport. TLS pre-master Shared Secret 384 Shared secret created using asymmetric DRAM Automatically when secret cryptography from which new session keys (plaintext) session terminated can be derived. This key was entered into the module via RSA key wrapping. SSL Traffic Keys Triple- Triple- Derived in the module. Used to protect the DRAM Automatically when DES/AES/HMAC DES traffics between SSL/TLS VPN peers. (plaintext) session terminated SHA-1 keys (168 bits)/AES (128/192/ 256- bits)/HM AC (160- bits) Table 5: Cryptographic Keys and CSPs The services accessing the CSPs, the type of access and which role accesses the CSPs are listed below. © Copyright 2013 Cisco Systems, Inc. 15 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. GDOI Traffic Encryption Key (TEK) IKE RSA Authentication private Key GDOI Key encryption Key (KEK) Diffie Hellman private exponent SSH session authentication key IKE session authentication key Diffie Hellman Shared Secret GDOI TEK Integrity Key IPSec authentication key IKE session encrypt key SSH RSA Private Key IPSec encryption key ISAKMP preshared TACACS+ secret Enable password SSH session key RADIUS secret User password Enable secret DRBG Key DRBG V skeyid_d Skeyid CSP Role/Service User Role Status Function r r r r r r r r r r r r r r r r r r r Network Function Terminal Function Directory Services Perform Self- tests r r r r r r r r r r r r r VPN Function w w w w w w w w w w w w w d d d d d d d d d d d d d CO Role r Configure the w module Define Rules and Filters Status Functions d d r r r r r Manage the w w w w w module d d d d d r r r r r r r r r r r r r r r r r Set w w w w w w w w w w w w w w w w w Encryption/ d d d d d d d d d d d d d d d d d Bypass Perform Self- tests r = read w = write d= delete Table 6: CSP/Role/Service Access Policy 2.7 Self-Tests In order to prevent any secure data from being released, it is important to test the cryptographic components of a security module to insure all components are functioning correctly. The router includes an array of self-tests that are run during startup and periodically during operations. All self-tests are implemented by the firmware and associated hardware component. An example of © Copyright 2013 Cisco Systems, Inc. 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. self-tests run at power-up is a cryptographic known answer test (KAT) on each of the FIPS- approved cryptographic algorithms and on the Diffie-Hellman algorithm. Examples of tests performed at startup are a software integrity test using an EDC. Examples of tests run periodically or conditionally include: a bypass mode test performed conditionally prior to executing IPSec, and a continuous random number generator test. If any of self-tests fail, the router transitions into an error state. In the error state, all secure data transmission is halted and the router outputs status information indicating the failure. Examples of the errors that cause the system to transition to an error state: • IOS image integrity checksum failed • Microprocessor overheats and burns out • Known answer test failed • NVRAM module malfunction. 2.7.1 Self-tests performed by the IOS and Hardware • IOS Self Tests o POST tests Firmware Integrity test AES Known Answer test DRBG Known Answer test HMAC-SHA-1 Known Answer test RSA Known Answer Test SHA-1/256/512 Known Answer test Triple-DES Known Answer test o Conditional tests RSA PWCT test Conditional bypass test CRNG test on DRBG CRNG tests on non-approved RNGs • Hardware Self Tests o POST tests AES Known Answer Test HMAC-SHA-1 Known Answer Test Triple-DES Known Answer Test © Copyright 2013 Cisco Systems, Inc. 17 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 3 Secure Operation of the Cisco 5915 ESR The Cisco 5915 ESR meets all the Level 1 requirements for FIPS 140-2. Follow the setting instructions provided below to place the module in FIPS-approved mode. Operating this router without maintaining the following settings will remove the module from the FIPS approved mode of operation. 3.1 Initial Setup 1. 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. 3.2 System Initialization and Configuration 1. The Crypto Officer must perform the initial configuration. IOS version 15.2(3)GC, filename c5940-adventerprisek9-mz.SPA.152-3.GC.bin is the only allowable image; no other image should be loaded. 2. The value of the boot field must be 0x0102. This setting disables break from the console to the ROM monitor and automatically boots the IOS image. From the “configure terminal” command line, the Crypto Officer enters the following syntax: config-register 0x0102 3. The Crypto Officer must create the “enable” password for the Crypto Officer role. The password must be 8 - 32 characters (all digits; all lower and upper case letters; and all special characters except ‘?’ are accepted) and is entered when the Crypto Officer first engages the “enable” command. The Crypto Officer enters the following syntax at the “#” prompt: enable secret [PASSWORD] 4. The Crypto Officer must always assign passwords (8-32 characters) to users. Identification and authentication on the console port is required for Users. From the “configure terminal” command line, the Crypto Officer enters the following syntax: line con 0 password [PASSWORD] login local 5. The Crypto Officer shall only assign users to a privilege level 1 (the default). © Copyright 2013 Cisco Systems, Inc. 18 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 6. The Crypto Officer shall not assign a command to any privilege level other than its default. 7. 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. RADIUS and TACACS+ shared secret key sizes must be at least 8 characters long. 8. Loading any IOS image onto the router is not allowed while in FIPS mode of operation. 3.3 IPSec Requirements and Cryptographic Algorithms 1. The only type of IPSec key establishment methods that is allowed in FIPS mode are Internet Key Exchange (IKE) and Group Domain of Interpretation (GDOI). 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 3. The following algorithms are not FIPS approved/allowed and should not be used during FIPS-approved mode: DES DES MAC HMAC MD4 HMAC MD5 MD4 MD5 RC4 4. The following non-FIPS approved, but FIPS allowed algorithms can be used in FIPS mode of operation: Diffie-Hellman (1024 - 2048 bits) key agreement scheme RSA (1024-2048 bits) key transport scheme GDOI (key wrapping; key establishment methodology provides between 112 and 256 bits of encryption strength) © Copyright 2013 Cisco Systems, Inc. 19 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 3.4 Protocols 1. SNMP v3 over a secure IPSec tunnel may be employed for authenticated, secure SNMP gets and sets. Since SNMP v2C uses community strings for authentication, only gets are allowed under SNMP v2C. 3.5 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 access to the module is only allowed if SSH is configured to use a FIPS-approved algorithm. The Crypto officer must configure the module so that SSH uses only FIPS- approved algorithms. Note that all users must still authenticate after remote access is granted. 3.6 HTTPS/TLS management is not allowed in FIPS mode. 3.7 Identifying Operation in an Approved Mode The following activities are required to verify that that the module is operating in an Approved mode of operation. 1. Verify that the length of User and Crypto Officer passwords and all shared secrets are at least eight (8) characters long, include at least one letter, and include at least one number character, as specified in the “Secure Operation of the Cisco 5915 ESR” section of this document. 2. Issue the following commands: 'show crypto ipsec sa', 'show crypto isakmp policy', and ‘show crypto gdoi policy’. Verify that only FIPS approved algorithms are used. © Copyright 2013 Cisco Systems, Inc. 20 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.