Ciena Corporation
Ciena 6500 Packet-Optical Platform4x10G
Hardware Version: 1.0
Firmware Version: 1.10
FIPS 140-2 Non-Proprietary Security Policy
FIPS Security Level: 3
Document Version: 1.1
Prepared for: Prepared by:
Ciena Corporation Corsec Security, Inc.
7035 Ridge Road
Hanover, Maryland 21076
United States of America
13135 Lee Jackson Memorial Highway, Suite 220
Fairfax, Virginia 22033
United States of America
Phone: +1 (410) 694-5700 Phone: +1 (703) 267-6050
Contact: http://www.ciena.com/about/contact-
us/?navi=top
http://www.ciena.com
Email: info@corsec.com
http://www.corsec.com
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 2 of 24
© 2015 Ciena Corporation
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 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 ..........................................................................................................................................6
2.4 ROLES, SERVICES, AND AUTHENTICATION.......................................................................................................7
2.4.1 Authorized Roles.....................................................................................................................................................7
2.4.2 Services......................................................................................................................................................................8
2.4.3 Authentication Mechanisms.............................................................................................................................10
2.5 PHYSICAL SECURITY...........................................................................................................................................11
2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................12
2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................12
2.8 EMI/EMC............................................................................................................................................................17
2.9 SELF-TESTS ..........................................................................................................................................................17
2.9.1 Power–Up Self–Tests.........................................................................................................................................17
2.9.2 Conditional Self-Tests.........................................................................................................................................17
2.9.3 Critical Functions Tests......................................................................................................................................17
2.9.4 Self-Test Failure Handling.................................................................................................................................18
2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................18
3 SECURE OPERATION..............................................................................................................19
3.1 INITIAL SETUP......................................................................................................................................................19
3.2 SECURE MANAGEMENT .....................................................................................................................................20
3.2.1 Management ........................................................................................................................................................20
3.2.2 Physical Inspection...............................................................................................................................................20
3.2.3 Monitoring Status................................................................................................................................................20
3.2.4 Zeroization ............................................................................................................................................................20
3.3 USER GUIDANCE ................................................................................................................................................21
4 ACRONYMS................................................................................................................................22
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 – CIRCUIT PACK WITH MODULE INSTALLED (TAMPER-EVIDENT SCREWS AND LABELS SHOWN) ............ 19
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........................................................................................................................ 11
TABLE 7 – CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS............................................... 13
TABLE 8 – ACRONYMS .......................................................................................................................................................... 22
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 3 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
1 Introduction
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy (SP) for the Ciena 6500 Packet-Optical
Platform 4x10G (Hardware Version: 1.0, Firmware Version: 1.10) 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
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 produced by Corsec Security,
Inc. 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.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 4 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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 SFP6
+/SFP-
based client ports (ports 1, 2, 3, and 4) and four XFP7
-based line ports (ports 5, 6, 7, and 8) , with full
10Gbps throughput for all client ports.
1
4
3
2
5
8
7
6
Krypto Daughter
Card
Client Ports
(SFP+/SFP)
Line Ports
(XFP)
Mapper 1 Mapper 2
OTR Motherboard
encrypt/decrypt
encrypt/decrypt
encrypt/decrypt
encrypt/decrypt
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.
1
OTR – Optical Transponder
2
TDM – Time-Division Multiplexing
3
WDM – Wavelength-Division Multiplexing
4
Gbps – Gigabits Per Second
5
G – Gigabit
6
SFP – Small Form Factor Pluggable
7
XFP – (10 Gigabit) Small Form Factor Pluggable
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 5 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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
6 Operational Environment N/A8
7 Cryptographic Key Management 3
8 EMI/EMC9
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
8
N/A – Not Applicable
9
EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility
10
FPGA – Field Programmable Gate Array
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 6 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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
Algorithm
Certificate Number
FPGA Firmware
AES11
– CTR12
and ECB13
modes with 256-bit keys 2964 -
AES – CBC14
mode with 128, 192, and 256-bit keys - 2963
Triple-DES – CBC (3-key) - 1759
SHA15
-1, SHA-256, and SHA-512 - 2493
HMAC16
with SHA-1, SHA-256, and SHA-512 - 1880
NIST17
SP18
800-90A CTR_DRBG19
- 562
RSA20
Key generation (2048-bit) (FIPS 186-4) - 1559
RSA (PKCS#1 v1.5) Signature generation/verification
(2048-bit)
- 1559
ECDSA Signature Verification - 543
Section 4.2.2 TLSv1.2 (SP 800-135) - 357
Section 4.1.1 IKEv1 (SP 800-135) - 357
Additionally, the module implements the following algorithms that are allowed for use in a FIPS-Approved
mode of operation:
 True Random Number Generator (TRNG)
 Diffie-Hellman21
(2048-bit)
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
11
AES – Advanced Encryption Standard
12
CTR – Counter
13
ECB – Electronic Codebook
14
CBC – Cipher Block Chaining
15
SHA – Secure Hash Algorithm
16
HMAC – (Keyed) Hash Message Authentication Code
17
NIST – National Institute of Standards and Technology
18
SP – Special Publication
19
DRBG – Deterministic Random Bit Generator
20
RSA – Rivest Shamir Adleman
21
Caveat: Diffie-Hellman (key agreement; key establishment methodology provides 112 bits of encryption strength). Please see NIST
Special Publication 800-131A for further details.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 7 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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,
LED22
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
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
22
LED – Light Emitting Diode
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 8 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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
Service
Operator
Description Input Output CSP and Type of Access
CO User
Initialize the
module   Initialize the module Command Status output None
Configure the
module  
Define and configure
enterprise network
interfaces and settings,
identity information, and
load certificates
Command
and
parameter
Command
response
RSA Public Key – R/X
MKEK23
– R/X
KEK24 – R/X
Monitor
alarms  
Monitor specific alarms
for diagnostic purposes
Command Status output None
Manage data
encryption
certificate
 
Manage data encryption
certificate enrollment,
signing CA certificate
information, trusted CA
certificates, import CA
certificate and CRL, and
clear CSPs
Command
and
parameters
Command
response
DEK25 – R/W
BKEK26 – R/X
MKEK – R/X
KEK – R/X
RSA Public Key – R/X
Manage Web
Access  
Manage web access
certificate and CRL
loading
Command
and
parameters
Command
response
Module RSA Public Key –
R/X
Show FIPS
status and
statistics
 
Show the system status,
FIPS-Approved mode,
configuration settings, and
active alarms.
Command Status output None
23
MKEK – Master Key Encryption Key
24
KEK – Key Encryption Key
25
DEK – Data Encryption Key
26
BKEK – Base Key Encryption Key
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 9 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Service
Operator
Description Input Output CSP and Type of Access
CO User
View system
logs  
View system status
messages in historical and
provisioning logs.
Command Status output None
Zeroize using
MyCryptoTool  
Zeroize certificates and
KEK
Command
Command
response
Certificates – W
KEK – W
Employ
encryption /
decryption
service
 
Encrypt or decrypt user
data, keys, or
management traffic
Command
and
parameters
Command
response
BKEK – R/X
MKEK – X
DEK – X
TLS Session Key – X
Message
Authentication
service
 
Authenticate
management traffic
Command
and
parameters
Command
response
TLS Authentication Key – X
Generate
asymmetric
key pair (data
path)
 
Generate the asymmetric
key pair (RSA)
Command
and
parameters
Key pair
Module RSA Private Key – W
Module RSA Public Key – W
Generate
asymmetric
key pair (web
access)
 
Generate the asymmetric
key pair (RSA)
Command
and
parameters
Key pair
Module RSA Private Key – W
Module RSA Public Key – W
Generate
signature
(CSR)
 
Generate a signature for
the supplied message
using specified key and
RSA algorithm
Command
and
parameters
Status,
signature
Module RSA Private Key –
R/X
Verify
signature  
Verify the signature on
the supplied message
using the specified key
and RSA algorithm
Command
and
parameters
Status
Module RSA Public Key –
R/X
Perform device
diagnostics  
Test the module during
operation, and monitor
the module
Command
and
parameters
Command
response and
status via log
and LEDs
None
Upgrade
firmware 
Upgrade the module
firmware using ECDSA
signature verification
Command
and
parameters
Command
response and
status output
ECDSA Public Key – R/X
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.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 10 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Table 5 – Additional Services
Service Description Input Output
CSP and Type of
Access
Perform operator
authentication
Authenticates
operators to the
module
Command Status output
CO RSA Public key – R/X
User RSA Public key – R/X
CA RSA Public Key – R/X
Preshared Authentication
String – R/X
Perform peer
authentication
Authenticates peer
devices to the module
Command Status output Peer RSA Public key – R/X
Zeroize using TCS
Zeroize certificates
and KEK
Command
Command
response
Certificates – W
KEK – W
Perform on-
demand self-tests
Performs Power-up
Self-Tests on demand
via module restart
Use power button
on the host system,
Command
Status output
All plaintext keys and CSPs –
W
Show system status
and statistics using
TCS
Show the system
status, system
identification, and
configuration settings
of the module
Command Status output None
Carrier
Provisioning using
TCS
Configure and manage
the carrier
provisioning
Command
Response and
status output
None
Process data traffic
Encrypt and decrypt
data traffic
None Status output
DEK – W/X
Entropy Input string – R
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.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 11 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Table 6 – Authentication Mechanism
Authentication
Type
Strength
Public Key
Certificates
The module supports RSA digital certificate authentication of Crypto Officers and
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
which 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:
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 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
which is less than 1:1,000,000 as required by FIPS 140-2
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 within one minute 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.
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. The enclosure has a total of
two tamper-evident labels applied at the factory; the tamper-evident label locations can be seen below in
Figure 4. 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.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 12 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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 uses the FIPS-Approved SP 800-90A CTR_DRBG to generate cryptographic keys. The
DRBG is seeded from seeding material provided by a hardware-based True Random Number Generator
(TRNG), which provides an entropy source and whitening circuitry to supply a uniform distributed
unbiased random sequence of bits to the DRBG.
Additionally, the module uses RSA (as specified in ANSI X9.31 standard) for generation of RSA key pairs
in the FIPS-Approved mode of operation.
The module supports the CSPs described in Table 7.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 13 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Table 7 – Cryptographic Keys, Cryptographic Key Components, and CSPs
Key Key Type Generation / Input Output Storage Zeroization27 Use
Base Key
Encryption Key
(BKEK)
AES 256-bit
key
Preloaded at the
factory
Never exits
the module
Stored in plaintext in
battery backed (BB)
RAM28 in the module
Power is removed from BB
RAM
Used for encrypting/decrypting
MKEK and ECDSA public
keys stored in nonvolatile
memory of the module
Master Key
Encryption Key
(MKEK)
AES 256-bit
key
Preloaded at the
factory
Never exits
the module
Encrypted with BKEK
and stored in the non-
volatile memory
Power is removed from BB
RAM
Used for encrypting/decrypting
authentication (RSA key and
entity certificates) and access
control of security materials
Key Encryption
Key (KEK)
AES 256-bit
key
Generated internally Never exits
the module
Encrypted with MKEK
and stored in non-
volatile memory
Power is removed from BB
RAM
Used for encrypting/decrypting
private key of an entity key pair
Data Encryption
Key (DEK)
AES 256-bit
key
Generated internally Never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Used for encrypting or
decrypting payload data
between an authorized
external entity and the module
Initialization
Vector (IV)
128-bit value Generated internally Never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Used for encrypting or
decrypting payload data
between an authorized
external entity and the module
Preshared
Authentication
String
256-bit value Hardcoded at the
factory
Never exits
the module
Stored plaintext in
non-volatile memory
N/A Used for authenticating a CO
for the Firmware Load service
27
Zeroization – Upon the detection of a tamper event, the module zeroizes all keys and CSPs listed in Table 7.
28
RAM – Random Access Memory
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 14 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Key Key Type Generation / Input Output Storage Zeroization27 Use
IKE DH29 Private
Key
224-bit DH
key
Generated internally
during IKE negotiation
Never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Exchanging shared secret to
derive session keys during IKE
IKE DH Public
Key
2048-bit DH
key
The module’s public
key is generated
internally during IKE
negotiation; public key
of a peer enters the
module in plaintext
The module’s
public key
exits the
module in
plaintext;
public key of
the a peer
never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Exchanging shared secret to
derive session keys during IKE
IKE Session
Encryption Key
AES 256-bit
key
Generated internally
during DH key
negotiation
Never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Used for encrypting/decrypting
IKE messages
IKE Session
Authentication
Key
HMAC SHA-
256
Generated internally
during DH key
negotiation
Never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Used for authenticating IKE
messages
29
DH – Diffie-Hellman
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 15 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Key Key Type Generation / Input Output Storage Zeroization27 Use
TLS Session Key AES 256-bit
or Triple-DES
168-bit key
Generated internally
during session
negotiation
Never exits
the module
Plaintext in RAM Session is terminated,
reboot, when power is
turned off, or
MyCryptoTool erasure
Used for encrypting/decrypting
TLS messages
TLS
Authentication
Key
HMAC SHA-
256
Generated internally
during session
negotiation
Never exits
the module
Plaintext in RAM Session is terminated,
reboot, When power is
turned off, or
MyCryptoTool erasure
Used for authenticating TLS
messages
Peer RSA Public
Key
2048-bit key Enters the module in
encrypted form
Never exits
the module
Stored in plaintext in
RAM
MyCryptoTool erasure Used for authenticating the
peers
CA RSA Public
Key
2048 or
4096-bit key
Preloaded, or can
enter the module in
encrypted form
Never exits
the module
Stored plaintext in
non-volatile memory
MyCryptoTool erasure Used for authenticating the
operator
CO RSA Public
Key
2048-bit key Preloaded, or can
enter the module in
encrypted form
Never exits
the module
Stored in plaintext in
RAM
MyCryptoTool erasure Used for authenticating the
operator
User RSA Public
Key
2048-bit key Preloaded, or can
enter the module in
encrypted form
Never exits
the module
Stored in plaintext in
RAM
MyCryptoTool erasure Used for authenticating the
operator
Module RSA
Private Key
2048-bit key Generated internally
using approved DRBG;
imported in encrypted
form
Never exits
the module
Stored encrypted with
KEK in non-volatile
memory
MyCryptoTool erasure Used for signature generation
Module RSA
Public Key
2048-bit key Generated internally
using approved DRBG;
imported in encrypted
form
Exits the
module
encrypted
Stored plaintext in
non-volatile memory
MyCryptoTool erasure Used for mutual authentication
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 16 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Key Key Type Generation / Input Output Storage Zeroization27 Use
DRBG seed 384-bit value Generated internally
using entropy input
Never exits
the module
Plaintext in RAM When power is turned off
or MyCryptoTool erasure
Random number generation
Entropy Input
string
512-bit value Generated internally
using TRNG
Never exits
the module
Plaintext in RAM When power is turned off
or MyCryptoTool erasure
Random number generation
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 17 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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 Self-
Test) 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:
 Power up integrity test using ECDSA signature verification of the Krypto Application load.
 Power up integrity test using ECDSA signature verification of the Krypto FPGA load.
 Known Answer Tests (KATs) for all implementations of the following FIPS-Approved
