DiamondLink and CL100 Security Policy Version 1.0 Revision Date: January 6, 2006 Cryptek Inc. 1501 Moran Road Sterling, VA. 20166-9309 ©Copyright Cryptek Inc. 2006 This document may be reproduced only in its original entirety [without revision]. © 2006 CRYPTEK Table of Contents 1 INTRODUCTION .............................................................................................................................................................. 1 1.1 PURPOSE ...................................................................................................................................................................... 1 1.2 REFERENCES ................................................................................................................................................................ 1 1.3 PRODUCT LINE NAME CHANGE ................................................................................................................................... 1 2 SECURITY LEVEL ........................................................................................................................................................... 2 3 DIAMONDLINK/CL100 OVERVIEW............................................................................................................................. 2 4 MODES OF OPERATION................................................................................................................................................ 3 4.1 FIPS APPROVED OPERATION ....................................................................................................................................... 3 4.2 NON-FIPS APPROVED ALGORITHMS ........................................................................................................................... 4 4.3 SETTING FIPS MODE ................................................................................................................................................... 4 5 PORTS AND INTERFACES............................................................................................................................................. 4 6 ROLES, SERVICES, AND AUTHENTICATION .......................................................................................................... 5 6.1 ASSUMPTION OF ROLES ............................................................................................................................................... 5 6.2 USER ROLE .................................................................................................................................................................. 5 6.3 CRYPTO OFFICER ROLE ............................................................................................................................................... 6 6.4 ADMINISTRATOR ROLE ................................................................................................................................................ 6 6.5 SERVICES ..................................................................................................................................................................... 6 7 DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS) ........................................................................... 7 7.1 CSP/SRDI TO SERVICES RELATIONSHIP ...................................................................................................................... 7 8 SERVICE TO CSPS/SRDI ACCESS OPERATION RELATIONSHIP ..................................................................... 10 9 OPERATIONAL ENVIRONMENT............................................................................................................................... 10 10 SECURITY RULES ......................................................................................................................................................... 10 11 PHYSICAL SECURITY .................................................................................................................................................. 13 12 MITIGATION OF OTHER ATTACKS POLICY ........................................................................................................ 14 13 ACRONYM LIST............................................................................................................................................................. 15 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 1 Introduction 1.1 Purpose This is a non-proprietary security policy for the Cryptek DiamondLink and CL1001 with firmware versions 2.1.9 or 2.4.0.3. The security policy describes how the DiamondLink and CL100 meet the security requirements of FIPS 140-2 level 2 and how to operate the devices securely, in FIPS mode. The information contained in this document is provided to fulfill the Security Policy requirements of FIPS 140-2. See table 1-0 for supported hardware listings. Nomenclature Hardware Version DiamondLink 5010D26200-4 Rev. C (copper network interface) DiamondLink [Fiber] 5010D26200-5 Rev. D (fiber network interface) CL100 5010D26200-4 Rev. D (copper network interface) CL100F 5010D26200-5 Rev. E (fiber network interface) Table 1-0 Supported Hardware Versions 1.2 References The following NIST Federal Information Processing Standards (FIPS) publications are referenced throughout this document. • FIPS 140-2 Security Requirements for Cryptographic Modules • FIPS 180-2 Secure Hash Standard • FIPS 198 The Keyed-Hash Message Authentication Code (HMAC) • FIPS 46-3 Data Encryption Standard (DES) • FIPS 186-2 Digital Signature Standard (DSS) For more information on Cryptek and the Cryptek product line visit the Cryptek website at http://www.cryptek.com. For information on validated Cryptek products visit the Common Criteria Evaluation and Validation Scheme (CCEVS) website at http://niap.nist.gov/cc-scheme/ValidatedProducts.html, and the NIST validated Modules List website at http://csrc.nist.gov/cryptval/140-1/140val-all.htm. 1.3 Product Line Name Change The Cryptek network security product line has recently undergone a branding change that affects the product names. The new product names are not yet reflected in all documents. Please refer to Table 1-1 below to map the old nomenclature to the new nomenclature. Note: the Cryptek Secure Facsimile product line is not affected by this name change. Table 1-1 Summary of Product Name Changes Previous New Description Nomenclature Nomenclature DiamondCentral™, CC200 Central manager for Cryptek network security products. 1 Cryptek has recently undergone a branding change that affects the entire product line. The DiamondLink is also being sold under the product name CL100. The only difference between the two products is the new color scheme and logo, functionally they are identical. The DiamondLink/CL100 supports either a copper network interface (CSM 5110N0017-1) or fiber network interface (CSM 5110N0017-2). This security policy covers both devices. Page 1 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 Previous New Description Nomenclature Nomenclature cCentral DiamondPAK™, PAK, CP102, 104, 106 Hardware-based, rack-mounted, server-side security device that cPAK protects up to 6 network devices. DiamondLink™, Link, CL100, CL150, Hardware-based, client-side security device that protects a single cLink, cPoint CL100F host. DiamondUTC™, UTC, CT100 Sun Ray-based, ultra thin client integrated security solution. SUTC, cTerm DiamondVPN™, cVPN CV100 Hardware-based, network edge or workgroup security device. DiamondSAT™, cSAT CS100, 101, 102 Hardware-based device for handling security and acceleration for long-haul networks. DiamondAgent™, CA100 Software-based, client-side security application. cAgent cVDL CVDL100 Database firewall network appliance that uses Virtual Data Labeling (VDL) technology. DiamondNIC, NIC, CN100 Hardware-based, client-side security device that protects a single cNIC, NSD-Prime host. PCI form factor (found only in the CC200) 2 Security Level The DiamondLink/CL100(s) specified within this security policy are classified as standalone cryptographic devices encased in commercial grade metal cases. All revisions within this security policy, where the device is factory sealed with tamper-evident stickers, meet the overall requirements applicable to FIPS 140-2 Level 2 security. Security Requirements Section Level Cryptographic Module Specification 2 Module Ports and Interfaces 2 Roles, Services and Authentication 2 Finite State Model 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A Table 2 - DiamondLink Security Level Specification with the tamper-evident seals. 3 DiamondLink/CL100 Overview The Cryptek DiamondLink/CL100 is a managed secure network appliance that features DiamondTEK’s self protecting security computer for added safety. DiamondTEK is the family name of a group of products designed and developed by Cryptek. DiamondTEK is designed to provide the highest level of protection for information assets inside your enterprise network. Flexible in design, DiamondTEK: Will not impact application or user performance; Is complementary to other security components and non-intrusive to your business process; Integrated with other IPSec products and provides a mechanism for including them in a secure managed network; Features an operating system and platform-independent design that is: Page 2 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 Unaffected by security leaks or flaws in the operating system or applications; Compatible with your legacy systems and applications; Adaptable to virtually any network configuration; Easily upgradeable and extremely flexible. DiamondLink automatically identifies and authenticates the user to the network, encrypts communications and determines which data and servers the user is authorized to access. Security functions include token based user I&A, firewall filtering, IPSec, Data Driven Access Control (DDAC) capabilities and centralize management using the DiamondTEK DiamondCentral. The design provides a status output and input interface, individual host and network interfaces, and an authentication interface. The authentication interface consists of an integrated keypad and card reader. The integrated LCD provides status output for the user. Diagram 1 – Photograph of the DiamondLink and CL100 4 Modes of Operation The DiamondLink/CL100 supports the following three modes of operation, ONLINE, ONLINE-SECURE, and BYPASS. The modes supported by the DiamondLink are determined by the Administrator during configuration setup and by the User, during authentication. The ONLINE mode signifies the DiamondLink is configured to communicate with DiamondTEK secure nodes and/or Other IPSec (OIPs) nodes and at least one Clear Text Nodes (CTNs). DiamondLinks will always talk encrypted to other DiamondTEK secure nodes and OIPs nodes and enforce the information flow controls set by the Administrator. DiamondLinks will talk to assigned2 CTNs in the clear (unencrypted) and enforce the information flow controls set by the Administrator. The ONLINE-SECURE mode signifies the DiamondLink is configured to only communicate with other DiamondTEK secure nodes or OIPs nodes. All communication between these nodes will employ encryption and enforce the information flow controls set by the Administrator. The BYPASS mode signifies the DiamondLink is configured to communicate with any CTN. While the DiamondLink is in the BYPASS mode no encryption or information flow controls are supported. To configure a DiamondLink to operate in the BYPASS mode requires two separate actions. The Administrator must configure the DiamondLink to allow the bypass condition and the User must present bypass credentials to the DiamondLink to activate the bypass mode. 4.1 FIPS Approved Operation In FIPS mode, the DiamondLink/CL100 cryptographic device only supports FIPS Approved algorithms as follows: • Triple-DES (three key) for encryption • DES (one key) for encryption (Transitional phase only – valid until May 19, 2007)3 • DES-MAC for firmware authentication (Transitional phase only – valid until May 19, 2007) 2 The modules ability to communicate with CTNs is established by the Administrator through the “Configure the DiamondLink per predefined policy” service. 3 DES is for use with interfacing with legacy systems only. Page 3 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 • SHA-1 for hashing and signature generation • HMAC-SHA-1 for message authentication • RSA PKCS#1 version 1.5 for digital signature • ANSI X9.31 A.2.4 RNG The DiamondLink/CL100 also provides the following cryptographic support in all modes of operation; • The DiamondLink supports a deterministic random number generator (DRNG), ANSI X9.31-1998. The DRNG is seeded by the Crypto Officer during the installation process. • The DiamondLink supports PKI using X.509 certificates wrapped in PKCS 7 format (1024 bits) for DiamondTEK secure node to DiamondTEK secure node authentication. Note: This is an option specified by the Administrator at the DiamondCentral during configuration setup and installed by the Crypto Officer. • Diffie-Hellman (DH) key exchange (Key establishment methodology provides 80 bits of strength) 4.2 Non-FIPS Approved Algorithms When not in FIPS mode the DiamondLink/CL100 supports the MD5, HMAC-MD5 algorithms for signature generation and hashing. 4.3 Setting FIPS Mode The DiamondLink/CL100 can be configured to operate in FIPS mode during initial setup by the Administrator at the DiamondCentral. The DiamondCentral is a centralized GUI security configuration and management workstation. Setup of the DiamondLink is accomplished by traversing the various menu screens and entering the appropriate values. Initial setup instructions are provided below: 1. At the Action Bar select the “ADD NSD” icon. 2. Enter the ID number and name of the DiamondLink. Click Next> to advance to the “Addressing” window. 3. Enter all the appropriate addressing information (e.g. Ethernet address, proxy Ethernet address, IP address, subnet mask, default router, link type). Click Next> to advance to the “Key Types” window. 4. Within the “Key Type” window make the following selections; • DES Key Length (Min = 168) (Max = 168) • Authentication Type HMAC SHA-1 • MODP Groups 1024 5. Click Next> to advance to the “Audit Threshold” window. Default values will remain unchanged. 6. Click Next> to advance to the “Profiles” window. Select the appropriate communication policy for the DiamondLink by scrolling through the “Security Profiles:” window. 7. Click the Finish button and the setting of the FIPS mode is complete for the DiamondLink. To view the FIPS settings of a DiamondLink, the Administrator must go to the DiamondCentral and select the “View NSD” icon. This will allow the Administrator to confirm the security values set for the DiamondLink without making any changes to it. 5 Ports and Interfaces The DiamondLink/CL100 supports seven physical ports, Network port, Host port, Authentication port, Status port, PS/2 in port, PS/2 out port, and the Power port (Note: the PS/2 ports are unused). The Network port and Host port for the DiamondLink Copper (5110N0017-1) are 10/100 sensing Ethernet ports providing a RJ45 connection. The DiamondLink Fiber (5110N0017- 2) consists of 10/100 SC fiber optic connections for the Network and Host ports. Status information is provided to the operator through a single LCD screen, audible signals or a combination of the two. The authentication port consists of a keypad and card reader. Page 4 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 Physical ports Logical Interface(s) Network port Data input, data output, status output, control input Host port Data input, data output, status output, control input Authentication port Data input, control input Status port Status output PS/2 Unused PS/2 Unused Power port Power interface 6 Roles, Services, and Authentication 6.1 Assumption of Roles The DiamondLink/CL100 supports three distinct operator roles (Administrator Role, Crypto Officer Role, and User Role) and provide Role Base authentication. The authentication types employed by the DiamondLink are determined by the Administrator during configuration setup and by the distinct operator role being assumed. The chart below maps the authentication type and authentication mechanism supported by firmware version 2.1.9 and 2.4.0.3. Authentication Type Authentication Strength of Mechanism The probability that a random attempt will succeed or a false acceptance will occur is between 1/106 and 1/1017 which is less than 1/1,000,000. Note to meet PIN the FIPS requirement a PIN should be at least 6 characters. The probability that a random attempt will succeed or a false acceptance will occur is 1/2112 which is less than 1/1,000,000. Shared Secret Note: By default, the DiamondLink always supports the Shared Secret authentication type. The probability that a random attempt will succeed or a false acceptance will PKI Certificate occur is 1/280 which is less than 1/1,000,000 The ID is 8 – 32 bytes long. The probability that a random attempt will ID succeed or a false acceptance will occur is 1/264 6.2 User Role The DiamondLink/CL100 provides User role access through the authentication port. The possession of the User authentication card (ISO 7816) provides access to the DiamondLink (not necessarily to the network) for the User role. The User role is supported by two methods of authentication; unique ID number (8 -32 bytes) with shared secret, or a unique ID number (8 – 32 bytes) and PIN (1 – 17 bytes) combination with shared secret. The selection of which combination of authentication mechanisms are activated, is determined by the Administrator during configuration setup. The User presents the authentication credentials to the DiamondLink for validation through the card reader. If a PIN is required (to operate in FIPS mode, PIN must contain six or more characters) the User enters it using the keypad. The User selects a valid security profile (policy) and submits. Once the DiamondLink has validated the authentication credentials they are sent to the DiamondCentral using a trusted channel for policy download. If the validation fails or the policy request is denied, an error message will be displayed by the status output (LCD). A successful validation and policy request will result in authorized services being provided to the User in accordance with the security policy download. Three consecutive failed authentication attempts will disable the DiamondLink, and requires Administrator action. If during the configuration setup the Administrator assigns the DiamondLink Page 5 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 to a Static user (No Authentication Card Required) then the Install4 card will also contain the Static users’ unique ID number (8 – 32 bytes) for authentication. The Static users’ unique ID number and shared secret are presented to the DiamondLink for validation. Once the DiamondLink has validated the authentication credentials for the Static user they are sent to the DiamondCentral using a trusted channel for policy download. If the validation fails or the policy request is denied an error message will be displayed by the status output (LCD). A successful validation will result in authorized services being provided to the Static user. 6.3 Crypto Officer Role The DiamondLink/CL100 provides the Crypto Officer Role access through the authentication port using the credentials provided by the Administrator. The credentials provided by the Administrator are in the form of an Install card (ISO 7816) with the following information: all the configuration settings for the DiamondLink, shared secret, and a checksum for integrity (Note: When the Administrator assigns the DiamondLink to support PKI certificates for node to node authentication the Crypto officer is provided additional authentication credentials in the form of a X.509 certificate in a PKCS 7 format. PKI certificates are loaded using the Host port on the DiamondLink.). The Crypto Officer inserts the Install card into the DiamondLink card reader and submits. A failed validation results in a failed installation and an error message being displayed by the status output (LCD). A successful validation results in authorized services being provided to the Crypto officer. 6.4 Administrator Role The possession of the shared secret (14 bytes) provides authentication for the DiamondCentral (Administrator Role) to the DiamondLink/CL100. The Administrator presents the authentication credentials to the DiamondLink using a trusted channel. A failed validation by the DiamondLink will require the DiamondLink be re-installed by the Crypto officer. A successful validation will allow the Administrator access to the DiamondLink to provide authorized services. 6.5 Services The following table provides information about the Services to Security functions and Roles availability to services within the DiamondLink/CL100 Crypto-Officer Administrator Services Security Functions User Role Role Role Transmit Packets Process DES, 3DES, SHA-1, X HMAC-SHA-1 Receive Packets Process DES, 3DES, SHA-1 X HMAC-SHA-1 Initiate Bypass N/A X Initiate State change of DiamondLink5 DES, 3DES, SHA-1 X X X HMAC-SHA-1 Initiate Self-test of DiamondLink N/A X X Load DiamondCentral shared secret SHA-1 X Configure the DiamondLink per predefined policy DES, 3DES, SHA-1 X HMAC-SHA-1 Zeroize DiamondLink DES, 3DES, SHA-1 X HMAC-SHA-1 Update DiamondLink Firmware DES, 3DES, SHA-1 X HMAC-SHA-1, DES-MAC 4 The installation of the Static user role is accomplished by the Crypto officer. 5 The Administrator can initiate a state change on a DiamondLink at any time using the trusted channel. The User and Crypto officer can initiate a state change by cycling power or by removing and re-inserting their authentication credentials. Page 6 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 7 Definition of Critical Security Parameters (CSPs) The following table contains the description of the Critical Security Parameters (CSP) in the DiamondLink/CL100. CSP Description DiamondCentral shared Used to provide encrypted communication between the DiamondLink and the DiamondCentral secret (DCSS) for the Administrator interface (used as an IKE pre-shared secret). Traffic encryption keys Used to encrypt the traffic between the DiamondLink and another DiamondTEK secure device or (TEKs) other IPSec device. These are generated as part of the IKE key generation process (3DES). Traffic authentication keys Used to authenticate traffic between the DiamondLink and another DiamondTEK secure device (TAKs) or other IPSec device. These are generated as part of the IKE key generation process. Diffie-Hellman private Generated by the DiamondLink for each used level of classification and used as part of the IKE keys (DHPK) key generation process. Firmware update key Sent to the DiamondLink by the DiamondCentral as part of the firmware update sequence. The (FWUK) firmware is stored in RAM and a DES_MAC is calculated on the firmware using the update key. If the computed value is the same as the value sent from the DiamondCentral then the firmware in the flash is replaced by the new firmware. Node authentication values A shared secret or the PK certificate value is used as the authentication mechanism for the IKE (NAV) key generation process. Unique Identification A number between 8-32 bytes long used in authenticating the user to a network security device. Number (ID) Personal Identification An optional number, between 1-17 bytes long used in conjunction with the unique identification Number (PIN) number to authenticate the user to the network security system. Deterministic Random A RNG is used to generate random numbers. The DiamondLink supports a deterministic Number Generator (RNG) random number generator (DRNG), in accordance with ANSI X9.31. The following table contains a description of a Security Relevant Data Item (SRDI) not considered CSPs. The SRDI is protected within the cryptographic boundary against unauthorized modification and substitution. SRDI Description Discretionary Access The list of approved source and destination addresses (IP address, TCP/UDP port numbers, and Control List (DAT) protocols). DH Public Key (DHLK) Generated by the DiamondLink for each used level of classification and used as part of the IKE key generation process. Node authentication value Used as part of the authentication mechanism for the IKE key generation process. (public key) 7.1 CSP/SRDI to Services Relationship Transmit Packet Processing: The operation to transmit a packet shall first access the current state of the DiamondLink/CL100. If the DiamondLink is off-line, then the packet is not processed until the state changes to on-line. If the DiamondLink is on- line, then the discretionary access control list (DAT) is checked to determine if communication is allowable. If the destination is not allowable (because of IP address, TCP/UDP port number, or protocol) then the packet is destroyed and an audit event is generated. If the DAT signifies that the destination is allowable and is clear text (CTN), then the transmit security window (TSW) is accessed to determine if the DiamondLink can transmit that particular label. If the label cannot be transmitted then the packet is destroyed and an audit event is generated. If the label is within the bounds of the transmit security window Page 7 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 (TSW) of the DiamondLink, then the DAT is checked to determine if the receiving address is allowed to receive the label associated with the address. If the packet label cannot be received by the destination address, then the packet is destroyed and an audit event is generated. If the label can be received by the destination address, then the packet is transmitted to the network. If the DAT signifies that the destination is allowable and communication is to be encrypted (DiamondTEK secure node or OIPs), then the keys associated with the destination (TEK and TAK) are accessed to determine if there is a key for the label associated with the packet. • If a key exists, then it is used to encrypt the packet and the key associated with the authentication mechanism (TAK) is used to perform the authentication of the packet. If the useful life of the key has been exhausted, then the keys (TEK and TAK) associated with the destination address are destroyed. After the encryption and authentication is complete, the packet is transmitted to the network. • If no key exists for the destination/label pair, then the DiamondLink shall check the label of the packet against the transmit security window (TSW) of the DiamondLink. If the label cannot be transmitted, then the packet is destroyed and an audit event is generated. If the packet is within the bounds of the transmit security window (TSW) and the destination address may not be a DiamondLink, then the label of the packet is checked against the label defined for the destination address in the DAT. If the label of the packet is not a subset of the label of the destination address, then the packet is destroyed and an audit event is generated. If the destination address is a DiamondTEK secure node or the label of the packet is a subset of the label associated with the destination address, then the packet is destroyed and an IKE process is instigated. The IKE process will utilize the list of approved encryption algorithms (ACAL) and the list of approved o authentication algorithms (AAAL) to negotiate an acceptable combination to secure the information between the new nodes. If the DiamondLink does not have a Diffie-Hellman private value generated for the classification level, then a Diffie-Hellman public (DHLK) and private (DHPK) keys are generated. The Diffie-Hellman data, the shared secret or PKI certificate (NAV) associated with the destination address and random data generated as part of the IKE protocol are used to generate the keying material (TEK and TAK) to secure the communications between the DiamondLink and the destination address. Receive Packet Processing: The operation to receive a packet shall first access the current state of the DiamondLink/CL100. If the DiamondLink is not on-line and the packet is not from the DiamondCentral, then the packet is thrown away and the network buffer is returned to the network coprocessor. If the DiamondLink is on-line, then the discretionary access control list (DAT) is checked to determine if communication is allowable. If the source is not allowable (because of IP address and SPI number) then the packet is destroyed and an audit event is generated. If the DAT signifies that the destination is allowable and is clear text (CTN), then the receive security window (RSW) is accessed to determine if the DiamondLink can receive that particular label. If the label cannot be received then the packet is destroyed and an audit event is generated. If the label is within the bounds of the receive security window (RSW) of the DiamondLink, then the DAT is checked to determine if the sending address is allowed to send the label associated with the address. If the packet label can not be sent by the source address, then the packet is destroyed and an audit event is generated. If the label can be sent by the source address, then the packet is passed to the host system. If the DAT signifies that the source is allowable and communication is supposed to be encrypted (DiamondTEK secure node or OIPs), then the keys associated with the destination (TEK and TAK) are accessed to determine if there is a key for the label associated with the packet. • If a key exists, then it is used to decrypt the packet and the key associated with the authentication mechanism (TAK) is used to perform the authentication of the packet. After the decryption and the authentication are complete, the packet is checked for allowable protocols and TCP/UDP port numbers. If the DAT signifies that the protocol and TCP/UDP port number is acceptable, then the packet is given to the host system. • If no key exists for the source/label pair, then the DiamondLink shall check the label of the packet against the receive security window (RSW) of the DiamondLink. If the label cannot be received, then the packet is destroyed and an audit event is generated. If the packet is within the bounds of the receive security window (RSW) and the source Page 8 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 address may not be a DiamondLink, then the label of the packet is checked against the label defined for the source address in the DAT. If the label of the packet is not a subset of the label of the source address, then the packet is destroyed and an audit event is generated. If the source address is a DiamondLink or the label of the packet is a subset of the label associated with the source address, then the packet is destroyed and an IKE process is instigated. The IKE process will utilize the list of approved encryption algorithms (ACAL) and the list of approved o authentication algorithms (AAAL) to negotiate an acceptable combination to secure the information between the new nodes. If the DiamondLink does not have a Diffie-Hellman private value generated for the classification level, then a Diffie-Hellman public (DHLK) and private (DHPK) key is generated. The Diffie-Hellman data, the shared secret or PKI certificate (NAV) associated with the source address and random data generated as part of the IKE protocol are used to generate the keying material (TEK and TAK) to secure the communications between the DiamondLink and the source address. If key material exists for the communications channel, then the old keying material (TEK and TAK) are zeroized and replaced with the new values. Load DiamondCentral shared secret: The load DiamondCentral shared secret function requires the use of the Crypto officer authentication credentials. The credentials identify its user as a Crypto officer and contain the shared secret used by the DiamondLink for communication with the DiamondCentral. The DiamondLink/CL100 will copy the information from the credentials and store it in its on-board FLASH memory (DCSS). Configure the DiamondLink per a predefined policy: The Administrator (via the DiamondCentral) shall download (under protection of the encrypted communication between the DiamondLink/CL100 and the DiamondCentral using the DCSS) the defined discretionary access control list (DAT), the transmit security window (TSW), the receive security window (RSW) and node authentication values (NAV) each time a user successfully logs into the DiamondLink. The change could be an addition or a removal of the ability to send/receive packets to other host systems. In the case of a removal, any traffic encryption keys (TEK) or traffic authentication keys (TAK) used for communication between the node and the removed destination node are zeroized. Zeroize DiamondLink: The Administrator can zeroize the all the CSPs (DCSS, TEKs, TAKs, DHPK, FWUK, NAV, RNG) and SRDIs stored and in use by the DiamondLink/CL100. The command is sent via the encrypted communication channel setup by the DCSS. The command will zeroize the DCSS, traffic keys (TEK and TAK), the Diffie-Hellman keys (DHPK and DHLK), the discretionary access control list (DAT), the security window (DSW), the node authentication values (NAV), approved crypto algorithm list (ACAL) and the approved authentication algorithm list (AAAL). Update DiamondLink firmware: The Administrator (via the DiamondCentral) can send a new version of the firmware of the DiamondLink/CL100 via the encrypted channel setup by the DCSS. The DiamondCentral will first send an authentication key (FWUK) and the firmware. The DiamondLink shall verify the signature of the firmware and only update the firmware if the signature is verified. Once the firmware is updated, the DiamondLink will zeroize the FWUK and reset its self. Initiate Bypass: To configure a DiamondLink/CL100 to operate in the BYPASS mode requires two separate actions. The Administrator must configure the DiamondLink to allow the bypass condition and the User must present bypass credentials to the DiamondLink to activate the bypass mode. The BYPASS mode signifies the DiamondLink is configured to communicate with any CTN. While the DiamondLink is in the BYPASS mode no encryption or information flow controls are supported. Initiate State change of DiamondLink: The Administrator (DiamondCentral) can initiate a state change (e.g. suspend, shutdown, and online) using the encrypted channel setup by the DCSS. The User and Crypto officer can initiate a state change by cycling the power of the DiamondLink/CL100 or by removing and re-inserting their authentication credentials. Note: Upon User/Crypto officer initiated state changes, authentication credentials must be submitted. There are two supported methods of authentication, a unique ID number (8-32 bytes) with shared secret or a unique ID number (8-32 bytes) and PIN (to operate in FIPS mode, PIN must contain six or more characters) combination with shared secret. Further information can be found in Section 6.2. Initiate Self-test of DiamondLink: The User and Crypto officer can initiate the DiamondLink/CL100 to perform self-tests by cycling the power or by removing and re-inserting their authentication credentials. Page 9 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 8 Service to CSPs/SRDI Access Operation Relationship The table on this page has been devised to show the Services vs. CSPs/SRDI and Role access. Services vs. CSPs/SRDI DCSS TEK TAK DHPK FWUK DAT NAV RNG ID PIN U C A Transmit Packet Processing WAZ WAZ WA AZ AZ AZ X Receive Packet Processing WAZ WAZ WA AZ AZ AZ X Initiate Bypass X Initiate Self-test X X Initiate State change6 A WAZ WAZ WA AZ AZ AZ AZ W AZ X X X Load DiamondCentral W W shared secret X Configure the A Z Z W W DiamondLink/ a predefined policy X Zeroize DiamondLink Z Z Z Z Z Z Z Z Z Z X Update DiamondLink WAZ Firmware X In the above table, access to the CSPs/SRDI via the service utilizes the following abbreviations: A = Access (note that the actual value is never seen outside the security perimeter so it is not technically a read) W = Write Z = Zeroize In the table above, access to services by individuals is shown by placing an X in the appropriate column at the right of the table. The following abbreviations apply: U = User C = Crypto officer A = Administrator. 9 Operational Environment The FIPS 140-2 Operational Environment requirements are not applicable because all DiamondLink revisions do not contain a modifiable operational environment. 10 Security Rules This section documents the security rules enforced by the DiamondLink/CL100 to implement the security requirements of this FIPS 140-2 Level 2 device7. 1. The DiamondLink shall provide three distinct operator roles. These are the User role, the Crypto Officer role, and the Administrator role. 2. The DiamondLink shall provide Role-Based authentication. 6 The User and Crypto officer can initiate a state change by cycling power or by removing and re-inserting their authentication credentials then submitting. Note: The Administrator (DiamondCentral) can initiate a state change (e.g. suspend, shutdown, and online) using the encrypted channel. Additionally, only the User is able to write to the PIN. 7 Security rules are contained in the numbered paragraphs. Additional information is provided for background purpose only. Page 10 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 • Possession of the User authentication credentials provides access to the DiamondLink (not necessarily the network) for the User role. Possession of the Crypto officer credentials provides authentication for the Crypto officer. Possession of the shared secret provides authentication for the Administrator role. 3. When the DiamondLink has not been placed in a valid role, the operator shall not have access to any cryptographic services. 4. The cryptographic device shall encrypt message traffic using the TDES algorithm. 5. The cryptographic device shall perform the following tests: A. Power up Self-Tests: 1. Cryptographic algorithm tests: a. TDES Known Answer Test b. DES Known Answer Test c. DES_MAC Known Answer Test d. SHA-1 Known Answer Test e. HMAC-SHA-1 Known Answer Test f. MD-5 Known Answer Test g. HMAC-MD-5 Known Answer Test h. DRNG Know Answer Test i. RSA Known Answer Test 2. Software Integrity Test (CRC32) 3. Critical Functions Tests a. RAM Walking Ones Test B. Conditional Self-Tests: 1. Continuous Random Number Generator (RNG) test – performed on DRNG 2. RSA pair-wise consistency test. This is performed when the DiamondLink is configured to support PKI. 3. Policy Integrity Test (Alternating Bypass test) 4. Firmware load Test (DES-MAC) 5. Exclusive Bypass Test 6. When the DiamondLink is in the exclusive bypass state the LCD displays “BYPASS”. When the DiamondLink is in the alternating bypass state the LCD displays “ONLINE”. When the LCD displays “ONLINE-SECURE” the DiamondLink is not in bypass mode. 7. Prior to each use, the internal DRNG shall be tested. Testing is accomplished using the continuous Random number generator test. 8. Data output shall be inhibited during key generation, self-tests, zeroization, and error states. 9. Status information shall not contain CSPs or sensitive data that if misused could lead to a compromise of the device. 10. The DiamondLink shall not support concurrent operators. Page 11 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 11. The User shall be capable of commanding the device to perform the power-up self-tests by removing and re-inserting the authentication credentials or cycling the power. 12. The DiamondLink shall not communicate with the DiamondCentral (Administrator role) to allow a User to login to the device until after it has been initialized by the Crypto officer credentials and User authentication credentials have been presented. • After reading the configuration information from the Crypto officer credentials and updating the DiamondCentral shared secret and communication data, the DiamondLink will transition to the offline state and await the insertion of User credentials. DiamondLinks configured to use a Static user assignment await the pressing of the Submit button or power cycle before transitioning to the online state. 13. The User is disallowed after one invalid attempt to initialize with the DiamondCentral (Administrator role). 14. The DiamondLink shall generate audits for all attempted Mandatory and Discretionary Access Control (MAC and DAC) violations. 15. The DiamondLink shall generate audits for all received encrypted packets that do not pass the message authentication code test. 16. The User shall not have access to any cryptographic services unless the DiamondLink has been commanded to transition to the ONLINE or ONLINE-SECURE state by the DiamondCentral (Administrator role). 17. The DiamondLink shall recognize a Users credentials and attempt to initialize with the DiamondCentral (Administrator role) using data on the DiamondCentral shared secret, User credentials and the profile selected by the User. 18. The DiamondLink shall have a bypass mode that is enabled by requiring two separate actions. The Administrator must configure the DiamondLink to allow the bypass condition and the User must present bypass credentials to the DiamondLink to activate the bypass mode. While the DiamondLink is in the bypass mode no encryption or information flow controls are supported. The LCD will display “BYPASS” while in this mode. 19. The DiamondCentral (Administrator role) shall download a non-security auditing policy to include statistical, broadcast and TCP Open/Close events. These audit events shall be sent to the DiamondCentral (Administrator role) for logging. 20. The DiamondLink and the DiamondCentral (Administrator role) shall use ISAKMP to negotiate keys during each initialization. 21. The DiamondLink shall determine the encryption, authentication algorithms and keys based on the shared secret or PKI method of the IKE standard. 22. The DiamondLink shall support a different key for each host/ label of data combination. 23. The DiamondLink shall accept a firmware update from the DiamondCentral (Administrator role) if the update passes a DES Message Authentication Code (DES-MAC) check using the firmware update key sent to the DiamondLink from the DiamondCentral (Administrator role) via the trusted channel. 24. The DiamondLink shall accept state control commands (e.g. suspend, online, and shutdown) commands from the DiamondCentral (Administrator role) via the trusted channel. 25. The DiamondCentral (Administrator role) shall be capable of zeroizing all CSP and SRDIs stored in the DiamondLink. 26. If the User credentials are removed from the DiamondLink or the DiamondLink is power cycled, the DiamondLink shall notify the DiamondCentral (Administrator role) and change its state to offline via the trusted channel. Page 12 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 27. The data communication keys (TEK and TAK) shall be zeroized when the User credentials are removed or the DiamondLink power is cycled. 28. The Administrator shall verify the authentication type reads SHA-1, when operating in FIPS mode. 29. The DiamondCentral (Administrator role) shall, before allowing the DiamondLink to transition to the online state, download a transmit and receive mandatory access control policy to the DiamondLink. This policy shall include a maximum and minimum transmit window as well as an allowable and mandatory transmit and receive category set. • All outgoing packets shall have a security level between the maximum and minimum transmit level and a category set that is a superset of the mandatory and a subset of the allowable category values. • All incoming packets shall have a security level between the maximum and minimum transmit classification level and a category set that is a superset of the mandatory and a subset of the allowable category values. 30. The DiamondLink shall only support or accept SHA-1 base signatures for the PKI node authentication value. 31. The DiamondLink shall send all auditable events to the DiamondCentral for logging. 32. The ANSI 9.31 A.2.4 PRNG shall be used to generate all keys. 33. The DiamondCentral (Administrator role) shall download communication rules (DAC policy) to the DiamondLink. The policy shall be re-configurable by the DiamondCentral (Administrator role) at any time. These rules define the communication paths as follows: • Valid destination addresses for packets sent from the attached host to the network. • Valid source addresses for packets being sent to the attached host from the network. • Allowable/prohibited TCP and UDP port values for transmission and reception by the host. • Allowable/prohibited protocols for transmission and reception by the host. • The encryption algorithm used to secure the IPSec packet (DES or 3DES). • The authentication mechanism used to secure the IPSec packet (MD5 or SHA-1). 11 Physical Security The DiamondLink/CL100 is classified as a standalone device enclosed in a commercial grade metal case. The factory affixes tamper-evident seals on the front and back covers to meet physical security requirements of FIPS 140-2 level 28. The drawings below show the placement of the seals and the table provides user guidance. 8 The location of the tamper-evident seals is identical for the DiamondLink and CL100 Page 13 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 Physical Security Mechanisms Recommended Frequency of Inspection/Test Guidance Details Inspection/Test Tamper Evident Seals Daily User should inspect each seal for tamper evidence. Tampering with the seals in any way will result in the metallic foil deforming 12 Mitigation of Other Attacks Policy The DiamondLink/CL100 cryptographic device makes no additional claims to mitigating other attacks. Page 14 Cryptek DiamondLink/CL100 Cryptographic Security Policy © CRYPTEK 2006 13 Acronym List AAAL Approved Authentication Algorithms ACAL Approved Encryption Algorithms CCEVS Common Criteria Evaluation and Validation Scheme CSM Common Security Module CSP Critical Security Parameters CTN Clear Text Node DAC Discretionary Access Control DAT Discretionary Access Control List DCSS DiamondCentral Shared Secret DDAC Data Driven Access Control DES Data Encryption Standard DES-MAC Date Encryption Standard – Message Authentication Code DHLK Diffie-Hellman Public Key DHPK Diffie-Hellman Private Key DRNG Deterministic Random Number Generator DSS Digital Signature Standard FIPS Federal Information Processing Standards FWUK Firmware Update Key GUI Graphical User Interface HMAC Hash Message Authentication Code LCD Liquid Crystal Display LED Light Emitting Diode MAC Mandatory Access Control MD5 Message Digest v.5 MODP Modular Exponential NAV Node Authentication Value NSD Network Security Device OIPS Other IPSec PIN Personal Identification Number PKCS#7 Public Key Cryptographic Standard #7 (Cryptographic Message Syntax Standard) PKI Public Key Infrastructure RNG Random Number Generator RSA Rivest, Shamir and Adleman RSW Receive Security Window SC Secure Channel TAK Traffic Authentication Key TCP Transmission Control Protocol TEK Traffic Encryption Key TSW Transmit Security Window UDP User Datagram Protocol X.509 Authentication Framework for Directory Services Page 15