Ciena Corporation Ciena 6500 Packet-Optical Platform 4x10G Hardware Version: 2.0 Firmware Version: 2.00 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 3 Document Version: 0.5 Prepared by/for: Ciena Corporation 7035 Ridge Road Hanover, Maryland 21076 United States of America Phone: +1 (410) 694-5700 Contact: http://www.ciena.com/about/contact- us/?navi=top http://www.ciena.com Security Policy, Version 0.5 April 20, 2016 Table of Contents 1. INTRODUCTION ................................................................................................................... 3 1.1 PURPOSE ................................................................................................................................................................ 3 1.2 REFERENCES .......................................................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 3 2. CIENA 6500 PACKET-OPTICAL PLATFORM 4X10G........................................................ 4 2.1 OVERVIEW ............................................................................................................................................................. 4 2.2 MODULE SPECIFICATION..................................................................................................................................... 5 2.3 MODULE INTERFACES .......................................................................................................................................... 7 2.4 ROLES, SERVICES, AND AUTHENTICATION ....................................................................................................... 8 2.4.1 Authorized Roles ..................................................................................................................................................... 8 2.4.2 Services ...................................................................................................................................................................... 8 2.4.3 Authentication Mechanisms ............................................................................................................................. 11 2.5 PHYSICAL SECURITY ...........................................................................................................................................13 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................13 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................13 2.8 EMI/EMC ............................................................................................................................................................20 2.9 SELF-TESTS ..........................................................................................................................................................20 2.9.1 Power–Up Self–Tests ......................................................................................................................................... 20 2.9.2 Conditional Self-Tests ......................................................................................................................................... 20 2.9.3 Critical Function Self-Tests................................................................................................................................ 21 2.9.4 Self-Test Failure Handling................................................................................................................................. 21 2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................21 3. SECURE OPERATION ......................................................................................................... 22 3.1 INITIAL SETUP......................................................................................................................................................22 3.2 SECURE MANAGEMENT .....................................................................................................................................23 3.2.1 Management ........................................................................................................................................................ 23 3.2.2 Physical Inspection............................................................................................................................................... 23 3.2.3 Monitoring Status ................................................................................................................................................ 23 3.2.4 Zeroization ............................................................................................................................................................ 23 3.3 USER GUIDANCE ................................................................................................................................................23 4. ACRONYMS .......................................................................................................................... 24 Table of Figures FIGURE 1 – THE MODULE ON CIRCUIT PACK FOR SECURE COMMUNICATION...............................................................4 FIGURE 2 – TOP AND BOTTOM VIEW OF THE MODULE ......................................................................................................5 FIGURE 3 – MEZZANINE CONNECTOR ..................................................................................................................................7 FIGURE 4 – TOP AND BOTTOM VIEW OF THE MODULE ................................................................................................... 22 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................5 TABLE 2 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .............................................................................................6 TABLE 3 – LOGICAL INTERFACE MAPPING.............................................................................................................................7 TABLE 4 – AUTHORIZED OPERATOR SERVICES .....................................................................................................................8 TABLE 5 – ADDITIONAL SERVICES........................................................................................................................................ 10 TABLE 6 – AUTHENTICATION MECHANISM........................................................................................................................ 12 TABLE 7 – CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS............................................... 14 TABLE 8 – ACRONYMS .......................................................................................................................................................... 24 Ciena 6500 Packet-Optical Platform 4x10G Page 2 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 1. Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy (SP) for the Ciena 6500 Packet-Optical Platform 4x10G (Hardware Version: 2.0, Firmware Version: 2.00) from Ciena Corporation. This Security Policy describes how the Ciena 6500 Packet-Optical Platform 4x10G meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This document also describes how to run the module in a secure FIPS-Approved mode of operation. This module supports one FIPS-Approved module of operation. This policy was prepared as part of the Level 3 FIPS 140-2 validation of the module. The Ciena 6500 Packet-Optical Platform 4x10G is referred to in this document as the cryptographic module or the module. 1.2 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 Ciena website (http://www.ciena.com/) contains information on the full line of products from Ciena Corporation.  The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm) contains contact information for individuals to answer technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains:  Vendor Evidence document  Finite State Model document  Other supporting documentation as additional references This Security Policy and the other validation submission documentation were modified from originals produced by Corsec Security, Inc. in 2014 while under contract to Ciena. With the exception of this Non- Proprietary Security Policy, the FIPS 140-2 Submission Package is proprietary to Ciena and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Ciena. Ciena 6500 Packet-Optical Platform 4x10G Page 3 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 2. Ciena 6500 Packet-Optical Platform 4x10G 2.1 Overview The module is the Ciena 6500 Packet-Optical Platform 4x10G, which is a daughter/mezzanine card designed for use on the 4x10G Encryption OTR1 circuit pack of the 6500 series Packet-Optical Platform. The module, also known as the Krypto Daughter Card, provides fully secure cryptographic functionality (including key generation and management, physical security, and identification and authentication of the module’s operators) on the 6500 Packet-Optical Platform. Architected for network modernization, Ciena’s 6500 Packet-Optical Platform converges comprehensive Ethernet, TDM2, and WDM3 capabilities in one platform for delivery of emerging and existing services, from the access edge to the backbone core. By using the 4x10G Encryption OTR circuit pack, customers can deploy solutions for 10Gbps4 client services with high capacity and offer differentiated service options including several path/equipment protection options. The 4x10G Encryption OTR circuit pack is a single-slot card that supports wire-speed point-to-point encryption and decryption (see Figure 1 below). The card contains eight 10G5 ports; four SFP 6+/SFP- based client ports (ports 1, 2, 3, and 4) and four XFP 7-based line ports (ports 5, 6, 7, and 8) , with full 10Gbps throughput for all client ports. Client Ports Line Ports (SFP+/SFP) (XFP) 1 5 Krypto Daughter Card 2 6 encrypt/decrypt Mapper 1 Mapper 2 encrypt/decrypt 3 7 encrypt/decrypt encrypt/decrypt 4 8 OTR Motherboard Figure 1 – The Module on Circuit Pack for Secure Communication The circuit pack is composed of two primary components: the OTR motherboard and the module (shown as ‘Krypto Daughter Card’ above). The OTR motherboard contains two traffic-mapping devices, where ‘Mapper 1’ connects to the four client ports and ‘Mapper 2’ connects to the four line ports. The Krypto Daughter Card connects to the OTR motherboard via a mezzanine connector, and provides the bulk encryption and decryption capabilities. OTR – Optical Transponder 1 TDM – Time-Division Multiplexing 2 WDM – Wavelength-Division Multiplexing 3 Gbps – Gigabits Per Second 4 G – Gigabit 5 SFP – Small Form Factor Pluggable 6 XFP – (10 Gigabit) Small Form Factor Pluggable 7 Ciena 6500 Packet-Optical Platform 4x10G Page 4 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 This validation focuses on the Ciena 6500 Packet-Optical Platform 4x10G daughter card depicted in Figure 1 with red-colored dotted line. The module is housed in an aluminum enclosure with a heat sink lid secured with tamper-resistant screws. Any attempts to remove the lid will provide tamper evidence via two tamper evident labels and tamper-resistant screws, and additionally the module will immediately zeroize all keys and CSPs if the lid is removed. Figure 2 below shows the top and bottom view of the module. Figure 2 – Top and Bottom View of the Module The module is validated at the FIPS 140-2 section levels as shown in Table 1 below. Table 1 – Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 3 2 Cryptographic Module Ports and Interfaces 3 3 Roles, Services, and Authentication 3 4 Finite State Model 3 5 Physical Security 3 N/A8 6 Operational Environment 7 Cryptographic Key Management 3 EMI/EMC9 8 3 9 Self-tests 3 10 Design Assurance 3 11 Mitigation of Other Attacks N/A 2.2 Module Specification The Ciena 6500 Packet-Optical Platform 4x10G is a hardware cryptographic module with a multiple-chip embedded embodiment. The module consists of firmware and hardware components enclosed in an aluminum metal enclosure. The main hardware components consist of integrated circuits, processors, Random Access Memories (SDRAM and BBRAM), flash memories (NOR and EEPROM), FPGAs10, and N/A – Not Applicable 8 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility 9 FPGA – Field Programmable Gate Array 10 Ciena 6500 Packet-Optical Platform 4x10G Page 5 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 the enclosure. The overall security level of the module is 3. The cryptographic boundary of the module surrounds the module enclosure, which includes all the hardware components, firmware, and the metal case. The Ciena 6500 Packet-Optical Platform 4x10G implements the FIPS-Approved algorithms as listed in Table 2 below. Table 2 – FIPS-Approved Algorithm Implementations Certificate Number Algorithm FPGA Firmware AES11 – CTR12and ECB13 modes with 256-bit keys #3600 AES – CBC14 mode with 128, 192, and 256-bit keys - #3599 AES–GCM mode with 128 and 256-bit keys - #3599 Triple-DES – CBC (3-key) - #2004 SHA15-1, SHA-256, SHA-384 and SHA-512 - #2962 HMAC16 with SHA-1, SHA-256, SHA-384 and SHA-512 - #2297 NIST17 SP18800-90A CTR_DRBG19 - #933 RSA20 Key generation (2048-bit) (FIPS 186-4) - #1851 RSA (PKCS21 #1 v1.5) signature generation/verification - #1851 (2048-bit) ECDSA PKG22 with NIST-defined P-curves P-224, P-256, P- - #735 384, and P-521 and PKV23 with NIST defined P-curves P- 192, P-224, P-384, and P-521. ECDSA signature generation with NIST-defined P-curves P- - #735 224, P-256, P-384 and P-521 with SHA-256, SHA-384, and SHA-512 ECDSA signature verification with NIST-defined P-curves P- 192, P-224, P-256, P-384, and P-521 with SHA-1, SHA-256, SHA-384, and SHA-512 Section 4.2 TLS24 v1.2 (SP 800-135) - #623 Section 4.1.1 IKE25 v1 (SP 800-135) - #623 Section 4.1.2 IKE v2 (SP 800-135) - #623 Note: The TLS and IKE protocols have not been reviewed or tested by the CAVP or CMVP. AES – Advanced Encryption Standard 11 CTR – Counter 12 ECB – Electronic Codebook 13 CBC – Cipher Block Chaining 14 SHA – Secure Hash Algorithm 15 HMAC – (Keyed) Hash Message Authentication Code 16 NIST – National Institute of Standards and Technology 17 SP – Special Publication 18 DRBG – Deterministic Random Bit Generator 19 RSA – Rivest Shamir Adleman 20 PKCS – Public-Key Cryptography Standards 21 PKG – Public Key Generation 22 PKV – Public Key Validation 23 TLS – Transport Layer Security 24 IKE – Internet Key Exchange 25 Ciena 6500 Packet-Optical Platform 4x10G Page 6 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Additionally, the module implements the following algorithms that are allowed for use in a FIPS-Approved mode of operation:  Non-Deterministic Random Number Generator (NDRNG)  Diffie-Hellman26 (2048-bit)  Elliptic Curve Diffie-Hellman27 (using NIST-defined P-curve P-384) 2.3 Module Interfaces The module’s design separates the physical ports into four logically distinct and isolated categories. They are:  Data Input Interface  Data Output Interface  Control Input Interface  Status Output Interface Data input/output consists of the data utilizing the services provided by the module. This data enters and exits the module through the mezzanine connector of the module. Control input consists of configuration or administration data entered into the module through the mezzanine connector of the module remotely using the MyCryptoTool interface or locally using the Transport Control Subsystem (TCS) interface. Control input that enters the module through MyCryptoTool is secured with an HTTPS/TLS session. Status output consists of the signals output via the mezzanine connector that are then translated into alarms, LED28 signals, and log information by the circuit pack. The physical ports and interfaces of the Ciena 6500 Packet-Optical Platform 4x10G are depicted below in Figure 3. Figure 3 – Mezzanine Connector Table 3 lists the physical ports and interfaces available in the module, and provides the mapping from the physical ports and interfaces to logical interfaces as defined by FIPS 140-2. Table 3 – Logical Interface Mapping FIPS 140-2 Logical Interface Module Interface Data Input Interface Mezzanine Connector 26 Caveat: Diffie-Hellman (key agreement; key establishment methodology provides 112 bits of encryption strength). Please see NIST Special Publication 800-131A for further details. 27 Caveat: EC Diffie-Hellman (key agreement; key establishment methodology provides 192 bits of encryption strength). Please see NIST Special Publication 800-131A for further details. LED – Light Emitting Diode 28 Ciena 6500 Packet-Optical Platform 4x10G Page 7 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 FIPS 140-2 Logical Interface Module Interface Data Output Interface Mezzanine Connector Control Input Interface Mezzanine Connector, tamper switch Status Output Interface Mezzanine Connector Power Interface Mezzanine Connector 2.4 Roles, Services, and Authentication The following sections described the authorized roles supported by the module, the services provided for those roles, and the authentication mechanisms employed. 2.4.1 Authorized Roles The module supports two authorized roles: a Crypto Officer (CO) role and a User role. The Crypto Officer and the User roles are responsible for module initialization and module configuration, including security parameters, key management, status activities, and audit review. All CO and User services (except the firmware upgrade service via the TCS interface) are provided through the MyCryptoTool. The MyCryptoTool interface is secured via an HTTPS/TLS session. The TCS interface is available to the CO only and is used for the firmware load. Operators must assume an authorized role to access module services. Operators explicitly assume both the CO and User role by a mutually authenticated HTTPS/TLS session over MyCryptoTool using digital certificates. Operators explicitly assume the CO role over the TCS interface using a username and password credential. 2.4.2 Services The services that require operators to assume an authorized role are listed in Table 4 below. Please note that the keys and Critical Security Parameters (CSPs) listed in Table 4 use the following indicators to show the type of access required:  R – Read: The CSP is read.  W – Write: The CSP is established, generated, modified, or zeroized.  X – Execute: The CSP is used within an Approved or Allowed security function or authentication mechanism. Table 4 – Authorized Operator Services Operator Service Description Input Output CSP and Type of Access CO User Initialize the Initialize the module Command Status output None   module Signing CA RSA/ ECDSA Configure the Configure enterprise Command Public Key – R/X Command module using settings and import and   response MKEK29 – R/X MyCryptoTool certificates parameter KEK30 – R/X MKEK – Master Key Encryption Key 29 KEK – Key Encryption Key 30 Ciena 6500 Packet-Optical Platform 4x10G Page 8 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Operator Service Description Input Output CSP and Type of Access CO User Monitor Monitor specific alarms Command Status output None   alarms for diagnostic purposes Manage data encryption DEK31 – R/W certificate enrollment, BKEK32 – R/X Manage data signing CA certificate Command MKEK – R/X Command encryption information, trusted CA and KEK – R/X   response certificate certificates, import CA parameters Signing CA RSA/ ECDSA certificate and CRL, and Public Key – R/X X clear CSPs BKEK – R/X Manage web Manage web access Command MKEK – R/X access Command certificate and import and KEK – R/X   certificate and response CRL parameters Signing CA RSA/ ECDSA import CRL Public Key – R/X Show the system status, Show FIPS FIPS-Approved mode, status and Command Status output None   configuration settings, and statistics active alarms. View system status View system messages in historical Command Status output None   logs alarm log and provisioning log. Zeroize the keys and Please see the ‘Zeroization’ CSPs listed in the Zeroize using Command Command column in Table 7 below.   ‘Zeroization’ column in MyCryptoTool response Table 7 below Employ BKEK – R/X Encrypt or decrypt user Command encryption / Command MKEK – X data, keys, or and   decryption response DEK – X management traffic parameters service TLS Session Key – X Message Command Authenticate Command TLS Authentication Key – X Authentication and   management traffic response service parameters Generate Module Data Path RSA/ Command asymmetric Generate the asymmetric ECDSA Private Key – W and Key pair   key pair (data key pair (RSA/ECDSA) Module Data Path RSA/ parameters path) ECDSA Public Key – W Generate Module Web Access RSA/ Command asymmetric Generate the asymmetric ECDSA Private Key – W and Key pair   key pair (web key pair (RSA/ECDSA) Module Web Access RSA/ parameters access) ECDSA Public Key – W Generate a signature for Generate Command the supplied message Status, Module RSA/ ECDSA Private signature and   using specified key and signature Key – R/X (CSR) parameters RSA/ECDSA algorithm DEK – Data Encryption Key 31 BKEK – Base Key Encryption Key 32 Ciena 6500 Packet-Optical Platform 4x10G Page 9 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Operator Service Description Input Output CSP and Type of Access CO User Verify the signature on the supplied message Command Verify Module RSA/ ECDSA Public using the specified key and Status   signature Key – R/X and RSA/ECDSA parameters algorithm Command Test the module during Command Perform device response and operation, and monitor and None   diagnostics status via log the module parameters and LEDs Upgrade the KM Upgrade KM Command Command application firmware using application and response and ECDSA Public Key – R/X  ECDSA signature firmware parameters status output verification Upgrade the KM FPGA Command Command Upgrade KM using ECDSA signature and response and ECDSA Public Key – R/X  FPGA verification parameters status output In FIPS-Approved mode, the module provides a limited number of services for which the operator is not required to assume an authorized role (see Table 5). None of the services listed in the table disclose cryptographic keys and CSPs or otherwise affect the security of the module. Table 5 – Additional Services CSP and Type of Service Description Input Output Access CO RSA/ECDSA Public key – R/X User RSA/ECDSA Public key Authenticates Perform operator – R/X operators to the Command Status output authentication CA RSA/ECDSA Public Key – module R/X Preshared Authentication String – R/X Perform peer Authenticates peer Peer RSA/ECDSA Public key Command Status output authentication devices to the module – R/X Zeroize certificates Command Please see the ‘Zeroization’ Zeroize using TCS Command and KEK response column in Table 7 below. Performs Power-up Use power button Perform on- All plaintext keys and CSPs – Self-Tests on demand on the host system, Status output demand self-tests W via module restart Command Show the system Show system status status, system and statistics using identification, and Command Status output None TCS configuration settings of the module Configure and manage Configure the Response and the carrier Command None module using TCS status output provisioning Ciena 6500 Packet-Optical Platform 4x10G Page 10 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 CSP and Type of Service Description Input Output Access DEK – W/X Encrypt and decrypt Process data traffic None Status output Entropy Input string – R data traffic DRBG seed – W/R 2.4.3 Authentication Mechanisms The module supports identity-based authentication. Module operators must authenticate to the module before being allowed access to services that require the assumption of an authorized role. The module authenticates an operator using digital certificates containing public key of the operator. The authentication is achieved via the process of initiating a TLS session and using digital certificates towards mutual authentication. The process of mutual authentication provides assurance to the module that it is communicating with an authenticated operator. The strength calculation below provides minimum strength based on the public key size in the digital certificates. The module employs the authentication methods described in Table 6 to authenticate Crypto Officers and Users. Ciena 6500 Packet-Optical Platform 4x10G Page 11 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Table 6 – Authentication Mechanism Authentication Strength Type Public Key The module supports RSA digital certificate authentication of Crypto Officers and Certificates Users during MyCryptoTool access. Using conservative estimates and equating a 2048-bit RSA key to a 112-bit symmetric key, the probability for a random attempt to succeed is 1:2112 or 1: 5.19 x 1033. Alternately the module can be configured to support ECDSA digital certificate authentication of COs and Users during MyCryptoTool access. Using conservative estimates and equating the use of ECDSA with the P-384 elliptic curve to a 192-bit symmetric key, the probability for a random attempt to succeed is: 1:2192 or 1: 6.28 x 1051 For either mode this is less than 1:1,000,000 as required by FIPS 140-2 The fastest network connection supported by the modules over Management interfaces is 5 Mbps. Hence, at most (5 ×106 × 60 = 3 × 108 =) 300,000,000 bits of data can be transmitted in one minute. Therefore, the probability that a random attempt will succeed or a false acceptance will occur in one minute is In RSA Mode: 1: (2112 possible keys / ((3 × 108 bits per minute) / 112 bits per key)) 1: (2112 possible keys / 2,678,572 keys per minute) 1: 19.38 × 1026; which is less than 1:100,000 as required by FIPS 140-2. In ECC Mode: 1: (2192 possible keys / ((3 × 108 bits per minute) / 192 bits per key)) 1: (2192 possible keys / 1,562,500 keys per minute) 1: 4.02 × 1051 which is less than 1:100,000 within one minute as required by FIPS 140-2. Preshared Key The module supports the use of Preshared authentication string for the TCS interface accessing the module on behalf of the Crypto Officer. An HMAC-SHA- 256 operation with a 512-bit key is performed on the Preshared authentication string. The 256-bit output value of the HMAC-SHA-256 value will have an equivalent symmetric key strength of 128 bits, Using conservative estimates, the probability for a random attempt to succeed is 1:2128 or 1: 3.40 × 1038. The module implements a 200 ms delay between authentication attempts yielding a rate of five (5) attempts per second, and therefore 300 attempts per minute. Given that an attacker will have at most, 300 attempts in one minute, and there are 1: 3.40 × 1038 possibilities, the probability that a random attempt will succeed or a false acceptance will occur in one minute is: 1: 3.40 × 1038 / 300 attempts per minute 1: 1.13 x 1036 which is less than 1:100,000 as required by FIPS 140-2. The module also performs authentication of Peers using public key certificates but the module does not provide any authenticated services to the Peer. Ciena 6500 Packet-Optical Platform 4x10G Page 12 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 2.5 Physical Security All CSPs are stored and protected within the module’s hard aluminum enclosure. The enclosure is completely opaque within the visible spectrum. The enclosure is secured using tamper-resistant screws, tamper-evident labels, and tamper switches with tamper-response circuitry. Any attempts to defeat or bypass the tamper-response mechanism on the enclosure to access the module’s internal components would result in zeroization of all the plaintext keys and CSPs. Once the module is commissioned and the tamper-response circuitry is activated, it continuously monitors the enclosure via the tamper switches. On removal of the cover, detection of unauthorized access, or tamper event, the tamper-response circuitry inside the enclosure immediately erases all the plaintext keys and CSPs stored within the module. Further, the enclosure of the module has been tested for hardness at a temperature of 74°F; no assurance is provided for Level 3 hardness conformance at any other temperature. 2.6 Operational Environment The operational environment of the module does not provide access to a general-purpose operating system (OS) to the module operator. The module’s Xilinx XC7Z045 processor runs an embedded Linux Kernel in a non-modifiable operational environment. The operating system is not modifiable by the operator, and only the module’s signed image can be executed. All firmware downloads are digitally signed, and a conditional self-test (ECDSA signature verification) is performed during each download. If the signature test fails, the new firmware is ignored and the current firmware remains loaded. Only FIPS validated firmware may be loaded into the module to maintain the module’s validation. 2.7 Cryptographic Key Management The module generates keys as described in example #1 of FIPS 140-2 Implementation Guidance 7.8. It uses the FIPS-Approved CTR_DRBG (as specified in SP 800-90A) to generate cryptographic keys and RSA/ECDSA key pairs. The DRBG is seeded from seeding material provided by a hardware-based Non- Deterministic Random Number Generator (NDRNG), which provides an entropy source and whitening circuitry to supply a uniform distributed unbiased random sequence of bits to the DRBG. The module supports the CSPs described in Table 7. Ciena 6500 Packet-Optical Platform 4x10G Page 13 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Table 7 – Cryptographic Keys, Cryptographic Key Components, and CSPs Key Key Type Generation / Input Output Storage Zeroization33 Use Base Key AES 256-bit Preloaded at the Never exits Stored in plaintext in Power is removed from BB Used for decrypting MKEK Encryption Key key factory the module battery backed (BB) RAM (BKEK) RAM34 in the module Master Key AES 256-bit Preloaded at the Never exits Encrypted with BKEK Power is removed from BB Used for encryption/decrypting Encryption Key key factory the module and stored in the non- RAM KEK (MKEK) volatile memory Key Encryption AES 256-bit Generated internally Never exits Encrypted with MKEK Power is removed from BB Used for encrypting/decrypting Key (KEK) key the module and stored in non- RAM or by command via private key of an entity key pair volatile memory MyCryptoTool and TCS interface Data Encryption AES 256-bit Generated internally Never exits Plaintext in RAM By session termination, Used for encrypting or Key (DEK) key the module reboot, power removal, or decrypting payload data command via between an authorized MyCryptoTool and TCS external entity and the module interface Initialization 128-bit value Generated internally Never exits Plaintext in RAM By session termination, Used for encrypting or Vector (IV) the module reboot, power removal, or decrypting payload data command via between an authorized MyCryptoTool and TCS external entity and the module interface Preshared 256-bit value Hardcoded at the Never exits Stored plaintext in N/A Used for authenticating a CO Authentication factory the module non-volatile memory for the Firmware Load service String (embedded in code) Zeroization – Upon the detection of a tamper event, the module zeroizes all keys and CSPs listed in Table 7. 33 RAM – Random Access Memory 34 Ciena 6500 Packet-Optical Platform 4x10G Page 14 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Key Key Type Generation / Input Output Storage Zeroization33 Use IKE DH35 Private 224-bit DH Generated internally Never exits Plaintext in RAM By session termination, Used for exchanging shared Component key during IKE negotiation the module reboot, power removal, or secret to derive session keys command via during IKE MyCryptoTool and TCS interface IKE DH Public 2048-bit DH The module’s public The module’s Plaintext in RAM By session termination, Used for exchanging shared Component key key is generated public key reboot, power removal, or secret to derive session keys internally during IKE exits the command via during IKE negotiation; public key module in MyCryptoTool and TCS of a peer enters the plaintext; interface module in plaintext public key of the a peer never exits the module IKE Session AES 256-bit Generated internally Never exits Plaintext in RAM By session termination, Used for encrypting/decrypting Encryption Key key during DH key the module reboot, power removal, or IKE messages negotiation command via MyCryptoTool and TCS interface IKE Session HMAC SHA- Generated internally Never exits Plaintext in RAM By session termination, Used for authenticating IKE Authentication 256 during DH key the module reboot, power removal, or messages Key negotiation command via MyCryptoTool and TCS interface DH – Diffie-Hellman 35 Ciena 6500 Packet-Optical Platform 4x10G Page 15 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Key Key Type Generation / Input Output Storage Zeroization33 Use IKEv2 ECDH36 384-bit value Generated internally Never exits Stored in plaintext in By session termination, Used for exchanging shared Private during IKEv2 the module RAM reboot, power removal, or secret to derive session keys Component negotiation command via during IKEv2 MyCryptoTool and TCS interface IKEv2 ECDH 384-bit value The module’s public The module’s Stored in plaintext in By session termination, Used for exchanging shared Public component is public RAM reboot, power removal, or secret to derive session keys Component generated internally component command via during IKEv2 during IKEv2 exits the MyCryptoTool and TCS negotiation; public module in interface component of a peer plaintext; enters the module in public key of plaintext the a peer never exits the module IKEv2 Session AES 256-bit Generated internally Never exits Stored in plaintext in By session termination, Used for encrypting/decrypting Encryption Key key during EC DH key the module RAM reboot, power removal, or IKEv2 messages using AES- negotiation command via GCM MyCryptoTool and TCS interface IKEv2 Session HMAC SHA- Generated internally Never exits Stored in plaintext in By session termination, Used for authenticating IKEv2 Authentication 384 during EC DH key the module RAM reboot, power removal, or messages Key negotiation command via MyCryptoTool and TCS interface ECDH – Elliptic Curve Diffie-Hellman 36 Ciena 6500 Packet-Optical Platform 4x10G Page 16 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Key Key Type Generation / Input Output Storage Zeroization33 Use TLS Session Key AES 128 or Generated internally Never exits Stored in plaintext in By session termination, Used for encrypting/decrypting 256-bit or during session the module RAM reboot, power removal, or TLS messages Triple-DES negotiation command via 168-bit key MyCryptoTool and TCS interface TLS HMAC SHA- Generated internally Never exits Stored in plaintext in By session termination, Used for authenticating TLS Authentication 256, HMAC during session the module RAM reboot, power removal, or messages Key SHA-384 negotiation command via MyCryptoTool and TCS interface TLS Pre-Master 384-bit Generated internally Never exits Stored in plaintext in By session termination, Establish the TLS Master Secret Secret random value during session the module RAM reboot, power removal, or negotiation command via MyCryptoTool and TCS interface TLS Master 384-bit Generated internally Never exits Stored in plaintext in By session termination, Establish the TLS Session Key Secret random value during session the module RAM reboot, power removal, or negotiation command via MyCryptoTool and TCS interface Peer RSA Public 2048-bit key Enters the module in Never exits Stored in plaintext in By reboot, power removal, Used for authenticating the Key encrypted form the module RAM or command via peers MyCryptoTool and TCS interface CA RSA Public 2048 or Enters the module in Never exits Stored plaintext in By Command via Used for authenticating the Key 4096-bit key encrypted form the module non-volatile memory MyCryptoTool and TCS operator interface CO RSA Public 2048-bit key Enters the module in Never exits Stored in plaintext in By reboot, power removal, Used for authenticating the Key encrypted form the module RAM or command via CO MyCryptoTool and TCS interface Ciena 6500 Packet-Optical Platform 4x10G Page 17 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Key Key Type Generation / Input Output Storage Zeroization33 Use User RSA Public 2048-bit key Enters the module in Never exits Stored in plaintext in By reboot, power removal, Used for authenticating the Key encrypted form the module RAM or command via User MyCryptoTool and TCS interface Module RSA 2048-bit key Generated internally Never exits Stored encrypted with By command via Used for signature generation Private Key using approved DRBG; the module KEK in non-volatile MyCryptoTool and TCS imported in encrypted memory interface form Module RSA 2048-bit key Generated internally Exits the Stored plaintext in By command via Used for mutual authentication Public Key using approved DRBG; module non-volatile memory MyCryptoTool and TCS imported in encrypted encrypted interface form Peer ECDSA 384-bit key Enters the module in Never exits Stored in plaintext in By reboot, power removal, Used for authenticating the Public Key encrypted form the module RAM or command via peers MyCryptoTool and TCS interface CA ECDSA 384-bit key Enters the module in Never exits Stored plaintext in By command via Used for authenticating the Public Key encrypted form the module non-volatile memory MyCryptoTool and TCS operator interface CO ECDSA 384-bit key Enters the module in Never exits Stored in plaintext in By session termination, Used for authenticating the Public Key encrypted form the module RAM reboot, power removal, or CO command via MyCryptoTool and TCS interface User ECDSA 384-bit key Enters the module in Never exits Stored in plaintext in By session termination, Used for authenticating the Public Key encrypted form the module RAM reboot, power removal, or User command via MyCryptoTool and TCS interface Module ECDSA 384-bit key Generated internally Never exits Stored encrypted with By command via Used for signature generation Private Key using approved DRBG; the module KEK in non-volatile MyCryptoTool and TCS imported in encrypted memory interface form Ciena 6500 Packet-Optical Platform 4x10G Page 18 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Key Key Type Generation / Input Output Storage Zeroization33 Use Module ECDSA 384-bit key Generated internally Exits the Stored plaintext in By command via Used for mutual authentication Public Key using approved DRBG; module non-volatile memory MyCryptoTool and TCS imported in encrypted encrypted interface form ECDH Private 384-bit value Generated internally Never exits Stored in plaintext in By session termination, Used for establishing TLS Component during TLS negotiation the module RAM reboot, power removal, or session for MyCryptoTool. command via MyCryptoTool and TCS interface ECDH Public 384-bit value The module’s public The module’s Stored in plaintext in By session termination, Used for establishing TLS Component component is Public RAM reboot, power removal, or session for MyCryptoTool generated internally Component command via during TLS negotiation; exits the MyCryptoTool and TCS public component of a module in interface peer enters the plaintext; module in plaintext Public Key Component of the a peer never exits the module DRBG seed 384-bit value Generated internally Never exits Stored in plaintext in By reboot, power removal Used for random number using entropy input the module RAM or command via generation MyCryptoTool and TCS interface Entropy Input 512-bit value Generated internally Never exits Stored in plaintext in By reboot, power removal Used for random number string using NDRNG the module RAM or command via generation MyCryptoTool and TCS interface Ciena 6500 Packet-Optical Platform 4x10G Page 19 of 26 © 2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 2.8 EMI/EMC The module was tested and found to be conformant to the EMI/EMC requirements specified by 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B (i.e., for home use). 2.9 Self-Tests The module performs various Self-Tests (Power-Up Self-Tests, Conditional Self-Tests, and Critical Function Self-Tests) on the cryptographic algorithm implementations to verify their functionality and correctness. 2.9.1 Power–Up Self–Tests The Ciena 6500 Packet-Optical Platform 4x10G module performs the following self-tests at power-up to verify the integrity of the firmware images and the correct operation of the FIPS-Approved algorithms implemented in the module:  Integrity test for the KM application firmware image (Zone A) using ECDSA signature verification  Integrity test for the KM application firmware image (Zone B) using ECDSA signature verification  Integrity test for the KM FPGA (Zone B) image using ECDSA signature verification  Following algorithm self-tests have been implemented for FIPS-Approved algorithms: o o KM  AES CBC Encryption Known Answer Test (KAT)  AES CBC Decryption KAT  AES GCM Encryption KAT  AES GCM Decryption KAT  Triple-DES Encryption KAT  Triple-DES Decryption KAT  SHA-1 KAT  SHA-256, 384, 512 KAT  HMAC SHA-1 KAT  HMAC SHA-256, 384, 512 KAT  SP 800-90A CTR_DRBG KAT  RSA 186-4 Signature Generation KAT  RSA 186-4 Signature Verification KAT  ECDSA 186-4 Signature Generation Pairwise Consistency Test (PCT)  ECDSA 186-4 Signature Verification PCT o o FPGA  AES Encryption KAT  AES Decryption KAT The power-up self-tests can be performed at any time by power-cycling the module or via TCS command. 2.9.2 Conditional Self-Tests The Ciena 6500 Packet-Optical Platform 4x10G implements the following conditional self-tests:  Continuous Random Number Generator Test (CRNGT) for the SP 800-90A CTR_DRBG  CRNGT for the NDRNG  Pair-wise Consistency Test for RSA key pair generation and verification  Pair-wise Consistency Test for ECDSA key pair generation and verification  Firmware Load Test for the KM Application using ECDSA signature verification Page 20 of 26 Ciena 6500 Packet-Optical Platform 4x10G ©2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016  Firmware Load Test for the KM FPGA using ECDSA signature verification 2.9.3 Critical Function Self-Tests The Ciena 6500 Packet-Optical Platform 4x10G performs the following critical function self-tests:  SP 800-90 CTR_DRBG Instantiate Health Test  SP 800-90 CTR_DRBG Generate Health Test  SP 800-90 CTR_DRBG Reseed Health Test  SP 800-90 CTR_DRBG Uninstantiate Health Test 2.9.4 Self-Test Failure Handling Upon the failure of any power-up self-test (except the Zone A application firmware integrity test, Zone B application firmware integrity test, or the Zone B FPGA integrity test), conditional self-test (except firmware load test), or critical function test, the module goes into “Critical Error” state and disables all access to cryptographic functions and CSPs. All data output via data output interfaces are inhibited upon any self-test failure. A permanent error status will be relayed via the status output interface, which then is interpreted either in the illumination of an LED or as a recorded entry to the system log file or alarm history log file. During the integrity tests at start up, the module first checks the Zone A firmware image. If this test fails, the module transitions to a Zone A Soft Error state where it will skip Zone A and proceed with Zone B application firmware and FPGA integrity test. If the Zone A firmware image passes the integrity check, the module checks the firmware and FPGA within Zone B. If the Zone B firmware integrity check fails, the module transitions to either Critical Error state if Zone A firmware integrity check also fails or Zone B Soft Error state if Zone A firmware integrity check passes. If the Zone B firmware integrity check passes, but the Zone B FPGA integrity check fails, the module transitions to a Zone B Soft Error state where a new firmware image can be loaded from TCS interface followed by a reboot. Upon failure of the firmware load test, the module enters “Soft Error” state. The soft error state is a non- persistent state wherein the module resolves the error by rejecting the loading of the new firmware. Upon rejection, the error state is cleared, and the module resumes its services using the previously-loaded firmware. While the error state persists, the module replies to all cryptographic service requests with a pre-defined error message to indicate the error status. The management interface does not respond to any commands until the module is operational. The module requires rebooting or power-cycling to come out of the error state and resume normal operations. In the case of firmware or FPGA load corruption in Zone B that cannot be corrected by TCS interface, the module will not be able to resume normal operation and the Crypto Officer should contact Ciena. 2.10 Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any other attacks. Page 21 of 26 Ciena 6500 Packet-Optical Platform 4x10G ©2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 3. Secure Operation The Ciena 6500 Packet-Optical Platform 4x10G meets overall Level 3 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS-Approved mode of operation. 3.1 Initial Setup The Ciena 6500 Packet-Optical Platform 4x10G module does not require any installation activities as it is delivered to the customer pre-installed on the circuit pack from the factory. Either the Crypto Officer or the User can perform the Secure Operation responsibilities and tasks listed here; however, this Security Policy places this responsibility solely on the Crypto Officer. On receipt of the circuit pack, the Crypto Officer must check that the tamper evident labels are in place as well as the battery in the battery holder. After the circuit pack is removed from the shipping package and prior to use, the Crypto Officer must perform a physical inspection of the unit for signs of damage. If damage is found, the Crypto Officer shall immediately contact Ciena. The module is shipped from the factory with the required physical security mechanisms (tamper-evident labels, tamper-resistant screws, and tamper switches with tamper-response circuitry) installed. The Crypto Officer should check the package for any irregular tears or opening. If tampering is suspected, the Crypto Officer should immediately contact Ciena. The module is contained in a strong, hard metal enclosure, and is protected by tamper-evident labels, tamper-resistant screws, tamper switches, and tamper-response circuitry. See Figure 4 below for tamper-evident label locations. Figure 4 – Top and Bottom View of the Module The Crypto Officer is responsible for configuring the module, which includes the configuration of the data path parameters and the security parameters for the data path. The Crypto Officer must install the web server certificate, one or more CA Certificates in order for the module to be able to verify the submitted CO and User RSA/ECDSA Public keys during TLS mutual authentication for the MyCryptoTool interface. Please refer to Chapter 4, “Provisioning Certificate Management using MyCryptoTool” in Ciena’s MyCryptoTool User’s Guide document for more information. Once the module’s web server certificate has been configured, the web server software will restart for the certificate change to take effect and begin enforcing TLS mutual authentication. When the web server has completed the restart process, the module operates only in FIPS-Approved mode of operation. At any point of time, the “FIPS mode” status of the module can be viewed using the MyCryptoTool interface. The module comes provisioned into FIPS mode from the factory, and the module will remain and operate in FIPS-Approved mode of operation unless decommissioned by the CO or the physical security has been breached. Page 22 of 26 Ciena 6500 Packet-Optical Platform 4x10G ©2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 3.2 Secure Management The Crypto Officer is responsible for maintaining and monitoring the status of the module to ensure that it is running in its FIPS-Approved mode. For additional details regarding the management of the module, please refer to Ciena’s User’s Guide and Technical Practices document. 3.2.1 Management When configured according to the Crypto Officer guidance in this Security Policy, the module only runs in an Approved mode of operation. The Crypto Officer is able to monitor and configure the module via MyCryptoTool. Detailed instructions for monitoring and troubleshooting the module are provided in the Ciena’s User’s Guide and Technical Practices document. 3.2.2 Physical Inspection As the labels are applied at the factory, the CO shall inspect the module to ensure that the labels are applied correctly. The CO shall periodically inspect the module for evidence of tampering at six-month intervals. The CO shall visually inspect the tamper-evident seals for tears, rips, dissolved adhesive, and other signs of tampering. The CO shall also inspect the module’s enclosure for any signs of damage. If evidence of tampering is found during periodic inspection, the Crypto Officer should send the module back to Ciena Corporation for repair or replacement. 3.2.3 Monitoring Status The Crypto Officer should monitor the module’s status regularly. The operational status of the module can be viewed using MyCryptoTool. At any point of time, the “FIPS mode” status of the module can be viewed by accessing the “Encryption Details”, “Data Encryption Certificate Management”, “Web Access Certificate Management”, “Active Alarms”, or “Historical Logs” web page of the MyCryptoTool interface. The line at the top of these pages indicates “FIPS mode” of the module. 3.2.4 Zeroization All ephemeral keys used by the module are zeroized on reboot, session termination, factory reset, or tamper event. The “Clear CSP (Critical Security Parameter)” button on MyCryptoTool and via the Zeroize command via TCS also allows an operator to clear certificates and the KEK. CSPs reside in SDRAM and Flash memory. The BKEK is stored in battery-backed RAM. Other keys and CSPs are stored in the volatile and non- volatile memories of the module. The BKEK can be zeroized by removing power to the BB RAM or in response to tamper events. The zeroization of the BKEK renders other keys and CSPs, including MKEK and KEK stored in non-volatile memory of the module useless, thereby, effectively zeroizing them. The zeroization of KEK renders asymmetric private keys inaccessible, thereby, rendering them unusable. The only public key that is stored in a file is embedded in code and is used for verifying the integrity of the image files cannot be zeroized. Resetting the module to factory state (software-controlled erasure) also erases all the volatile and non-volatile keys and CSPs from the module. Additionally, all keys and CSPs are also zeroized or become inaccessible when the module detects a tamper event. 3.3 User Guidance The User shall follow all the instructions and guidelines provided for the Crypto Officer in Section 3 of this Security Policy document in order to ensure the secure operation of the module. Page 23 of 26 Ciena 6500 Packet-Optical Platform 4x10G ©2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 4. Acronyms Table 8 below describes the acronyms used in this document. Table 8 – Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute BB Battery Backed BKEK Base Key Encryption Key CA Certificate Authority CBC Cipher Block Chaining CMVP Cryptographic Module Validation Program CO Crypto Officer CRNGT Continuous Random Number Generator Test CSEC Communications Security Establishment Canada CSP Critical Security Parameter CSR Certificate Signing Request CTR Counter DCC Data Communication Channel DEK Data Encryption Key DH Diffie-Hellman DRBG Deterministic Random Bit Generator EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard FPGA Field Programmable Gate Array Gb/s Gigabit Per Second GbE Gigabit Ethernet GCC General Communication Channel GUI Graphical User Interface HMAC (Keyed-) Hash Message Authentication Code HTTPS Hypertext Transfer Protocol Secure IKE Internet Key Exchange IV Initialization Vector KAT Known Answer Test Page 24 of 26 Ciena 6500 Packet-Optical Platform 4x10G ©2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 April 20, 2016 Acronym Definition KEK Key Encrypting Key LED Light Emitting Diode MKEK Master Key Encrypting Key N/A Not Applicable NDRNG Non-Deterministic Random Number Generator NIST National Institute of Standards and Technology OS Operating System OTN Optical Transport Network OTR Optical Transponder PKCS Public-Key Cryptography Standards PRNG Pseudo Random Number Generator RAM Random Access Memory RNG Random Number Generator ROM Read Only Memory RSA Rivest, Shamir, and Adleman SDRAM Synchronous Dynamic Random Access Memory SHA Secure Hash Algorithm SP Special Publication TLS Transport Layer Security Page 25 of 26 Ciena 6500 Packet-Optical Platform 4x10G ©2016 Ciena Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice.