Title:
Security Target for the
Ciena 6500 Packet-Optical Platform
Flex3 WaveLogic 3e OCLD
Encryption Module
Doc-ID
323-1851-CC-ST-NTK539QS-
NTK539QV
ST Version: 1.6
Date: April 28, 2020
Author: Ciena Corporation
7035 Ridge Road
Hanover, MD 21076
Certification-ID: BSI-DSZ-CC-1082
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 2 of 62
Table of Contents
1 Security Target Introduction ..............................................................................................................................5
1.1 ST Reference .............................................................................................................................................5
1.2 TOE Reference ..........................................................................................................................................5
1.3 TOE Overview............................................................................................................................................6
1.3.1 Introduction ...........................................................................................................................................6
1.3.2 TOE Type..............................................................................................................................................6
1.3.3 TOE Usage and Major Security Features.............................................................................................6
1.3.4 Non-TOE Hardware/Software/Firmware...............................................................................................7
1.4 TOE Description.........................................................................................................................................9
1.4.1 Introduction ...........................................................................................................................................9
1.4.2 TOE Logical Scope and Boundary .................................................................................................... 10
1.4.3 TOE Physical Scope and Boundary .................................................................................................. 13
2 Conformance Claims...................................................................................................................................... 19
2.1 CC Conformance Claims ........................................................................................................................ 19
2.2 PP Conformance Claims......................................................................................................................... 19
2.3 Package Claims ...................................................................................................................................... 19
2.4 Conformance Rationale .......................................................................................................................... 19
3 Security Problem Definition ............................................................................................................................ 21
3.1 Assets...................................................................................................................................................... 21
3.2 Threats .................................................................................................................................................... 21
3.3 Organizational Security Policies.............................................................................................................. 22
3.4 Assumptions............................................................................................................................................ 22
4 Security Objectives......................................................................................................................................... 24
4.1 Security Objectives for the TOE.............................................................................................................. 24
4.2 Security Objectives for the Operational Environment ............................................................................. 25
4.3 Security Objectives Rationale ................................................................................................................. 26
4.3.1 Overview............................................................................................................................................ 26
4.3.2 Countering the Threats ...................................................................................................................... 26
4.3.3 Coverage of Organizational Security Policies ................................................................................... 27
4.3.4 Coverage of Assumptions.................................................................................................................. 27
5 Extended Components Definition................................................................................................................... 29
5.1 Extended Functional Components.......................................................................................................... 29
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 3 of 62
5.1.1 Class FCS: Cryptographic Support.................................................................................................... 29
5.1.2 Class FDP: User Data Protection ...................................................................................................... 30
5.1.3 Class FIA: Identification and Authentication ...................................................................................... 30
5.2 Extended Assurance Components.......................................................................................................... 31
6 Security Requirements ................................................................................................................................... 32
6.1 Overview ................................................................................................................................................. 32
6.2 Security Functional Requirements .......................................................................................................... 32
6.2.1 Class FCS: Cryptographic Support.................................................................................................... 32
6.2.2 Class FDP: User Data Protection ...................................................................................................... 38
6.2.3 Class FIA: Identification and Authentication ...................................................................................... 39
6.2.4 Class FMT: Security Management .................................................................................................... 40
6.2.5 Class FPT: Protection of the TSF...................................................................................................... 41
6.3 Security Assurance Requirements.......................................................................................................... 42
6.4 Security Requirements Rationale............................................................................................................ 42
6.4.1 Security Functional Requirements Rationale .................................................................................... 42
6.4.2 Security Assurance Requirements Rationale.................................................................................... 47
7 TOE Summary Specification .......................................................................................................................... 48
7.1 Overview ................................................................................................................................................. 48
7.2 SF.FCS: Cryptographic Support ............................................................................................................. 49
7.3 SF.FDP: User Data Protection ................................................................................................................ 53
7.4 SF.FIA: Identification and Authentication................................................................................................ 53
7.5 SF.FMT: Security Management .............................................................................................................. 54
7.6 SF.FPT: Protection of the TSF................................................................................................................ 54
8 Appendices..................................................................................................................................................... 56
8.1 Acronym Definition .................................................................................................................................. 56
8.2 References.............................................................................................................................................. 60
8.3 Revision History ...................................................................................................................................... 62
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 4 of 62
Figures
Figure 1: TOE usage scenario..................................................................................................................................6
Figure 2: Non-TOE components within the Ciena 6500 Flex3 WaveLogic 3e OCLD Circuit Pack..........................8
Figure 3: The TOE on the Circuit Pack plugged into the Ciena 6500 Packet-Optical Platform ............................ 10
Figure 4: The TOE logical interfaces ..................................................................................................................... 11
Figure 5: The TOE on the Ciena 6500 Flex3 WaveLogic 3e OCLD Circuit Pack (Bottom & Top View)............... 14
Figure 6: Tamper-Evident Label Locations............................................................................................................ 15
Figure 7: The KM Mezzanine connector................................................................................................................ 16
Figure 8: The ASIC Pin-Outs................................................................................................................................. 16
Figure 9: Overview of the TOE’s components....................................................................................................... 48
Figure 10: OPU4 Encryption (AES-256-CTR) ....................................................................................................... 50
Figure 11: Encryption Keys Hierarchy ................................................................................................................... 52
Tables
Table 1: ST reference...............................................................................................................................................5
Table 2: TOE reference ............................................................................................................................................5
Table 3: TOE Guidance Documents...................................................................................................................... 18
Table 3: Rationale for Security Objectives ............................................................................................................ 26
Table 4: Definition of Extended Component for Random Number Generation..................................................... 29
Table 5: Definition of Extended Component for Stored Data Confidentiality ........................................................ 30
Table 6: Definition of Extended Component for Authentication Proof of Identity .................................................. 31
Table 7: Rationale for Security Objectives ............................................................................................................ 43
Table 8: Fulfillment of SFR dependencies............................................................................................................. 46
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 5 of 62
1 Security Target Introduction
The scope of this Security Target is to describe the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e
OCLD Encryption Module in terms of Common Criteria and to specify its security functional and security assurance
requirements.
1.1 ST Reference
The ST reference provides identification attributes for the ST.
ST Title: Security Target for the
Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption
Module
ST Version: 1.6
ST Date: April 28, 2020
ST Authors: Ciena Corporation
CC Version: Version 3.1 Revision 5
Assurance Level: EAL2 augmented by ALC_FLR.2 (hereafter called „EAL2+“)
Certification ID: BSI-DSZ-CC-1082
Keywords: Optical Transport Network, Layer 1 Encryption, Wire-speed Data Throughput
Table 1: ST reference
1.2 TOE Reference
The TOE reference provides identification material for the TOE that the ST refers to.
TOE Type: Cryptographic module that implements user data confidentiality functions
TOE Name: Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module
TOE Version: 2.01
TOE Developer: Ciena Corporation
TOE Hardware: Components:
• Krypto Module (part number NTK53926-501, NTK53926-502) and
• ASIC (part number 077-0084-017, 077-0084-028)
on the Ciena 6500 Flex3 WaveLogic 3e OCLD (NTK539QS/NTK539QV variants)
circuit packs
TOE Firmware: • KM Firmware Version 2.01
• ASIC Firmware Version 1.00
Table 2: TOE reference
The difference between the QS and QV circuit packs is essentially the optical performance on the DWDM line side
- the QS is rated for long haul reach (1000s of km) vs. metro reach (~300km) for the QV variant.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 6 of 62
1.3 TOE Overview
1.3.1 Introduction
The endpoints of network device communication can be geographically and logically distant and may pass through
a variety of other potentially untrusted systems. To protect any critical user data traffic the security functionality of
the network device must provide appropriate cryptographic services.
Thus, the Target of Evaluation (TOE) addressed by this Security Target is a cryptographic subsystem comprising
firmware and hardware implemented as components on a line card or circuit pack (the Ciena 6500 Flex3
WaveLogic 3e OCLD Circuit Pack), which can be installed with the Ciena 6500 series Packet-Optical Platform.
The TOE offers an integrated transport encryption solution providing protocol-agnostic 100 Gb/s or 200 Gb/s wire-
speed encryption service.
1.3.2 TOE Type
The Target of Evaluation (TOE) is a network-related cryptographic subsystem that implements wire-speed
encryption of user data transported to a peer cryptographic subsystem over the Optical Transport Network (OTN).
The cryptographic security functions protect the confidentiality of user data and thus provide security services
according to an organizational security policy. The TOE generates, uses, manages and protects the cryptographic
keys used for these cryptographic security functions.
1.3.3 TOE Usage and Major Security Features
Typically, the TOE respectively the WaveLogic 3e OCLD circuit pack product is installed in two 6500 Packet-
Optical Platform shelves which are connected via the OTN as shown in the following figure:
Figure 1: TOE usage scenario
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 7 of 62
In this environment the TOE provides the following major security features to guarantee the confidentiality of the
user data transferred on the OTN:
● verification of integrity and authenticity of the TOE’s firmware during start-up,
● mutual peer authentication between the TOE and the peer device connected via OTN,
● regular agreement on new encryption/decryption keys between the TOE and the peer,
● encryption/decryption of all user data transferred between the TOE and the peer node,
Thus, the TOE serves as a cryptographic subsystem responsible for encryption/decryption of user data exiting or
entering the Flex3 WL3e OCLD circuit pack on its way to a peer device, which is connected via the OTN.
Configuration and management of the TOE security functions are done by a Crypto Officer who connects to the
TOE via a TLS 1.2 mutual authenticated HTTPS connection to use the services of the MyCryptoTool application
as shown in the figure above.
Chassis management and Flex3 WL3e OCLD circuit pack management for non-security-related configuration and
carrier provisioning are done by an operator using the Transport Control Subsystem (TCS) which does not belong
to the TOE.
The Crypto Officer management role is referred to as administrator in the following.
1.3.4 Non-TOE Hardware/Software/Firmware
The following figure outlines the main hardware components of the Ciena 6500 Packet-Optical Platform Flex3
WaveLogic 3e OCLD Encryption Module circuit pack and shows those parts of the circuit pack that are considered
as non-TOE, too.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 8 of 62
Figure 2: Non-TOE components within the Ciena 6500 Flex3 WaveLogic 3e OCLD Circuit Pack
On the Ciena 6500 Flex3 WaveLogic 3e OCLD Circuit Pack the following hardware components are considered
as the TOE hardware:
● the Krypto Module (KM),
● the ASIC,
● the embedded wire connections.
All other hardware components, i.e.:
● the Processor on the circuit pack,
● the Backplane Interface,
● the attached Memory (Flash, RAM, EEPROM),
● the Physical Link Circuitry,
● the FPGAs,
● the KM module's/ASIC casing, heatsink, heatspreader, tamper-evident labels and screws
● the real time clock.
do not belong to the TOE.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 9 of 62
The TOE software consists of an implementation of the Internet Key Exchange Protocol Version 2 (IKEv2) running
on the KM with an embedded Linux OS. This IKEv2 implementation is responsible for establishing an authenticated
and encrypted secure communication channel between two peer nodes for key management, i.e. an IKE Security
Association (IKE SA) is established and further used to derive symmetric AES keys for datapath encryption and
decryption which is in turn executed by the ASIC.
The IKEv2 protocol implementation is supported by cryptographic functions providing random number generation,
hashing, ECC signature generation/verification, key derivation and symmetric protocol data encryption/decryption.
For management access to the Ciena 6500 Flex3 WaveLogic 3e OCLD Module security functions there exists a
Web server software on the KM called “MyCryptoTool”. This application can be accessed by an administrator via
HTTPS. It is assumed that the communication subsystem of this Web service responsible for establishing the
mutually authenticated HTTPS session with the administrator is non-TSF software, as this functionality might be
subject to a separate evaluation according to the collaborative Protection Profile for Network Devices (NDcPP).
Thus, only the management functions executed by the MyCryptoTool application that can be called via this
interface, i.e. only the internal commands executed by the MyCryptoTool application to change/manage the TOE
config parameters are part of the TSF and are subject to the TOE evaluation.
Additionally, the ASIC firmware responsible for AES en-/decryption of the user datapath belongs to the TOE.
1.4 TOE Description
1.4.1 Introduction
The TOE description explains the TOE in more technical detail than it has been provided in the TOE Overview.
The following figure shows the TOE (confined by the dotted red line) as part of the Ciena 6500 Flex3 WaveLogic
3e OCLD Circuit Pack which is installed in the 6500 Packet-Optical Platform shelf.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 10 of 62
Figure 3: The TOE on the Circuit Pack plugged into the Ciena 6500 Packet-Optical Platform
1.4.2 TOE Logical Scope and Boundary
The TOE is logically defined by the implemented cryptographic algorithms and protocols, which provide the
following security functions:
1. Encryption of plaintext user data entering the TOE and leaving the TOE as ciphertext data to ensure
confidentiality during transfer to a peer device. The encryption key for this operation is kept confidential
by the TOE.
2. Decryption of ciphertext data sent from a peer device entering the TOE and leaving the TOE as plaintext
data for the user. The decryption key for this operation is kept confidential by the TOE.
3. Digital signature creation to support authentication against the peer device. The signature-creation key is
kept private by the TOE.
4. Digital signature verification, which allows authentication of the peer device. The signature verification key
is authentically assigned to the holder of the signature-creation key and is public available to the verifier.
The TOE manages the cryptographic keys necessary for its implemented cryptographic algorithms and protocols.
The cryptographic key management controls the generation, storage, access and use of the cryptographic keys
by the cryptographic functions. The cryptographic key management includes:
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 11 of 62
1. Generation of random numbers using a deterministic random number generator seeded by a physical
RNG
2. Implementation of key generation algorithms depending on the intended use of the keys
3. Secure storage of private keys protecting their confidentiality
4. Key agreement protocols establishing ephemeral common secrets with external peer entities
The mutual authentication of communicating entities and the key agreement are combined to initiate and keep
secure communication between trusted peer devices protecting the confidentiality of the transmitted user data.
1.4.2.1 TOE Logical Interfaces
The TOE offers its security functionality via a set of external interfaces. The following Figure 4 provides an overview
of the external logical interfaces of the TOE:
Figure 4: The TOE logical interfaces
External TOE Interfaces are provided by both the Krypto Module (KM) and the ASIC.
The KM separates its external interfaces into the following four logically distinct and isolated interface categories.
They are:
● Data Input Interface
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 12 of 62
● Data Output Interface
● Control Input Interface
● Status Output Interface
Data input/output consists of the data for the IKEv2 SA services provided by the KM. Control input consists of
configuration or administration data entered into the KM through the mezzanine connector of the module remotely
using the MyCryptoTool interface or locally using the Transport Control Subsystem (TCS) interface. Status output
consists of signals output that are then translated into alarms, LED signals, and log information by the circuit pack.
The ASIC also separates its external interfaces into the same groupings, whereas the Data Input and Output
interfaces are subdivided into Backplane Data and Line Data:
● Data Input Interface
○ Backplane Data In (plaintext user data)
○ Line Data In (ciphertext)
● Data Output Interface
○ Backplane Data Out (plaintext user data)
○ Line Data Out (ciphertext)
1.4.2.2 Cryptographic Support
The following cryptographic mechanisms are implemented by the TOE:
● Random Number Generation (RNG) used for generating private ECC keys and (ephemeral) ECKA-DH
keys and nonces,
● SHA-2 Hash (SHA-384),
● HMAC with SHA-2 (SHA-384),
● EC Key-Agreement Diffie-Hellman (ECKA-DH) on NIST Curve P-384 (secp384r1) as used in IKEv2,
● Pseudo-Random-Functions (PRF) as used in IKEv2 for key derivation,
● ECDSA Signature Generation/Verification (ECDSA) as used in IKEv2,
● AES-CBC with 256 bit key for private key encryption,
● AES-GCM with 256 bit key for securing the IKEv2 SA ,
● AES-CTR with 256 bit key as implemented in the ASIC for datapath encryption/decryption.
The cryptographic protocols (i.e. IKEv2) are built on top by using these cryptographic mechanisms as
recommended in [TR-02102-3].
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 13 of 62
1.4.2.3 Protection of Confidentiality of User Data
The TOE protects the confidentiality of user data transferred between the TOE and connected peer devices.
Communication channels between the TOE and peer devices are secured via AES encryption in CTR mode with
256 bit keys that are agreed using IKEv2 IKE_SA_INIT and IKE_AUTH or CREATE_CHILD_SA exchanges.
1.4.2.4 Identification and Authentication
The TOE implements mechanisms that require the TOE and its peer device to be successfully identified and
authenticated before allowing any user data transfer between them. There is no plaintext bypass path, i.e. traffic
is either squelched or encrypted depending on successful IKEv2/ECDSA based peer authentication.
Devices are identified and authenticated through their public key X.509 certificate during an IKEv2 IKE_AUTH
exchange. The corresponding private key is stored encrypted by a symmetric key encryption key within the TOE.
1.4.2.5 Management of Security Functions
The TOE implements the configuration and management of security functions as defined in this ST in FMT_SMF.1.
For this purpose the module offers two management interfaces:
● MyCryptoTool Interface – used for security-related configuration and management of the module.
A Crypto Officer gains access to the security-related management by establishing a mutually-
authenticated HTTPS/TLS session to the MyCryptoTool application using trustable X.509 certificates.
● TCS Interface – used for non-security-related configuration and carrier provisioning of the module and
also firmware loads.
An operator gains authorization over the TCS interface using a username and password credential in the
form of a preshared HMAC-SHA-256 authentication string.
Application Note 1: For this ST it is assumed and must be ensured by organizational controls that access to both
management interfaces is only possible for trustworthy personal whose identity is known and which has been
authenticated.
1.4.2.6 Self-Protection
During startup the TOE verifies that the TOE’s firmware has not been compromised and is authentic. Additionally,
both the KM and the ASIC run some known answer tests (KAT) to verify the correctness of the cryptographic
algorithms implemented in the sub-modules.
1.4.3 TOE Physical Scope and Boundary
The physical scope of the TOE consists of:
● Hardware components
● Firmware/Software components
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 14 of 62
1.4.3.1 Hardware Components
The hardware components of the TOE appear on the circuit pack as can be seen in Figure 5:
Figure 5: The TOE on the Ciena 6500 Flex3 WaveLogic 3e OCLD Circuit Pack (Bottom & Top View)
The WL3e Encryption Module is composed of a Krypto Module (KM) daughtercard, an ASIC and the PCB-
embedded wire connections between them.
The KM is contained in a strong, hard metal enclosure, and is protected by two tamper-evident labels (3, 4). The
wire connections between the KM and ASIC are protected from view and from tampering by multiple PCB layers.
The bottom of the PCB where the KM connects is protected using the heat spreader and tamper-evident label (1).
The ASIC component of the module is protected by the installed heatsink and security plate, with one tamper-
evident label over one of the screws (2).
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 15 of 62
Figure 6: Tamper-Evident Label Locations
Application Note 2: Even though the Flex3 WaveLogic 3e OCLD Circuit Pack shows those physical security
features they are not subject to the evaluation according to this ST.
The KM contains a Xilinx Zynq 7020 (Xilinx XC7Z020) with Cortex A9 dual-core processor running an embedded
Linux kernel version 3.10 in a non-modifiable operational environment. The Linux operating system on the KM is
not modifiable by the operator, and only the KM firmware’s signed image can be executed.
The HunQ v3 ASIC contains an embedded ARM946E-S ARM processor with 128 KB of ITCM (Instruction Tightly
Coupled Memory), 128 KB of DTCM (Data Tightly Coupled Memory), 8 KB of instruction cache, and 4 KB of data
cache. Program and data storage is provided by 64 KB of ROM and 2 MB of RAM. The ASIC firmware is stored
in the ROM prior to being loaded into RAM. While the ASIC firmware is still in ROM, a 32-bit CRC check of the
ROM bootloader is performed. If successful, the firmware is loaded into RAM. Immediately upon loading into RAM,
an ECDSA signature verification test using NIST P-384 curve is performed on the firmware to ensure that the
image has not been modified or corrupted in any way. Once loaded, the ASIC operating environment cannot be
modified.
The physical ports and interfaces of the WL3e Encryption Module consist of the KM mezzanine connector and
ASIC pin-outs, as depicted in Figure 7 and Figure 8.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 16 of 62
Figure 7: The KM Mezzanine connector
The KM mezzanine connector pins are grouped into the following four logically distinct and isolated interface
categories:
● Data Input Interface
● Data Output Interface
● Control Input Interface
● Status Output Interface
Figure 8: The ASIC Pin-Outs
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 17 of 62
The ASIC pins are categorized into the following groupings (with associated pin counts):
● Backplane Data In (40 pins)
● Backplane Data Out (40 pins)
● Line Data In (8 pins)
● Line Data Out (44 pins)
● Control In (52 pins)
● Status Out (59 pins)
● Power In (342 pins)
Remark: The ASIC also includes the following pin groupings that, based upon their purpose, are not further
considered as TOE interface:
● General Purpose I/O pins: provide interfaces for pre-installation ASIC scan testing (unused/deactivated
on installation)
● Internal Control/Status I/O pins: provide internal interfaces between module components
● Ground pins
1.4.3.2 Firmware/Software Components
The firmware components of the TOE consist of:
● KM Application Firmware
The firmware is based on a hardened embedded Linux kernel version 3.10 where only the minimum
number of libraries needed are contained. The Linux operating system on the KM is not modifiable by the
operator, and only the KM firmware’s signed image can be executed.
The KM firmware implements the TOE’s IKEv2 protocol handling, the cryptographic support and the
management and configuration for that protocol.
Application Note 3: The Web server subsystem within the KM firmware called “MyCryptoTool” providing
an administration and management interface to the administrator is non-TSF software.
● ASIC Firmware
The ASIC firmware implements the TOE’s security functions for confidentiality of user data during OTN
transfer and only the ASIC firmware’s signed image can be executed.
All firmware/software components are pre-installed as binary image on the TOE hardware.
1.4.3.3 Guidance Documentation
The TOE is delivered with the following TOE guidance documents:
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 18 of 62
Name Reference/Version
6500 Packet-Optical Platform, Release 12.3:
WaveLogic Ai, Flex, 100G+, 40G, OSIC ISS, and SLIC10
Circuit Packs
323-1851-102.4 - Standard Issue 1
6500 Packet-Optical Platform, Release 12.3:
Installation - General Information
323-1851-201.0 - Standard Issue 1
6500 Packet-Optical Platform, Release 12.3:
Administration and Security
323-1851-301 - Standard Issue 2
6500 Packet-Optical Platform, Release 12.3:
TL-1 Command Definition
323-1851-190, Standard Issue 1
6500 Packet-Optical Platform, Release 12.3:
MyCryptoTool Certificate Management and Quick Start
323-1851-341 - Standard Issue 1
6500 Packet-Optical Platform, Release 12.3:
Encryption and FIPS Security Policy Overview and
Procedures
323-1851-340 - Standard Issue 1
Ciena 6500 Flex3 WaveLogic 3e OCLD Encryption
Module:
FIPS 140-2 Non-Proprietary Security Policy
Version 1.1
Table 3: TOE Guidance Documents
These documents can be accessed by Ciena customers through Ciena’s website at https://ciena.com/.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 19 of 62
2 Conformance Claims
The conformance claims indicate the source of the collection of requirements that is met by the ST.
2.1 CC Conformance Claims
This Security Target claims conformance to
● Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model;
April 2017, Version 3.1, Revision 5, CCMB-2017-04-001 ([CC1]),
● Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; April 2017, Version 3.1, Revision 5, CCMB-2017-04-002 ([CC2]),
● Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; April 2017, Version 3.1, Revision 5, CCMB-2017-04-003 ([CC3])
as follows:
● Common Criteria Part 2 extended (due to the use of SFR FCS_RNG.1, FDP_SDC.1 and FIA_API.1 as
defined in chapter 5 of this ST)
● Common Criteria Part 3 conformant. (No extended assurance components have been defined.)
The
● Common Methodology for Information Technology Security Evaluation, Evaluation Methodology; April
2017, Version 3.1, Revision 5, CCMB-2017-04-004 ([CEM])
has to be taken into account.
2.2 PP Conformance Claims
This Security Target does not claim conformance to a Protection Profile.
2.3 Package Claims
This Security Target claims conformance to EAL2 augmented with ALC_FLR.2 as defined in CC Part 3 [CC3].
This augmentation of the predefined CC package EAL2 is denoted by the term EAL2+.
2.4 Conformance Rationale
The conformance rationale demonstrates why the chosen conformance claims were deemed appropriate.
This Security Target claims conformance to EAL2 augmented with ALC_FLR.2. This claim was chosen to ensure
that the TOE has a low to moderate level of independently assured security in enforcing its security functions when
instantiated in its intended environment in the absence of ready availability of the complete development record
(e.g. source code).
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 20 of 62
Augmentation was chosen to demonstrate that the security measures to be followed have flaw remediation
procedures in place to correct security flaws as they are reported and ensure that TOE users are aware of the
corrections and the fixes.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 21 of 62
3 Security Problem Definition
This ST describes the security problem for TOE. The intended protection of primary assets of the TOE is addressed
by organizational security policies. The TOE protects the user data in confidentiality. The use of cryptographic
methods implies specific threats, which are common for a TOE as a cryptographic module.
3.1 Assets
The TOE is intended to protect the following data as primary assets:
● Plaintext user data, i.e. user data encoded in a public known way which is transformed by an encryption
algorithm into ciphertext data (i.e. plaintext as input data) or which is the result of decryption of the
corresponding ciphertext data (i.e. plaintext as output data). Plaintext data contain information, which need
protection in confidentiality.
● TOE configuration, i.e. the TOE Firmware (KM and ASIC), the current (stored) configuration data (e.g.
trusted peer certificates, IKE and Child-SA Key-Exchange periods, selected TCM/GCC channel and ODU
OH Reserve Encryption Bytes), which need protection in integrity.
The use of cryptographic algorithms and protocols requires the protection of the cryptographic keys as secondary
assets. The cryptographic keys need protection depending on the cryptographic technique they are used for:
● Secret keys of symmetric and private keys of asymmetric cryptographic algorithms and protocols need
protection in confidentiality and integrity.
● Public keys of asymmetric cryptographic algorithms and protocols need protection in integrity and
authenticity.
The need of confidentiality of secret and private keys follows directly from the cryptographic technique. The
integrity protection for these keys prevents indirect attacks (e.g. substitution of an unknown secret key by a known
key compromise the subsequent encryption of plaintext data, an undetected modification of a private key may
enable attacks against this key).
3.2 Threats
The threat agents, the TOE must demonstrate resistance against, are attackers with expertise, resources, and
motivation that combine to have a basic attack potential.
The TOE addresses the following threats:
T.DisclosedUserData An attacker may attempt to disclose data within the user data stream
transmitted/received by the TOE over the untrusted OTN.
If such an attack is successful, then the confidentiality of
transmitted/received user data is compromised.
T.ModifiedFirmware An attacker may attempt to infiltrate a modified firmware that the TOE would
boot during start-up.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 22 of 62
If such an attack is successful, the integrity of the whole TOE security
features would be compromised.
3.3 Organizational Security Policies
The following table describes the organizational security policies (OSP) relevant to the operation of the TOE:
OSP.AuthenticatedPeer The organizational security policy requires that user data exchange is only
allowed with mutual trusted peers, i.e. both the TOE must proof its identity to
the peer and the peer must be authenticated by the TOE.
OSP.TransferProtected The organizational security policy requires that the confidentiality of data
exchanged with peers is protected during transfer.
3.4 Assumptions
In this threat model the following assumptions about the environment need to be taken into account in order to
ensure a secure operation of the TOE.
A.TrustedAdmin As the security functions of the TOE can be compromised by an authorized
administrator, such persons are assumed to be non-evil, well-trained and
can be trusted to perform their duties correctly.
A.TrustedAdminAccess The tools used by the administrator (e.g. Web Browser) for admin access to
the TOE are assumed to be trustworthy, so that nothing evil can be caused
to the TOE by their usage.
The access channels for administration are separate from the datapath
channel and provide authenticity and confidentiality.
It is assumed that the administrator has been identified and authenticated
prior to accessing any controlled resources of the TOE.
A.TrustedCertificates The administrator is responsible to manage (i.e. obtain and import) the TOE’s
ECC certificate necessary for identifying the TOE during IKEv2 message
exchange.
It is assumed that the device certificate has been issued by a trustworthy CA.
It is assumed that the administrator imports a certificate establishing the
identity of the TOE into the corresponding TOE only.
It is assumed that the certificate used by the developer to sign the TOE
firmware has been issued by a trustworthy CA.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 23 of 62
A.TrustedFactoryKeys It is assumed that keys generated at the factory are strong random numbers
and are brought into the TOE in a secure production environment.
A.ReliableTime It is assumed that the real time clock outside of the TOE provides reliable
time services for the TOE. It is assumed that this is achieved by regular time
synchronization with NTP time server(s).
A.TrustedCircuitPack It is assumed that all non-TOE parts of the Flex3 WL3e OCLD circuit pack
(see Figure 2) are trustworthy and do not compromise the security
functionality of the TOE.
A.PhysicalProtection As the security functions of the TOE can be compromised by an attacker with
physical access to the internetworking device containing the TOE, it is
assumed that the internetworking device containing the TOE is located in a
physically secure environment.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 24 of 62
4 Security Objectives
The security objectives are a high-level and abstract statement of the intended solution to the security problem
defined by the SPD. The following objectives describe how the security problem is addressed.
4.1 Security Objectives for the TOE
The following security objectives are defined for the TOE:
SOT.CryptographyForIKE The TOE must implement the cryptographic algorithms necessary for
session establishment and regular session key renewals in short
intervals according to the Internet Key Exchange (IKEv2) protocol.
In addition, the TOE must implement a random number generator and
shall generate the required keys, ensure that the keys are only used for
an acceptable amount of time and destroy ephemeral keys if not longer
needed.
SOT.DatapathEncryption The TOE must use its ASIC module for encryption/decryption of user
data payload to protect confidentiality.
SOT.ManagementForIKE The TOE must provide the following management functions for
configuring the IKE service:
● IKE SA certificate management
● IKE SA timeout parameters configuration
SOT.SelfProtection The TOE shall implement functionality to protect its security functions
against malfunctions and tampering.
Private keys for TOE identification and authentication shall be kept
secret.
On startup the TOE shall:
● overwrite any information that is no longer needed to ensure
that it is no longer available via the interfaces of the TOE,
● check TOE firmware for integrity and authenticity,
● perform various self-tests on the cryptographic algorithm
implementations to verify their functionality and correctness.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 25 of 62
4.2 Security Objectives for the Operational Environment
SOE.TrustedAdmin Those responsible for the operation of the TOE must ensure that
management and configuration of the security functions of the TOE is
undertaken by non-evil, trusted administrators trained in the secure operation
of the TOE.
SOE.TrustedAdminAccess The tools used by the administrator (e.g. Web Browser) are non-evil and
trustworthy.
Administration by an administrator is only possible through a channel which
is separate from the datapath channel and which provides authenticity and
confidentiality.
The administrator must be identified and authenticated prior to accessing any
controlled resources of the TOE.
SOE.TrustedCertificates The administrator is responsible to manage (i.e. obtain and enroll) the TOE’s
ECC certificate necessary for identifying the TOE during IKEv2 message
exchange.
The ECC device certificate is signed by a trustworthy CA with a strong ECC
key pair from the NIST P-384 (secp384r1) elliptic curve.
The administrator imports the certificate establishing the identity of the TOE
into the proper TOE only.
The developer key pair used for signing the TOE firmware is a
cryptographically strong ECC key pair from the NIST P-384 (secp384r1)
elliptic curve signed by a trustworthy CA.
SOE.TrustedCircuitPack All non-TOE parts of the Flex3 WL3e OCLD circuit pack (see Figure 2) are
trustworthy and do not compromise the security functionality of the TOE.
SOE.TrustedFactoryKeys Keys generated at the factory are strong random numbers and are brought
into the TOE in a secure production environment by the manufacturer.
These keys are the symmetric 256-bit Base Key Encryption Key (BKEK) and
the symmetric 256-bit Master Key Encryption Key (MKEK), see Figure 11.
SOE.ReliableTime The real time clock in the TOE environment provides reliable time services
for the TOE. This shall be achieved by regular time synchronization with NTP
time server(s).
SOE.PhysicalProtection The TOE shall be installed in a non-public environment which is physically
secure. Only authorized individuals may physically access the TOE.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 26 of 62
4.3 Security Objectives Rationale
4.3.1 Overview
The security objectives rationale shows how the security objectives correspond to assumptions, threats, and
organizational security policies and provide a justification of that tracing.
The following table lists all objectives for the TOE and the operational environment to show which objectives are
necessary to counter a threat, meet a policy or satisfy an assumption. The table also shows that no objective exists
which does not trace back to a threat, policy, or assumption.
Table 4: Rationale for Security Objectives
4.3.2 Countering the Threats
The following sections provide more detailed information on how the threats are countered by the security
objectives for the TOE and its operational environment.
Security Objective
Threat, Policy,
Assumption
SOT.CryptographyForIKE
SOT.DatapathEncryption
SOT.ManagementForIKE
SOT.SelfProtection
SOE.TrustedAdmin
SOE.TrustedAdminAccess
SOE.TrustedCertificates
SOE.TrustedFactoryKeys
SOE.ReliableTime
SOE.TrustedCircuitPack
SOE.PhysicalProtection
T.DisclosedUserData x x x
T.ModifiedFirmware x
OSP.AuthenticatedPeer x x x
OSP.TransferProtected x
A.TrustedAdmin x
A.TrustedAdminAccess x
A.TrustedCertificates x
A.TrustedFactoryKeys x
A.ReliableTime x
A.TrustedCircuitPack x
A.PhysicalProtection x
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 27 of 62
4.3.2.1 T.DisclosedUserData
The threat T.DisclosedUserData is countered by a combination of the security objectives
SOT.CryptographyForIKE, SOT.ManagementForIKE and SOT.DatapathEncryption.
SOT.CryptographyForIKE defines that the TOE will implement the cryptographic algorithms necessary for the
IKEv2 protocol. The TOE uses IKEv2 to establish a secure and mutually authenticated Security Association (SA)
with a peer device which serves as a secure channel to agree on encryption/decryption keys for the user datapath.
The negotiated keys are used in SOT.DatapathEncryption for encrypting/decrypting the user data flow. The
objectives together ensure that the user data communicated between the TOE and a peer device cannot be
disclosed by an attacker. The derived session keys are renewed at regular short intervals using the IKEv2
mechanisms, thus avoiding an overuse of a session key. The management of those IKEv2 timeout parameters is
done via SOT.ManagementForIKE.
4.3.2.2 T.ModifiedFirmware
The threat T.ModifiedFirmware is countered by the security objective SOT.SelfProtection.
Through the TOE firmware integrity and authenticity checking by SOT.SelfProtection an attack to compromise
the TOE’s security functions by altering its firmware is detected.
4.3.3 Coverage of Organizational Security Policies
The following sections provide more detailed information about how the security objectives for the environment
and the TOE cover the organizational security policies.
4.3.3.1 OSP.AuthenticatedPeer
The Organizational Security Policy OSP.AuthenticatedPeer that mandates that the TOE and its peer are mutually
identified and authenticated before data can be exchanged is covered by SOT.CryptographyForIKE. The
IKE_AUTH exchange during the IKEv2 protocol which builds on the cryptographic operations provided by
SOT.CryptographyForIKE addresses this security requirement.
The mutual identification and authentication during the IKE_AUTH exchange depends on device certificates, which
must be enrolled by management functions from SOT.ManagementForIKE. Finally, the signing key belonging to
the device certificate must be kept secret and protected by the TOE which is implemented by SOT.SelfProtection.
4.3.3.2 OSP.TransferProtected
The Organizational Security Policy OSP.TransferProtected that mandates that the confidentiality of data
exchanged with peers is protected during transfer is directly addressed by the security objective for the TOE
SOT.DatapathEncryption.
4.3.4 Coverage of Assumptions
The following sections provide more detailed information about how the security objectives for the environment
cover the assumptions.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 28 of 62
4.3.4.1 A.TrustedAdmin
The assumption A.TrustedAdmin is directly and completely covered by the corresponding security objective
SOE.TrustedAdmin.
4.3.4.2 A.TrustedAdminAccess
The assumption A.TrustedAdminAccess is directly and completely covered by the corresponding security
objective SOE.TrustedAdminAccess.
4.3.4.3 A.TrustedCertificates
The assumption A.TrustedCertificates is directly and completely covered by the corresponding security objective
SOE.TrustedCertificates.
4.3.4.4 A.TrustedFactoryKeys
The assumption A.TrustedFactoryKeys is directly and completely covered by the corresponding security
objective SOE.TrustedFactoryKeys.
4.3.4.5 A.ReliableTime
The assumption A.ReliableTime is directly and completely covered by the corresponding security objective
SOE.ReliableTime.
4.3.4.6 A.TrustedCircuitPack
The assumption A.TrustedCircuitPack is directly and completely covered by the corresponding security objective
SOE.TrustedCircuitPack.
4.3.4.7 A.PhysicalProtection
The assumption A.PhysicalProtection is directly and completely covered by the security objective
SOE.PhysicalProtection.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 29 of 62
5 Extended Components Definition
The extended components definition specifies additional functional requirements not contained in CC Part 2 [CC2]
or additional assurance requirements not contained in CC Part 3 [CC3].
5.1 Extended Functional Components
5.1.1 Class FCS: Cryptographic Support
This class containing cryptographic support requirements is extended by a requirement to specify the
characteristics of random number generators as defined in [KS2011] section 3.1.
5.1.1.1 FCS_RNG Generation of random numbers
This section describes the functional requirements for the generation of random numbers, which may be used as
secrets or nonces for cryptographic purposes.
Family behaviour
This family defines quality requirements for the generation of random numbers that are intended to be used for
cryptographic purposes.
Component leveling
FCS_RNG.1 Generation of random numbers requires that the random number generator implements defined
security capabilities and that the random numbers meet a defined quality metric.
Management: FCS_RNG.1
There are no management activities foreseen.
Audit: FCS_RNG.1
There are no actions defined to be auditable.
FCS_RNG.1 Random number generation (Class DRG.2)
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybrid
physical, hybrid deterministic] random number generator that implements: [assignment:
list of security capabilities].
FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric].
Table 5: Definition of Extended Component for Random Number Generation
FCS_RNG: Generation of random numbers 1
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 30 of 62
5.1.2 Class FDP: User Data Protection
To define the security functional requirements of the TOE an additional family (FDP_SDC.1) of the Class FDP
(User Data Protection) is defined here, see [SOGIS-CESGD] section 7.3.
The family “Stored data confidentiality (FDP_SDC)” is specified as follows.
5.1.2.1 FDP_SDC Stored data confidentiality
Family behaviour
This family provides requirements that address protection of user data confidentiality while these data are stored
within memory areas protected by the TSF. The TSF provides access to the data in the memory through the
specified interfaces only and prevents compromise of their information bypassing these interfaces. It complements
the family Stored data integrity (FDP_SDI) which protects the user data from integrity errors while being stored in
the memory.
Component leveling
FDP_SDC.1 requires the TOE to protect the confidentiality of information of the user data in specified memory
areas.
Management: FDP_SDC.1
There are no management activities foreseen.
Audit: FDP_SDC.1
There are no actions defined to be auditable.
FDP_SDC.1 Stored data confidentiality
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_SDC.1.1 The TSF shall ensure the confidentiality of the information of the user data while it is stored
in the [assignment: memory area].
Table 6: Definition of Extended Component for Stored Data Confidentiality
5.1.3 Class FIA: Identification and Authentication
The standard families of the class FIA describe only the authentication verification of users’ identity performed by
the TOE and do not describe the functionality of the user to prove their identity. The following paragraph defines
the extended family FIA_API from point of view of a TOE proving its identity.
5.1.3.1 FIA_API Authentication Proof of Identity
Family behaviour
FDP_SDC: Stored data confidentiality 1
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 31 of 62
This family defines functions provided by the TOE to prove its identity and to be verified by an external entity in
the TOE IT environment.
Component leveling
FIA_API.1 Authentication Proof of Identity, provides proof of the identity of the TOE, an object or an authorized
user or role to an external entity.
Management: FIA_API.1
The following actions could be considered for the management functions in FMT: Management of authentication
information used to prove the claimed identity.
Audit: FIA_API.1
There are no actions defined to be auditable.
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to prove the identity of
the [selection: TOE, [assignment: object, authorized user or role]] to an external entity.
Table 7: Definition of Extended Component for Authentication Proof of Identity
5.2 Extended Assurance Components
None specified.
FIA_API: Authentication Proof of Identity 1
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 32 of 62
6 Security Requirements
6.1 Overview
Security requirements specify the security objectives of the TOE in a standardized manner. Security requirements
fall into two groups: Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs).
SFRs are modeled by using components from CC Part 2 [CC2]. SARs are modeled by using components from
CC Part 3 [CC3]. Necessary modifications to SFRs are performed through the permitted operations assignment,
selection, iteration and refinement. This document uses the following conventions to identify the operations defined
by the CC:
● Refinement operation (indicated by bold text): is used to add details to a requirement, and thus further
restricts a requirement. In case that a word has been deleted from the original text this refinement is
indicated by crossed out bold text.
● Selection operation (denoted by [underlined text enclosed in square brackets]): is used to select one or
more options provided by the [CC2] in stating a requirement.
● Assignment operation (denoted by [italicised text enclosed in square brackets]): is used to assign a
specific value to an unspecified parameter, such as the length of a password.
● Iteration operation: is identified with a suffix in the component identifier of the SFR (e.g. FCS_COP.1/IKE-
SA and FCS_COP.1/Datapath).
It should be noted that the requirements in the following chapters are not necessarily be ordered alphabetically.
Where useful the requirements have been grouped.
6.2 Security Functional Requirements
6.2.1 Class FCS: Cryptographic Support
6.2.1.1 Random Number generation (FCS_RNG)
FCS_RNG.1 Random number generation (Class DRG.2)
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1 The TSF shall provide a [deterministic] random number generator of the pre-defined
class DRG.2 according to [KS2011] that implements: [
(DRG.2.1) If initialized with a random seed [[using the hardware-based true random
number generator (TRNG) described in [Ciena-TRNG] as entropy source]],
the internal state of the RNG shall [have [a min-entropy of at least 100
bits]].
(DRG.2.2) The RNG provides forward secrecy.
(DRG.2.3) The RNG provides backward secrecy.
].
FCS_RNG.1.2 The TSF shall provide random numbers that meet [
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 33 of 62
(DRG.2.4) The RNG initialized with a random seed [of 384 bits at startup], generates
output for which [214] strings of bit length 128 are mutually different with
probability [>= (1-2-8)]1.
(DRG.2.5) Statistical test suites cannot practically distinguish the random numbers
from output sequences of an ideal RNG. The random numbers pass test
procedure A [and no additional test suites].
].
Application Note 4: The TSF performs all random bit generation services in accordance with NIST Special
Publication 800-90A [NIST-SP800-90A] using CTR_DRBG (AES) seeded by an entropy source that accumulates
entropy from one independent TSF-hardware-based noise source.
6.2.1.2 Cryptographic key operation for Hashing (FCS_COP)
FCS_COP.1/HASH Cryptographic operation - hashing for signatures
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/HASH The TSF shall perform [hashing for signature creation or verification and as
basis in a Pseudo-Random Function (PRF) for IKEv2] in accordance with a
specified cryptographic algorithm [SHA-384] and cryptographic key sizes [none]
that meet the following: [NIST-FIPS-180-4, Secure Hash Standard (SHS),
2015].
6.2.1.3 Cryptographic key management for the Key Encryption Key (FCS_CKM)
FCS_CKM.1/KEK Cryptographic key generation – Key Encryption Key
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/KEK The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm method [generate a Key Encryption
Key (KEK) using the Random Number Generator as specified in
FCS_RNG.1] and specified cryptographic key sizes [256 bits] that meet the
following: [none].
Application Note 5: The 256-bit KEK is used for encrypting or decrypting the private key material of the IKE SA
authentication certificate of the TOE which is either generated by the TOE (see FCS_CKM.1/IKE-SA-AuthCert) or
1 The parameters chosen depend on the claimed attack potential and are taken from [KS2011] Table 13.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 34 of 62
imported into the TOE with FDP_ITC.1/IKE-SA-AuthCert. The private key is then stored KEK encrypted (see
FCS_COP.1/KEK) in non-volatile memory (see FDP_SDC.1).
6.2.1.4 Cryptographic key management for IKE SA authentication certificate
(FCS_CKM)
FCS_CKM.1/IKE-SA-
AuthCert
Cryptographic key generation - IKE SA authentication certificate
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/IKE-SA-
AuthCert
The TSF shall generate cryptographic ECC keys in accordance with a
specified cryptographic key generation algorithm [Elliptic Curve Key Pair
Generation] and specified cryptographic key sizes [384 bits length group
order] that meet the following: [
use of EC domain parameter from FIPS186, D.1.2.4:
• Curve P-384 (secp384r1)
].
Application Note 6: The TOE uses an IKE SA authentication certificate to identify and authenticate itself against
the peer device (see FIA_API.1). The key pair used in this certificate is either generated in the TSF itself with this
SFR (FCS_CKM.1/IKE-SA-AuthCert) or the keys are generated securely in the TOE’s external PKI environment
and then imported into the TSF during certificate import (see FDP_ITC.1/IKE-SA-AuthCert). In the first case the
TSF random number generator (FCS_RNG.1) is used to generate the private key “d” in the ECC key pair (d, [d]G).
The private key is then stored KEK encrypted (see FCS_COP.1/KEK) in non-volatile memory.
6.2.1.5 Cryptographic key management for IKEv2 (FCS_CKM)
FCS_CKM.1/IKEv2 Cryptographic key generation - IKEv2
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/IKEv2 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [IKEv2 Session Key Generation] and
specified cryptographic key sizes [ECDHE: 384 bits; AES: 256; HMAC: 384]
that meet the following: [IPsec IKE v2 standards:
• RFC-7296 sections
o 2.13 (Generating Keying Material),
o 2.14 (Generating Keying Material for the IKE SA);
o 2.17 (Generating Keying Material for Child SAs);
• use of Diffie-Hellman group 20 from RFC-5903, section 3.2;
• PRF-HMAC-SHA-384 from RFC-4868
].
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 35 of 62
Application Note 7: FCS_COP.1/HASH defines the hashing function used by the PRF-HMAC function.
Application Note 8: The TOE uses PRF-HMAC-SHA-384 as Pseudo-Random Function (PRF) to build a bit string
for deriving AES keys for IKE SA and Child SAs according to RFC-7296. The Diffie-Hellman shared secret
established during the IKE_SA_INIT or CREATE_CHILD_SA exchange is computed using the NIST P-384
(secp384r1) elliptic curve.
Application Note 9: The random number generator (FCS_RNG.1) is used to generate the nonces and Diffie-
Hellman public values, which are transmitted in the IKE_SA_INIT and CREATE_CHILD_SA exchange.
Application Note 10: An IKE_SA key is renewed on regular intervals (minimum 1 hour, maximum 24 hours) using
a new IKE_SA_INIT handshake. A Child-SA key is renewed on regular intervals (minimum 1 second, maximum
3600 seconds) using a new CREATE_CHILD_SA handshake.
6.2.1.6 Cryptographic key operation for Key Encryption/Decryption (FCS_COP)
FCS_COP.1/KEK Cryptographic operation – using a KEK
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/KEK The TSF shall perform [encryption and decryption of symmetric and private
keys] in accordance with a specified cryptographic algorithm [AES-CBC] and
cryptographic key sizes [
• AES 256 bit,
] that meet the following: [
• NIST-FIPS-197 (AES)
• AES-CBC Mode as defined in NIST-SP800-38A
].
Application Note 11: The TOE uses three layers of encryption keys to ultimately secure the private ECC key
used by the TOE during IKEv2 authentication.
● The first key is an AES 256-bit key called Base Key Encryption Key (BKEK) which has been generated
per Flex3 WL3e OCLD circuit pack and preloaded into the TOE at the factory. It is stored in plaintext in
non-readable, write once, non-probable eFuse within the KM processor. During normal operation of the
TOE the BKEK is used to decrypt (FCS_COP.1/KEK) the AES-256-bit key called Master Key Encryption
Key (MKEK).
● The MKEK has been generated per Flex3 WL3e OCLD circuit pack at the factory and has been encrypted
at the factory with the BKEK. The BKEK encrypted MKEK is stored in non-volatile memory in the KM.
During normal operation of the TOE the MKEK is used to encrypt or decrypt (FCS_COP.1/KEK) the Key
Encryption Key (KEK).
● The KEK is generated by the TOE (FCS_CKM.1/KEK) and is stored MKEK encrypted in non-volatile
memory. During normal operation the KEK is used to encrypt or decrypt (FCS_COP.1/KEK) the private
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 36 of 62
ECC key of the device. The private ECC key of the device has been either generated (see
FCS_CKM.1/IKE-SA-AuthCert) or imported (see FDP_ITC.1/IKE-SA-AuthCert) by the TOE.
6.2.1.7 Cryptographic key operation for IKE SA (FCS_COP)
FCS_COP.1/IKE-SA Cryptographic operation – IKE SA
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/IKE-SA The TSF shall perform [IKE SA data encryption, decryption, and integrity
protection and mutual peer authentication by digital signature generation and
digital signature verification] in accordance with a specified cryptographic
algorithm [AES-GCM, ECDSA] and cryptographic key sizes [
• AES 256 bit,
• ECDSA 384 bit
] that meet the following: [
• NIST-FIPS-197 (AES)
• AES-GCM Mode as defined in NIST-SP800-38D and RFC-5282
• ECDSA-384 as defined in RFC-4754 on octets as specified in RFC-
7296 section 2.15 according to
FIPS PUB 186-4, Digital Signature Standard (DSS)], Section 6 and
Appendix D, Implementing “NIST curves” P-384; [ISO/IEC 14888-3,
Section 6.4, for ECDSA schemes
• SHA-384 as defined in NIST-FIPS-180-4, Secure Hash Standard
(SHS), 2015
].
Application Note 12: The AES 256 Bit keys for encryption and decryption of the IKE SA messages are generated
with FCS_CKM.1/IKEv2. The ECDSA-384 signature generation key is the private key belonging to the TOE’s ECC
X.509 certificate which has been installed in the TOE by the trusted administrator (see FDP_ITC.1/IKE-SA-
AuthCert). The ECDSA-384 signature verification key is the public key in the peer’s ECC certificate which is
received in the IKE_AUTH exchange.
Application Note 13: FCS_COP.1/HASH contains the specification for the hashing function used by the ECDSA
function.
6.2.1.8 Cryptographic key operation for Datapath (FCS_COP)
FCS_COP.1/Datapath Cryptographic operation – Datapath
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 37 of 62
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/DataPath The TSF shall perform [user data encryption, decryption] in accordance with
a specified cryptographic algorithm [AES-CTR] and cryptographic key sizes [
• AES 256 bit,
] that meet the following: [
• AES as defined in [NIST-FIPS-197]
• CTR Mode as defined in [NIST-SP800-38A]
].
Application Note 14: The AES 256 Bit keys for encryption and decryption of user data are generated with
FCS_CKM.1/IKEv2 during a CREATE_CHILD_SA exchange according to RFC-7296 section 2.17 (Generating
Keying Material for Child SAs).
6.2.1.9 Cryptographic key operation for Firmware (FCS_COP)
FCS_COP.1/FW Cryptographic operation – Firmware validation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/FW The TSF shall perform [digital signature verification] in accordance with a
specified cryptographic algorithm [ECDSA] and cryptographic key sizes [
• ECDSA 384 bit
] that meet the following: [
• ECDSA-384 with NIST-defined P-curve P-384 (secp384r1) with SHA-
384 as defined in
FIPS PUB 186-4, Digital Signature Standard (DSS)], Section 6 and
Appendix D, Implementing “NIST curves” P-384; [ISO/IEC 14888-3,
Section 6.4, for ECDSA schemes
• SHA-384 as defined in NIST-FIPS-180-4, Secure Hash Standard
(SHS), 2015
].
Application Note 15: The ECDSA-384 signature verification applies to the KM and ASIC firmware during start-
up self-tests. The public key is programmed into the device at manufacturing time.
6.2.1.10 Cryptographic key management for key destruction (FCS_CKM)
FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 38 of 62
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [
• The KEK (see FCS_CKM.1/KEK) is destroyed by zeroization via a
MyCryptoTool or TCS interface command.
• The private key belonging to the device certificate for IKA SA
authentication (see FCS_CKM.1/IKE-SA-AuthCert or FDP_ITC.1/IKE-
SA-AuthCert) is destroyed by zeroization of the KEK.
• All ephemeral keys (see FCS_CKM.1/IKEv2) are destroyed by
overwriting with new ephemeral key material or zeros by session
termination, reboot, power removal or command via MyCryptoTool and
TCS interface]
that meets the following: [none].
Application Note 16: The private key belonging to the device certificate for IKA SA authentication, which is either
imported via FDP_ITC.1/IKE-SA-AuthCert or had been generated in the TOE via FCS_CKM.1/IKE-SA-AuthCert
is stored encrypted with a KEK (see FCS_COP.1/KEK) in non-volatile TSF memory. Zeroization of the KEK, which
encrypts all other non-ephemeral cryptographic keys (i.e. the private key of the IKE SA authentication certificate),
renders the keys stored in non-volatile memory useless, thereby effectively zeroizing them. Ephemeral key
material for the high speed datapath is very short lived (typically 10 seconds) and hence continuously
erased/refreshed or overwritten with zeros at session termination.
6.2.2 Class FDP: User Data Protection
6.2.2.1 Import from outside of the TOE (FDP_ITC)
FDP_ITC.1/IKE-SA-
AuthCert
Import of user data without security attributes – IKE SA authentication certificate
with or without private key
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialization.
FDP_ITC.1.1/IKE-
SA-AuthCert
The TSF shall enforce the [none SFP] when importing user data the IKE SA
authentication certificate, controlled under the SFP, from outside of the TOE.
FDP_ITC.1.2/IKE-
SA-AuthCert
The TSF shall ignore any security attributes associated with the user data when
imported from outside the TOE.
FDP_ITC.1.3/IKE-
SA-AuthCert
The TSF shall enforce the following rules when importing user data the IKE SA
authentication certificate controlled under the SFP from outside the TOE: [apply
encryption as specified in FCS_COP.1/KEK to store the private key in non-volatile
memory].
Application Note 17: The imported device certificate for IKA SA authentication serves for identification and
authentication of the TOE to peer devices, see FIA_API.1. Either the private key corresponding to the certificate
has been generated within the TOE, see FCS_CKM.1/IKE-SA-AuthCert, or the private key has been generated
externally and will be imported together with the data structure used in FDP_ITC.1/IKE-SA-AuthCert.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 39 of 62
6.2.2.2 Stored data confidentiality (FDP_SDC)
FDP_SDC.1 Stored data confidentiality- private key of IKE SA authentication certificate
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_SDC.1.1 The TSF shall ensure the confidentiality of the information of the user data a
private key while it is stored in the [non-volatile memory].
Application Note 18: The private key belonging to the device certificate for IKA SA authentication, which is either
imported via FDP_ITC.1/IKE-SA-AuthCert or had been generated in the TOE via FCS_CKM.1/IKE-SA-AuthCert
is stored encrypted with a KEK (see FCS_COP.1/KEK) in non-volatile TSF memory.
6.2.3 Class FIA: Identification and Authentication
6.2.3.1 User identification (FIA_UID)
FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies.
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
Application Note 19: A peer device is identified by the TOE through its X.509 certificate submitted during the
IKEv2 SA protocol handshake.
6.2.3.2 User Authentication (FIA_UAU)
FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
Dependencies: FIA_UID.1 Timing of identification.
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing
any other TSF-mediated actions on behalf of that user.
Application Note 20: A peer device is authenticated by the TOE through validation of the submitted X.509 peer
device certificate and verification of the peer device signature (see FCS_COP.1/IKE-SA) presented during the
IKEv2-SA protocol handshake.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 40 of 62
6.2.3.3 Proof of Identity (FIA_API)
FIA_API.1 Authentication Proof of Identity – IKEv2
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1 The TSF shall provide a [authentication mechanism using ECDSA signature
generation (IKEv2 RFC-7296 section 2.15 “Authentication of the IKE SA”),
ECDSA with SHA-384 on the P-384 curve according to RFC-4754] to prove the
identity of the [TOE] to an external entity.
Application Note 21: The imported IKE SA authentication certificate (see FDP_ITC.1/IKE-SA-AuthCert) together
with the corresponding private key serves for identification and authentication of the TOE to peer devices using
the cryptographic operations as defined in FCS_COP.1/IKE-SA.
6.2.4 Class FMT: Security Management
6.2.4.1 Specification of Management Functions (FMT_SMF)
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [
• firmware load service
• generation of a Certificate Request Message for the IKE SA authentication
certificate using an asymmetric key pair generated with FCS_CKM.1/IKE-
SA-AuthCert
• import of IKE SA authentication certificate with or without private key
depending on whether the key pair had been generated in the TOE or
outside of the TOE
• clearing of IKE SA authentication certificate private key
• import/removal of trusted CA certificates
• import/removal of trusted CA CRL
• setting of IKEv2-parameters
o Re-Authentication Failure Mode, determines what happens if SA
re-authentication fails
o Re-Authentication Period, i.e. IKEv2 SA re-authentication (1 hour
min, 24 hours max)
o Re-Keying Period, i.e. IKEv2 Child SA re-keying (1 second min,
3600 seconds max)
].
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 41 of 62
6.2.5 Class FPT: Protection of the TSF
6.2.5.1 Inter-TSF TSF data consistency (FPT_TDC)
FPT_TDC.1 Inter-TSF basic TSF data consistency – IKE SA authentication certificate
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [
• IKE SA authentication certificates,
• CA certificates,
• CRLs
] when shared between the TSF and another trusted IT product.
FPT_TDC.1.2 The TSF shall use [
• PKCS#12 Personal Information Exchange Syntax Standard, Version 1.1,
RFC-7292 for IKE SA authentication certificates where the private key had
been generated outside the TOE,
• PEM (base64 encoded) file format for IKE SA authentication certificates
where the private key had been generated within the TOE, CA certificates
and CRLs
] when interpreting the TSF data from another trusted IT product.
Application Note 22: The TOE uses the IKE SA authentication certificate for authentication to the peer, see
FIA_API.1. The CA certificate is the certificate of the CA which issues the peer device certificate. The CRL is the
CRL of the CA of the peer device certificate.
6.2.5.2 TSF self test (FPT_TST)
FPT_TST.1 TSF Testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self tests [during initial start-up] to demonstrate the
correct operation of [the TSF].
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of
[TSF data].
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of
[TSF].
Application Note 23: The TOE implements power-up self-tests checking the integrity and authenticity of the KM
and the ASIC firmware (via FCS_COP.1/FW) and cryptographic algorithm tests in terms of known answer tests
(KAT).
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 42 of 62
6.3 Security Assurance Requirements
The assurance requirements for the evaluation of the TOE, its development and operating environment are those
from the predefined assurance package EAL2 augmented by the following components:
ALC_FLR.2 (Flaw reporting procedures)
6.4 Security Requirements Rationale
According to the two groups SFR and SAR of security requirements, the security requirements rationale is also
divided into two sections: Security functional requirements rationale and security assurance requirements
rationale.
6.4.1 Security Functional Requirements Rationale
6.4.1.1 Fulfilment of the Security Objectives
The following table maps security objectives to security functional requirements, showing that each security
objective is covered by at least one security functional requirement and that no security functional requirement
exists that is not needed by any security objective.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 43 of 62
Security Objective
of the TOE
Security Function
Requirement
SOT.CryptographyForIKE
SOT.DatapathEncryption
SOT.SelfProtection
SOT.ManagementForIKE
FCS_RNG.1 x
FCS_COP.1/HASH x
FCS_CKM.1/KEK x
FCS_CKM.1/IKE-SA-AuthCert x
FCS_CKM.1/IKEv2 x
FCS_COP.1/KEK x
FCS_COP.1/IKE-SA x
FCS_COP.1/Datapath x
FCS_COP.1/FW x
FCS_CKM.4 x
FDP_ITC.1/IKE-SA-AuthCert x
FDP_SDC.1 x
FIA_UID.2 x
FIA_UAU.2 x
FIA_API.1 x
FMT_SMF.1 x
FPT_TDC.1 x
FPT_TST.1 x
Table 8: Rationale for Security Objectives
The inspection of the table above shows that:
● Each SFR traces back to at least one security objective,
● Each security objective for the TOE has at least one SFR tracing to it.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 44 of 62
The following paragraphs contain more details on this mapping.
6.4.1.1.1 SOT.CryptographyForIKE
The TOE performs the cryptographic algorithms and message exchanges needed for the confidentiality and
integrity of the IKE SA establishment as follows:
● FCS_RNG.1 provides the random numbers needed for key and nonce generation in the IKEv2 protocol.
● FCS_COP.1/HASH is the basic cryptographic primitive used for calculating the hashes for signature
generation and verification and as building block for the PRF.
● FCS_CKM.1/IKEv2 generates the IKEv2 session keys for the IKE SA and the Child-SAs datapath
encryption/decryption keys.
● FCS_COP.1/IKE-SA implements the cryptographic mechanisms necessary for establishment of the IKE-
SA according to the Internet Key Exchange (IKEv2) protocol.
● FCS_CKM.4 ensures that keys are destroyed in a safe way. In particular, session keys negotiated via IKE
are destroyed after they are no longer needed.
● FIA_UID.2 supports the identification of the peer device through its X.509 certificate submitted during the
IKEv2 SA protocol handshake.
● FIA_UAU.2 supports the authentication of the peer device through its X.509 certificate submitted during
the IKEv2 SA protocol handshake.
● FIA_API.1 serves for identification and authentication of the TOE to peer devices during the IKEv2 SA
protocol handshake.
6.4.1.1.2 SOT.DatapathEncryption
The TOE implements the confidentiality protection of user data in the ASIC module. The following SFRs support
that functionality within the TOE:
● FCS_COP.1/Datapath directly implements the objective SOT.DatapathEncryption.
6.4.1.1.3 SOT.SelfProtection
SOT.SelfProtection is met by a combination of the following SFRs:
● FCS_CKM.1/KEK generates the KEK which is used for encrypting or decrypting the private key material
of the IKE SA authentication certificate and thus supports the SOT.SelfProtection objective that keys for
TOE identification and authentication shall be kept secret.
● FCS_COP.1/KEK uses the KEK for encrypting or decrypting the private key material of the IKE SA
authentication certificate.
● FCS_COP.1/FW supports FPT_TST.1 to verify the integrity and authenticity of the firmware and thus
contributes to the TOE self protection.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 45 of 62
● FDP_SDC.1 implements the SOT.SelfProtection objective that keys for TOE identification and
authentication shall be kept secret
● FPT_TST.1 defines the self-testing functionality to detect whether the security functionality is working as
expected.
6.4.1.1.4 SOT.ManagementForIKE
SOT.ManagementForIKE is met by a combination of the following SFRs:
● FMT_SMF.1 lists the management functions the administrator can use to ensure the secure operation of
the TOE.
● FCS_CKM.1/IKE-SA-AuthCert allows the generation of the cryptographic ECC key pair used in the TOE’s
IKE SA authentication certificate.
● FDP_ITC.1/IKE-SA-AuthCert allows the import of the TOE’s IKE SA authentication certificate generated
by a trustworthy CA.
● FPT_TDC.1 requires the use of standardized formats for the import of certificates and private keys and
thus supports FDP_ITC.1/IKE-SA-AuthCert.
6.4.1.2 Fulfilment of the SFR dependencies
The following table summarizes the existing dependencies between security requirements of this ST and
demonstrates that they are fulfilled.
SFR Dependency Fulfilled by
FCS_RNG.1 - -
FCS_COP.1/HASH [FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Please refer to chapter
6.4.1.3 for missing
dependency
FCS_CKM.1/KEK [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/KEK
FCS_CKM.4
FCS_CKM.1/IKE-
SA-AuthCert
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/IKE-SA
FCS_CKM.4
FCS_CKM.1/IKEv2 [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/IKE-SA
FCS_CKM.4
FCS_COP.1/KEK [FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1/KEK
FCS_CKM.4
FCS_COP.1/IKE-
SA
[FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.1/IKE-SA-
AuthCert
FDP_ITC.1/IKE-SA-
AuthCert
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 46 of 62
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1/IKEv2
FCS_CKM.4
FCS_COP.1/Datap
ath
[FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1/IKEv2
FCS_CKM.4
FCS_COP.1/FW [FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Please refer to chapter
6.4.1.3 for missing
dependency
FCS_CKM.4 [FDP_ITC.1 Import of user data without security attributes,
or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.1/KEK
FCS_CKM.1/IKE-SA-
AuthCert
FDP_ITC.1/IKE-SA-
AuthCert
FCS_CKM.1/IKEv2
FDP_ITC.1/IKE-
SA-AuthCert
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation.
Please refer to chapter
6.4.1.3 for missing
dependency
FDP_SDC.1 - -
FIA_UID.2 - -
FIA_UAU.2 FIA_UID.1 Timing of identification FIA_UID.2
FIA_API.1 - -
FMT_SMF.1 - -
FPT_TDC.1 - -
FPT_TST.1 - -
Table 9: Fulfillment of SFR dependencies
The inspection of the table above shows that:
● All dependencies between security functional requirements are satisfied, except as noted below in the
next section
6.4.1.3 Justification of missing SFR dependencies
The hash algorithm as defined in FCS_COP.1/HASH does not need any key material. As such the dependency to
an import or generation and destruction of key material is omitted for this SFR.
The signature validation as defined in FCS_COP.1/FW uses a public key that has been preloaded at the factory.
The public keys are key wrapped with BKEK and written to boot flash device. The TOE does not generate or
destroy this public key.
The TOE environment ensures that only trustworthy administrators can access the TOE for management (see
SOE.TrustedAdmin, SOE.TrustedAdminAccess). Thus, importing the IKE SA authentication certificate
FDP_ITC.1/IKE-SA-AuthCert does not require TSF access control, FDP_ACC.1 and FMT_MSA.3 are therefore
not required as TOE SFRs.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 47 of 62
6.4.2 Security Assurance Requirements Rationale
In order to keep evaluations according to this Security Target commercially feasible, EAL 2 has been chosen as
assurance level, as this is the level that is commonly agreed under CCRA members.
Eventually, the augmentation by ALC_FLR.2 has been chosen to emphasize the importance of a structured
process for flaw remediation at the developer’s side.
6.4.2.1 Fulfillment of SAR Dependencies
The dependencies of the assurance requirements taken from EAL 2 are fulfilled automatically. The augmentation
by ALC_FLR.2 does not introduce additional assurance components that are not contained in EAL 2.
6.4.2.2 Justification of missing SAR dependencies
None at this time.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 48 of 62
7 TOE Summary Specification
7.1 Overview
This TOE Summary Specification (TSS) describes the TOE in terms of security functions and how the TOE meets
the security functional requirements. The TSS explains the general technical mechanisms that the TOE uses for
this purpose.
The TOE (i.e. the NTK539QS and NTK539QV variants of Flex3 WL3e OCLD circuit packs) supports wire speed
point-to-point 100G and 200G encryption/decryption at the ODU4 payload layers (see Figure 10) with end-to-end
encryption authentication/key exchange. The TOE provides support for the following rates and modulation formats:
• 100G QPSK modulation (NTK539QS);
• 200G 16QAM modulation (NTK539QV);
Encryption is always enabled on the encryption circuit pack. There is no option to disable encryption. The two end
points of a secured datapath must be equipped with NTK539QS or NTK539QV circuit pack for peer authentication
and payload encryption/decryption.
The TOE requires a valid Time of Day (TOD) in order to validate the data encryption certificates and establish
traffic on the circuit pack.
The TOE is a hardware module with a multiple-chip embedded embodiment. The module consists of two primary
components: a KM (processor complex) enclosed in an aluminum enclosure and a high speed datapath ASIC
(HunQ) mounted on the motherboard’s PCB and covered by a heatsink. These two components communicate via
wire connections embedded beneath multiple PCB layers. The KM also contains integrated circuits, processors,
Synchronous Dynamic Random Access Memory (SDRAM), flash memories (NOR6 and EEPROM), and FPGAs.
Figure 9 below provides another high level depiction of the TOE.
Figure 9: Overview of the TOE’s components
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 49 of 62
The TOE components together implement the following security functions that cover the SFRs listed in Chapter 6
of this ST:
SF.FCS: Cryptographic Support for IKEv2 and datapath encryption
SF.FDP: User Data Protection
SF.FIA: Identification and Authentication
SF.FMT: Security Management
SF.FPT: Protection of the TSF
The TSS is given in more detail in the following sections.
7.2 SF.FCS: Cryptographic Support
The TOE implements the following cryptographic mechanisms either in the high speed datapath ASIC or the KM
firmware:
● Random Number Generation (RNG)
● ECC Key Generation on NIST defined P-curve P-384 (secp384r1)
● ECC Key-Agreement Diffie-Hellman (ECKA-DH) on NIST defined P-curve P-384 (secp384r1)
● ECDSA signature generation and verification for NIST defined P-curve P-384 (secp384r1)
● SHA-2 family of hash algorithms, especially
○ SHA-384
● KDF
○ PRF_HMAC_SHA2_384
● AES
○ AES-GCM
○ AES-CBC
○ AES-CTR
The implemented cryptographic mechanisms are combined and used as building blocks to finally provide high
speed datapath encryption for keeping user data transferred between two connected TOE devices confidential.
The IKEv2 protocol is used to establish an authenticated and secure connection (IKEv2 Security Association) of
the TOE device to its peer device. The IKEv2 SA established is used to continuously derive and establish new
datapath AES keys.
ASIC Cryptographic Services: high speed (100 Gb/s) AES-256 ciphers
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 50 of 62
The primary objective of the TOE is to protect the confidentiality of the cleartext user data when transiting an
untrusted OTN wide area network. This is achieved by way of high speed (100 Gb/s) AES-256-CTR ciphers
embedded within the primary high speed datapath ASIC (HunQ).
The HunQ ASIC implements the AES encryption/decryption with an AES 256 Bit key in AES-CTR mode
(FCS_COP.1/Datapath). The uniqueness of counter blocks across all plaintext blocks that are encrypted under a
given AES 256 Bit key is guaranteed as follows:
The ICV is 128 Bit, generated from the TOE DRNG; each invocation of the AES encrypt function increments the
counter by 1 mod 2128; the regular {K, ICV} rotation interval is maximum 3600 seconds (see FMT_SMF.1); the
ODU4 frame rate is ~856Kf/s with nominally 952 AES blocks per OTN frame. Hence the maximum number of
plaintext blocks encrypted under a given {K, ICV} does not exceed 242.
The HunQ ASIC supports operation at either 200G/16QAM or 100G/QPSK depending on the modulation of the
circuit pack’s line interface. Hence there can actually be two fully independent AES-256-CTR ciphers within the
ASIC. When configured for 200 Gb/s, both ciphers are enabled and two totally independent IKEv2 SA connections
between the peers are established to generate entirely independent key material for both 100 Gb/s ciphers.
Each 100 Gb/s cleartext user data interfaces on the ASIC presents as a standard ITU-T G.709 ODU4 frame format.
Each AES-256-CTR cipher operates on the OPU4 payload portion of the OTN frame. A low speed overhead
channel carried within the G.709 ODU4 overhead facilitates IKEv2 peer authentication/ephemeral key agreement,
hitless key bank rolling and fast counter resynchronization, see Figure 10 below.
Figure 10: OPU4 Encryption (AES-256-CTR)
There is no cleartext bypass path in the ASIC; the cleartext user data is either squelched (i.e. overwritten with a
locally generated replacement signal, typically all 1’s) or encrypted. The default behavior on power up is to squelch.
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 51 of 62
Traffic remains squelched during POST/KAT’s and continues indefinitely pending successful IKEv2 peer
authentication and ephemeral key agreement.
Each 100 Gb/s cipher has its own dedicated key bank. Key (K) length is 256 bits, ICV length is 128 bits. IKEv2
software configures unique {K, ICV} for each direction (i.e. onramp/encrypt {K, ICV} is distinct from offramp/decrypt
{K, ICV}). Each key bank comprises current/active key material and next/standby key material to facilitate hitless
key bank rolling; IKEv2 protocol agrees fresh {K, ICV} roughly once a second (maximum 3600 seconds), see
FMT_SMF.1 for configuration. Periodic IKEv2 re-authentication refreshes the master session key roughly once an
hour (maximum 24 hours), see also FMT_SMF.1.
The AES-256-CTR cipher of the ASIC (FCS_COP.1/Datapath) has successfully completed FIPS CAVP at NIST
approved lab (AES Validation Number #4231). Upon power up, KAT’s are executed to confirm cipher operation is
correct and if not circuit pack is failed.
KM Cryptographic Services
The TOE’s KM component implements a deterministic random number generator DRBG according to [NIST-
SP800-90A, Chapter 10.2] (FCS_RNG.1). The DRBG mechanism is based on AES-256 as block cipher. The
DRBG is seeded from seeding material provided by a hardware-based PTRNG, which provides an entropy source
and whitening circuitry to supply a uniformly-distributed unbiased random sequence of bits to the DRBG. CRNGT
(Continuous Random Number Generator Test) is implemented to ensure confidence in the entropy source. The
DRBG has successfully completed FIPS CAVP at NIST approved lab (DRBG Validation Number #1315).
The TOE provides cryptographic hashing services using SHA-384 (FCS_COP.1/HASH) as specified in NIST FIPS
180-4, Secure Hash Standard (SHS), 2015. This cryptographic primitive is used in various situations, e.g. for
signature generation or verification or in the PRF of IKEv2. The Hash function has successfully completed FIPS
CAVP at NIST approved lab (SHS Validation Number #3469, #3468).
FCS_CKM.1/IKEv2 uses the random numbers from FCS_RNG.1 to generate an ephemeral ECC key pair in Diffie-
Hellman group 20 according to RFC-5903, section “3.2 384-Bit Random ECP Group”, which is used in the
IKE_SA_INIT exchange as KE payload, i.e. as the Diffie-Hellman value. The shared secret computed from the
Diffie-Hellman exchange and the initiator/responder nonces are then used to generate the SKEYSEED as
described in RFC-7296, section 2.14. The SKEYSEED value is further used to generate all necessary IKEv2 SA
keys applying the PRF function PRF-HMAC-SHA-384 iteratively as specified in RFC-7296, section 2.13. The AES
256 bit keys for datapath encryption are taken from the KEYMAT bit string as specified in RFC-7296, section 2.17.
In addition to the ephemeral ECC key generation during the IKEv2 SA establishment the TOE can generate a
static ECC key pair with FCS_CKM.1/IKE-SA-AuthCert which serves as key material for the TOE’s IKE SA
authentication certificate. For secure storage of the corresponding private key of the certificate, the TOE stores it
encrypted in non-volatile memory (see FDP_SDC.1).
Actually, the TOE uses three layers of encryption keys to ultimately secure the private ECC key used by the TOE
during IKEv2 authentication.
● The first key is an AES 256-bit key called Base Key Encryption Key (BKEK) which has been generated
per Flex3 WL3e OCLD circuit pack and preloaded into the TOE at the factory. It is stored in plaintext in
non-readable, write once, non-probable eFuse within the KM processor. During normal operation of the
TOE the BKEK is used to decrypt (FCS_COP.1/KEK) the AES-256-bit key called Master Key Encryption
Key (MKEK).
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 52 of 62
● The MKEK has been generated per Flex3 WL3e OCLD circuit pack at the factory and has been encrypted
at the factory with the BKEK. The BKEK encrypted MKEK is stored in non-volatile memory in the KM.
During normal operation of the TOE the MKEK is used to encrypt or decrypt (FCS_COP.1/KEK) the Key
Encryption Key (KEK).
● The KEK is generated by the TOE (FCS_CKM.1/KEK) and is stored MKEK encrypted in non-volatile
memory. During normal operation the KEK is used to encrypt or decrypt (FCS_COP.1/KEK) the private
ECC key of the device. The private ECC key of the device has been either generated (see
FCS_CKM.1/IKE-SA-AuthCert) or imported (see FDP_ITC.1/IKE-SA-AuthCert) by the TOE.
The following figure shows this hierarchy of key encryption keys.
Figure 11: Encryption Keys Hierarchy
The SFRs FCS_CKM.1/IKEv2 and FCS_COP.1/IKE-SA are implemented by the TOE to facilitate the IKEv2
protocol message exchanges.
After FCS_CKM.1/IKEv2 helped to generate all necessary keys for the IKEv2 SA FCS_COP.1/IKE-SA supports
the IKE_AUTH exchange by generating/verifying ECDSA-384 signatures for authentication purposes. The TOE’s
signature key is the private key belonging to its ECC X.509 certificate. This key has either been generated internally
by the TOE through FCS_CKM.1/IKE-SA-AuthCert or has been installed in the TOE by the trusted administrator
during the certificate enrollment process (see FDP_ITC.1/IKE-SA-AuthCert). The ECDSA-384 signature
verification key is the public key in the peer’s ECC certificate which is received in the IKE_AUTH exchange. The
ECDSA signature generation/verification implementation has successfully completed FIPS CAVP at NIST
approved lab (ECDSA Validation Number #977).
The IKE_AUTH exchange messages themselves are already encrypted and integrity protected using the AES-
256-GCM cipher also implemented by FCS_COP.1/IKE-SA. The implementation of the AES-256-GCM
cryptographic algorithm has successfully completed FIPS CAVP at NIST approved lab (AES Validation Number
#4232).
The TOE implements the destruction of ephemeral session keys by overwriting the corresponding area in RAM
with new ephemeral session keys during normal operation or with zero bytes at session termination, reboot or
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 53 of 62
power removal (see FCS_CKM.4). The TOE stores all static private keys (i.e. the IKEv2 certificate private key) in
non-volatile memory encrypted with the KEK. By zeroizing the KEK (FCS_CKM.4) the TOE both destroys the KEK
and renders asymmetric private keys inaccessible, i.e. effectively destroying those cryptographic keys.
It is worthwhile noting that this is a “closed system”. Broad multi-vendor interoperability is intentional not required
and hence the IKEv2 implementation is focused on a narrow set of options. In particular there is no need for agility
in the selection of cipher suites allowing the TOE to focus on a very narrow selection of transforms (see [IKEv2-
PAR]):
● Transform Type 1 - Encryption Algorithm Transform ID = 20 (ENCR_AES_GCM_16) with 256 bit AES key
● Transform Type 2 - Pseudorandom Function Transform ID = 6 (PRF_HMAC_SHA2_384)
● Transform Type 3 - Integrity Algorithm Transform ID = none (because of ENCR_AES_GCM_16 as
Transform Type 1)
● Transform Type 4 - Diffie-Hellman Group Transform ID = 20 (384-bit random ECP group)
● IKEv2 Authentication Method = 10 (ECDSA with SHA-384 on the P-384 curve)
Firmware images are digitally signed (SHA-384/ECDSA-384) at time of manufacturing. Upon power-on the TOE
validates this digital signature using SFR FCS_COP.1/FW executed in the FSBL, thus ensuring the TOE will only
enter normal operation with a legitimate/signed Ciena software image. The ECDSA signature verification
(FCS_COP.1/FW) has successfully completed FIPS CAVP at NIST approved lab (ECDSA Validation Number
#977 for KM and #976 for ASIC).
7.3 SF.FDP: User Data Protection
FDP_ITC.1/IKE-SA-AuthCert allows importing the TOE’s IKE SA authentication certificate issued by a trustworthy
CA in an appropriate syntax (see FPT_TDC.1). The implementation of FDP_ITC.1/IKE-SA-AuthCert ensures that
the private key of the certificate imported is not stored in plaintext but encrypted with the Key Encryption Key as
required by FDP_SDC.1.
The KEK itself is a 256-bit key that is stored in non-volatile memory and never exits the TOE. The KEK is encrypted
with a Master Key Encryption Key (MKEK) which in turn is encrypted by a Base Key Encryption Key (BKEK) that
is preloaded at the factory and stored in non-readable, write once, non-probable eFuse within the KM processor
(see Figure 11).
7.4 SF.FIA: Identification and Authentication
The TOE requires each peer device to be successfully identified (FIA_UID.2) and authenticated (FIA_UAU.2)
before any action can be performed.
A peer device is identified and authenticated by the TOE through validation of the submitted X.509 peer device
certificate and verification of the peer device signature (see FCS_COP.1/IKE-SA) presented during the IKEv2-SA
protocol handshake.
The TOE assumes the peer entity certificate as valid if all of the following conditions are met:
● peer entity certificate’s validity is checked against local system date/time
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 54 of 62
● peer entity certificate is issued by the same CA as the certificate of the TOE or one of the imported trusted
CAs
● peer entity certificate serial number does not appear in the CRL for the corresponding signing CA
The administrator installs trusted CA certificate(s) and CRLs (see FMT_SMF.1) to establish roots of trust.
The other way around the TOE proofs its identity to the peer device through FIA_API.1. The TOE IKE SA
authentication certificate is used to identify and the corresponding private key is used to authenticate the TOE to
the peer device. Authentication is done by signing the IKE_AUTH message using the cryptographic signature
generation operation as defined in FCS_COP.1/IKE-SA.
7.5 SF.FMT: Security Management
The TOE implements the security management functions as specified in FMT_SMF.1.
The management commands can be issued by the administrator using the Web based application “MyCryptoTool”.
The administrator connects via TLS 1.2 (HTTPS) to the “MyCryptoTool” application. The session is mutually
authenticated and secured via TLS_ECDHE_ECDSA_AES128/256_GCM_SHA384 cipher suite. Note however
that the MyCryptoTool subsystem is considered as non-TSF (see Section 1.3.4).
The TOE performs a firmware update when triggered by the administrator through the TCS management interface
(FMT_SMF.1). Before the TOE actually executes the firmware update the TOE verifies the integrity of the new
firmware image by checking its digital signature with FCS_COP.1/FW. The corresponding public key is embedded
in the active firmware code.
7.6 SF.FPT: Protection of the TSF
The TOE implements several measures to protect the TSF which are summarized in this security function.
FPT_TDC.1 requires the use of standardized encodings for the enrollment of device certificates (see
FDP_ITC.1/IKE-SA-AuthCert) and the import of CA certificates and CRLs.
The following objects must be in PEM (base64 encoded) file format:
● Signing CA certificate
● Trusted CA certificates
● Certificate Revocation Lists (CRLs)
● Device certificate (if key pair has been generated in the TOE)
The following object must be in PKCS#12 file format:
● Device certificate (if key pair has been generated externally)
The TOE performs the following self-tests at power-up (FPT_TST.1) to verify the integrity of the firmware images
and the correct operation of the cryptographic algorithms implemented in the module:
● Integrity and authenticity test for the KM:
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 55 of 62
○ KM application firmware image using ECDSA signature verification (FCS_COP.1/FW)
● Integrity and authenticity test for the ASIC:
○ ASIC firmware image using ECDSA signature verification (FCS_COP.1/FW)
● Cryptographic algorithm tests for all implementations of the following FIPS-approved algorithms:
○ KM
■ AES Encryption Known Answer Test (KAT)
■ AES Decryption KAT
■ SHA-256, 384, 512 KAT
■ HMAC SHA-256, 384, 512 KAT
■ SP 800-90A CTR_DRBG KAT
■ ECDSA 186-4 Signature Generation Pairwise Consistency Test (PCT)
■ ECDSA 186-4 Signature Verification PCT
○ ASIC
■ AES Encryption KAT
■ AES Decryption KAT
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 56 of 62
8 Appendices
The appendixes provide explanations for abbreviations and references to relevant standards.
8.1 Acronym Definition
A.x Assumption x on the environment
AES Advanced Encryption Standard
ARM Advanced RISC Machine
ASIC Application-Specific Integrated Circuit
BKEK Base Key Encryption Key
BSI Bundesamt für Sicherheit in der Informationstechnik, Federal Office for Information Security
CA Certificate Authority
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
CC Common Criteria
CCRA Common Criteria Recognition Arrangement
CEM Common Evaluation Methodology for Information Technology Security
CLI Command Line Interface
CMVP Cryptographic Module Validation Program
CO Crypto Officer
CRL Certificate Revocation List
CRNGT Continuous Random Number Generator Test
CSE Communications Security Establishment
CSP Critical Security Parameter
CTR Counter
DEK Data Encryption Key
DES Data Encryption Standard
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 57 of 62
DH Diffie-Hellman
DRBG Deterministic Random Bit Generator
DTCM Data Tightly Coupled Memory
EAL Evaluation Assurance Level
EAL2 EAL level 2, predefined package of CC
EAL2+ EAL2 augmented by at least one SFR or SAR
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EEPROM Electrically-Erasable Programmable Read-Only Memory
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
FAU CC Functional class security AUdit
FCO CC Functional class COmmunication
FCS CC Functional class Cryptographic Support
FDP CC Functional class user Data Protection
FIA CC Functional class Identification and Authentication
FIPS Federal Information Processing Standard
FMT CC Functional class security ManagemenT
FPGA Field Programmable Gate Array
FPR CC Functional class PRivacy
FPT CC Functional class Protection of the TSF
FSBL First Stage Boot Loader
FTP CC Functional class Trusted Path/channels
Gb/s Gigabit Per Second
GbE Gigabit Ethernet
GCC General Communications Channel
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 58 of 62
GCM Galois/Counter Mode
HMAC (Keyed-) Hash Message Authentication Code
HTTPS Hyper-Text Transport Protocol Secure
I/O Input/Output
ICV Initial Counter Vector
IT Information Technology
ITCM Instruction Tightly Coupled Memory
IV Initialization Vector
KA Key Agreement
KAT Known Answer Test
KB Kilobyte
KE Key Exchange, in IKEv2 Diffie-Hellman value
KEK Key Encrypting Key
KM Krypto Module
LED Light Emitting Diode
Mb/s Megabits per second
MCLI Management Command Line Interface
MKEK Master Key Encrypting Key
MPLS Multiprotocol Label Switching
ms millisecond
N/A Not Applicable
NDPP Network Device Protection Profile
NDRNG Non-Deterministic Random Number Generator
NIST National Institute of Standards and Technology
NOR Not Or
NTP Network Time Protocol
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 59 of 62
OCLD Optical Channel Laser and Detector
OS Operating System
OSI Open Systems Interconnection
OSP Organizational Security Policy
OSP.x OSP x enforced by environment and TOE
OTN Optical Transport Network
OTR Optical Transponder
PCB Printed Circuit Board
PCT Pairwise Consistency Test
PKCS Public-Key Cryptography Standard
PKG Public Key Generation
PKV Public Key Validity
POST Power-On Self-Test
PRF Pseudo Random Function
PP Protection Profile
QAM Quadrature Amplitude Modulation
QPSK Quadrature Phase Shift Keying
RAM Random Access Memory
RISC Reduced Instruction Set Computing
ROM Read Only Memory
RSA Rivest Shamir Adelman (encryption algorithm)
SAR Security Assurance Requirement
SDH Synchronous Digital Hierarchy
SDRAM Synchronous Dynamic Random Access Memory
SFR Security Functional Requirement
SFTP Secure File Transfer Protocol
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 60 of 62
SHA Secure Hash Algorithm
SHS Secure Hash Standard
SOE.x Security objective x for the environment
SONET Synchronous Optical Networking
SOT.x Security Objective x for the TOE
SP Special Publication
SPD Security Problem Definition
SSH Secure Shell
ST Security Target
T.x Threat x
TCM Tandem Connection Monitor
TCS Transport Control Subsystem
TL1 Transaction Language One
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF Interface
TSP TOE Security Policy
TSS TOE Summary Specification
WL3e WaveLogic 3 Extreme
8.2 References
CC1 Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
general model, April 2017, Version 3.1, Revision 5, CCMB-2017-04-001
CC2 Common Criteria for Information Technology Security Evaluation, Part 2: Security
functional components, April 2017, Version 3.1, Revision 5, CCMB-2017-04-002
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 61 of 62
CC3 Common Criteria for Information Technology Security Evaluation, Part 3: Security
assurance components, April 2017, Version 3.1, Revision 5, CCMB-2017-04-003
CEM Common Criteria for Information Technology Security Evaluation, Evaluation
methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017
CIENA-TRNG Ciena Corporation, Ciena 6500 Packet-Optical Platform 4x10G, FIPS 140-2 Entropy
Supplement
IKEv2-PAR Internet Key Exchange Version 2 (IKEv2) Parameters,
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-
parameters-12, last visited 22.12.2017
KS2011 W. Killmann, W. Schindler, "A proposal for: Functionality classes for random number
generators", Version 2.0, September 18, 2011
NIST-FIPS-180-4 NIST FIPS 180-4, Secure Hash Standard (SHS), 2015
NIST-FIPS-186-4 FIPS PUB 186-4, Digital Signature Standard (DSS), 2013
NIST-FIPS-197 NIST FIPS 197, Advanced Encryption Standard (AES), 2001
NIST-SP800-38A NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of
Operation: Methods and Techniques, December 2001
NIST-SP800-38D NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC, November 2007
NIST-SP800-90A NIST Special Publication 800-90A Revision 1, Recommendation for Random Number
Generation Using Deterministic Random Bit Generators, June 2015
RFC-4754 IETF RFC 4754, D. Fu & J. Solinas, IKE and IKEv2 Authentication Using the Elliptic Curve
Digital Signature Algorithm (ECDSA), January 2007
RFC-4868 IETF RFC 4868, S. Kelly & S. Frankel, Using HMAC-SHA-256, HMAC-SHA-384, and
HMAC-SHA-512 with IPsec, May 2007
RFC-5282 IETF RFC 5282, D. Black & D. McGrew, Using Authenticated Encryption Algorithms with
the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol, August
2008
RFC-5903 IETF RFC 5903, D. Fu & J. Solinas, Elliptic Curve Groups modulo a Prime (ECP Groups)
for IKE and IKEv2, June 2010
RFC-7292 IETF RFC 7292, K. Moriarty, et al., PKCS #12: Personal Information Exchange Syntax
v1.1, July 2014
RFC-7296 IETF RFC 7296, C. Kaufman, et al., Internet Key Exchange Protocol Version 2 (IKEv2),
October 2014
ST for the Ciena 6500 Packet-Optical Platform Flex3 WaveLogic 3e OCLD Encryption Module Version 1.6
© 2020 Ciena Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice
Page 62 of 62
SEC2 SEC 2: Recommended Elliptic Curve Domain Parameters, Certicom Research, Version
2.0, January 27, 2010
SOGIS-CESGD Joint Interpretation Library: SOG-IS Crypto Evaluation Scheme – Guidance Document,
Guide to Evaluation of Cryptographic Devices – Draft -, Version 0.9.1, September 2017
TR-02102-3 Bundesamt für Sicherheit in der Informationstechnik, Technische Richtlinie BSI TR-02102-
3, Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Teil 3 – Verwendung
von Internet Protocol Security (IPsec) und Internet Key Exchange, Version 2017-01
8.3 Revision History
Version Date Description
0.1 18.09.2017 Initial version after kick-off telephone conference with Ciena
0.2 22.09.2017 Work on SFRs
0.16 07.11.2017 First complete draft (except TSS)
0.18 15.11.2017 After internal review
0.19 18.12.2017 After input for Chapter 7 from MWW
0.20 03.01.2018 Rearrange Chapter 7 input, link with SFRs of Chapter 6
1.0 15.02.2018 Comments incorporated, questions answered by MWW
1.1 26.02.2018 Minor changes, corrections
1.2 19.03.2018 Updates after kick-off meeting at BSI
1.3 02.05.2018 Removed security algorithms from Section 1.4.2.2 that are not used by the
TOE, added BSI certification id
1.4 29.05.2018 Added some functional description in Section 7.1
1.5 29.04.2019 Include review comments of CertLab
1.6 28.04.2020 Align document title with ST of 4x10G OTR, correct TOE version to 2.01,
add Doc-ID