002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Model 650 SafeNet Encryptor FIPS 140-2 – Level 3 Validation Non-Proprietary Security Policy 002-010004-001 DOCUMENT NUMBER: Joseph Vohwinkel / Chris Brych AUTHOR: Program Management R&D DEPARTMENT: Belcamp, MD LOCATION OF ISSUE: May, 2009 DATE ORIGINATED: M REVISION LEVEL: June 12, 2014 REVISION DATE: L SUPERSESSION DATA: Non-Proprietary SECURITY LEVEL: © Copyright 2014 SafeNet, Inc. ALL RIGHTS RESERVED. This document may be freely reproduced and distributed whole and intact including this copyright notice. SafeNet, Inc. reserves the right to make changes in the product or its specifications mentioned in this publication without notice. Accordingly, the reader is cautioned to verify that information in this publication is current before placing orders. The information furnished by SafeNet, Inc. in this document is believed to be accurate and reliable. However, no responsibility is assumed by SafeNet, Inc. for its use, or for any infringements of patents or other rights of third parties resulting from its use. 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy PREFACE This document deals only with operations and capabilities of the Model 650 SafeNet Encryptor in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the Model 650 SafeNet Encryptor and other SafeNet products from the following sources:  The SafeNet internet site contains information on the full line of security products at http://www.safenet-inc.com/products/data-protection/  For answers to technical or sales related questions please refer to the contacts listed below or on the SafeNet internet site at http://www.safenet-inc.com/contact-us/ SafeNet Contact Information: 4690 Millennium Drive SafeNet, Inc. (Corporate Headquarters) Belcamp, Maryland 21017 USA Telephone: 410-931-7500 TTY Users: 800-735-2258 Fax: 410-931-7524 SafeNet Sales: (800) 533-3958 U.S. (410) 931-7500 International SafeNet Technical Support: (800) 545-6608 U.S. (410) 931-7520 International SafeNet Customer Service: (866) 251-4269 U.S. +44 (0) 1276 60 80 00 EMEA 852 3157 7111 APAC Document is Uncontrolled When Printed. Page 2 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy TABLE OF CONTENTS Section Title Page 1  Introduction ........................................................................................................................................... 5  1.1  Overview .......................................................................................................................................... 5  1.2  References ....................................................................................................................................... 5  1.3  Terminology ..................................................................................................................................... 6  1.4  FIPS Requirements .......................................................................................................................... 6  2  Model 650 SafeNet Encryptor .............................................................................................................. 7  2.1  Functional Overview......................................................................................................................... 7  2.2  Module Description .......................................................................................................................... 8  2.2.1  Enclosure Indicators Connectors and Controls ......................................................................... 9  2.2.1.1  Front Panel Physical Interfaces .................................................................................................. 10  2.2.1.2  Rear Panel Physical Interfaces ................................................................................................... 10  2.3  Security Functions.......................................................................................................................... 12  2.4  Modes of Operation........................................................................................................................ 14  2.4.1  FIPS Approved Mode .............................................................................................................. 14  2.4.2  Non-FIPS Approved Mode ...................................................................................................... 15  2.5  Identification and Authentication .................................................................................................... 15  2.5.1  Cryptographic Keys and CSPs ................................................................................................ 18  2.5.2  Roles and Services .................................................................................................................. 20  2.5.3  Access Control ........................................................................................................................ 23  2.6  Physical Security ............................................................................................................................ 24  2.7  Self-Tests ....................................................................................................................................... 26  3  Glossary of Acronyms, Terms and Abbreviations .......................................................................... 29  Document is Uncontrolled When Printed. Page 3 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy LIST OF TABLES Table Title Page Table 1.4-1 – Cryptographic Module Security Requirements ....................................................................... 6  Table 2.2-1 – Supported Models ................................................................................................................... 8  Table 2.2-2 – Cryptographic Module Logical Interfaces ............................................................................. 10  Table 2.2-3 – Mapping of Logical Interfaces to Physical Ports ................................................................... 11  Table 2.3-1 – Approved Module Algorithms................................................................................................ 12  Table 2.3-2 – Non-Approved Algorithms..................................................................................................... 13  Table 2.3-3 – Module Security Functions ................................................................................................... 13  Table 2.5-1 – Roles with Required Identification and Authentication ......................................................... 15  Table 2.5-2 – Strength of Authentication .................................................................................................... 17  Table 2.5-3 – Cryptographic Keys and CSPs ............................................................................................. 18  Table 2.5-4 – Roles and Services ............................................................................................................... 21  Table 2.5-5 – Access Control ...................................................................................................................... 23  Table 2.6-1 – Security Mechanism Inspection and Test ............................................................................. 26  Table 2.7-1 – Self-Tests .............................................................................................................................. 27  LIST OF FIGURES Figure Title Page Figure 2.1-1 – Encryptor Operation .............................................................................................................. 7  Figure 2.1-2 – Encryptor Usage in Path/Multi-Point Encryption Mode ......................................................... 7  Figure 2.1-3 – Encryptor Usage Example in Line/Link Encryption Mode ..................................................... 8  Figure 2.2-1 – Front View of Model 650 SafeNet Encryptor ......................................................................... 9  Figure 2.2-2 – Rear View of Model 650 SafeNet Encryptor.......................................................................... 9  Document is Uncontrolled When Printed. Page 4 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 1 Introduction 1.1 Overview This document is the Security Policy for the Model 650 SafeNet Encryptor manufactured by SafeNet, Inc. This Security Policy specifies the security rules under which the module shall operate to meet the requirements of FIPS 140-2 Level 3. It also describes how the encryptor functions in order to meet the FIPS requirements, and the actions that operators must take to maintain the security of the encryptor. This Security Policy describes the features and design of the encryptor using the terminology contained in the FIPS 140-2 specification. FIPS 140-2, Security Requirements for Cryptographic Modules specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The NIST/CSEC Cryptographic Module Validation Program (CMVP) validates cryptographic modules to FIPS 140-2. Validated products are accepted by the Federal agencies of both the USA and Canada for the protection of sensitive or designated information. The FIPS 140-2 standard, and information on the CMVP, can be found at http://csrc.nist.gov/groups/STM/cmvp/index.html. More information describing the Model 650 SafeNet Encryptor can be found at http://safenet-inc.com. This Security Policy defines the cryptographic module for multiple interface variants operating at 10 GBPS. These variants are functionally identical. This Security Policy contains only non-proprietary information. All other documentation submitted for FIPS 140-2 conformance testing and validation is “SafeNet - Proprietary” and is releasable only under appropriate non-disclosure agreements. 1.2 References Document No. Author Title FIPS PUB 140-2 NIST FIPS PUB 140-2: Security Requirements for Cryptographic Modules FIPS PUB 140-2 NIST FIPS 140-2 Annex A: Approved Security Functions Annex A FIPS PUB 140-2 NIST FIPS 140-2 Annex B: Approved Protection Profiles Annex B FIPS PUB 140-2 NIST FIPS 140-2 Annex C: Approved Random Number Generators Annex C FIPS PUB 140-2 NIST FIPS 140-2 Annex D: Approved Key Establishment Techniques Annex D DTR for FIPS PUB NIST Derived Test Requirements (DTR) for FIPS PUB 140-2, Security 140-2 Requirements for Cryptographic Modules NIST SP 800-67 NIST Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher FIPS PUB 186-2 NIST Digital Signature Standard (DSS) FIPS PUB 180-4 NIST Secure Hash Standard (SHS) SP 800-131A NIST Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths SP 800-90A NIST Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised) Document is Uncontrolled When Printed. Page 5 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy All of the above references are available at URL: http://csrc.nist.gov/groups/STM/cmvp/index.html. 1.3 Terminology In this document, the Model 650 SafeNet Encryptor is also referred to as “the module” or “the encryptor”. 1.4 FIPS Requirements The encryptor meets the overall requirements applicable for FIPS 140-2 Level 3 security as shown in Table 1.4-1. Table 1.4-1 – Cryptographic Module Security Requirements Security Requirements Section Level 3 Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles and Services and Authentication 3 Finite State Machine Model 3 Physical Security N/A Operational Environment 3 Cryptographic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance N/A Mitigation of Other Attacks 3 Cryptographic Module Security Policy Document is Uncontrolled When Printed. Page 6 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 2 Model 650 SafeNet Encryptor 2.1 Functional Overview The Model 650 SafeNet Encryptor provides data privacy and access control for connections between vulnerable public and private networks. It employs FIPS-approved AES and Triple-DES algorithms and, with the flexibility to choose the desired interface module, can be deployed in 10 Gigabit SONET or Ethernet networks. The encryptor can be centrally controlled or managed across multiple remote stations using SafeNet's Security Management Center (SMC), a SNMPv3-based security management system. The role of the encryptor is illustrated in Figure 2.1-1. The encryptor is installed between private network equipment and a public network. An encryptor communicates with other encryptors in the network, establishing secured connections between itself and the other modules. The encryptors selectively encrypt, zeroize, or pass in the clear, data flowing from the switch to the network. Conversely the encryptors selectively decrypt, reject, or pass information flowing from the network to the switch. Figure 2.1-1 – Encryptor Operation Secured connections are established between the cryptographic modules using the RSA key exchange process (as specified in the ATM Forum Security Specification version 1.1). This results in a separate secure session and does not require any secret session keys to ever be displayed or manually transported and installed. Figure 2.1-2 – Encryptor Usage in Path/Multi-Point Encryption Mode Figure 2.1-2 shows an example of three secured paths and one unsecured path between sites. Document is Uncontrolled When Printed. Page 7 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Figure 2.1-3 – Encryptor Usage Example in Line/Link Encryption Mode ENCRYPTOR SWITCH SITE 2 SWITCH / ADM * ENCRYPTOR SITE 1 / ADM * ENCRYPTOR SWITCH SITE 3 ENCRYPTOR / ADM * * ADM = Add/Drop Multiplexer Figure 2.1-3 shows an example of two secured sessions between sites. 2.2 Module Description The Model 650 SafeNet Encryptor is a multiple-chip standalone cryptographic module consisting of production-grade components contained in a physically protected enclosure in accordance with FIPS 140-2 Level 3. The module outer casing defines the cryptographic boundary. The steel case completely encloses the encryptor to protect it from tampering. Any attempt to remove the cover will automatically erase all sensitive information stored internally in the encryptor. Table 2.2-1 – Supported Models1 Model Configuration Shipped with 4.3 Field Upgraded to 4.3 SafeNet SONET OC 192, Dual DC 904-000028-001 904-53260-007 904-53261-007 Encryptor (SSE) OC192, Dual AC 904-000029-001 904-53260-207 904-53361-201 (RoHS) 10GBPS, Dual DC 943-53270-007 943-53271-007 SafeNet Ethernet Encryptor (SEE) 10GBPS, Dual AC 904-000036-001 943-53270-207 943-53371-201 (RoHS) The models have been tested with firmware version 4.3 and differ only in the enclosed line interface card containing the protocol specific cryptographic accelerators. The line interface card itself is not meant to be field serviceable. Any attempt to remove the interface will tamper the encryptor, erasing all sensitive information stored internally. While the line interface cards are not field-serviceable, the pluggable transceivers and hot swappable power supplies are. The pluggable transceivers and hot swappable power supplies are outside the cryptographic boundary and may be changed as needed for the specific requirements of the network infrastructure. Module management is provided out-of-band using the dedicated front panel Ethernet port or a console port. 1 The part numbers shown are based on the chassis, line card, and firmware installed. The underlying hardware is the same for the models field upgraded to 4.3. Document is Uncontrolled When Printed. Page 8 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 2.2.1 Enclosure Indicators Connectors and Controls The 650 series models share a common enclosure. Figure 2.2-1 shows the front view, which is common to all the 650 series models. The front panel provides a network management port, a console port, a USB port, an LCD display and LEDs for status, and a keypad for control input. Figure 2.2-1 – Front View of Model 650 SafeNet Encryptor Figure 2.2-2 – Rear View of Model 650 SafeNet Encryptor The encryptor has two network interfaces located in the rear of the module (Figure 2.2-2): the Local Port interface connects to a physically secure private network and the Network Port interface connects to an unsecure public network. The rear view is identical for the models except for the labeling on the line interface card. The labeling identifies the interface card as either SONET or Ethernet. Document is Uncontrolled When Printed. Page 9 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy The rear panel also contains network activity LEDs as well as status LEDs on the power supply units (DC variant shown). The height accommodates the dual power supplies. A tamper evident seal indicates movement of the module cover with respect to the module enclosure. 2.2.1.1 Front Panel Physical Interfaces  The RJ45 Ethernet port allows remote management from the SMC application. Access is protected by SNMPv3 security mechanisms for authentication and data encryption. This port is also on the same layer 2 LAN subnet as all other encryptors in the network.  The DB9 RS-232 serial console port connects to a local terminal and provides a command line interface for initialization prior to authentication and operation in the approved mode. This port also allows administrative access and monitoring of operations. Access is protected by user names and passwords.  The USB Port is reserved for updating the system firmware locally.  The keypad allows entry of initialization commands.  The LCD displays configuration information in response to commands entered using the front panel keypad and indicates the state of RSA keys and certificates.  The LEDs indicate the state of the system including alarms. 2.2.1.2 Rear Panel Physical Interfaces  The LEDs indicate network traffic.  The power connectors are used for power input to the module.  The Network Port connects to the public network via the transceiver’s rear panel public network connector. Access is protected by RSA certificates. The Local Port and Network Port are of the same interface type.  The Local Port connects to the private network via the transceiver’s rear panel local network connector. The Local Port and Network Port are of the same interface type. The logical interfaces consist of Data Input, Data Output, Control Input, and Status Output as follows: Table 2.2-2 – Cryptographic Module Logical Interfaces Logical Description Interface Data Input Local Port: Data Output  Connects to the private network via the transceiver, sending and receiving plaintext user data. Network Port:  Connects to the public network via the transceiver, sending and receiving cipher text and plaintext user data to and from a far end module.  Sends authentication data and RSA key exchange components to a far end module.  Receives authentication data, RSA key exchange components from a far end module.  The module can be set to bypass, to send and receive plaintext for the selected connection. Document is Uncontrolled When Printed. Page 10 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Logical Description Interface Control Input Control Input is provided by the front panel keypad, the serial port, the Ethernet Port (out- of-band control), the USB Port, and the Local and Network ports (in-band control) as follows:  The front panel keypad is used for initialization prior to authentication and operation in the approved mode. An operator uses the keypad to set the IP address for remote administration by SMC, set the system clock and load the certificate (in conjunction with the SMC).  The front panel DB9 RS-232 serial console port may be used for initialization prior to authentication and operation in the approved mode as an alternative to using the keypad. This port receives control input (protected via a username and password) from a locally connected terminal.  The front panel RJ45 Ethernet port receives out-of-band control input from the SMC application.  Session establishment, heartbeat messages and key update messages between encryptors travel on the layer 2 LAN subnet via the front panel RJ45 Ethernet port.  The front panel USB port, while shipped in a locked configuration, may be unlocked by the Crypto Officer and used to apply firmware updates to the encryptor. Status output Status output is provided by the LCD, front and rear panel LEDs, the Front Panel DB9 RS- 232 port, the Ethernet Port (out-of-band status), and the Local and Network ports (in-band status) as follows:  The LCD indicates the state of RSA keys and certificates and displays command data being entered using the front panel keypad.  Front and rear panel LEDs indicate error states, state of the local and network interfaces, alarm, temperature, and battery state.  The front panel DB9 RS-232 serial console port may be used for initialization prior to authentication and operation in the approved mode as an alternative to using the keypad. It is also used for monitoring some operations. This port sends status output (protected via a username and password) to a locally connected terminal.  The front panel RJ45 Ethernet port sends out-of-band status output information to an SMC application.  Local and Network ports may send in-band status output information, protected via the SNMPv3 security mechanisms, to the SMC application. Table 2.2-3 maps FIPS 140-2 logical interfaces to the cryptographic module’s logical interfaces and physical ports. Table 2.2-3 – Mapping of Logical Interfaces to Physical Ports FIPS 140-2 Logical Logical Interface Physical Port Interface Data Input 1) Public network interface 1) Rear panel Network Port 2) Private network interface 2) Rear panel Local Port Data Output 1) Public network interface 1) Rear panel Network Port 2) Private network interface 2) Rear panel Local Port Document is Uncontrolled When Printed. Page 11 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy FIPS 140-2 Logical Logical Interface Physical Port Interface Control Input 1) SNMPv3 interface 1) Front panel RJ45 Ethernet port 2) Local console 2) Front panel DB9 RS-232 serial console port 3) Keypad 3) Front panel Keypad 4) USB 4) Front panel USB port Status Output 1) SNMPv3 interface 1) Front panel RJ45 Ethernet port 2) Local console 2) Front panel DB9 RS-232 serial console port 3) Front Panel Display 3) Front panel LED Display Power Power Switch Rear panel power connectors The module prevents data output during initialization and self-test.  No data is output from the module until the self-tests complete successfully and the NC has been properly loaded into the module.  No data is output during and after zeroization of cryptographic keys and CSPs as this occurs when a tamper condition exists. The encryptor’s internal modules and timing controls work together to isolate user data input and output processes from CSP and key management functions. 2.3 Security Functions The module provides symmetric key encryption (AES) for user data transferred through the module. AES is also used to secure the remote management interface to the module. Asymmetric keys and SHA hashing are used to authenticate remote modules, and asymmetric keys are used to wrap symmetric keys for symmetric key exchange with other modules. Asymmetric keys and SHA hashing are used to authenticate management access, and Diffie-Hellman key agreement is used to establish symmetric keys for securing management interactions. To ensure maximum security, unique encryption keys are automatically generated for a connection only after the encryptor has positively identified and authenticated the remote module. The encryptor implements the following approved algorithms: Table 2.3-1 – Approved Module Algorithms Approved Algorithm 2092 Module 2093 Module SxE (SONET) (Ethernet) Cryptographic Library AES (FIPS PUB 197) 26162 ECB(e only; 256); CTR(int only; 256) ECB(e only; 256); CTR(int only; 256) 2617 CBC,(e/d; 128,256) 2619 Triple-DES (NIST SP 800-67) TECB (d only; KO 1); TCBC (e/d; KO 1); 1574 TCFB8 (e/d; KO 1); TCFB64 (e/d; KO 1) 2 AES certificate 2616 is for the 2093 Ethernet encryptor interface, AES certificate 2617 is for the 2092 SONET encryptor interface, and all remaining certificates are for the common library shared by both encryptors. Document is Uncontrolled When Printed. Page 12 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Approved Algorithm 2092 Module 2093 Module SxE (SONET) (Ethernet) Cryptographic Library Hashing (FIPS PUB 180-4) SHA-1, SHA-256 (byte oriented hashing) 2196 Keyed Hash (FIPS PUB 198-1) HMAC-SHA-13, HMAC-SHA-256 1620 Random Number Generation (NIST SP 800-90A) Hash_Based DRBG (SHA-256) 400 RSA (FIPS 186-2) Key Gen ANSI X9.31 / (MOD: 2048 | Pubkey Values: 65537) 1337 RSA PKCS#1 Sig Gen | 2048 | / Sig Ver | 1024, 2048 | SHA-1, SHA-256 CVL Key Derivation Function (NIST SP 800-135) SNMP V3 101 Table 2.3-2 – Non-Approved Algorithms 2082 2084 SxE Module Module Cryptographic Non-Approved Algorithms (SONET) (Ethernet) Library Digital Signatures (FIPS 186-2) Key Gen ANSI X9.31 / (MOD: 1024,| 1337 Pubkey Values: 65537) RSA PKCS#1 Sig Gen | 1024 | SHA-1 | NDRNG A hardware noise source is used as a non-Approved NDRNG to generate seed material (consisting of random sequences of ones and zeroes) for the FIPS-approved DRBG. The encryptor implements the following security functions: Table 2.3-3 – Module Security Functions Security Function Symmetric Key Encryption AES Triple-DES Symmetric Key Establishment RSA Key Wrapping (per ATM Forum Security Spec 1.1)4 Diffie-Hellman Key Agreement5 3 HMAC-SHA-1 uses a key of at least 112 bits in the FIPS Approved Mode. 4 Key transport, key establishment methodology provides 112 bits of encryption strength, non-compliant less than 112 bits. 5 Non-compliant less than 112 bits. Non-approved key establishment is equivalent to plaintext. Document is Uncontrolled When Printed. Page 13 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Security Function Authentication RSA asymmetric key 1024-bit with HMAC SHA-1 2048-bit with HMAC SHA-256 Key Generation Triple-DES/AES Keys – DRBG (per NIST SP 800-90A) RSA keys – ANSI X9.31 Key Derivation Function (KDF) SNMP V3 – NIST SP 800-135 2.4 Modes of Operation The module is shipped by the manufacturer with the FIPS approved mode of operation enabled. Each encryptor must have a unique Network Certificate (NC) issued under a common Security Management Center (SMC). During key exchange, communicating modules mutually authenticate one another by exchanging NCs in digitally-signed messages. The module cannot build a secure connection with a remote module that does not have a valid NC. Moreover, the module cannot establish any connections unless it has been issued a valid NC. This mode of operation requires a common SMC to issue NCs to all modules that will communicate securely. For backward interoperability, the module supports 1024-bit as well as 2048-bit Network Certificates. When establishing secure connections, the module will default to the 2048-bit certificate and SHA-256 hashing if a 2048-bit certificate is available. If there is no 2048-bit certificate, the module will fall back to the 1024-bit certificate and SHA-1 hashing for establishing secure connections. User data received from the local (private) network is encrypted before being transmitted out to the public network. Similarly, user data received from the public network is decrypted before being transmitted to the local network. When a secure connection is first created, the pair of encryptors exchange an encryption master key and session key. The master key is used for all subsequent session key exchanges. When operating in this state, the two ends of the connection are in cryptographic synchronization using the defined AES algorithm. Crypto officers can force a new master key by manually restarting a connection. An organization’s security policy dictates the frequency of forcing a new master key. Within a secure connection, the module encrypts all data received from the Local Port (the private network) and decrypts all data received from the Network Port (the public network). For each connection, the Connection Action Table can be set to encrypt, block, or pass data. The module supports configured encryption, blocking, or passing of user data as plaintext on a per-connection basis. The FIPS mode status may be queried from the management application or the console interface, and operators may run the power-on self-tests on-demand by power-cycling the module. Refer to the User’s Guide for more details concerning the module’s modes of operation. 2.4.1 FIPS Approved Mode The module ships with FIPS Mode enabled. FIPS Mode constrains several aspects of the module’s operation:  The privacy of the SNMPv3-based management interface is ensured with AES encryption; the privacy option cannot be disabled while in FIPS mode.  All the algorithms accessible to the module are approved algorithms as noted above. Non- approved algorithms cannot be specified for use. Document is Uncontrolled When Printed. Page 14 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy The FIPS mode of operation can be confirmed by logging into the console interface and using the fips command. It can also be confirmed by reviewing the device configuration from SMC. The module front panel SEC LED provides details about the operational configuration of the device, as detailed in the User’s Guide, but does not specifically indicate the FIPS Mode status of the module. FIPS Mode operation may be turned off as needed. When FIPS Mode operation is turned off, the SNMPv3 Privacy option may also be disabled; however, to turn FIPS Mode operation back on, SNMPv3 Privacy must first be re-enabled. When changing from FIPS Mode to non-FIPS Mode operation, a module erase and reboot is forced. This effectively zeroizes all keys and CSPs prior to the transition. 2.4.2 Non-FIPS Approved Mode Non-FIPS Mode operations follow the same general flow as FIPS Mode. The module must be certified; connections must be configured; the encryptors must authenticate to each other with NCs. When the module is set by a Crypto Officer to operate in non-FIPS approved mode, several aspects of the module’s operation are relaxed:  The SNMPv3-based management interface need not be encrypted; the SNMPv3 privacy feature may be disabled or enabled as needed. While SNMPv3 privacy may be disabled when FIPS Mode operation is turned off, the SNMPv3 Privacy must first be re-enabled before FIPS Mode operation can be turned back on. The non-approved algorithms are disabled within the module automatically, but FIPS Mode cannot be set if SNMPv3 privacy is disabled. When changing from non-FIPS Mode to FIPS Mode operation, a module erase and reboot is forced. This effectively zeroizes all keys and CSPs prior to the transition. 2.5 Identification and Authentication The module supports two Crypto Officer roles and a single Network User role. Services for the Crypto Officer roles (full access and read only) are accessible directly via the console or remotely via the SMC application. The Network User role services are only accessible indirectly based on the configured connections with other SafeNet encryptors. Roles cannot be changed while authenticated to the module. Access to the authorized roles is restricted as follows in Table 2.5-1: Table 2.5-1 – Roles with Required Identification and Authentication Role Type of Authentication Data Authentication Identity-based Crypto Officers using the CLI present unique user Crypto Officer (Full names and passwords to log in to the CLI. Access) Crypto Officers using SMC present unique identities (embedded in the SNMPv3 command protocol). Identity-based Crypto Officers using the CLI present unique user Crypto Officer names and passwords to log in to the CLI. (Read Only) Crypto Officers using SMC present unique identities (embedded in the SNMPv3 command protocol). Identity-based Network Users (remote Encryptors) must present a Network User certificate issued by the SMC. Document is Uncontrolled When Printed. Page 15 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Multiple concurrent Crypto Officers and Network Users are allowed. For example, a Network User may be sending data to the data input port while a Crypto Officer is connected via the console or sending an SNMPv3 command to the module. The architecture of the system allows for simultaneous interactions with many far end systems, or Network Users. Access control rules, system timing, and internal controls maintain separation of multiple concurrent Crypto Officers and Network Users. The module employs identity-based authentication of operators and users. Up to 30 unique names and passwords can be defined for operators of the module.  Crypto Officers using the console enter their name and password to authenticate directly with the module.  Crypto Officers using SMC to issue SNMPv3 commands to the Encryptor, use SNMPv3-based authentication to establish a secure connection / tunnel to the module. Within the secure tunnel, SNMPv3 commands are individually authenticated to ensure Data Origin Authentication, and Data Integrity for all commands sent from SMC. Data Origin Authentication, based on the above names and passwords, ensures the authenticity of the identity of the user claiming to have sent the command.  Users (Network Users) using the module cryptographic algorithms and security functions over the Data Input and Output ports authenticate using certificates that have been generated and signed by the SMC. These Network Users exchange master and session keys using RSA public key certificates that have been generated and signed by a common SMC. Physical Maintenance is performed at the factory, as there are no services that require the cover to be removed in the field. The module should be zeroized by a Crypto Officer before the module is returned to the factory, either by command or by removing the network interface card. Document is Uncontrolled When Printed. Page 16 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy The strength of the authentication, per the roles in Table 2.5-1, is as follows: Table 2.5-2 – Strength of Authentication Authentication Mechanism Strength of Mechanism Crypto Officers accessing the module using the CLI (via the Authentication Password console port) must authenticate using a password that is at least 8 characters and at most 30 characters. The characters used in the password must be from the ASCII character set of alphanumeric and special (shift-number) characters. This yields a minimum of 958 (over 5 quadrillion) possible  combinations (8 characters, 95 possibilities per character); thus, the possibility of correctly guessing a password is less than 1 in 1,000,000.  After three failed authentication attempts via the CLI, console port access is locked for 3 minutes; thus, the possibility of randomly guessing a password in 60 seconds is less than 1 in 100,000. Note: the module suppresses feedback of authentication data being entered into the CLI by returning blank characters. Authentication with SMC is accomplished via SNMPv3 and the Authentication from SMC Authentication Password described above.  Based on the noted characteristics of the password, the possibility of correctly guessing the authentication data is less than 1 in 1,000,000.  The multi-step handshaking process for establishing a connection and then issuing an authenticated command sets the possibility of randomly guessing the passphrase in 60 seconds at less than 1 in 100,000. Network Users must authenticate using a 1024-bit or 2048-bit Network User Certificates RSA authentication certificate based on a key of similar size.  The possibility of deriving a private RSA key is less than 1 in 1,000,000 and the possibility of randomly guessing the key in 60 seconds is less than 1 in 100,000.  The multi-step handshaking process for establishing a connection sets the possibility of randomly guessing the authentication data in 60 seconds at less than 1 in 100,000. Document is Uncontrolled When Printed. Page 17 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 2.5.1 Cryptographic Keys and CSPs Table 2.5-3 identifies the Cryptographic Keys and Critical Security Parameters (CSPs) employed within the module. Table 2.5-3 – Cryptographic Keys and CSPs Data Item Description On initialization, the module generates a 168-bit symmetric key that is System Master Key stored in the clear in battery-backed RAM.  This key encrypts (using 3-key Triple-DES CFB8) the module’s public and private RSA keys and the user table stored in the configuration flash memory.  On tamper or battery drain, the module zeroizes the System Master Key (SMK), rendering the encrypted data in the flash memory undecipherable. The secret component of the module’s RSA Key pair. RSA Private Key  This 1024-bit or 2048-bit key is generated when the module receives a load certificate command from the SMC, and is used to authenticate connections with other encryptors and to unwrap master session keys and session keys received from far-end encryptors.  This key is stored encrypted in flash memory.  On tamper, the SMK is zeroized, rendering the encrypted private key undecipherable. The public component of the module’s RSA Key pair is stored RSA Public Key encrypted in flash memory.  This key resides in the Network Certificate that in turn is stored in the clear in system non-volatile RAM.  This key is used for authenticating connections with other encryptors. Up to 30 passwords (and associated usernames) may be stored to Authentication Password allow access by up to 30 unique operators in the role of Crypto Officer (full access) or Crypto Officer (read only).  The CLI uses the authentication password to authenticate Crypto Officers accessing the system via the console port.  SNMPv3 concatenates and hashes (with SHA-1) the authentication password (8-30 characters) and the SNMPv3 unique engine ID to create an HMAC key used for Data Origin Authentication, and Data Integrity of each command.  Passwords and usernames are hashed and stored in the encrypted user table in flash memory.  On tamper, the SMK is zeroized, rendering the encrypted passwords undecipherable. Document is Uncontrolled When Printed. Page 18 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Data Item Description The Management Privacy Key (MPK) is the parameter that is used to Management Privacy Key secure data on the remote management channel. This parameter is essentially a key that is derived from a DH key exchange between the module and the remote management station.  The MPK persists for the life of the management session and is used to AES encrypt management traffic that may be exchanged between the module and the remote management station.  The MPK is maintained in volatile memory and may be updated periodically during the session.  The MPK is held only in volatile memory within the module, and is destroyed at the end of a remote management session or when power is removed. The erase, reboot, and tamper conditions will also destroy the remote management session. For each session, the module generates a symmetric Master Session Master Session Key Key (MSK) and Session Keys using the NIST SP 800-90 DRBG.  The MSK is used with RSA key exchange to transfer these keys to a far-end encryptor for data encryption and decryption purposes.  The MSK persists for the life of the session and is used to AES- encrypt session keys that may be changed periodically during the session.  The MSK is held only in volatile memory within the module, and is destroyed at the end of a remote management session or when power is removed. The erase, reboot, and tamper conditions will also destroy the remote management session. For each session the module generates two Session Keys (SKs) for Session Keys each data flow path in a secure connection (one for the Initiator- Responder path and another for the Responder-Initiator path).  These keys are used to AES-encrypt user data transferred between encryptors.  SKs may be changed periodically during the session based on time or based on the amount of data transferred.  All SKs are held only in volatile memory within the module, and are destroyed at the end of a remote management session or when power is removed. The erase, reboot, and tamper conditions will also destroy the remote management session. The Network Certificate (NC) is the X.509v3 certificate associated with Network Certificate the module in an operational environment.  The NC is produced and signed by the managing SMC system, then stored in the clear in the module’s non-volatile system RAM and used for authenticating connections with other encryptors.  Other encryptors use the public key embedded in the NC to wrap initial SKs used to encrypt a session with AES.  The NC is deleted from memory only on an Erase command from a module operator or a tamper condition. The Firmware Update Certificate is a hard coded RSA 1024 bit public Firmware Update key that is used to verify firmware that is to be updated. Certificate Document is Uncontrolled When Printed. Page 19 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Data Item Description 440 bit random value DRBG Seed  The DRBG Seed is a one-time volatile value that is not stored in the module.  The DRBG Seed is destroyed as part of a power cycle, reboot, and tamper condition. 384 bit random value generated by the hardware noise source. DRBG Entropy  The DRBG Entropy is a one-time volatile value that is not stored in the module.  The DRBG Entropy is destroyed as part of a power cycle, reboot, and tamper condition. Hash DRBG V and C State Values. Hash DRBG V and C State Values  The Hash DRBG V and C State Values are volatile values that are not stored in the module.  The state values are destroyed as part of a power cycle, reboot, and tamper condition. Note: While the above table lists the certificates maintained within the module, the certificates contain only public information. The module prevents data output during initialization and self-test. - No data is output from the module until the self-tests complete successfully and the NC has been properly loaded into the module. - No data is output during and after zeroization of cryptographic keys and CSPs, as this occurs when a tamper condition exists. The encryptor’s internal modules and timing controls work together to isolate user data input and output processes from CSP and key management functions. 2.5.2 Roles and Services The encryptor supports services that are available to Crypto Officers and Users. All of the services are described in detail in the module’s User’s Guide and in the SMC User’s Guide. The Crypto Officer (full access) role provides cryptographic initialization and management functions. Crypto Officer functions are available using SMC and via the console CLI. The Crypto Officer (read only) role is restricted to read-only access to module configuration data. The Network User Role can negotiate encryption/decryption keys and use encryption/decryption services. (The Network User Role is available only to, or in conjunction with, other authenticated modules.) Table 2.5-4 shows the services available to the various roles. All services except Run Self-Test (Power Cycle the Module), AES or Triple-DES encryption, SHA-1hashing for password verification, and physical tamper, require a console operator to be authenticated by entering a username and password, or an SMC operator to use RSA public key authentication and SNMPv3 user authentication. Document is Uncontrolled When Printed. Page 20 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Table 2.5-4 – Roles and Services Crypto Crypto Officer Officer Network Service No Role (Full (Read User Access) Only) ● Load Initial Network Certificate ● Load Subsequent Network Certificate ● Set Real Time Clock ● Edit Connection Action Table ● ● View Connection Action Table ● Create user accounts ● Modify user accounts ● Delete user accounts ● Lock/Unlock USB Port ● ● Show Firmware Version ● ● View User Accounts ● Clear Audit Trail ● ● View Audit Trail ● Clear Event Log ● ● View Event Log ● ● View FIPS Mode Status ●[4] Change SNMPv3 Privacy Mode Run Self-Test (Power Cycle the ● Module) ● Run Self-Test (Reboot Command) ● ● Generate AES session keys [1] ● ● Generate Initialization Vector [1] ●[5] ●[5] Agree on Management Privacy Key ● ● RSA signature generation [1] ● ● RSA signature verification [1] ●[2],[5] ●[5] ● AES encryption ●[2],[5] ●[5] ● AES decryption Document is Uncontrolled When Printed. Page 21 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Crypto Crypto Officer Officer Network Service No Role (Full (Read User Access) Only) Triple-DES encryption and decryption ● (for the master secret) ● SHA Hashing for password verification ● Generate DH keys ● ● DH Key Agreement [1] ● Firmware load test ● Erase unit (Console Command) [3] ● Tamper ● Alternating Bypass ● Set FIPS mode [6] [1] Restarting a connection causes new session keys to be generated. Note: DH key generation and establishment is non- Approved and equivalent to plaintext. [2] Plaintext data entering the Local Port is encrypted, and cipher text data entering the Network Port is decrypted, if the connection is set to encrypt data. [3] Erasing the content of the module zeroizes the module. [4] The SNMPv3 Privacy Mode may only be changed when FIPS Mode is turned off. Privacy must be enabled before FIPS Mode can be turned on. [5] When Privacy is enabled, all remote management connections are secured regardless of the Crypto Officer role. [6] FIPS mode is enabled by default. This service is only available to a CO who has taken the module out of FIPS mode. Note: Plaintext Cryptographic Keys and CSPs are never output from the module. Document is Uncontrolled When Printed. Page 22 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 2.5.3 Access Control Table 2.5-5 shows services from Table 2.5-4 that use or affect cryptographic keys or CSPs. For each service, the key or CSP is indicated along with the type of access. R- The item is read or referenced by the service. W- The item is written or updated by the service. The item is executed by the service. (The item is used as part of a cryptographic function.) E- The item is deleted by the service. D- Table 2.5-5 – Access Control Service Authentication Data (Key or CSP) Access Control Authenticate Crypto Officer RSA Public Key R RSA Private Key R,E E Password Load Network Certificates RSA public and private keys W W RSA public key certificate W System Master Key Create user accounts Password (W) W Modify user accounts (reset Password (W) W password) Delete user accounts Password (D) D Change password Password (E,W) E,W Generate AES session keys AES Session Key W Generate IV IV W Agree on Management Privacy Key Management Privacy Key W RSA signature generation RSA Private Key R,E RSA signature verification RSA Public Key R,E AES encryption Management Privacy Key R Session Key AES decryption Management Privacy Key R Session Key Erase unit (Console Command) System Master Key W Tamper System Master Key W Alternating Bypass System Master Key E Set FIPS mode All W Document is Uncontrolled When Printed. Page 23 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 2.6 Physical Security The module employs the following physical security mechanisms: The encryptor is made of commercially available, production-grade components meeting commercial specifications for power, temperature, reliability, shock and vibration. The module hardness testing was only performed at 75 degrees Fahrenheit and no assurance is provided for Level 3 hardness conformance at any other temperature.  All integrated circuit chips have passivation techniques and materials applied to them.  The enclosure is strong and opaque.  Attempts to enter the module without removing the cover will cause visible damage to the module.  Ventilation holes on the side of the unit are fitted with baffles, or other obscuring material, to prevent undetected physical probing inside the enclosure. Access to the circuitry contained within the encryptor is restricted by the use of tamper detection and response (CSP zeroization) circuitry. Attempting the removal of the enclosure’s cover causes the immediate zeroization of the 168-bit symmetric System Master Key, rendering all cryptographic keys and CSPs indecipherable. This capability is operational whether or not power is applied to the module. A tamper-evident seal is factory installed over the interface module face plate, providing visible evidence of any attempt to remove the interface card to obtain access to the internal components of the module. Any attempt to remove the module cover is considered tampering; access to the cryptographically relevant components of the module requires the cover to be removed. Removal of the cover requires removal of the network interface card which triggers the Tamper Switch. When the module detects tampering it destroys the cryptographic keys and unprotected CSPs automatically, then returns to an uncertified state and remains in that state until it is re-certified. If the Tamper Switch is triggered while the module is powered on:  the module erases the 168-bit symmetric key which is used to encrypt the unit’s private key and user localized passwords  the module also erases any active key material and logs an event message indicating that the card has been removed After tamper activation the system is uncertified and the Secure LED is illuminated red until a new certificate is loaded. If the Tamper Switch is triggered while the module is powered off:  the module erases the 168-bit symmetric System Master Key  the event message will be logged and the Secure LED will be illuminated red after the module is powered on While in the uncertified state, the CLI and SNMPv3 access are still active, but no user data is output from the module. The module indicates this state with the Secure LED illuminated red on the front panel. In addition to the physical security mechanisms integrated with the module, the following recommendations should be considered in the implementation of a Security Policy governing the installation and operation of the encryptors:  To ensure the security of the module during distribution and delivery, the User’s Guide contains procedures in the Security Requirements section for inspection of the module by an authorized operator. Document is Uncontrolled When Printed. Page 24 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy  Secure access to the cryptographic module within a physically secure, limited access room or environment. Document is Uncontrolled When Printed. Page 25 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Table 2.6-1 outlines the recommended inspection and/or testing of the physical security mechanisms. Table 2.6-1 – Security Mechanism Inspection and Test Recommended Physical Security Frequency of Inspection/Test Guidance Details Mechanism Inspection/Test No direct inspection or test The module enters the tamper error state Tamper Switch is required. when the switch is tripped. Once in this state, the module blocks all traffic until it is physically reset. In accordance with Inspect the enclosure and tamper evident Tamper Evidence organization’s Security label for physical signs of tampering or Policy. attempted access to the cryptographic module. During normal operation, the Secure LED is illuminated green. If the unit is uncertified or tampered, the Secure LED is illuminated red and all traffic is blocked. 2.7 Self-Tests In addition to the physical security mechanisms noted in 2.6, the encryptor performs both power-up and conditional self-tests to verify the integrity and correct operational functioning of the cryptographic module. Table 2.7-1 summarizes the system self tests. If the system fails a self test, it reports the failure on the front panel LCD and transitions to an error state and blocks all traffic on the data ports. The specific failure will be identified by one of the following three messages:  Fatal system error Self-tests failed  SHA1 sw check failed System halted  FW self test fail Crypto Officers can run the power-up self-test on demand by issuing a reboot command. An operator with physical access to the device can also run the power-up self-test on demand by cycling the power to the module. Rebooting or power cycling the module causes the keys securing the connection to be reestablished after communications are restored. The design of the cryptographic module ensures that all data output via the data output interface is inhibited whenever the module is in a self-test condition. Status information displaying the results of the self-tests is allowed from the status output interface, but no CSPs, plaintext data, or other information that if misused could lead to a compromise is passed to the status output interface. Document is Uncontrolled When Printed. Page 26 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Table 2.7-1 – Self-Tests Self-Test Description Mandatory power-up tests performed at power-up and on demand: Each cryptographic function, performed by the Encryptor, is tested using Cryptographic Algorithm a “known answer” test to verify the operation of the function. Known Answer Tests AES (e/d), HMAC-SHA-1, HMAC-SHA-256, Algorithms tested: SHA-1, SHA-256, Triple-DES (e/d), DRBG, RSA (sign/verify) The binary image(s) of the Encryptor’s firmware includes a 160-bit error Firmware detection code (EDC) that allows the Encryptor to verify the integrity of the firmware. The EDC is calculated for the image(s) and compared with the known value(s), using a SHA hash, to confirm the integrity of the module. The Connection Action Table (CAT) contains settings for bypass mode Bypass (configured administratively). Each time the CAT is changed, the system generates a checksum and stores it as a parameter. On booting, the system calculates a fresh checksum and compares it to the stored value to assure that the CAT rules have not changed or been corrupted. If the values do not match, the encryptor determines an error exists within the CAT. The encryptor sets an alarm and does not pass data (encrypted or unencrypted) to any connection. To manually confirm the bypass configuration, review the settings in the CAT. This may be accomplished with the SMC application or via the console at the encryptor.  With SMC, log into the management application and select the target encryptor from the Device table. Review device status on the Status tab or configure specific connection settings on the Security tab. Refer to the SMC documentation for details.  At the encryptor, log into the console and use the sessions command (SONET) or the tunnels command (Ethernet). Refer to the User’s Guide for details. Critical Functions tests performed at power-up: A test to verify the configuration memory integrity. An error detection Configuration Memory formula is calculated on all configuration memory and compared against the expected value (EDC), which is also stored in the configuration memory. If failed, the unit attempts to correct the EDC and report the failure. The real time clock is tested for valid time and date. If this test fails, the Real Time Clock time/date is set to 01-Jan-2000 at 00:00. The battery is tested to determine if it is critically low. This test is Battery guaranteed to fail prior to the battery voltage falling below the minimum specified data retention voltage for the associated battery-backed components. If this test should fail, the battery low alarm condition will be on. The unit will continue to operate after taking whatever precautions are necessary to guarantee correct operation. A destructive test verifies that the general purpose memory (RAM) is General Purpose properly operating, e.g., all legal addresses may be written to and read Memory from, and that no address lines are open or shorted. Document is Uncontrolled When Printed. Page 27 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Self-Test Description Tamper memory is examined for evidence of Tamper. Tamper Memory Conditional tests performed, as needed, during operation: Public and private keys are used for the calculation and verification of Pairwise consistency digital signatures and also for key transport. Keys are tested for consistency, according to their purpose, at the time they are generated. Encryption keys are tested by an encrypt/decrypt pairwise consistency test while signature keys are tested by a sign/verify pairwise consistency test. Algorithms tested: RSA Test to verify the authenticity of any firmware load that is applied to the Firmware load Encryptor in the field. The firmware is authenticated with an RSA 1024 bit signature. This test is a “stuck at” test to check the DRBG output data for failure to a Continuous DRBG constant value. All internal RNGs (Deterministic and Non-Deterministic) are subject to this test. Document is Uncontrolled When Printed. Page 28 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy 3 Glossary of Acronyms, Terms and Abbreviations Term Definition AES Advanced Encryption Standard CBC Cipher Block Chaining CFB Cipher Feedback CLI Command Line Interface CMVP Cryptographic Module Validation Program CSEC Communications Security Establishment Canada CSP Critical Security Parameter DES, Triple-DES Data Encryption Standard DRBG Deterministic Random Bit Generator EDC Error Detection Code EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communication Commission FIPS Federal Information Processing Standard Gbps Giga Bits Per Second HMAC (Keyed) Hash Message Authentication Code IP Internet Protocol KAT Known Answer Test LAN Local Area Network LED Light Emitting Diode Mbps Mega bits per second MIB Management Information Block MPK Management Privacy Key MSK Master Session Key NC Network Certificate NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program PUB Publication RAM Random Access Memory RFC Request for Comment ROM Read Only Memory RNG Random Number Generator RSA Rivest Shamir and Adleman (public key algorithm) SDH Synchronous Digital Hierarchy SHA Secure Hash Algorithm SK Session Key SMC SafeEnterprise Management Center SMK System Master Key SNMPv3 Simple Network Management Protocol version 3 SONET Synchronous Optical Network SSE SafeEnterprise SONET Encryptor Document is Uncontrolled When Printed. Page 29 of 30 002-010004-001 Revision M Model 650 SafeNet Encryptor Security Policy Term Definition SEE SafeEnterprise Ethernet Encryptor X.509 Digital Certificate Standard RFC 2459 Document is Uncontrolled When Printed. Page 30 of 30