DiamondVPN and CV100 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 DIAMONDVPN/CV100 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............................................................................................................................................. 5 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 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 1 Introduction 1.1 Purpose This is a non-proprietary security policy for the Cryptek DiamondVPN (H/W Ver. 5010D27450 Rev. D) and CV1001 (H/W Ver. 5010D27450 Rev. F) with firmware version 2.1.9 or 2.4.0.3 The security policy describes how the DiamondVPN and CV100 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 DiamondVPN is also being sold under the product name CV100. The DiamondVPN/CV100 both use CSM hardware version 5110N0017-3. Page 1 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 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 DiamondVPN/CV100 specified within this security policy is classified as a cryptographic device encased in a rack-mount commercial grade metal case. 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 1 ­ DiamondVPN/CV100 security level specification with the tamper-evident seals. 3 DiamondVPN/CV100 Overview The DiamondVPN/CV100 is a single channel rack-mounted network security appliance that features DiamondTEK's self protecting security computer for added safety. The DiamondVPN can be installed to enforce a single security policy for a workgroup or department operating on your enterprise network. It can be deployed at the edge of a corporate LAN for outbound communications security and control of access to the LAN. This option offers secure pass-through to other networks in which DiamondLinks protect some users by providing full path, end-to-end security in combination with conventional VPN tunneled communications. 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. Page 2 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy Photograph of the CV100 Photograph of the DiamondVPN 4 Modes of Operation The DiamondVPN/CV100 supports the following three modes of operation, ONLINE, ONLINE-SECURE, BYPASS. The modes supported by the DiamondVPN are determined by the Administrator during configuration. The ONLINE mode, signaled by the lighting of both the Online and Bypass LEDs, signifies the DiamondVPN is configured to communicate with other DiamondTEK secure nodes and/or Other IPSec (OIPs) nodes and Clear Text Nodes (CTNs). The DiamondVPN will always talk encrypted to other DiamondTEK secure nodes and OIPs nodes and enforce the information flow controls set by the Administrator. The DiamondVPN will talk to assigned2 CTNs in the clear (unencrypted) and enforce the information flow controls set by the Administrator. The ONLINE-SECURE mode, signaled by the lighting of the Online LED without the Bypass LED, signifies DiamondVPN 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, signaled through the lightning of the Bypass LED without the Online LED, signifies the DiamondVPN is configured to communicate with any CTN. While the DiamondVPN is in the Bypass mode, no encryption or information flow controls are supported. To configure a DiamondVPN to operate in the Bypass mode requires two separate actions. The Administrator must configure the DiamondVPN to allow the bypass condition. The Crypto officer must present bypass credentials, in the form of a Bypass card, to the DiamondVPN and press the reboot button. 4.1 FIPS Approved Operation In FIPS mode, the DiamondVPN 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 2 The devices ability to communicate with CTNs is established by the Administrator through the "Configure the DiamondVPN per predefined policy" service. 3 DES is for use with interfacing with legacy systems only. Page 3 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy · 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 DiamondVPN cryptographic device also provides the following cryptographic support in all modes of operation; · The DiamondVPN supports a deterministic random number generator (DRNG), ANSI X9.31-1998. The DRNG is seeded by the Crypto Officer during the installation process. · The DiamondVPN 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 DiamondVPN/CV100 supports the MD5, HMAC-MD5 algorithms for signature generation and hashing. 4.3 Setting FIPS Mode The DiamondVPN/CV100 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 a DiamondVPN 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 DiamondVPN. 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 DiamondVPN by scrolling through the "Security Profiles:" window. 7. Click the Finish button and the setting of the FIPS mode is complete for the DiamondVPN. To view the FIPS settings of a DiamondVPN, 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 DiamondVPN without making any changes to it. Page 4 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 5 Ports and Interfaces The DiamondVPN/CV100 supports the following physical interfaces, Network port, Host port, an Authentication Interface, Status Interface and the Power port. The Network port and Host port for the DiamondVPN 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. The authentication interface includes a card reader, and a reboot button. The power port is controlled through a switch. 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 Power port Power interface Reboot Button Power interface 6 Roles, Services, and Authentication 6.1 Assumption of Roles The DiamondVPN/CV100 supports three distinct operator roles (Administrator Role, Crypto Officer Role and User Role) and provides Role Base authentication. The authentication mechanisms employed by the DiamondVPN is determined by the Administrator during configuration setup and by the distinct operator role being assumed. The chart below maps the DiamondVPN 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. 6.2 User Role The DiamondVPN/CV100 can only be assigned to a Static user. Because the DiamondVPN can only be assigned to a Static user, the Install card4 will contain the Static user's unique ID number (8 ­ 32 bytes) for authentication, configuration settings, shared secret, and checksum for integrity. In order to present the Static user's unique ID number and shared secret to the DiamondVPN for validation, the Crypto-officer must insert the Install card and press the Reboot button. Once the DiamondVPN has validated the authentication credentials for the Crypto-officer and 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. 4 The installation of the Static user role is accomplished by the Crypto officer. Page 5 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 6.3 Crypto-Officer Role The DiamondVPN/CV100 provides the Crypto-Officer Role access through the authentication interface using the credentials provided by the Administrator (Note: PKI certificates are loaded using the Host port). For the DiamondVPN, the authentication interface includes a card reader and a reboot button. When the Administrator assigns the DiamondVPN 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 DiamondVPN/CV100. The Administrator presents the authentication credentials to the DiamondVPN using a trusted channel. A failed validation by the DiamondVPN will require the DiamondVPN be re-installed by the Crypto officer. A successful validation will allow the Administrator access to the DiamondVPN 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 DiamondVPN/CV100. 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 DiamondVPN5 DES, 3DES, SHA-1 X X X HMAC-SHA-1 Initiate Self-test of DiamondVPN N/A X X Load DiamondCentral shared secret SHA-1 X Configure the DiamondVPN per predefined policy DES, 3DES, SHA-1 X HMAC-SHA-1 Zeroize DiamondVPN DES, 3DES, SHA-1 X HMAC-SHA-1 Update DiamondVPN Firmware DES, 3DES, SHA-1 HMAC-SHA-1, X DES-MAC 5 The Administrator can initiate a state change on a DiamondVPN 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 DiamondVPN/CV100 Cryptographic Security Policy 7 Definition of Critical Security Parameters (CSPs) The following table contains the description of the Critical Security Parameters (CSP) in the DiamondVPN/CV100. CSP Description DiamondCentral shared secret Used to provide encrypted communication between the DiamondVPN 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 DiamondVPN 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 DiamondVPN 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 DiamondVPN for each used level of classification and used as part of (DHPK) the IKE key generation process. Firmware update key (FWUK) Sent to the DiamondVPN 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 DiamondVPN 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 DiamondVPN 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 assess the current state of the DiamondVPN. If the DiamondVPN is off-line, then the packet is not processed until the state changes to on-line. If the DiamondVPN 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 DiamondVPN 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 DiamondVPN, then the DAT is checked to determine if the receiving address is allowed to receive the label Page 7 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 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 DiamondVPN shall check the label of the packet against the transmit security window (TSW) of the DiamondVPN. 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 DiamondVPN, 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 DiamondVPN 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 DiamondVPN and the destination address. Receive Packet Processing: The operation to receive a packet shall first access the current state of the DiamondVPN. If the DiamondVPN 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 DiamondVPN 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 DiamondVPN 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 DiamondVPN, 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 DiamondVPN shall check the label of the packet against the receive security window (RSW) of the DiamondVPN. 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 DiamondVPN, then the label of the packet is checked against the Page 8 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 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 DiamondVPN 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 DiamondVPN 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 DiamondVPN 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 DiamondVPN for communication with the DiamondCentral. The DiamondVPN will copy the information from the credentials and store it in its on-board FLASH memory (DCSS). Configure the DiamondVPN per a predefined policy: The Administrator (via the DiamondCentral) shall download (under protection of the encrypted communication between the DiamondVPN 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 DiamondVPN 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 DiamondVPN: The Administrator can zeroize the all the CSPs (DCSS, TEKs, TAKs, DHPK, FWUK, NAV, RNG) and SRDIs stored and in use by the DiamondVPN. 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 DiamondVPN firmware: The Administrator (via the DiamondCentral) can send a new version of the firmware of the DiamondVPN via the encrypted channel setup by the DCSS. The DiamondCentral will first send an authentication key (FWUK) and the firmware. The DiamondVPN shall verify the signature of the firmware and only update the firmware if the signature is verified. Once the firmware is updated, the DiamondVPN will zeroize the FWUK and reset its self. Initiate Bypass: To configure a DiamondVPN to operate in the Bypass mode requires two separate actions. The Administrator must configure the DiamondVPN to allow the bypass condition and the Crypto officer must present bypass credentials to the DiamondVPN. The Bypass mode signifies the DiamondVPN is configured to communicate with any CTN. While the DiamondVPN is in the Bypass mode, no encryption or information flow controls are supported. Initiate State change of DiamondVPN: 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 can initiate a state change by cycling the power of the DiamondVPN or selecting the appropriate channel on the DiamondVPN and pressing the Reboot button. Note: Upon 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 DiamondVPN: The Crypto officer can initiate the DiamondVPN to perform self-tests by cycling the power or selecting the appropriate channel on the DiamondVPN and pressing the Reboot button. Page 9 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 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 change6 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 DiamondVPN/ a predefined policy Zeroize DiamondVPN Z Z Z Z Z Z Z Z Z X Update DiamondVPN 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 DiamondVPN does not contain a modifiable operational environment. 10 Security Rules This section documents the security rules enforced by the DiamondVPN to implement the security requirements of this FIPS 140-2 Level 2 device7. 1. The DiamondVPN shall provide three distinct operator roles. These are the Static User, Crypto Officer and the Administrator roles. 2. The DiamondVPN 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. 7 Security rules are contained in the numbered paragraphs. Additional information is provided for background purpose only. Page 10 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 3. When the DiamondVPN 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 DiamondVPN 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 DiamondVPN is in the bypass state (BYPASS) the BYPASS LED will illuminate Amber. When the DiamondVPN 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 DiamondVPN does not support the bypass state (ONLINE-SECURE). 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 DiamondVPN 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 DiamondVPN and pressing the Reboot button.. Page 11 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 12. The DiamondVPN 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 DiamondVPN shall generate audits for all attempted Mandatory and Discretionary Access Control (MAC and DAC) violations. 15. The DiamondVPN 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 DiamondVPN has been commanded to transition to the Online state by the DiamondCentral (Administrator role). 17. The DiamondVPN 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 DiamondVPN shall have a bypass mode that is only enabled by requiring two separate actions. The Administrator must configure the DiamondVPN to allow the bypass condition and the Crypto officer must present bypass credentials too the DiamondVPN to activate the bypass mode. While the DiamondVPN 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 DiamondVPN 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 DiamondVPN and the DiamondCentral (Administrator role) shall use ISAKMP to negotiate keys during each initialization. 21. The DiamondVPN shall determine the encryption and authentication algorithms and keys based on the shared secret or PKI method of the IKE standard. 22. The DiamondVPN shall support a different key for each host/ label of data combination. 23. The DiamondVPN 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 DiamondVPN from the DiamondCentral (Administrator role) via the trusted channel. 24. The DiamondVPN shall accept state control commands (suspend, online, and shutdown) commands from the DiamondCentral (Administrator role) via the trusted channel. 25. The DiamondCentral shall be capable of zeroizing the DiamondCentral (Administrator role) shared secret stored in the DiamondVPN. 26. If the DiamondVPN is power cycled or rebooted, the DiamondVPN 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 DiamondVPN 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 DiamondVPN to transition to the online state, download a transmit and receive mandatory access control policy to the DiamondVPN. This policy shall include a maximum and minimum transmit window as well as an allowable and mandatory transmit and receive category set. Page 12 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy · 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 DiamondVPN shall only support or accept SHA-1 based signatures for the PKI node authentication value. 31. The DiamondVPN 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 DiamondVPN. 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 DiamondVPN/CV100 is a multi-chip standalone device with a CSM 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 DiamondVPN/CV100 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 DiamondVPN/CV100 cryptographic device makes no additional claims to mitigating other attacks. Page 14 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 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- Date Encryption Standard ­ Message Authentication Code MAC 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 Page 15 © CRYPTEK 2006 Cryptek DiamondVPN/CV100 Cryptographic Security Policy 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 16