algorithms:
o AES Encryption (firmware)
o AES Encryption (hardware)
o AES Decryption (firmware)
o AES Decryption (hardware)
o Triple-DES Encryption (firmware)
o Triple-DES Decryption (firmware)
o SHA-1 (firmware)
o SHA-256 (firmware)
o SHA-512 (firmware)
o HMAC SHA-1 (firmware)
o HMAC SHA-256 (firmware)
o HMAC SHA-512 (firmware)
o SP 800-90A CTR_DRBG (firmware)
o RSA 186-4 Signature Generation (firmware)
o RSA 186-4 Signature Verification (firmware)
o ECDSA 186-4 Signature Verification (firmware)
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 TRNG
 Pair-wise Consistency Test for RSA
 Firmware Load Test using ECDSA signature verification
2.9.3 Critical Functions Tests
The Ciena 6500 Packet-Optical Platform 4x10G performs the following critical functions self-tests:
 SP 800-90 CTR_DRBG Instantiate Health Test
 SP 800-90 CTR_DRBG Generate Health Test
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 18 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
 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, conditional self-test (except firmware load test), or critical
function test, the module goes into “Critical Error” state and it disables all access to cryptographic
functions and CSPs. On 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 and continues to provide services.
The module resolves the error by rejecting the loading of the new firmware, and continuing to provide
services. All data outputs 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 recorded as an entry to the system log file or recorded as an alarm code in alarm
history log file.
In addition, 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.
2.10 Mitigation of Other Attacks
This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2
Level 3 requirements for this validation.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 19 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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
removing the circuit pack 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 and screw locations.
Figure 4 – Circuit Pack with Module Installed (Tamper-Evident Screws and Labels Shown)
The module is received in an uninitialized state and is not considered a Validated Cryptographic Module
until the Crypto Officer has performed the necessary configuration steps. The Crypto Officer must
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 20 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
configure the data path parameters and the security parameters for the data path. First, the Crypto Officer
must install the web server certificate and one or more CA Certificates in order for the module to be able to
verify the submitted CO and User RSA Public keys during TLS mutual authentication for the
MyCryptoTool interface. Please refer to Chapter 4, “Provisioning Certificate Management using
MyCryptoTool” in Ciena’s User’s Guide and Technical Practices 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 is considered initialized and only operates in a 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 in an uninitialized state from the factory and requires the Crypto Officer to perform the
above configuration before it can be considered a Validated Cryptographic Module. Once configured, the
module will remain and operate in FIPS-Approved mode of operation unless decommissioned by the CO or
the physical security has been breached.
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 1-year 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 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
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 21 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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 in the flash file system 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.
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 22 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
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
CSE Communications Security Establishment
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
Security Policy, Version 1.1 May 8, 2015
Ciena 6500 Packet-Optical Platform 4x10G Page 23 of 24
© 2015 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Acronym Definition
KEK Key Encrypting Key
LED Light Emitting Diode
MKEK Master Key Encrypting Key
N/A Not Applicable
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
TRNG True Random Number Generator
Prepared by:
Corsec Security, Inc.
13135 Lee Jackson Memorial Highway, Suite 220
Fairfax, Virginia 22033
United States of America
Phone: +1 (703) 267-6050
Email: info@corsec.com
http://www.corsec.com