DiamondPak and CP106 Security Policy Version 1.1 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 DIAMONDPAK/CP106 OVERVIEW............................................................................................................................... 2 4 MODES OF OPERATION................................................................................................................................................ 3 4.1 FIPS APPROVED OPERATION ....................................................................................................................................... 4 4.2 NON-FIPS APPROVED ALGORITHMS ........................................................................................................................... 4 4.3 SETTING FIPS MODE ................................................................................................................................................... 4 5 PORTS AND INTERFACES............................................................................................................................................. 5 6 ROLES, SERVICES, AND AUTHENTICATION .......................................................................................................... 5 6.1 ASSUMPTION OF ROLES ............................................................................................................................................... 5 6.2 USER ROLE .................................................................................................................................................................. 6 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 ...................................................................................................................... 8 8 SERVICE TO CSPS/SRDI ACCESS OPERATION RELATIONSHIP ..................................................................... 10 9 OPERATIONAL ENVIRONMENT............................................................................................................................... 10 10 SECURITY RULES ......................................................................................................................................................... 11 11 PHYSICAL SECURITY .................................................................................................................................................. 13 12 MITIGATION OF OTHER ATTACKS POLICY ........................................................................................................ 14 13 ACRONYM LIST............................................................................................................................................................. 15 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 1 Introduction 1.1 Purpose This is a non-proprietary cryptographic device security policy for the Cryptek DiamondPak (H/W Ver. 5010D27630 Rev. C) and CP1061 (H/W Ver. 5010D27630 Rev. D) with firmware version 2.1.9 or 2.4.0.3. The security policy describes how the DiamondPak and CP106 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. 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 Nomenclature New Nomenclature Description DiamondCentralTM, CC200 Central manager for Cryptek network security products. cCentral DiamondPakTM, PAK, CP102, CP104, Hardware-based, rack-mounted, server-side security device cPAK CP106 that protects up to 6 network devices. DiamondLinkTM, Link, CL100, CL150, Hardware-based, client-side security device that protects a cLink, cPoint CL100F single host. DiamondUTCTM, UTC, CT100 Sun Ray-based, ultra thin client integrated security solution. SUTC, cTerm DiamondVPNTM, cVPN CV100 Hardware-based, network edge or workgroup security device. DiamondSATTM, cSAT CS100, CS101, Hardware-based device for handling security and acceleration CS102 for long-haul networks. 1 Cryptek has recently undergone a branding change that affects the entire product line. The DiamondPak is also being sold under the product name CP106. Only the DiamondPak (DP-600) or CP106 with 6 CSMs has been FIPS 140-2 validated. The DiamondPak/CP106 both use CSM hardware version 5110N0017-3. This security policy only covers the DiamondPak (DP600) and CP106 with 6 CSMs. Cryptek also makes a CP102 and CP104 with 2 and 4 CSMs encased in rack-mounted commercial grade metal cases. Page 1 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy Previous Nomenclature New Nomenclature Description DiamondAgentTM, cAgent CA100 Software-based, client-side security application. cVDL CVDL100 Database firewall network appliance that uses Virtual Data Labeling (VDL) technology. DiamondNIC, NIC, cNIC, CN100 Hardware-based, client-side security device that protects a NSD-Prime single host. PCI form factor (found only in the CC200) 2 Security Level The DiamondPak/CP1062 specified within this security policy is classified as a standalone cryptographic device with six CSMs encased in a rack-mount commercial grade metal case. Each CSM, or "channel", within the DiamondPak acts as its own cryptographic device. All revisions within this security policy, where the device is sealed with tamper-evident stickers, meet the overall requirements applicable to FIPS 140-2 Level 2 security. Security Requirements Section FIPS 140-2 Level Cryptographic Module 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 - DiamondPak Security Level Specification with the tamper-evident seals. 3 DiamondPak/CP106 Overview DiamondPak/CP106 is a rack-mounted network appliance designed for protecting multiple network based servers. With six channels, each having DiamondTEK's self-protecting computer with a single security profile, DiamondPak can protect multiple servers or split-band lines within a single server. With advanced access control for protecting critical back-end systems, DiamondPak provides the same security protection that is used for our government's sensitive information. The design provides individual host and network interfaces for each channel, an authentication interface, status output interfaces, and a power switch. The authentication interface consists of a single card reader; a channel selector button to assign control of a CSM; and a reboot button. Status output is provided for each channel through a series of LEDs and audible signals. DiamondTEK is the family name of a group of products designed and developed by Cryptek 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: 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. 2 This security policy only covers the DiamondPak (DP600) and CP106 with 6 CSMs. Page 2 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy Photograph of a DiamondPak-6 Photograph of a CP106 4 Modes of Operation The DiamondPak/CP106 supports the following three modes of operation, ONLINE, ONLINE-SECURE, and BYPASS. The modes supported by the DiamondPak are determined by the Administrator during configuration. Each channel within the DiamondPak maintains its own mode of operation. The ONLINE mode signifies the active channel in the DiamondPak is configured to communicate with other DiamondTEK secure nodes and/or Other IPSec (OIPs) nodes, and Clear Text Nodes (CTNs). The DiamondPak will always talk encrypted to other DiamondTEK secure nodes and OIPs nodes and enforce the information flow controls set by the Administrator. The DiamondPak will talk to assigned3 CTNs in the clear (unencrypted) and enforce the information flow controls set by the Administrator. The ONLINE-SECURE mode signifies the active channel in the DiamondPak is configured to only communicate with other DiamondTEK secure nodes and/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 active channel in the DiamondPak is configured to communicate with any CTN. While the active channel in the DiamondPak is in the Bypass mode, no encryption or information flow controls are supported. To configure a channel in a DiamondPak to operate in the Bypass mode requires two separate actions. The Administrator must configure the CSM in the DiamondPak to allow the bypass condition. The Crypto officer must present bypass credentials, in the form of a bypass card, to the active channel in DiamondPak and press the reboot button. 3 The devices ability to communicate with CTNs is established by the Administrator through the "Configure the DiamondPak per predefined policy" service. Page 3 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 4.1 FIPS Approved Operation In FIPS mode, the DiamondPak/CP106 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)4 · DES-MAC for firmware authentication (Transitional phase only ­ valid until May 19, 2007) · 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 DiamondPak/CP106 cryptographic device also provides the following cryptographic support in all modes of operation; · The DiamondPak supports a deterministic random number generator (DRNG), ANSI X9.31-1998. The DRNG is seeded by the Crypto Officer during the installation process. · The DiamondPak 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 for each channel. · 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 DiamondPak/CP106 supports the MD5, HMAC-MD5 algorithms for signature generation and hashing. 4.3 Setting FIPS Mode The DiamondPak/CP106 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 DiamondPak is accomplished by traversing the various menu screens and entering the appropriate values for each channel supported. 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 DiamondPak. 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. 4 DES is for use with interfacing with legacy systems only. Page 4 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 6. Click Next> to advance to the "Profiles" window. Select the appropriate communication policy for the DiamondPak by scrolling through the "Security Profiles:" window. 7. Click the Finish button and the setting of the FIPS mode is complete for the DiamondPak. To view the FIPS settings of the DiamondPak channel 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 DiamondPak without making any changes to it. This step would be repeated for each channel supported by the DiamondPak. 5 Ports and Interfaces The DiamondPak/CP106 supports the following physical interfaces, Network ports, Host ports, an Authentication Interface, Status Interfaces and the Power port. The Network port and Host port for the DiamondPak are 10/100 sensing Ethernet ports providing a RJ45 connection. Status information is provided to the operator through a series of LEDs, audible signals or a combination of the two. For the DiamondPak (DP600) there are six of the following5, network ports, host ports and status interfaces; one for each channel. There is only one authentication interface which includes a card reader, a channel selector button, and a reboot button. The power port is controlled through a switch. Physical ports Logical Interface(s) Network port (6) Data input, data output, status output, control input Host port (6) Data input, data output, status output, control input Authentication port (1) Data input, control input Status port (6) Status output Power port (1) Power interface Reboot Button Power interface 6 Roles, Services, and Authentication 6.1 Assumption of Roles The DiamondPak/CP106 supports three distinct operator roles (Administrator Role, Crypto Officer Role and User Role) and provides Role Base authentication. The chart below maps the DiamondPak to the authentication mechanism and authentication type, supported by firmware version 2.1.9 and 2.4.0.3. Authentication Type Authentication Strength of Mechanism Shared Secret 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 PKI Certificate The probability that a random attempt will succeed or a false acceptance will occur is 1/280 which is less than 1/1,000,000 ID The ID is 8 ­ 32 bytes long. The probability that a random attempt will succeed or a false acceptance will occur is 1/264. 5 The number of network ports, host ports, and status interfaces supported by the DiamondPak is determined by the number of CSMs installed. Page 5 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 6.2 User Role The DiamondPak/CP106 can only be assigned to a Static user (No Authentication Card Required). Because the DiamondPak can only be assigned to a Static user, the Install card6 will contain the Static user's unique ID number (8 ­ 32 bytes) for authentication, configuration settings, shared secret, and a checksum for integrity. In order to present the Static user's unique ID number and shared secret to the DiamondPak for validation, the Crypto-officer must select the correct channel on the DiamondPak, insert the Install card and press the Reboot button. Once the DiamondPak has validated the authentication credentials for the Static user, the Crypto-officer must remove the Install card and press the Reboot button. The credentials are sent to the DiamondCentral using a trusted channel for policy download. If the validation fails or the policy request is denied, the error LED will be illuminated. A successful validation will result in authorized services being provided to the Static user. 6.3 Crypto Officer Role The DiamondPak/CP106 provides the Crypto-Officer Role access through the authentication interface (Note: PKI certificates are loaded using the Host port) using the credentials provided by the Administrator. For the DiamondPak, the authentication interface includes a card reader, a channel select button and a reboot button. When presenting the credentials, the Crypto Officer must use the Select button to activate the correct channel on the DiamondPak. When the Administrator assigns the DiamondPak 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.). A failed installation will result in an error LED being illuminated. A successful installation will result 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 DiamondPak/CP106. The Administrator presents the authentication credentials to the DiamondPak using a trusted channel. A failed validation by the DiamondPak will require the DiamondPak be re-installed by the Crypto officer. A successful validation will allow the Administrator access to the DiamondPak 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 DiamondPak. Services Security Functions User Crypto- Administrator Role Officer 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 DiamondPak7 DES, 3DES, SHA-1 X X X HMAC-SHA-1 Initiate Self-test of DiamondPak N/A X X Load DiamondCentral shared secret SHA-1 X 6 The installation of the Static user role is accomplished by the Crypto officer. 7 The Administrator can initiate a state change on a DiamondPak at any time using the trusted channel. The Static User and Crypto officer can initiate a state change by cycling power or pressing the Reboot button. Page 6 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy Services Security Functions User Crypto- Administrator Role Officer Role Role Configure the DiamondPak per predefined policy DES, 3DES, SHA-1 X HMAC-SHA-1 Zeroize DiamondPak DES, 3DES, SHA-1 X HMAC-SHA-1 Update DiamondPak Firmware DES, 3DES, SHA-1 HMAC-SHA-1, X DES-MAC 7 Definition of Critical Security Parameters (CSPs) The following table contains the description of the Critical Security Parameters (CSP) in the DiamondPak. CSP Description DiamondCentral shared secret Used to provide encrypted communication between the DiamondPak and the (DCSS) DiamondCentral for the Administrator interface (used as an IKE pre-shared secret) Traffic encryption keys (TEKs) Used to encrypt the traffic between the DiamondPak and another DiamondTEK secure device or other IPSec device. These are generated as part of the IKE key generation process (3DES). Traffic authentication keys (TAKs) Used to authenticate traffic between the DiamondPak and another DiamondTEK secure node or other IPSec device. These are generated as part of the IKE key generation process. Diffie-Hellman private keys Generated by the DiamondPak for each used level of classification and used as part of (DHPK) the IKE key generation process. Firmware update key (FWUK) Sent to the DiamondPak by the DiamondCentral as part of the firmware update sequence. The 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 (NAV) A shared secret or the PKI certificate value is used as the authentication mechanism for the IKE key generation process. Deterministic Random Number A RNG is used to generate random numbers. The DiamondPak supports a Generator (RNG) deterministic random number generator (DRNG), in accordance with ANSI X9.31. Unique Identification Number (ID) A number between 8-32 bytes long used in authenticating the use to a network security device. 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 DiamondPak 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) Page 7 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 7.1 CSP/SRDI to Services Relationship Note: For the following discussion, "DiamondPak" references a single CSM in the DiamondPak/CP106. Transmit Packet Processing: The operation to transmit a packet shall first assess the current state of the DiamondPak. If the DiamondPak is off-line, then the packet is not processed until the state changes to on-line. If the DiamondPak 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 DiamondPak 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 (TSW) of the DiamondPak, 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 DiamondPak shall check the label of the packet against the transmit security window (TSW) of the DiamondPak. 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 DiamondPak, 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. o The IKE process will utilize the list of approved encryption algorithms (ACAL) and the list of approved authentication algorithms (AAAL) to negotiate an acceptable combination to secure the information between the new nodes. If the DiamondPak 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 DiamondPak and the destination address. Receive Packet Processing: The operation to receive a packet shall first access the current state of the DiamondPak. If the DiamondPak 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 DiamondPak 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 DiamondPak 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 DiamondPak, 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. Page 8 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 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 DiamondPak shall check the label of the packet against the receive security window (RSW) of the DiamondPak. 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 address may not be a DiamondPak, 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 DiamondPak 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. o The IKE process will utilize the list of approved encryption algorithms (ACAL) and the list of approved authentication algorithms (AAAL) to negotiate an acceptable combination to secure the information between the new nodes. If the DiamondPak 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 DiamondPak 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 DiamondPak for communication with the DiamondCentral. The DiamondPak will copy the information from the credentials and store it in its on-board FLASH memory (DCSS). Configure the DiamondPak per a predefined policy: The Administrator (via the DiamondCentral) shall download (under protection of the encrypted communication between the DiamondPak 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 the DiamondPak is initiated (either by a reboot or power cycle). 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 DiamondPak: The Administrator can zeroize the all the CSPs (DCSS, TEKs, TAKs, DHPK, FWUK, NAV, RNG) and SRDIs stored and in use by the DiamondPak. 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 DiamondPak firmware: The Administrator (via the DiamondCentral) can send a new version of the firmware of the DiamondPak via the encrypted channel setup by the DCSS. The DiamondCentral will first send an authentication key (FWUK) and the firmware. The DiamondPak shall verify the signature of the firmware and only update the firmware if the signature is verified. Once the firmware is updated, the DiamondPak will zeroize the FWUK and reset its self. Initiate Bypass: To configure a DiamondPak to operate in the Bypass mode requires two separate actions. The Administrator must configure the DiamondPak to allow the bypass condition and the Crypto officer on the behalf of the Static user must Page 9 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy present bypass credentials to the DiamondPak. The Bypass mode signifies the DiamondPak is configured to communicate with any CTN. While the DiamondPak is in the Bypass mode, no encryption or information flow controls are supported. Initiate State change of DiamondPak: The Administrator (DiamondCentral) can initiate a state change (e.g. suspend, shutdown, and online) using the encrypted channel setup by the DCSS. The Crypto officer on the behalf of the Static user can initiate a state change by cycling the power of the DiamondPak or selecting the appropriate channel on the DiamondPak and pressing the Reboot button. Note: Upon Static User/Crypto officer initiated state changes, authentication credentials must be submitted. Authentication credentials consist of a unique ID number (8-32 bytes) with shared secret. Initiate Self-test of DiamondPak: The Crypto officer can initiate the DiamondPak to perform self-tests by cycling the power or selecting the appropriate channel on the DiamondPak and pressing the Reboot button. 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 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 change8 A WAZ WAZ WA AZ AZ AZ AZ X X X Load DiamondCentral W W X shared secret Configure the A Z Z W W X DiamondPak/ a predefined policy Zeroize DiamondPak Z Z Z Z Z Z Z Z Z X Update DiamondPak WAZ X Firmware 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 the DiamondPak does not contain a modifiable operational environment. 8 The Static User and Crypto officer can initiate a state change by cycling power or by pressing the Reboot button. Note: The Administrator (DiamondCentral) can initiate a state change (e.g. suspend, shutdown, and online) using the encrypted channel. Page 10 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 10 Security Rules Note: For the following discussion, "DiamondPak" references a single CSM in the DiamondPak. This section documents the security rules enforced by the DiamondPak to implement the security requirements of this FIPS 140-2 Level 2 device. 1. The DiamondPak shall provide three distinct operator roles. These are the User, Crypto Officer, and the Administrator roles. 2. The DiamondPak shall provide Role-Based authentication. · 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 DiamondPak 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 DiamondPak 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 DiamondPak is in the bypass state (BYPASS) the BYPASS LED will illuminate Amber. When the DiamondPak is in the alternating bypass (ONLINE) state the ONLINE & BYPASS LEDs will illuminate Green and Amber. The illumination of the single green ONLINE LED signifies the DiamondPak does not support the bypass state (ONLINE-SECURE). Page 11 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 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 on a per CSM/channel basis. 9. Status information shall not contain CSPs or sensitive data that if misused could lead to a compromise of the device. 10. The DiamondPak shall not support concurrent operators. 11. The Crypto officer shall be capable of commanding the device to perform the power-up self-tests by cycling the power or selecting the appropriate channel on the DiamondPak and pressing the Reboot button.. 12. The DiamondPak shall not communicate with the DiamondCentral (Administrator role) to login to the device until after it has been initialized by the Crypto officer's credentials. 13. The User is disallowed after one invalid attempt to initialize with the DiamondCentral (Administrator role). 14. The DiamondPak shall generate audits for all attempted Mandatory and Discretionary Access Control (MAC and DAC) violations. 15. The DiamondPak 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 DiamondPak has been commanded to transition to the Online state by the DiamondCentral (Administrator role). 17. The DiamondPak shall recognize the Crypto officer's credentials and attempt to initialize with the DiamondCentral (Administrator role) using data on the DiamondCentral shared secret. 18. The DiamondPak shall have a bypass mode that is only enabled by requiring two separate actions. The Administrator must configure the DiamondPak to allow the bypass condition and the Crypto officer must present bypass credentials too the DiamondPak to activate the bypass mode. While the DiamondPak is in the bypass mode no encryption or information flow controls are supported. The status LED will illuminate the BYPASS LED (Amber). The alternating bypass mode is enabled by configuring the DiamondPak to communicate with DiamondTEK nodes, and/or OIPS nodes, and Clear Text Nodes (CTNs) on the DiamondCentral (Administrator role). 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 DiamondPak and the DiamondCentral (Administrator role) shall use ISAKMP to negotiate keys during each initialization. 21. The DiamondPak shall determine the encryption and authentication algorithms and keys based on the shared secret or PKI method of the IKE standard. 22. The DiamondPak shall support a different key for each host/ label of data combination. 23. The DiamondPak 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 DiamondPak from the DiamondCentral (Administrator role) via the trusted channel. 24. The DiamondPak shall accept state control commands (suspend, online, and shutdown) commands from the DiamondCentral (Administrator role) via the trusted channel. Page 12 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 25. The DiamondCentral shall be capable of zeroizing the DiamondCentral (Administrator role) shared secret stored in the DiamondPak. 26. If the DiamondPak is power cycled or rebooted, the DiamondPak shall notify the DiamondCentral (Administrator role) and change its state to offline via the trusted channel. 27. The data communication keys (TEK and TAK) shall be zeroized when the DiamondPak power is cycled or rebooted. 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 DiamondPak to transition to the online state, download a transmit and receive mandatory access control policy to the DiamondPak. 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 DiamondPak shall only support or accept SHA-1 based signatures for the PKI node authentication value. 31. The DiamondPak 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 DiamondPak. 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 DiamondPak/CP106 is a multi-chip standalone device, with six CSMs enclosed in a commercial grade metal case. The factory affixes 4 tamper-evident seals on the top of the case (over access screws) and 1 in the card-reader bay (over an access screw) to fulfill FIPS 140-2 level 2 physical security requirements. Page 13 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy Physical Security Mechanism 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 DiamondPak/CP106 cryptographic device makes no additional claims to mitigating other attacks. Page 14 © CRYPTEK 2006 Cryptek DiamondPak/CP106 Cryptographic Security Policy 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 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