| Standard | FIPS 140-3 |
|---|---|
| Overall level | 3 |
| Module type | Hardware |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 11/5/2029 |
| Caveat | Interim Validation. When operated in approved mode and initialized as per Section 2.3.1 of the Security Policy |
| Vendor | Senetas Corporation Ltd, distributed by Thales SA (SafeNet) |
flowchart LR
%% Deterministic review-risk graph for CN Series Encryptors
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update<br/>upgrade</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status output</i>"]
C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
end
subgraph Risk["Reviewer question"]
R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C5 --> I5 --> R5 --> E5
C6 --> I6 --> R6 --> E6
classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
class C2,C3,C5,C6 clue;
class I2,I3,I5,I6 infer;
class R2,R3,R5,R6 risk;
class E2,E3,E5,E6 evidence;flowchart LR
%% Deterministic clue tier for CN Series Encryptors
%% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
subgraph CMVP["CMVP-disclosed clues (deterministic)"]
C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update<br/>upgrade</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>Status output</i><br/>src: text:keyword"]
C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
end
classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
class C2,C3,C5,C6 clueLow;Senetas Corporation Ltd., distributed by Thales SA (SafeNet) CN Series Encryptors Level 3 Validation June 2025 Module Name: CN Series Encryptors Model Names: CN4010 1G Ethernet Encryptor CN4020 1G Ethernet Encryptor CN6010 1G Ethernet Encryptor CN6100 10G Ethernet Encryptor CN6110 1/10G Ethernet Encryptor CN6140 1/10G Multi Port Ethernet Encryptor CN9100 100G Ethernet Encryptor CN9120 100G Ethernet Encryptor HW Versions: CN4000 Series: A4010B (DC) A4020B (DC) CN6000 Series: A6010B (AC), A6011B (DC), A6012B (AC/DC) A6100B (AC), A6101B (DC), A6102B (AC/DC) A6110B (AC), A6111B (DC), A6112B (AC/DC) A6140B (AC), A6141B (DC), A6142B (AC/DC) CN9000 Series: A9100B (AC), A9101B (DC), A9102B (AC/DC) A9120B (AC), A9121B (DC), A9122B (AC/DC) FW Versions: 5.5.0 and 5.5.1 CN9120 v1.02 Once released this document may be freely reproduced and distributed whole and intact www.senetas.com
Document History Authors Date Version Comment Senetas Corp. Ltd. 19-Dec-2023 1.00 CMVP Release for firmware version 5.5.0 Senetas Corp. Ltd. 11-Sep-2024 1.01 Interim validation update Senetas Corp. Ltd. 16-Jun-2025 1.02 CMVP Release for firmware version 5.5.1
| # | Section | Page |
|---|
1. General This is a non-proprietary FIPS 140-3 Security Policy for the Senetas Corporation Ltd. CN Series Encryptors (running firmware versions 5.5.0 and 5.5.1) comprising of the CN4010, CN4020, CN6010, CN6100, CN6110, CN6140, CN9100 and CN9120 hardware cryptographic models. This Security Policy specifies the security rules under which the module operates to meet the FIPS 140-3 Level 3 requirements. The CN Series Encryptors are distributed worldwide under different brands as depicted in this Security Policy. Senetas distributes under their own brand. Thales SA, the master worldwide distributor, distributes under the joint Thales/Senetas and SafeNet/Senetas brands (refer to Section 2.1.2). FIPS 140-3 (Federal Information Processing Standards Publication 140-3), Security Requirements for Cryptographic Modules, specifies the security requirements for a cryptographic module utilized within a security system protecting sensitive but unclassified information. Based on four security levels for cryptographic modules this standard identifies requirements in twelve sections. For more information about the NIST/CCCS Cryptographic Module Validation Program (CMVP) and the FIPS 140-3 standard, visit www.nist.gov/cmvp. This Security Policy, using the terminology contained in the FIPS 140-3 specification, describes how the CN Series models comply with the twelve sections of the standard. In this document, the CN4010, CN4020, CN6010, CN6100, CN6110, CN6140, CN9100 and CN9120 Encryptors are collectively referred to as the “CN Series” and individually as “the module” or “the encryptor”. The CN4010 and CN4020 models are collectively referred to as the “CN4000 Series”. The CN6010, CN6100, CN6110 and CN6140 models are collectively referred to as the “CN6000 Series”. The CN9100 and CN9120 models are collectively referred to as the “CN9000 Series”. The model name refers to all of the relevant module versions i.e. CN6010 refers to the module versions A6010B (AC), A6011B (DC), A6012B (AC/DC) (refer to Table 2 for a full listing). This Security Policy and the associated CMVP certificate are for firmware versions 5.5.0 and 5.5.1 only
3 conformance testing and validation is proprietary and confidential to Senetas Corporation Ltd. and is releasable
only under appropriate non-disclosure agreements. For more information describing the CN Series systems, visit http://www.senetas.com.
For more information on the FIPS 140-3 standard and validation program please refer to the National Institute of Standards and Technology website at www.nist.gov/cmvp. The following standards from NIST are all available via the URL: www.nist.gov/cmvp . [1] FIPS PUB 140-3: Security Requirements for Cryptographic Modules. [2] NIST Special Publication (SP) 800-140 FIPS 140-3 Derived Test Requirements (DTR). [3] NIST Special Publication (SP) 800-140A CMVP Documentation Requirements. [4] NIST Special Publication (SP) 800-140B CMVP Security Policy Requirements. [5] NIST Special Publication (SP) 800-140Crev2 CMVP Approved Security Functions. [6] NIST Special Publication (SP) 800-140Drev2 CMVP Approved Sensitive Security Parameter Generation and Establishment Methods. [7] NIST Special Publication (SP) 800-140E CMVP Approved Authentication Mechanisms. [8] NIST Special Publication (SP) 800-140Frev1 CMVP Approved Non-Invasive Attack Mitigation Test Metrics. [9] ISO/IEC 19790:2012(E), Information technology
AAA Authentication, Authorization and Accounting AES Advanced Encryption Standard CA Certification Authority CBC Cipher Block Chaining CCCS Canadian Centre for Cyber Security CFB Cipher Feedback CM7 Senetas Encryptor Remote Management Application Software CI Connection Identifier (used interchangeably with Tunnel) CLI Command Line Interface CMVP Cryptographic Module Validation Program CRNGT Continuous Random Number Generator Test CSE Communications Security Establishment CSP Critical Security Parameter CTR Counter Mode DEK Data Encrypting Key(s) DES Data Encryption Standard DH Diffie-Hellman DRBG Deterministic Random Bit Generator ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm EFP Environmental Failure Protection EFT Environmental Failure Testing EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESV Entropy Source Validation ESV (P) Physical Entropy Source ESV (NP) Non-Physical Entropy Source FIPS Federal Information Processing Standard FTP File Transfer Protocol FTPS FTP Secure (FTP Over TLS) Gbps Gigabits per second GCM Galois Counter Mode GDK Group Derivation Key HMAC Keyed-Hash Message Authentication Code IP Internet Protocol IV Initialization Vector KAS-ECC Elliptic Curve Key Agreement Scheme (ECDH) KAS-FCC Finite Field Key Agreement Scheme (DH) KAT Known Answer Test KDF Key Derivation Function KDK Key Derivation Key
KEM Key Encapsulation Method KID Key ID KEK Key Encrypting Key(s) KMIP Key Management Interoperability Protocol KMS Key Management Service LED Light Emitting Diode MAC Media Access Control (Ethernet source/destination address) Mbps Megabits per second NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program OAEP Optimal Asymmetric Encryption Padding OQS Open Quantum Safe PKCS Public Key Cryptography Standards PSP Public Security Parameter PUB Publication QKD Quantum Key Distribution QRA Quantum Resistant Algorithms RAM Random Access Memory RFC Request for Comment ROM Read Only Memory RNG Random Number Generator RSA Rivest Shamir and Adleman Public Key Algorithm RTC Real Time Clock SAN Storage Area Network SDRAM Synchronous Dynamic Random Access Memory SFP Small Form-factor Pluggable (transceiver) SFTP SSH File Transfer Protocol SID Sender ID SMC Gemalto’s Network Security Management Center SME Secure Message Exchange SMK System Master Key SP Special Publication SPB Shortest Path Bridging SHA Secure Hash Algorithm SSH Secure Shell SSP Sensitive Security Parameter TACACS+ Terminal Access Control Access Control Server TIM Transport Independent Mode TLS Transport Layer Security TRANSEC TRANsmission SECurity (also known as Traffic Flow Security or TFS) X.509 Digital Certificate Standard RFC 2459
The module meets the overall Security Level 3 requirements for FIPS 140-3. See Table 1 below, which indicates the security level of each of the twelve sections of the FIPS 140-3 standard. Table 1 Security Levels ISO/IEC 24759 Section 6 FIPS 140-3 Section Title Security Level [Number Below]
2. Cryptographic Module Specification CN Series Encryptors are Hardware cryptographic modules. The CN6000 Series and CN9000 Series outer casing defines the cryptographic boundary aside from the pluggable transceivers, dual redundant power supplies and replaceable fan tray module that lie outside the cryptographic boundary. The CN4000 Series outer casing defines the cryptographic boundary aside from the pluggable transceivers on the CN4020 and the “AC to DC” plug-pack adapter which lie outside the cryptographic boundary. The cryptographic boundary is depicted by the red dashed line in Figure 1 below. CN6000/9000 Series Dual CN4000 Series Power Power Input input Power/Cooling Dual Fan Power Power +12V System Tray Supply A Supply B AC/DC Power Distribution and Fan Control High Speed Crypto Management System System Entropy Source Firmware Common Library Cryptographic CPU Cryptographic Algorithms Algorithms Tamper Optical Optical Transceiver/s Transceiver/s Keypad Emergency 8P8C 8P8C (CN6000/ LEDs Erase (mag) (mag) Management Ports CN9000 Button Series) Cryptographic Boundary Local Port/s Network Port/s Management Management Connection to protected Connection to Ethernet Console network unprotected network SNMPv3 RS232 Figure 1 Cryptographic Boundary Block Diagram
CN Series Encryptors, with firmware versions 5.5.0 and 5.5.1, provide data privacy and access control services for Ethernet networks. See model details summarized in Table 2.
Table 2 Cryptographic Module Tested Configuration Distinguishing Features Model Hardware Firmware Name Versions Power Interface / Protocol Transceiver/ Versions Connector A4010B [O]1,2 1G Ethernet 5.5.0 and CN4010 A4010B [Y]1,2 DC RJ45 1G TIM 5.5.1 A4010B [T]1,2 A4020B [O]1,3 1G Ethernet 5.5.0 and CN4020 A4020B [Y]1,3 DC SFP 1G TIM 5.5.1 A4020B [T]1,3 A6010B [O]1,4 A6010B [Y]1,4 AC A6010B [T]1,4 A6011B [O]1,4 1G Ethernet 5.5.0 and CN6010 A6011B [Y]1,4 DC RJ45, SFP 1G TIM 5.5.1 A6011B [T]1,4 A6012B [O]1,4 A6012B [Y]1,4 AC/DC 1,4 A6012B [T] A6100B [O]1,4 A6100B [Y]1,4 AC A6100B [T]1,4 A6101B [O]1,4 10G Ethernet 5.5.0 and CN6100 A6101B [Y]1,4 DC XFP 10G TIM 5.5.1 A6101B [T]1,4 A6102B [O]1,4 A6102B [Y]1,4 AC/DC A6102B [T]1,4 A6110B [O]1,4 A6110B [Y]1,4 AC 1,4 A6110B [T] 1G Ethernet A6111B [O]1,4 1G TIM CN6110 A6111B [Y]1,4 DC RJ45, SFP+ 5.5.0 and 10G Ethernet 5.5.1 A6111B [T]1,4 10G TIM A6112B [O]1,4 A6112B [Y]1,4 AC/DC A6112B [T]1,4 A6140B [O]1,4 1G Ethernet
A6140B [Y]1,4 AC 1G TIM SFP+ 5.5.1 A6140B [T]1,4 10G Ethernet
Distinguishing Features Model Hardware Firmware Name Versions Power Interface / Protocol Transceiver/ Versions Connector A6141B [O]1,4 10G TIM CN6140 A6141B [Y] 1,4 DC 4x10G Ethernet A6141B [T]1,4 A6142B [O]1,4 A6142B [Y]1,4 AC/DC A6142B [T]1,4 A9100B [O]1,5 A9100B [Y]1,5 AC 1,5 A9100B [T] A9101B [O]1,5
CN9100 A9101B [Y]1,5 DC 100G Ethernet CFP4 5.5.1 A9101B [T]1,5 A9102B [O]1,5 A9102B [Y]1,5 AC/DC A9102B [T]1,5 A9120B [O]1,6 A9120B [Y]1,6 AC A9120B [T]1,6 A9121B [O]1,6
CN9120 A9121B [Y]1,6 DC 100G Ethernet QSFP28 5.5.1 A9121B [T]1,6 A9122B [O]1,6 A9122B [Y]1,6 AC/DC 1,6 A9122B [T] Note 1: Model variants distinguished by [O], [Y] and [T] are identical except for logos on the front fascia: [O] Denotes Senetas Corp. Ltd. sole branded version [Y] Denotes Senetas Corp. Ltd. & SafeNet co-branded version [T] Denotes Senetas Corp. Ltd. & Thales SA co-branded version Note 2: These models derive their power from an “AC to DC” plug-pack adapter which is considered to be outside the cryptographic boundary. Note 3: These models support pluggable SFP transceivers and derive their power from an “AC to DC” plug-pack adapter all of which are considered to be outside the cryptographic boundary. Note 4: These models support pluggable SFP transceivers, dual power supplies and removable fan tray which are considered to be outside the cryptographic boundary. Note 5: This model supports pluggable CFP4 transceivers, dual power supplies and removable fan tray which are considered to be outside the cryptographic boundary. Note 6: This model supports pluggable QSFP28 transceivers, dual power supplies and removable fan tray which are considered to be outside the cryptographic boundary.
Module Images CN4010 1G Ethernet Encryptor CN4020 1G Ethernet Encryptor CN6010 1G Ethernet Encryptor CN6100 10G Ethernet Encryptor CN6110 1/10G Ethernet Encryptor CN6140 1/10G Multi Port Ethernet Encryptor CN9100 100G Ethernet Encryptor CN9120 100G Ethernet Encryptor
Figure 2
Figure 5
Figure 8
General CN Series Encryptors operate in point-to-point and point-to-multipoint network topologies and at data rates ranging from 10Mb/s to 100Gb/s. Encryptors are typically installed between an operator’s private network equipment and public network connection and are used to secure data travelling over either fibre optic or CAT5/6 cables. Securing a data link that connects two remote office sites is a common installation application. Figure 11 provides an operational overview of two CN6010 encryptors positioned in the network. Figure 11
Devices establish one or more encrypted data paths referred to as `connections`. The term refers to a connection that has been securely established and is processing data according to a defined encryption policy. Each `connection` has a `connection identifier` (CI) and associated CI mode that defines how data is processed for each policy. Connections are interchangeably referred to as ‘tunnels’. CN Series Encryptors support CI Modes of ‘Secure’, ‘Discard’ and ‘Bypass’. These CI Modes can be applied to all data carried on a connection or to a selected subset or grouping which can be user configured in accordance the specific protocol being carried on the network connection. A typical example in the case of an Ethernet network would be to make policy decisions based upon an Ethernet packet’s VLAN ID. The default CI Mode negotiated between a pair of connected encryptors is `Discard`. In this mode user data is not transmitted to the public network. In order to enter `Secure` mode and pass information securely, each encryptor must be activated and `Certified` by a trusted body (refer to Section 2.3 for initial configuration steps) and exchange the key encrypting key (KEK) and initial data encryption key (DEK), using the RSA-OAEP-256 key transport process in accordance with SP 80056Brev2 Section
Encryptor deployment Figure 13 illustrates a point-to-point (or link) configuration in which each module connects with a single far end module and encrypts the entire bit stream. If a location maintains secure connections with multiple remote facilities, it will need a separate pair of encryptors for each physical connection (link). Figure 13
Administrator Guidance: Approved mode Full configuration instructions are provided in the User Guides [26]. Use the guidance here to constrain the configuration so that the device is not compromised during the configuration phase. This will ensure the device boots properly and enters FIPS 140-3 approved mode. When powering up the module for the first time, use the front panel or the CLI to configure the system for network connectivity. Then use the remote management application to initialize the module and perform the configuration operations.
Basic operation The Ethernet encryptor provides layer 2, 3 and 4 security services by encrypting the contents of data frames across Ethernet networks. The encryptor connects between a local (protected) network and a remote (protected) network across the public (unprotected) network. An encryptor is paired with one or more remote Ethernet encryptors to provide secure data transfer over encrypted connections as shown in Figure 15 below. Figure 15
Unicast operation Unicast traffic is encrypted using a key pair for each of the established connections. When operating in line mode there is just one entry in the connection table. When operating in multipoint mode, connection table entries are managed by MAC address or VLAN ID and can be added manually, or if ‘Auto discovery’ is enabled, they will be automatically added based on the observed traffic. Entries do not age and will remain in the table. Multipoint VLAN operation Multicast traffic between encryptors connected in line mode shares the same single key pair that is used by unicast traffic. VLAN encryption mode is used to encrypt traffic sent to all encryptors on a VLAN. Unlike unicast encryption (which encrypts traffic from a single sender to a single receiver and uses a unique pair of keys per encrypted connection), VLAN encryption within a multipoint network requires a group key management infrastructure to ensure that each encryptor can share a set of encryption keys per VLAN ID. The group key management scheme which is used for VLAN mode is responsible for ensuring group keys are maintained across the visible network. The group key management scheme is designed to be secure, dynamic and robust; with an ability to survive network outages and topology changes automatically. It does not rely on an external key server to distribute group keys as this introduces both a single point of failure and a single point of compromise. For robustness and security, a group key master is automatically elected amongst the visible encryptors within a mesh based on the actual traffic. If communications problems segment the network, the group key management scheme will automatically maintain/establish new group key managers within each segment. Figure 16
Figure 17
Optionally, a hybrid mode for session establishment is available in line with NIST guidance for use of both approved and quantum resistant key establishment/derivation methods. When operating in this mode, the approved methods may be augmented with both Quantum Resistant Algorithm methods, and/or Quantum Key Distribution mechanisms. Quantum Resistant Algorithms (QRA) The CN Series Encryptors support the use of candidate Quantum Resistant Algorithms as available from the Open Quantum Safe initiative. The user can select from a full list consisting of the RSA/ECDSA algorithms and the new OQS signing algorithms. The keys established using the approved RSA/ECDH algorithms are combined with data established using the Quantum Resistant Algorithms. Quantum Key Distribution (QKD) The CN Series Encryptors support the use of Quantum Key Distribution devices such as ID Quantique’s Cerberis QKD system or any industry standard ETSI compliant QKD systems for hybrid key establishment. For hybrid key establishment the keys distributed using the approved RSA/ECDH algorithms are combined with the data derived from the QKD server.
Traffic Analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. TRANSEC is TRANsmission SECurity and is used to disguise patterns in network traffic to prevent Traffic Analysis. TRANSEC mode can be optionally enabled between two end points of a point-point rate-limited layer 2 service provider network. When operating in TRANSEC mode (CN4000 and CN6000 Series only) transport frames exit the network port at a constant rate irrespective of the rate at which user data arrives at local port. This ensures that Traffic Analysis, if performed, would generate no useful insight into the user data. The transport frame rate and length are user configurable. AES encryption protects the user data and when operating in GCM encryption mode provides the additional guarantee of data authentication. TRANSEC mode coupled with AES-256 GCM provides triple layer protection of user data.
Figure 18
Table 3 lists approved software algorithms that are common to the CN Series Encryptors. These algorithms are used during the establishment of secure connections (SME), for management services (SNMPv3, TLS and SSH) and to generate and encrypt CSPs. Table 3 Approved Algorithms
used for key derivation A3451 dhEphem key agreement MODP-2048-bit Key Establishment KAS-FFC Oakley Group 149 SP 800-56Arev3 using SHA-256 for key derivation A3451 SHA-14 (BYTE only) Hashing SHA SHA-256 (BYTE only) FIPS 180-4 SHA-384 (BYTE only) SHA-512 (BYTE only) A3451 HMAC-SHA-15 Key Sizes Ranges Keyed Hashing Tested: KS<BS HMAC HMAC-SHA-256 FIPS 198-1 HMAC-SHA-384 HMAC-SHA-512 A3451 DRBG Hash_Based DRBG: [Prediction Random Number Resistance Tested: Not Enabled Generation SP 800-90Arev1 (SHA-256)] A3451 KBKDF Counter based KDF using HMAC- Key Derivation SHA-256 SP 800-108rev1 A3451 KTS-IFC RSA-OAEP-256 Key Transport6 Key Transport SP 800-56Brev2 A3451 KTS AES-2567 CFB key wrapping 256-bit Key Transport/ Key authenticated with HMAC-SHA-256 Wrapping FIPS 140-3 IG D.G A3451 SNMP KDF10 SHA-1 Key Derivation (CVL) SHA-256 SP 800-135rev1 A3451 TLS v1.2 KDF11 SHA-256 Key Derivation (CVL) RFC5246 SHA-384 TLS v1.2 KDF11 (CVL) RFC7627 SP 800-135rev1 A3451 SSH KDF12 (CVL) SHA-256 Key Derivation SP 800-135rev1 SHA-512 E51 ESV (P)13 256-bit Entropy source for DRBG SP 800-90B E49 ESV (NP)14 256-bit Entropy source for DRBG SP 800-90B Sections 5.1 & 5.2 - Asymmetric key Key Generation generation using unmodified DRBG output Section 6.1 - Direct generation of Key Generation symmetric key using unmodified CKG DRBG output Vendor Affirmed SP 800-133rev2 Section 6.2.1 - Symmetric keys Key Generation generated using ECDH key agreement in accordance with SP 800-56Arev3 (see KAS-ECC) Section 6.4 - Distribution of Key Transport generated symmetric key (see KTS) Note 1: Triple-DES is only used to decrypt CSPs when upgrading from legacy versions of software. The CSPs are subsequently reencrypted using AES-256 CFB. Triple-DES is no longer used by the module for encryption operations. Note 2: AES-ECB Is only validated as part of the AES-CTR validation. The mode is not actively used by the module. Note 3: The module does not generate RSA keys < 2048 for use in X.509v3 certificates in accordance with SP 800-131Arev2. Note 4: The module does not support the use of SHA-1 for X.509v3 certificate digital signatures in line with SP 800-131Arev2. Note 5: HMAC keys < 112 bits are non-compliant in line with SP 800-131Arev2. HMAC keys for SSL and TLS are a minimum of 160 bits. Note 6: Approved RSA-OAEP-256 key transport as per SP 800-56Brev2 Section 9 using 2048-bit keys (112-bit equivalent strength) with OAEP padding using SHA-256 can be employed to establish the AES 128- or 256-bit symmetric keys used to secure connections between cryptographic modules. Note 7: AES-256 key wrapping provides 256 bits of encryption strength and can be employed to establish the AES 128- or 256-bit symmetric keys used to secure connections between cryptographic modules.
Note 8: It is possible to configure an encryptor to use ECDH ephemeral key agreement with NIST P-256 (128-bit equivalent strength), P-
384 (192-bit equivalent strength) or NIST P-521 (256-bit equivalent strength) curves to establish AES 256-bit symmetric keys.
Only the use of P-521 will ensure that the established key maintains the full 256 bits of encryption strength. Note 9: Diffie-Hellman Key Agreement using 2048-bit Oakley Group 14 (112-bit equivalent strength) is employed to establish the AES 128-bit SNMPv3 privacy keys used to secure the management interface between the management application and the cryptographic module. Note 10: No parts of the SNMP protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Note 11: No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Note 12: No parts of the SSH protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Note 13: The CN4010, CN4020, CN6010, CN6110, CN6140, CN9100 & CN9120 models employ a physical entropy source. Note 14: The CN6100 employs a non-physical entropy source
Table 6 below lists approved firmware algorithms that are specific to the CN4010, CN4020, CN6010, CN6100, CN6110, CN6140, CN9100 and CN9120 hardware versions. These AES implementations are used to encrypt/decrypt data plane traffic. Table 6 Approved Algorithms
CN4010 Module Version 1.10
AES CTR (e) FIPS PUB 197, ECB1 (e) 128-bit A3458 Data Plane Encryption SP 800-38A 2 GCM (e/d; Internal IV , AAD=112 to 688) 256-bit SP 800-38D CN6110 Module Version 1.10
CN6140 Module Version 1.11
2.7.1.4 AES-GCM Key and IV generation for data-plane encryption (refer to Table 6 above)
The Senetas Secure Message Exchange (SME) protocol is used to establish secure connections between modules. The approved cryptographic algorithms employed by the SME protocol are listed in Table 7 below. Table 7 SME Cryptographic Algorithms Algorithm Type Algorithm RSA2 Authentication ECDSA1 ECDH1 Key Exchange RSA-OAEP AES-256-CFB Hash for HMAC SHA-256 SHA-256 ECDH KDF SHA-384 SHA-512 AES Key Wrap key (KEK & GEK) and HMAC key KDF HMAC-SHA256 (KBKDF) SHA-256 Signature SHA-384 SHA-512 AES-128-CFB AES-256-CFB AES-128-CTR Symmetric Encryption AES-256-CTR AES-128-GCM AES-256-GCM Note 1: ECDSA/ ECDH curves are restricted to NIST P-256, P-384 and P-521. Note 2: The module does not generate RSA keys < 2048 for use in X.509v3 certificates in accordance with SP 800-131Arev2.
The TLS protocol (version 1.2) is used for FTPS (firmware upgrades), RESTful interface and KMS (KeySecure). The approved cryptographic algorithms employed by the TLS protocol are listed in Table 8 and Table 9 below. Table 8 TLS Cryptographic Algorithms (FTPS, RESTful) OpenSSL1 Cipher Suite Authentication Key Symmetric Hash for HMAC2 Exchange Encryption ECDHE-ECDSA-AES256-GCM-SHA384 ECDSA3 ECDH3 AES-256-GCM4 SHA-384
ECDHE-ECDSA-AES128-GCM-SHA256 ECDSA ECDH AES-128-GCM SHA-256 ECDHE-ECDSA-AES256-SHA-384 ECDSA3 ECDH3 AES-256-CBC SHA-384
ECDHE-ECDSA-AES128-SHA-256 ECDSA ECDH AES-128-CBC SHA-256 Note 1: OpenSSL version 1.1.1n. Note 2: Minimum HMAC key size is 256 bits. Note 3: ECDSA/ ECDH curves are restricted to NIST P-256, P-384 and P-521. Note 4: The AES GCM IV is internally generated randomly in compliance with TLS 1.2 GCM Cipher Suites for TLS and Section 8.2.2 of SP 800-38D.
Table 9 TLS Cryptographic Algorithms (KMS) OpenSSL1 Cipher Suite Authentication Key Symmetric Hash for HMAC2 Exchange Encryption ECDHE-ECDSA-AES256-GCM-SHA384 ECDSA3 ECDH3 AES-256-GCM4 SHA-384
ECDHE-ECDSA-AES128-GCM-SHA256 ECDSA ECDH AES-128-GCM SHA-256 ECDHE-ECDSA-AES256-SHA-384 ECDSA3 ECDH3 AES-256-CBC SHA-384
ECDHE-ECDSA-AES128-SHA-256 ECDSA ECDH AES-128-CBC SHA-256 ECDHE-RSA-AES256-GCM-SHA384 RSA5 ECDH3 AES-256-GCM4 SHA-384 ECDHE-RSA-AES128-GCM-SHA256 RSA5 ECDH3 AES-128-GCM4 SHA-256
ECDHE-RSA-AES256-SHA-384 RSA ECDH AES-256-CBC SHA-384 ECDHE-RSA-AES128-SHA-256 RSA5 ECDH3 AES-128-CBC SHA-256 Note 1: OpenSSL version 1.1.1n. Note 2: Minimum HMAC key size is 256 bits. Note 3: ECDSA/ ECDH curves are restricted to NIST P-256, P-384 and P-521. Note 4: The AES GCM IV is internally generated randomly in compliance with TLS 1.2 GCM Cipher Suites for TLS and Section 8.2.2 of SP 800-38D. Note 5: Minimum RSA key size allowed is 2048 bits.
The SSH protocol (version 2.0) is used for Remote CLI and SFTP (firmware upgrades). The approved cryptographic algorithms employed by the SSH protocol are listed in Table 10 below. Table 10 SSH (for Remote CLI and SFTP) Cryptographic Algorithms Algorithm Type Algorithm Authentication ECDSA1 Key Exchange ECDH1 AES-256-CTR Symmetric Encryption AES-128-CTR SHA-1 Hash for HMAC SHA-256 SHA-512 Note 1: ECDSA/ ECDH curves are restricted to NIST P-256, P-384 and P-521.
The SNMPv3 protocol is used for Remote management. The approved cryptographic algorithms employed by the SNMPv3 protocol are listed in Table 11 below. Table 11 SNMPv3 (for remote management) Cryptographic Algorithms
Algorithm Type Algorithm HMAC-SHA1 Authentication HMAC-SHA256 Key Exchange DH1 AES-128-CFB Symmetric Encryption AES-256-CFB Note 1: MODP-2048-bit Oakley Group 14 using SHA-256 for key derivation. The Module does not implement any non-approved services when configured as per section 2.3.1 Administrator Guidance: Approved mode.
CN4010 Ports The CN4010 status LEDs and Emergency Erase Button are located on the module front panel. Status LEDs (8) Emergency Erase button Figure 19 - Front View of the CN4010 Encryptors The CN4010 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support electrical media in the form of RJ45 electrical physical ports. All other ports and interfaces are common to the CN4000 Series. Status LEDs (2) Ethernet Console RJ45 RJ45 Power Connector port & Local port Network ports USB Figure 20 - Rear View of the CN4010 Encryptor
CN4020 Ports The CN4020 status LEDs and Emergency Erase Button are located on the module front panel. Status LEDs (8) Emergency Erase button Figure 21 - Front View of the CN4020 Encryptor The CN4020 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support optical media in the form of SFP optical physical ports. All other ports and interfaces are common to the CN4000 Series. Status LEDs (2) Ethernet Console SFP SFP Power Connector Local & Network Ports USB Figure 22 - Rear View of the CN4020 Encryptor
CN6010 & CN6110 Encryptor Ports The CN6010 & CN6110 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support optical or electrical media in the form of RJ45 electrical physical ports or SFP (CN6010) or SFP+ (CN6110) optical physical ports. All other ports and interfaces are common to the CN6000 Series.
Emergency Erase button Status LEDs (4) LCD Management Ports Ethernet ports Serial console RJ45 CN6010 SFP RJ45 CN6110 SFP+ Keypad USB Local & Network Ports Figure 23 - Front View of the CN6010 & CN6110 Encryptor CN6100 Encryptor Ports The CN6100 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support optical media in the form of XFP optical physical ports. All other ports and interfaces are common to the CN6000 Series. Emergency Management Ports Status LEDs (4) Erase Button Ethernet Ports Serial Console XFP XFP LCD Keypad USB Local & Network Ports Figure 24 - Front View of the CN6100 Encryptor CN6140 Encryptor Ports The CN6140 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support optical media in the form of SFP+ optical physical ports. All other ports and interfaces are common to the CN6000 Series. Emergency Management Ports Status LEDs (4) Erase Button Ethernet Ports Serial Console LCD Keypad USB SFP+ (4) SFP+ (4) Local & Network Ports Figure 25 - Front View of the CN6140 Encryptor
CN6000 Series Encryptor Power Supplies and Fan Tray The CN6000 Series Encryptors support dual redundant power supplies which are available in two variants, an AC version for typical installs and a DC version for telecoms applications. Any power supply combination i.e. AC/AC, AC/DC or DC/DC is supported. Details of each can be seen in Figure 26. AC ON/OFF switch Power LED Power LED AC Power DC Power Fan Tray receptacle receptacle Figure 26 - Rear View: CN6000 Series Encryptor (pictured with AC & DC supplies installed)
CN9100 Encryptor Ports The CN9100 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support optical media in the form of CFP4 optical physical ports. All other ports and interfaces are common to the CN9000 Series. Status LEDs (4) Emergency LCD Erase Management ports button Ethernet ports Serial console CFP4 CFP4 Keypad USB Local & Network port Figure 27 - Front View of the CN9100 Encryptor CN9120 Encryptor Ports The CN9120 Encryptor’s Local and Network data ports, which provide connectivity between the secure and insecure network respectively, support optical media in the form of QSFP28 optical physical ports. All other ports
and interfaces are common to the CN9000 Series. Emergency Erase Management ports Status LEDs (4) LCD button Ethernet ports Serial console QSFP28 (2) Keypad USB Local & Network port Figure 28 - Front View of the CN9120 Encryptor CN9000 Series Encryptor Power Supplies and Fan Tray CN9000 Series Encryptors support dual redundant power supplies which are available in two variants, an AC version for typical installs and a DC version for telecoms applications. Any power supply combination i.e. AC/AC, AC/DC or DC/DC is supported. Details of each can be seen in Figure 29. AC ON/OFF switch Power LED (2) AC Power Supply DC Power Supply AC Power DC Power Fan Tray Receptacle Receptacle Figure 29 - Rear View: CN9000 Series Encryptor
Table 12 defines the CN Series interfaces and the mapping of the physical ports to the logical interfaces. Table 12 Ports and Interfaces Physical Port Logical Location Data that passes over the interface Interface1 CN4000 CN6000/ Series CN9000 Series RJ45 Management Control input Rear Front SNMPv3 Ethernet Remote CLI (SSH) Status output Upgrade image transfer via FTP/FTPS (TLS)/SFTP (SSH) RESTful I/F (TLS) KMS (TLS) RJ-45 RS-232 Console Control input Rear Front CLI Status output USB Control input Rear Front Upgrade image transfer Keypad Control input NA Front Navigation of LCD menu system and limited configuration input (Set IP address, Activation via CM7, USB upgrades) LCD Status output NA Front Displays configuration information in response to commands entered via the keypad. Also displays system information such as boot sequence and active alarm messages Power LED Status output Front Front Indicate powered state System LED Status output NA Front Indicate the system operational state Secure LED Status output Front/Rear Front Indicate the system secure state LAN LED Status output Front Front Indicate management LAN link status and activity Local LED Status output Front Front Indicate Local Port link status and activity Network LED Status output Front Front Indicate Network link status and activity Alarm LED Status output Front/Rear Front Indicate system alarm state Temperature LED Status output Front LCD Indicate temperature warning alarm Battery LED Status output Front LCD Indicate internal battery state Network Port Data input/output Rear Front The Network Port connects to the public network; access is
4. Roles, Services and Authentication The cryptographic module supports four administrative privilege levels: Administrator, Supervisor, Upgrader and Operator. The Administrator role is highest (least restricted) privilege level and is authorized to access all module services. FIPS140-3 defines two operator classes, the Crypto Officer, who is granted access to management functions and the User who obtains cryptographic services of the module. Crypto Officers would assume the role of either an Administrator, Supervisor or Upgrader whilst Users assume the role of an Operator.
The supported roles and services are summarized in Table 13.
Table 13 Roles, Service Commands, Input and Output Role Service Input Output Set Real Time Clock Time and Date New time and date Activation New administrator credentials Status Generate X.509v3 Certificate Certificate parameters CSR Signing Request Load X.509v3 Certificate Signed certificate Updated certificate table Create User Account User details and passwords Updated user table Modify User Account User details and passwords Updated user record Delete User Account User record index Updated user table View User Account User record index User record Set Global Mode (Bypass) Global mode setting –b (Bypass) Global Mode status View Global Mode Command Global Mode status Show Version Command Versioning info Clear Audit Trail Command Command status View Audit Trail Command Audit log Clear Event Log Command Command status View Event Log Command Event log Change FIPS mode status FIPS mode setting (on/off) Command status View FIPS mode status Command FIPS mode status Run Self-test (Reboot Command Self-test status Command) Administrator Install Firmware Upgrade Signed firmware upgrade image Updated firmware version (Crypto Officer) Establish FTPS (TLS) Session Session parameters Connection success/failure Establish SFTP (SSH) Session Session parameters Connection success/failure Re/Start Secure Connection Command Connection success/failure Erase Module
View User Account User record index User record View Global Mode Command Global Mode status Show Version Command Versioning info View Audit Trail Command Audit log View Event Log Command Event log View FIPS mode status Command FIPS mode status Operator Establish a Remote Session parameters Connection success/failure (User) Management (SNMP) Session Establish a Remote CLI (SSH) Session parameters Connection success/failure Session Establish RESTful HTTPS (TLS) Session parameters Connection success/failure Session Roles cannot be changed while authenticated to the module; however, the module permits multiple concurrent operators. While only one operator may connect to the Local Console at a time, multiple concurrent remote sessions are permitted. Remote management is not session oriented; thus, multiple operators may be issuing commands with each command processed individually as it is received by the module. In a meshed network the system architecture supports simultaneous interactions with many far end modules; the multiple users (remote modules) all sending data to the data input port. The module’s access control rules, system timing, and internal controls maintain separation of the multiple concurrent operators. The module does not support a maintenance role. Since there are no field services requiring removal of the cover, physical maintenance is performed at the factory. Note: A Crypto Officer should zeroize the module before it is returned to the factory. The module can be zeroized using several methods. When the module is powered on, the module can be zeroized by command or by performing the Erase key press sequence defined in the user guides [26]. An immediate erase can be achieved, powered or un-powered, by depressing the concealed front panel Emergency Erase button, accessed using a “paperclip” or other suitable tool. Refer to Section 3 for location on each of the models.
The module implements a bypass capability initiated by an authenticated user with sufficient privileges. Prior to application, the integrity of the current configuration is confirmed. After this the change is enacted by updating the static configuration and then enforcing the policy in the hardware data path controller. Bypass configuration is evident through policy configuration.
The module employs Identity-Based Authentication. Four operator privilege levels have been defined for use, Administrator, Supervisor, Upgrader and Operator with access rights as indicated in Table 14. Restricted Administrator privileges are available until the module is “Activated”. Activation ensures that the default Administrator password is changed and allows additional user accounts to be created. A user with Administrator privilege can further restrict the available privilege levels to Administrator and Operator by selecting “Simplified” user model from the CLI. Users with administrator privilege level can set a password change lockout period of between 0 (disabled) and 240 hours in which user’s passwords cannot be changed. This feature is intended to prevent a user from exhausting the password history and recycling a previously used password. The feature is disabled by default. Up to 30 user accounts with unique names and passwords may be defined for authorised operators (Administrators, Supervisors, Upgraders and Operators) of the module. Operators using the Local Console enter their name and password to authenticate directly with the module. Operators using the remote management application issue commands to the encryptor. Password based authentication is used between the management station and the module to authenticate each user. If the user is authenticated, then Diffie-Hellman Key Agreement is employed to establish secure AES SNMPv3 privacy keys allowing the transport of secure messages to and from the module. Commands from the remote management application are individually authenticated to ensure Data Origin Authentication and Data Integrity. Data Origin Authentication, based on the names and passwords, ensures the authenticity of the user claiming to have sent the command.
The strength of the authentication mechanisms is detailed in Table 14 Table 14 Roles and Authentication Role Authentication Authentication Strength Method Crypto Officers and Users accessing the module CLI, via the Local Console, must authenticate using a password that is at least 8 characters and at most 29 characters in length. The characters used in the password must be from the ASCII character set of alphanumeric and special (printable) characters. This yields a minimum of 948 possible combinations making the possibility of correctly guessing a password 1/948 which is far less than 1/ 1,000,000. Administrator (Crypto Officer) After three failed authentication attempts via the CLI, the Local Console Supervisor (Crypto Officer) port access is locked for 3 minutes. With the 3 minute lockout, the Identity-based possibility of randomly guessing a password in 60 seconds is 3/948 which Upgrader (Crypto Officer) is less than 1/100,000. Note: The module also suppresses feedback of authentication data, being Operator (User) entered into the Local Console, by returning * characters. Crypto Officers and Users using the Local Console present unique user names and passwords to log in to the CLI. Crypto Officers using the remote management application have unique identities embedded in the command protocol. Each issued command is individually authenticated.
CN Series Encryptors support the services listed in the following tables. The tables group the authorized services by the module’s defined roles and identify the Cryptographic Keys and SSPs associated with the services. The modes of access are also identified per the explanation. Legend for access rights column in Table 15: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A - Not Applicable. The module’s services are described in more detail in the CN Series User Guides. Once authenticated, the user has access to the services required to initialize, configure and monitor the module. With the exception of passwords associated with user accounts, the module user never enters Cryptographic Keys or SSPs directly into the module (an Administrator CO will enter passwords when working with user accounts). Approved Services The CN Series Encryptors support the approved services listed in Table 15. Table 15 Approved Services Service Description Approved Keys and/or SSPs Roles Access rights Indicator Security to Keys or Functions SSPs Set Real Time None None Administrator N/A N/A Clock Supervisor Activation RSA RSA Public Key Administrator G, R, E activation status SHA256 RSA Private Key G, E audit log CKG Authentication W AES-256 Password SMK E
Service Description Approved Keys and/or SSPs Roles Access rights Indicator Security to Keys or Functions SSPs Generate X.509v3 RSA X.509v3 Certificate, Administrator G, R command status Certificate Signing ECDSA RSA Public Key, event log Request AES-256 ECDSA Public Key CKG RSA Private Key, G ECDSA Private Key SMK E Load X.509v3 RSA X.509v3 Certificate, Administrator W certificate status Certificate ECDSA RSA or ECDSA audit log Public Key6 Create User AES-256 Authentication Administrator W command status Account SHA256 Password audit log SMK E Modify User AES-256 Authentication Administrator W command status Account SHA256 Password audit log SMK E Delete User None Authentication Administrator Z command status Account Password audit log View User None None Administrator N/A N/A Account Supervisor Upgrader Operator Set Global Mode SHA256 None Administrator N/A command status (Bypass) Supervisor audit log View Global Mode None None Administrator N/A N/A Supervisor Upgrader Operator Show Version None None Administrator N/A N/A Supervisor Upgrader Operator Show Status None None Administrator N/A N/A Supervisor Upgrader Operator Clear Audit Trail None None Administrator N/A N/A View Audit Trail None None Administrator N/A N/A Supervisor Upgrader Operator Clear Event Log None None Administrator N/A N/A View Event Log None None Administrator N/A N/A Supervisor Upgrader Operator Change FIPS None All Administrator Z command status mode status audit log View FIPS mode None None Administrator N/A N/A status Supervisor Upgrader Operator Run Self-test None None Administrator N/A N/A (Reboot Supervisor Command) Install Firmware RSA Firmware Upgrade Administrator E command status Upgrade9 SHA256 RSA Public Key Upgrader audit log Triple-DES10 SMK, AES-256 Authentication Passwords, Private Keys Establish FTPS CKG X.509v3 Certificate, Administrator R, E command status (TLS) Session TLS v1.2 TLS Public Key Upgrader event log KDF (CVL) TLS Private Key E RFC5246 TLS Key Exchange G, R, E TLS v1.2 Public Keys KDF (CVL) TLS Key Exchange G, E RFC7627 Private Keys Ref. Table 8 TLS Premaster G, E Secret, TLS Master Secret8 TLS Privacy Keys3, G, E TLS Integrity Keys SMK E Establish SFTP CKG SSH Public Key Administrator E, R command status (SSH) Session SSH Private Key Upgrader E event log
Service Description Approved Keys and/or SSPs Roles Access rights Indicator Security to Keys or Functions SSPs SSH KDF SSH Key Exchange G, R, E (CVL) Public Keys Ref. Table SSH Key Exchange G, E
SSH, Shared Secret8 G, E SSH Privacy Keys3, G, E SSH Integrity Keys SMK E Re/Start Secure CKG X.509v3 Certificate, Administrator R, W, E command status Connection Ref. Table 7 ECDSA Public Key, Supervisor event log RSA Public Key ECDSA Private Key E RSA Private Key SME ECDH Public G, R, E Key SME ECDH Private G, E Key SME ECDH Shared G, E Secret8 SME KDKs1,4. G, R, W, E GDKs5 KEKs1, G, E GEKs1, SME HMAC key TIM KDK E DEKs1 G, R, W, E SMK E Erase Module
Keys SNMPv3 Privacy G, E Key2 Establish a Connect to the CKG SSH Public Key Administrator E Login status Remote CLI (SSH) CLI via SSH SSH KDF SSH Key Exchange Supervisor G, R, E Session (CVL) Public Keys Upgrader Ref. Table SSH Key Exchange Operator G, E
SSH Shared Secret G, E SSH Privacy Keys3, G, E SSH Integrity Keys Establish RESTful CKG X.509v3 Certificate, Administrator R, E HTTPS Connection HTTPS (TLS) TLS v1.2 TLS Public Key Supervisor status Session KDF (CVL) TLS Private Key Upgrader E RFC5246 TLS Key Exchange Operator G, R, E TLS v1.2 Public Keys KDF (CVL) TLS Key Exchange G, E RFC7627 Private Keys Ref. Table 8 TLS Premaster G, E Secret, TLS Master Secret8 TLS Privacy Keys3, G, E TLS Integrity Keys SMK E KeyVault Sign Sign an RSA RSA or ECDSA Administrator E operation output (X.509v3 X.509v3 CSR ECDSA Private Key audit log Certificate Signing SMK Request) KeyVault Encrypt Encrypt a RSA RSA Public Key Administrator E operation output base64url encoded 32 byte block of plaintext.
Service Description Approved Keys and/or SSPs Roles Access rights Indicator Security to Keys or Functions SSPs KeyVault Decrypt Decrypt a RSA RSA Private Key, Administrator E operation output base64url SMK encoded 32 byte block of ciphertext KeyVault DRBG Output a 32 DRBG DRBG Entropy Input Administrator E operation output Access byte block of and Nonce, random data DRBG Seed, from the DRBG V and C DRBG KeyVault Backup Create AES256- RSA Private/ Public Administrator R operation output PKCS12 CBC Key audit log backup of HMAC- ECDSA Private/ public and SHA256 Public Key private keys Password E KeyVault Restore Restore AES256- RSA Private/ Public Administrator W operation output PKCS12 CBC Key audit log backup of HMAC- ECDSA Private/ public and SHA256 Public Key private keys Password E Enable KeySecure Enable CKG X.509v3 Certificate, Administrator R, E operation output KeySecure TLS v1.2 TLS Public Key audit log connector KDF (CVL) TLS Private Key E (Ref. Section RFC5246 TLS Key Exchange G, R, E 9.3.5) TLS v1.2 Public Keys KDF (CVL) TLS Key Exchange G, E RFC7627 Private Keys Ref. Table 8 TLS Premaster G, E Secret, TLS Master Secret TLS Privacy Keys3, G, E TLS Integrity Keys SMK_Local G, E SMK_Mask W, E SMK_CSP G, E Generate TIM DRBG TIM Key Derivation Administrator G, R operation output KDK Key (KDK) audit log DRBG Entropy Input E and Nonce, DRBG Seed, DRBG V and C Note 1: Starting/Restarting a secure connection causes new SME KDK, GDKs, KEKs, DEKs, GEKs and SME HMAC keys to be generated. Note 2: AES SNMPv3 Privacy keys are established using Diffie-Hellman when an SNMPv3 remote management session is initiated and used to encrypt and decrypt all subsequent directives. The DH modulus size is set to a minimum of Oakley group 14 (2048 bits) in SNMP. Note 3: If the firmware upgrade image is being transferred via SFTP then SSH Privacy Keys are established using ECDH. If the firmware upgrade image is being transferred via FTPS then TLS Privacy Keys are established using ECDH. When a remote CLI session is established SSH Privacy Keys are established using ECDH. Note 4: SME KDKs are established using Approved RSA-OAEP-256 key transport as per SP 800-56Brev2 Section 9. Note 5: GDKs are established using ECDH key agreement. Note 6: The Load X.509 Certificate service can access any RSA or ECDSA Public/Private keys that are associated with the certificate being loaded. The RSA key size in a certificate is checked when the certificate is loaded onto the module. If the key size is below 2048 bits, the certificate will be rejected. Note 7: All key material is sourced from the SP 800-90Arev1 DRBG and in accordance with FIPS 140-3 IG D.L, the entropy input string, seed and state variables V and C are considered CSPs. Note 8: The firmware upgrade image’s signature is checked prior to installation. Note 9: Triple-DES is only used to decrypt CSPs when upgrading from legacy versions of software. The CSPs are subsequently re-encrypted using AES-256 CFB. Triple-DES is no longer used by the module for encryption operations.
A 32-byte SHA-256 hash is used for each firmware component to verify the integrity of all components within the cryptographic module when the module is powered up, during the periodic test and on demand. The original hash calculation is performed, for each module within the system, at firmware build time. The hash values are then maintained within the system. During the self-tests, the hash calculation is performed again for each module and compared with the stored values that were generated at build time. Any discrepancy will cause the self-test to fail and the module will transition to the Secure Halt state. Refer to Section 10 for further information. On Demand Software/Firmware Integrity Test The user can execute the Software/Firmware integrity test on demand by issuing the reboot command.
6. Operational Environment Not Applicable. The operational environment of the module does not provide access to a general-purpose operating system (OS). The module employs a limited operational environment. Only signed and authenticated firmware upgrade images that pass the firmware load test can be installed on the module by authorised users.
CN Series Encryptors have a multiple-chip standalone embodiment and employ the following physical security mechanisms:
Figure 31
Figure 32
While the physical security mechanisms protect the integrity of the module and its keys and SSPs, it is strongly recommended that the cryptographic module be maintained within a physically secure, limited access room or environment. Table 16 outlines the recommended inspection practices and/or testing of the physical security mechanisms. Table 16 Physical Security Inspection Guidelines Physical Security Mechanism Recommended Frequency of Inspection/Test Guidance Details Inspection/Test Tamper Evidence In accordance with the organization’s Tamper indication is available to all user roles via the Security Policy. physical evidence of tampering against the tamper evident seals. The Crypto Officer is responsible for the physical security inspection. Inspect the enclosure and tamper evident seals for physical signs of tampering or attempted access to the cryptographic module. Tamper Circuit No direct inspection or test is required; The module enters the tampered state when the circuit is triggering the circuit will block all data flow. triggered. Once in this state, the module blocks all user traffic until the module is re-activated and re-certified. It is recommended that the module’s alarm table is reviewed on a daily basis. Tamper indication is available to all users via the alarm mechanism. During normal operation, the Secure LED is illuminated green. When the unit is not activated and/or uncertified (i.e. it has no loaded certificate since it is either in the default factory manufactured state or a user erase operation has been executed) or in the tampered state, the Secure LED is illuminated red and all traffic is blocked.
Environmental Failure Protection is implemented in the CN Series Encryptors for both temperature and voltage. The internal temperature and main 12VDC input voltage are constantly monitored and if the sensed values exceed the critical thresholds the encryptor will shutdown. The critical thresholds are given in Table 17 below. Table 17 Environmental Failure Protection/Testing Measurement EFP/EFT Action (Shutdown or Zeroization) CN4010 Internal Low Temperature (oC) 15 EFP Shutdown
CN6100 Low Temperature (oC) 5 EFP Shutdown High Temperature (oC) 80 EFP Shutdown Low Voltage (V) 10.2 EFP Shutdown High Voltage (V) 13.8 EFP Shutdown CN6110 Low Temperature (oC) 10 EFP Shutdown High Temperature (oC) 80 EFP Shutdown Low Voltage (V) 10.2 EFP Shutdown High Voltage (V) 13.8 EFP Shutdown CN6140 Low Temperature (oC) 10 EFP Shutdown High Temperature (oC) 80 EFP Shutdown Low Voltage (V) 10.2 EFP Shutdown High Voltage (V) 13.8 EFP Shutdown CN9100 Low Temperature (oC) 10 EFP Shutdown High Temperature (oC) 85 EFP Shutdown Low Voltage (V) 10.2 EFP Shutdown High Voltage (V) 13.8 EFP Shutdown CN9120 Low Temperature (oC) 10 EFP Shutdown High Temperature (oC) 85 EFP Shutdown Low Voltage (V) 10.2 EFP Shutdown High Voltage (V) 13.8 EFP Shutdown
The CN Series Encryptor’s enclosures were tested across the temperature ranges detailed in Table 18. No perceptible deformation or change to the enclosure’s integrity occurred during testing. Table 18 Hardness Testing Temperature Ranges CN4000 Hardness tested temperature measurement Low Temperature (oC) -20 High Temperature (oC) +80 CN6000 Low Temperature (oC) -20 High Temperature (oC) +80 CN9000 Low Temperature (oC) -20 High Temperature (oC) +80
8. Non-Invasive Security This section is not applicable. There are currently no approved non-invasive mitigation techniques referenced in SP 800-140F.
9. Sensitive Security Parameter Management
The following table identifies the Cryptographic Keys and Sensitive Security Parameters (SSPs) employed within the module. Table 19 SSPs Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export System Master 256-bit AES-CFB Internal N/A N/A Persistently stored
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export RSA Private Keys 2048-bit RSA SigGen Internal N/A N/A Persistently stored
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export SME ECDH P-256 ECDH Internally generated using SP N/A N/A Stored ephemerally
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export Authentication 8-29 N/A N/A External N/A AES-256-bit
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export Data Encrypting 128-bit AES-CFB Internal Approved Approved Stored ephemerally
256 key wrapping KEK authenticated with HMAC-
AES A3439 SHA-256. AES A3440 Provided by For each ECC based connection a pair of AES A3441 an external encryptors use ECDH KAS to establish DEKs. KMIP Key AES A3442 Server AES A3443 In Transport Independent Mode each encryptor uses a single egress DEK to encrypt AES A3444 all secure traffic. Each encryptor maintains 2 egress DEKs one in current use and one AES A3445 stored for the next key update. The egress AES A3446 DEKs are updated every hour. AES A3447 AES A3448 AES A3458 AES A3459 AES A3460 AES A3492 AES A3549 TIM KDK (CSP) 256-bit KBKDF Internal Distributed N/A AES-256-bit
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export Group 256-bit AES-CFB Internal N/A N/A Stored ephemerally
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export SNMPv3 Diffie 2048-bit DH N/A N/A Diffie- Stored ephemerally
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export SSH Public Key P-256 ECDSA SigVer Internal Loaded N/A Stored persistently
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export TLS Private Key P-256 RSA SigGen External Loaded N/A Persistently stored
Key/SSP Name/ Strengt Security Generation Import/ Establish- Storage Zeroisation Use & Related Keys Type h Function and ment Cert. Number Export TLS Privacy Keys 128-bit AES-CBC Derived from the TLS Master N/A N/A Stored ephemerally
Entropy CN4010, CN4020, CN6010, CN6110, CN6140, CN9100 & CN9120 The CN4010, CN4020, CN6010, CN6110, CN6140, CN9100 & CN9120 models employ a hardware based (physical) true random number generator (RNG) that has been validated for compliance with SP 800-90B. Based on noise source testing and analysis, the estimated minimum amount of entropy per output bit is 1.0 bits. The overall amount of generated entropy meets the required security strength of 256 bits based on the entropy per bit and the amount of entropy requested by the module. Table 20 Non-Deterministic Random Number Generation Specification CN4010, CN4020, CN6010, CN6110, CN6140, CN9100 & CN9120 Entropy Sources Minimum number of bits of Details entropy ESV #E51 256 bits The module employs a hardware based random bit generator Entropy CN6100 The CN6100 employs a software based (non-physical) true random number generator (RNG) that has been validated for compliance with SP 800-90B. Based on testing and analysis, the estimated minimum amount of entropy per output bit is 1.0 bits. The overall amount of generated entropy meets the required security strength of
256 bits based on the entropy per bit and the amount of entropy requested by the module.
Table 21 Non-Deterministic Random Number Generation Specification CN6100 Entropy Sources Minimum number of bits of Details entropy ESV #E49 256 bits The module employs a software based random bit generator
Zeroization of cryptographic Keys and CSPs is a critical module function that can be initiated by a Crypto Officer or under defined conditions, carried out automatically. Zeroization is achieved using the “Zeroization sequence” defined in Section 9.3.1 below. Crypto Officer initiated zeroization will occur immediately when the:
• Zeroizes the System Master Key rendering the RSA and ECDSA Private Keys, TIM KDK, User passwords and other CSPs (Certificates, RSA public keys) indecipherable • Deletes all Certificate information • Deletes RSA and ECDSA Private and Public keys, TIM KDK, module Configuration and User passwords • Automatically REBOOTs the module destroying KEKs, DEKs, Privacy and Diffie Hellman keys residing in volatile system memory Erase command and key press sequence A Crypto Officer can initiate a module Erase remotely using the remote management application or when physically in the presence of the module using the management console CLI interface or Front Panel key press Erase sequence. Zeroization of the module Keys and CSPs is achieved using the zeroization sequence as defined in Section 9.3.1. Tamper initiated zeroization Zeroization will be initiated immediately upon detection of a tamper event. The Tamper Circuit is active at all times; the specific tamper response differs slightly based on the module’s power state. From a practical standpoint the effect on the Keys and CSPs is the same. The tamper initiated zeroization process achieves the following:
KeySecure Connector integration (Split Key SMK) The CN Series Encryptors have the ability to communicate with SafeNet’s KeySecure key management system. When KeySecure is enabled and correctly configured the encryptor will still derive a local System Master Key (SMK_local) from the internal DRBG and store it in tamper protected memory. In addition, it will also obtain a System Master Key mask (SMK_mask) from the external KeySecure server. When the encryptor needs to encrypt or decrypt a CSP it will retrieve SMK_local and SMK_mask and combine them to create SMK_CSP which is used to perform the crypto operation. This feature allows centralised management of CSPs within a network of encryptors. Deleting SMK_mask in the KeySecure server will effectively destroy the CSPs in the encryptor. The KeySecure feature is disabled by default. Please note that throughout this Security Policy SMK can be used to refer to both the SMK and the SMK_CSP as they both perform the same function even though they have different generation methods.
To ensure user data privacy the module prevents data output during system initialization. No data is output until the module is successfully authenticated (activated) and the module certificate has been properly loaded. Following system initialization, the module prevents data output during the self-tests associated with a power cycle or reboot event. No data is output until all self-tests have completed successfully. The module also prevents data output during and after zeroization of data plane cryptographic keys and CSPs; zeroization occurs when the tamper circuit is triggered. In addition, the system’s underlying operational environment logically separates key management functions and CSP data from the data plane.
10. Self-tests CN Series Encryptors perform pre-operational, conditional and periodic self-tests to verify the integrity and correct operational functioning of the encryptor.
A set of pre-operational self-tests are executed during the power up sequence. The design of the CN Series cryptographic modules ensures that all data output, via the data output interface, is inhibited whenever the module is in a pre-operational self-test condition. Status information displaying the results of the self-tests is allowed from the status output interface. No CSPs, plaintext data, or other information, that if misused could lead to a compromise, is passed to the status output interface. The pre-operational self-tests are detailed in Table 22. Failure of the Software/Firmware integrity self-test will cause the module to transition to an error state and block all traffic on the data ports. Upon entering an error state an operator can attempt to clear the state by restarting the module. If the state cannot be cleared the module must be returned to the manufacturer. The SHA256 algorithm is tested using a known answer test prior to it being used for the Software/Firmware integrity self-test. Upon successful completion of the pre-operational self-tests the module will allow access via the CLI and remote management tools. The LCD will display a message stating that the self-tests passed. The data-plane ports will be enabled and normal operation will commence. Periodic Self-tests A subset of the pre-operational tests run periodically. The bypass/encrypt policy test, software/firmware integrity test are scheduled to run every 24 hours. The critical function tests run continuously. The action taken upon failure of a periodic self-test is context dependant. On demand Self-tests Crypto Officers can run the pre-operational self-tests on demand by issuing a module reboot command. This may be accomplished via the Local Console, or by cycling the power to the module. Use of the Local Console or power cycling the module requires a direct connection or physical access to the module respectively. Rebooting or power cycling the module causes the keys securing the configured connections to be re-established following the restoration of communications.
A set of conditional self-tests run when required. The action taken upon failure of a conditional self-test is context dependant. The conditional self-tests are described in Table 22 The conditional cryptographic algorithm known answer tests are run during the power up sequence. Failure of a cryptographic algorithm known answer test will cause the module to transition to an error state and block all traffic on the data ports. Upon entering an error state an operator can attempt to clear the state by restarting the module. If the state cannot be cleared the module must be returned to the manufacturer. Table 22 Self-tests Table Legend Halt (Secure) Behaviour: The module will enter a Secure shutdown state and Halt (“Secure Halt”). Thereby preventing the module being configured and passing any data over the Network data output interface. Recovery: Attempt to recover by power-cycle. If the Secure Halt condition persists the module cannot be recovered and must be returned to the factory. Indication: LEDs flashing red (all models) and alarm message on LCD (CN6000 and CN9000 Series) Erase Behaviour: The module will be Erased and reset to Factory Defaults. Recovery: Re-activate, certify and attempt to pass Network data. Error/Alarm Behaviour: Error/Alarm logged. System state unchanged Recovery: Observe carefully and re-attempt, if error persists check “User Guide”
Self-test Description Fault Pre-Operational Tests Performed at power-up Pre-Operational Software/ A 32-byte SHA-256 hash is used to verify the integrity of all components within the Halt Firmware Integrity cryptographic firmware when the module is powered up and on demand by issuing the reboot command. The SHA256 algorithm is tested using a KAT prior to the Software/Firmware integrity test running. Upon any file error the system will enter a Secure shutdown state and Halt (“Secure Halt”) Pre-Operational Bypass/Encrypt The Bypass/Encrypt Policy test ensures that the Bypass/Encrypt policy setting is observed Error Policy by the encryption datapath and that a frame cannot be spuriously transmitted in bypass (plaintext) when it should have been encrypted (and vice versa). In the event the test fails a log message will be generated and the global policy will be set to Discard. Pre-Operational Critical Function tests RTC/ Tamper Tamper memory is examined for evidence of a Tamper Condition. If the tamper event Halt cannot be cleared, indicating a persistent tamper state, the module transitions to the Secure Halt state Conditional Tests Performed, as needed, during operation Conditional Cryptographic Each cryptographic algorithm, employed by the encryptor, is tested using a “Known Algorithm Tests Answer Test” to verify the operation of the function.CN Series KATs are divided into 19 distinct modules which correspond to the common modules listed in Table 2 and firmware modules listed in Table 6. The cryptographic KATs are run during the power up sequence. CN Series Common Crypto The following CN Series Common Crypto Library algorithms are tested: AES128 CFB Halt Library encrypt, AES128 CFB decrypt, AES256 CFB encrypt, AES256 CFB decrypt, AES-CBC-
GCM-128 encrypt, AES-GCM-128 decrypt, AES-GCM-256 encrypt, AES-GCM-256 decrypt, Triple-DES168 decrypt, SHA-1, SHA-256, SHA-384, SHA-512, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, KDF CTR HMAC-SHA256, RSA2048 encrypt, RSA2048 decrypt, RSA4096 encrypt, RSA4096 decrypt, RSA-OAEP-SHA-256
Sign and Verify, ECDSA P-256, P-384, and P-521 (Sign and Verify and KAT), ECDH P256, P-384, and P-521 (primitive KAT), SP 800-90Arev1 DRBG KAT, Statistical, Instantiate, Reseed, Generate and Un-instantiate tests, ECDH (Cofactor) Ephemeral Unified Model SP 800-56Arev3, DH dhEphem 2048 MODP group SP 800-56Arev3, KDF-
Firmware Algorithms CN4010 1G Ethernet; AES CFB (e/d; 128, 256), CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN4010 TIM 1G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN4020 1G Ethernet; AES CFB (e/d; 128, 256), CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN4020 TIM 1G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6010 1G Ethernet; AES CFB (e/d; 128, 256), CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6010 TIM 1G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6100 10G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6100 TIM 10G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6110 1G Ethernet; AES CFB (e/d; 128, 256), CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6110 TIM 1G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6110 10G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6110 TIM 10G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6140 1G Ethernet; AES CFB (e/d; 128, 256), CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6140 TIM 1G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6140 10G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6140 TIM 10G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN6140 TIM 4x10G Ethernet; AES CTR (e/d; 128, 256) Halt CN9100 100G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt CN9120 100G Ethernet; AES CTR (e/d; 128, 256), GCM (e/d; 128, 256) Halt Entropy Related Health Tests The entropy source is tested using adaptive proportion and repeat count tests compliant Reboot with SP 800-90B Section 4.4 during the start-up sequence and then continuously. Conditional Bypass Tests Conditional Bypass Integrity The module supports alternating between Bypass, Discard and Encrypt modes (which can Erase be seen from the management interface). The configuration files that control the bypass/discard and encrypt settings are integrity checked using a stored checksum (32byte SHA-256 hash). Conditional bypass tests are enforced by checking the integrity during each process initialisation that memory maps specific configuration data. If the
Hash is valid, the process continues execution with that data, otherwise a re-initialisation is executed to failsafe values. Once running, a process will update the relevant configuration data when required, recalculating and storing the new hash value. Conditional Bypass/Encrypt The Bypass/Encrypt Policy test ensures that the Bypass/Encrypt policy setting is observed Error Policy by the encryption datapath and that a frame cannot be spuriously transmitted in bypass (plaintext) when it should have been encrypted (and vice versa). This test is performed after any change to policy. In the event the test fails a log message will be generated and the global policy will be set to Discard causing all data transmission to stop. Conditional Pair-wise RSA Public and Private keys are used for the calculation and verification of digital Discard Consistency signatures and for key transport. These keys are tested for consistency, based on their Key purpose, at the time they are used. RSA wrapping keys are tested by an encrypt/decrypt pair-wise consistency test; signature keys are tested by a sign/verify pair-wise consistency test. ECDSA Public and Private keys are used for the calculation and verification of digital signatures. These keys are tested at the time they are used with a sign/verify pair-wise consistency test. ECDH Public and Private keys are used for SP 800-56Arev3 approved key agreement. These keys are tested at the time they are used with a pair-wise consistency test. DH Public and Private keys are used for SP 800-56Arev3 approved key agreement. These keys are tested at the time they are used with a pair-wise consistency test. Conditional Software/Firmware When a new firmware image file is generated by the vendor, the file is encrypted and then Error Load signed with the firmware upgrade RSA private key. When any firmware load is applied to the encryptor in the field, the module verifies the authenticity of the firmware image file using its copy of the firmware upgrade RSA public key. Only firmware loads with a valid and verified firmware upgrade RSA signature are accepted. Conditional Critical Function Performed continuously Tests Battery The battery voltage is tested to determine if it is critically low. This test is guaranteed to fail Alarm prior to the battery voltage falling below the minimum specified data retention voltage for the associated battery-backed components. If this test fails, the battery low alarm condition is raised. The module continues to operate however it is advisable that the battery be replaced immediately. The battery is located in the removable fan tray and can be ordered from the module’s supplier. Battery alarm indication is available to all user roles via the alarm mechanism. Real Time Clock / Tamper The Real Time Clock (RTC) oscillator is checked at start-up and the Tamper memory is Reboot Memory examined continuously for evidence of a Tamper Condition.
11. Life-cycle Assurance This section provides information for Crypto Officers to install, configure and operate the CN Series Encryptors in FIPS mode. As outlined in this Security Policy, Crypto Officers (more specifically, Administrators and Supervisors) are the only administrators/operators that can make configuration changes or modify the system settings. The Crypto Officer is responsible for the physical security inspection. The CN Series is designed to operate in an approved mode. The operator can query the FIPS status (operating mode) of a module, and authorized operators may change the FIPS mode of operation. The FIPS status can be queried from the Local Console via the CLI or remotely via the remote management application. To ensure that no CSPs are accessible from a previous operating mode a module Erase and Reboot are automatically performed upon mode change. The console command is: > fips on<ENTER> The Senetas CM7 remote management application screen for reporting the FIPS status is found on the User Management screen, in the System pane under FIPS Mode. All of the versioning information is also displayed. Figure 33
Before the shipment proceeds a serial number is allocated for the ordered module. Prior to the module shipping, a Shipping Advice form listing the purchase order number, the model number, the serial number and date of shipment is sent to the purchaser. When the module is delivered, the CO can verify that the model and serial numbers on the outside of the packaging, the model and serial numbers attached to the encryptor itself, and the numbers listed on the Shipping Advice form, all match. The CO can also verify that the encryptor has not been modified by examining the tamper evident seal on the outside of the unit. If the seal is broken, then the integrity of the encryptor cannot be assured and the supplier should be informed immediately. Upon receipt of a CN Series Encryptor, the following steps should be undertaken:
The encryptor must be installed in a secure location to ensure that it cannot be physically bypassed or tampered with. Ultimately the security of the network is only as good as the physical security around the encryptor. Always maintain and operate the CN Series Encryptor in a protected/secure environment. If it is configured in a staging area, and then relocated to its operational location, never leave the unit unsecured and unattended. Ideally the encryptor will be installed in a climate-controlled environment with other sensitive electronic equipment (e.g. a telecommunications room, computer room or wiring closet). The encryptor can be installed in a standard 19inch rack or alternatively mounted on any flat surface. Choose a location that is as dry and clean as possible. Ensure that the front and rear of the encryptor are unobstructed to allow a good flow of air through the fan vents. The encryptor is intended to be located between a trusted and an untrusted network. The Local Interface of the encryptor is connected to appropriate equipment on the trusted network and the Network Interface of the encryptor is connected to the untrusted (often public) network. Depending on the topology of your network, the Local Interface will often connect directly to a router or switch, while the Network Interface will connect to the NTU provided by the network carrier.
As outlined in NIST SP 800-88 Revision 1; for secure destruction of networking devices at the end of their service life:
12. Mitigation of Other Attacks The CN4000 Series and CN6000 Series can be configured to mitigate against traffic analysis attacks on point-topoint connections using the TRANSEC feature. The module does not mitigate against any other specific attacks.
Traffic Analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. It can be performed even when the messages are encrypted and cannot be decrypted. TRANSEC is transmission security and is used to disguise patterns in network traffic to prevent Traffic Analysis. A TRANSEC enabled module exhibits the following encryption characteristics: