Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 1 of 22 Security Policy for the Fortress Technology, Inc., NetFortress®, Level 2 Multi-Chip Standalone Cryptographic Modules. Rev. 2 July 26, 2000 Although this policy was developed for FIPS 140-1 validation of the NetFortress® VPN- 1, ("GVPN"), the NetFortress® 10 and the NetFortress® 100 products, the policy reflects general rules and regulations for the Fortress Technologies, Inc. These rules and regulations must be followed in all phases of all NF-F FIPS 140-1 projects, including the design, development, manufacturing, service, and deliver/distribution of software and hardware products. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 2 of 22 Table of Contents Paragraph Title Page 1.0 Introduction 3 2.0 Security Design Concepts 6 3.0 Implementing the Security Design Concepts 11 3.1 Minimizing Human Intervention to the Module's Operation 11 3.2 The Role of the Crypto Officer and the User 12 3.3 Tamper Evident Seals, no Scheduled Maintenance 14 3.4 Factory set Configuration, Company Proprietary Signature and Activation 14 3.5 Trusted Distribution, Initial Start-up, and the Role of the First Outgoing 15 Message 4.0 Customer Security Policy Issues 16 5.0 Summary 17 6.0 Appendix: Maintenance at FTI Premisses 18 7.0 Bibliography of References 20 Table Title 1. Summary of Securioty Requirements 5 2. Summary of Cryptographic Keys in the NetFortress Modules 9 3. Summary of Common Secret Keys Between the "I-th" and "j-th" 10 NetFortress Modules 4. Rples and Services Matrix for NetFortress Cryptographic Modules 13 \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 3 of 22 1.0 Introduction Federal Information Processing Standard Publication (FIPS PUB) 140-1, the Security Requirement for Cryptographic Modules, [1], [2a], requires a stand-alone document that specifies the Security Policy for a cryptographic module intended for use as security equipment protecting sensitive but unclassified information within government computer and telecommunication (including voice) systems. This Security Policy is a supporting document to the main Submittal Document [2] that contains the other required information about the cryptographic module for FIPS 140-1, Level 2 validation. The Security Policy includes all security rules under which the module must operate (and enforce), particularly rules derived from the security requirements of the standard (see Vendor Requirement VE01.07.01 in [2a]), and the security rules derived from additional security requirements imposed by the manufacturer. Thus, a proper security policy describes all roles, services, and security-relevant data items pertaining to the cryptographic module. The policy specifies what access, if any, a user performing a service within the context of a given role is permitted to each of the security-relevant data items. The specification is required to be complete and detailed enough to answer the question: "What access does operator X, performing service Y, while in role Z, have to security-relevant data item K?" This question must be asked and answered for every role, service, and security-relevant data item contained in the cryptographic module. Reflecting these requirements to the NetFortress® FIPS 140-1 validated products the following definitions are appropriate: · "Operator X" is the authorized crypto officer(s) and/or the Fortress Technologies' service engineer. · "Services Y" are not scheduled but "as required" system maintenance through the unit's Maintenance Access Interface Port, (MAIP) at customer site, or at the FTI's lab by "X". All services are "role based" as defined above. · "Role Z" is defined by Section 4.3.1, [1]: "Crypto Officer Role: The role assumed by an authorized crypto officer performing a set of cryptographic initialization or management functions (e.g., cryptographic key and parameter entry, cryptographic key cataloging, audit functions, alarm resetting)". The NetFortress® FIPS 140-1 validated products services are "role-based" as defined by Section 4.3.3 in [1]: "Role-Based Authentication: A cryptographic module shall authenticate that the operator is authorized to assume a specific role (or set of roles). The module shall require that the operator either implicitly or explicitly select one or more roles, and the module shall authenticate that the operator is \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 4 of 22 authorized to assume the selected roles and to request the corresponding services. The module is not required to authenticate the individual identity of each operator. The selection of roles and the authentication of the authorization to perform those roles may be combined (e.g., a physical key may both indicate one or more roles and verify the authorization to perform those roles). A module may permit an operator to change roles, but the module shall authenticate the authorization of the operator to assume any role that was not previously authenticated". Realization of this definition is explained in Subsection 3.2 below. · "Security-relevant data items K" are the hardware, firmware and software components of modules, which define the NetFortress® system security level. A cross-reference "matrix" of roles and services is presented in Subsection 3.2. This document describes the Security Policy for the multi-chip stand-alone cryptographic module for all NetFortress® FIPS 140-1 validated security products of Fortress Technologies, Inc. (FTI). The security rules and directives described in this document serve as a reference, guide, and obligation in any federal government-related transaction concerning this product which is approved at Security Level 2, [6]. The document specifically covers the: 1. Rules and directives related to the module's security during design, development and manufacturing. 2. Module's "trusted distribution procedure" (including factory-set activation and installation) 3. Module's "maintenance and service" at the vendor's premises 4. Objectives of the "Security Policy" must be applied as guideline in the design and development phases of all FIPS 140-1 validated products. While this is an "internal" FTI document, and its scope is intended to be "informative", it is a non-proprietary document. The rules it contains are of great benefit when conducting business transactions with federal agencies. Therefore, the company's management, specifically those involved in Manufacturing, Marketing, Sales, and post-sale Customer Service (delivery, installation, and maintenance of this module) must become familiar with the contents of this document. The "Summary of Security Requirements" is listed in the Table 1. below. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 5 of 22 \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 6 of 22 Summary of Security Requirements (FIPS PUB 140-1, January 11, 1994) Security Level 1 Security Level 2 Security Level 3 Security Level 4 Crypto Module Design Specification of cryptographic module and cryptographic boundary. Description of cryptographic module including all hardware, software and firmware components. Statement of module security policy. Module Interfaces Required and optional interfaces. Specification of all Data ports for critical security parameters interfaces and of all internal data paths. physically separated from other data ports. Roles and Services Logical separation of Role-based operator Identity-based operator authentication. required and optional authentication. roles and services. Finite State Machine Specification of finite state machine model. Required states and optional states. State transition diagram and specification of state transition. Physical Security Production grade Locks or tamper evidence. Tamper detection and Tamper detection equipment. response for covers and and response doors. envelope. EFP/EFT No requirements. Temperature and voltage. Software Security Specification of software design. High-level language Formal model. Pre- implementation. and post- conditions. Operating System Security Executable code. Controlled access Labeled protection: B1 or Structured Authenticated. Single protection: C2 or equivalent. Trusted protection: B2 or user, single process. equivalent. communication path. equivalent. Key Management FIPS approved generation and distribution Entry/exit of keys in encrypted form or direct techniques. entry/exit with split knowledge procedures. Crypto Algorithms FIPS approved cryptographic algorithms for protecting unclassified information. EMI/EMC FCC Part 15, Subpart J, Class A; business use. FCC Part 15. Subpart J, Class B, home use. Applicable FCC requirements for voice. Self Test Power-up tests and conditional tests. Table 1. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 8 of 22 2.0 Security Design Concepts The FTI has implemented the following principal security rules in the NetFortress® FIPS 140-1 validated product design, development and application: a. implement a simple computational device to protect a single host or a particular network from potential security threats (hence the name "NetFortress® "), and b. serve as an inexpensive, automatic tool to build Virtual Private Networks (VPNs) over the Internet. The following six security design concepts were developed to fulfill these objectives and the security requirements listed in the Table 1. These are: 1. Contain the device's electronic hardware in a sealed, tamper-evident, tamper resistant, strong metal box; (in a secured cryptographic module). The module's cover is attached to the housing with tamper-resistant security screws. 2. Minimize the human intervention to the module operation with a high degree of automation. The automation is rather important, because the module as a commercial product, is intended to be used in a variety of security environments (targeted at a medium level, or Security Level 2, per the FIPS 140-1 security level categories ranging from Security Levels 1 to 4) by a variety of customers. 3. Allowing any of its sensitive operational tasks, including maintenance, to be performed under these conditions by operators would represent a liability, rather than an aid, to security. 4. Create and assign a unique Company Proprietary Signature (CPS) to each customer organization and a unique Company Security Identifier, (CSI) within a company, a group or division thereof, defined by the customer. During manufacturing, the CPS is placed into the software of every cryptographic module that is used to establish the customer's VPN. All key exchanges between the modules of a particular VPN are encrypted by the Module's Secret Key that is the SHA-1, [5] function of the CPS, and thus protected from unauthorized modification and substitution. Using a unique CSI ensures that only modules with the same CSI can exchange keys and establish a secure VPN; all other modules are excluded. Tables 2. and 3. summarize key hierarchy used in the NetFortress FIPS 140-1 validated modules. 5. The Maintenance Access Interface Port, MAIP, provides a secure way for diagnosis and evaluation of the unit by role-based operator authentication. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 9 of 22 6. Prevent the module from being used fraudulently, if stolen after installation at a customer's site. The following two consecutive steps enforce this concept: · activating the module at the factory, followed by · the installation process, including the initial startup and the first outgoing message procedures, performed at the customer's site. Performing these steps permanently attaches the module to a customer's site. Besides providing encrypted communication between secured sites, should provide restricted bypass operation with an unsecured site. (Segmented Module*) After installation, the module serves to not only guard against threats from outside the network, but also acts as a cryptographic co-processor for client systems requiring cryptographic services. With regard to these services, the high degree of automation has the following advantages: a. the module can provide cryptographic services with only minimal human intervention and at low level security risk, b. simple role based access control is considered to be satisfactory for its usage, to enforce this access control, the module can apply the least complex access-control mechanism, c. * for the segmented configuration the module enforces encrypted communication between secured sites and it enforces the rule that allows unencrypted (bypass) communication with an unsecured site only if that communication was initiated by the secured client, d. the burden to cope with the eventual high security tasks is shifted to the local security policy of the customer. As a result: a. The automation reduces the role of an operator (user) essentially to survey only the power/status/connectivity of the module. This type of operator activity generally poses a relatively low-level security risk b. Consequently, it is expected that the security of the module from inside attacks does not require a stricter security policy than a minimal role-based Discretionary Access Control (DAC) that conforms to the concept of "access, restricted only to operators who are authorized by the legitimate customer." \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 10 of 22 c. Thus it seems unnecessary that the module would employ more complex DAC- enforcing mechanism (e.g., password or PIN reader, token or biometrics processor, smart card, etc.), rather than using a simple, role-based authentication device such as a key-operated pick resistant security power lock. Applying more advanced mechanisms would only decrease the cost-effectiveness of the NetFortress® VPN, and would inhibit its operational efficiency. d. The NetFortress® VPN product reduces the security risk associated with its operation, and per se, does not require strict access control. This does not mean that presence of the module would not affect the local security policy of a customer. It is expected, that after installing a NetFortress® VPN, the security rules for the personnel who is servicing the client systems, particularly for those who are performing sensitive tasks such as cryptographic traffic handling, would be modified. It is also expected, that the access control mechanisms or tools of the client systems, particularly where the plaintext messages become visible, would be upgraded. Effective implementation of the above described security design concepts and considerations is outlined Section 3.0. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 11 of 22 Summary of Cryptographic Keys in the NetFortressModules Key Key Generation/Function Feature It is an SHA-1 hash function of the CPS and an added CSI within Written in the flash memory in all The Module's Secret the customer's network. CSI can be modified with "SetSig", while modules belong to one customer, at the Key: MSK the CPS is permanently assigned to the unit. The MSK is used to time of manufacturing. encrypt the static Diffie-Hellman key exchange. Private: ANSI X9.17 compliant PRNG. Regenerated at each power-up SPRK and it is always same. It is used to generate the SPUK. The two key pairs are generated each Static Public: Generated with the Diffie-Hellman protocol and the modules time in the module when it is turned on. SPUK SPRK. The dynamic keys are regenerated every Private: Randomly generated with ANSI X9.17 compliant PRNG, but its 24 hours and after each reboot of the Dynamic DPRK seed is not reproducible. module. Public: Generated with the Diffie-Hellman protocol and the modules DPUK DPRK. Table 2. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 12 of 22 Summary of Common Secret Keys between the "i-th" and "j-th" NetFortressNodes Key Key Generation/Function Feature Generated by the Diffie-Hellman protocol and The SCSK is a constant identifier of the two modules, Static Common with the module's own SPRKi and the partner written in their FlashDrive. Secret Key: module's SPUKj. The other module generate its SCSK own SCSK key in the same way with "i j". Encrypted with DES/3DES. Generated by the Diffie-Hellman protocol and The DCSK key is used with DES or 3DES to encrypt/ Dynamic with the module's own DPRKi and the partner decrypt the regular network traffic. It is stored in the Common Secret module's DPUKj. The other module generate its DRAM/SDRAM. Key: DCSK own SCSK key in the same way with "i j ". Its value is regenerated in every system boot-up and at least one time in every 24-hour period. Table 3. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 13 of 22 3.0 Implementing the Security Design Concepts 3.1 Minimizing Human Intervention to the Module's Operation The NetFortress® VPN is a multi-chip, standalone cryptographic module. It is housed in a metal case having "non-removable" boundaries secured with tamper-resistant fasteners. Its communication ports (serial, parallel, floppy disk, video, keyboard and mouse) are behind the chassis' rear plate, which is permanently assembled with the unit housing. The user cannot connect a keyboard to either the monitor or to the module through the "standard" communication ports of the motherboard. Not only does the module block hacker attacks, it also blocks local access to its firmware and its operating and file systems. The unit's type or configuration (see 3.4 below), as well as the CPS set up by the factory, cannot be altered without leaving evidence. The module evaluation and trouble-shooting at customers' sites takes place through the Maintenance Access Interface Port, (MAIP), which is located behind the chassis front door. This door is secured with a pick-resistant mechanical lock. As a standard, only the authorized Security Officer possesses the key. In general, the MAIP application is governed by the role-based operator authentication regulation. The specific procedure for MAIP implementation of the maintenance process is realized with application of the hardware and with the Service Software, (SSW). This feature is applied in both commercial and FIPS 140-1 validated NetFortress modules. However, the commercial modules software allows more flexible operation during the service session than the validated one. The functions of MAIP are: · Review the static Database · Deleting Static Database · Review Configuration File · Setting/modifying the Company Security Identifier, (CSI) as part of the Company Proprietary Signature, (CPS) · Review module's Log file The MAIP hardware as part of the crypto unit consists of a DB-9 connector, the necessary fasteners for the connector and the ribbon cable with header pin connectors. These items are located within the "cryptographic boundary". A null-modem serial cable with the special adapter connects the crypto unit to the service computer serial port. Neither the service computer nor this external cable is part of the module. From the FIPS regulation point of view, they should be regarded as a temporary service tools. The special cable adapter, which is necessary to connect the unit to the service computer can be regarded as a security token and provides additional security feature for the MAIP usage. Application of the SSW is regulated by the automated Sequence of Operation and makes impossible to tamper with the system software. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 14 of 22 A factory-set and activated module automatically adapts itself to any Ethernet platform using TCP/IP. The NetFortress® VPN needs no special modification for most network applications. The module assumes many operational functions usually performed by human operators at earlier types of cryptographic modules. The NetFortress® VPN automatically uses protocols, performs key management (on an installed module there is no manual key or cryptographic parameter entry) to establish VPNs, and provides cryptographic services, such as encryption and decryption. The module changes dynamic keys automatically every 24 hours of operation, and verifies the encryption/decryption process, as well as checking data integrity after transmission. All of these functions greatly reduce the possibility for human error. 3.2 The Roles of the Crypto-Officer and the User The physical security lock, mounted on the front door, is under the control of individuals authorized by the legitimate customer to install and operate (to power up, diagnose and zeroize) the unit. These individuals are defined as crypto-officers, who have the keys that operate the lock, and the user. In several cases, the same individual can perform the tasks of both the crypto-officer and the user. FTI supplies two sets of two (2) unique keys with each module, four keys altogether. They operate the security lock and the lock for the zeroization switch. The security keys are given to the crypto-officer by an authorized FTI employee who participates in the Trusted Distribution of the modules (description given in Section 3.5), and provides assistance to the crypto-officer during the module's initial start up. After the initial startup, the crypto-officer either operates the module himself, or designates and authorizes a user to operate the module. At any later time, when the crypto-officer deems it necessary, he/she can perform zeroization using the second pair of security keys. Both the FTI and the customer inventory the identification number on all four keys. Thus, each module enforces a crypto-officer's and a user's role. It satisfies FIPS 140-1 Vendor Requirement VE03.02.01, which specifies that any cryptographic module, as a minimum, must support two roles: a crypto-officer role and a user role. The crypto-officer's role is to install (or reinstall) the NetFortress® VPN at the customer's site, perform its initial startup, send the first outgoing message, and render the unit inoperable if needed. The user's role is limited to operating the module, by 1. using the power switch behind the front door after the AC connector is plugged in and the door is unlocked, 2. attaching the connecting cables to the client system's data port and to the outside network, \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 15 of 22 3. observing the module's status, and to rebooting the module, given a power loss or apparent malfunction (resulting in an "error" state). Powering off the module zeroizes all the sensitive cryptographic data in the module's dynamic memory, 4. initiating bypass operation (for segmented modules only) by initiating communication with an unsecured site. The module's physical connection to a client system is under continuous surveillance according to the customer's local security policy, so that it cannot be subject to a communication interception attack with a "sniffing" device from a remote location. The roles and services for the NetFortress® VPN module are summarized in a "matrix" in Table 4. Operator. (X) Services. (Y) Role. (Z) Access to. (K) Install module FTIE/CO VPN/Internet Replace module FTIE/CO VPN/Internet Initiation of the first outgoing message: CO VPN/Internet, IP/MAC Posses module's HW keys CO Module's HW Maintenance at Customer site: MAIP CO CSI, SKDB, Log file, AUTHORIZED Maintenance at FTI FTIE NF HW, SW PERSONNEL Set CPS FTIE MSK Viewing Static Key Database CO SPRK, SPUK Deleting Static Key Database CO SPRK, SPUK Read "Log" File CO Module's Log File Zeroization FTIE/CO CSP Checking module's operating status U Module Checking module's physical security U Module Power-up/Self-test CO/U Module Key Management Operation None/Aut. N/A Key Generation, Key exchange None/Aut. N/A Cryptographic Operation and None/Aut. N/A Management Show Status Aut./LED/ N/A Aud. Note: Aud. Audio/Speaker Aut. Automatic CO Crypto Officer CSP Critical Security Parameter FTIE Fortress Technologies, Inc. Engineer SKDB Static Key Database U User Table 4. Roles and Services Matrix for NetFortress Cryptographic Modules \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 16 of 22 3.3 Tamper Evident Seals. No Scheduled Maintenance The sealed metal box housing the NetFortress® VPN electronic and mechanical hardware is neither intended to be, nor allowed to be opened by the user. The module neither requires nor permits scheduled maintenance. The seal consists of a minimum of five, numbered tamper-evident labels that leave detectable traces on the surfaces of the affected module. Two of these labels are placed over the tamper-resistant security screws. Removing the traces takes a minimum of two hours. Both FTI and the customer inventory the number on each label. The most important goals of a customer's own security policy are prevention and quick detection of the module's tampering. FTI is not responsible for malfunction of the module after installation due to tampering or breach of security by successful tampering attacks. FTI provides, however, full technical support and cooperation in any investigation associated with detected tampering attempts, or security breach and security damage control due to tampering attacks, and will test/perform necessary maintenance of the tampered module for reasonable compensation. Maintenance or tests (particularly after "hard" failures), which requires human access to the module's interior cannot be performed at the customer's site. They must be performed exclusively at FTI premises (for detailed information, see Appendix: Maintenance at FTI Premises). 3.4 Factory-Set Configuration, Company Proprietary Signature and Activation NetFortress® VPN modules are available in two types (host and LAN). The host module provides protection for a single node (a "client" computer). The LAN module provides security for all the nodes of a client network (computers or servers). The client network is a Class C or Class B network, (or part of it). The modules of these types provide secure communication with other NetFortress® VPN - protected nodes only. Based on the customer's interest and needs, the configuration and the type of the unit, as well as the unique CPS, are set at the factory and cannot be altered by the user. Arrangements must be made with FTI to change the type or the assigned CPS. These two security provisions ensure that no one can compromise the integrity of a network by substituting the proper modules with other, (inappropriate) ones: · The CPS from which the Module's Secret Key, or "hard key" is calculated, which is in turn is used to encrypt the static Diffie-Hellman key exchange is generated and tested when the module is manufactured for a given customer. The CPS is a hexadecimal number whose length is 56 bits. It is generated and assigned externally for each customer by an authorized FTI employee. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 17 of 22 The FTI employee tests the CPS for uniqueness and for "guessability" (i.e., whether the CPS contains any potentially useful information concerning the customer's real name, logo, well-known product, or any characteristics from which a seasoned "guesser" would be able to determine the generated number). After this test, the MSK is calculated from the selected CPS, and it is written in DES sub-key expanded form into the module's software, which is then loaded into the flash. At FTI the list of CPSs, the customer's identity, and the associated software hard copies are kept under secure conditions (with encrypted files in secured computers and redundant encrypted diskettes in a bank vault). · Factory-set activation is the first security step against fraudulent use of the module before a module is put into service. An authorized FTI employee performs the activation during the manufacturing process. The activation allows or disallows writing a client's IP and MAC addresses (in a LAN module, the MAC address used is from the first node to send a message) into the flash by the first message from the client. Activation also provides an important security element for FTI's "Trusted Distribution" system for the modules. Trusted distribution assures detection of any tampering with a module's firmware from the time it leaves the vendor site to the time it arrives and is installed at a customer's site. Consequently, it protects the security of the information to be processed on the module(s) (see section 3.5). The activation procedure, performed under laboratory conditions, is as follows: 1. From a dedicated, standalone computer program, "act", sends an activation packet (an IP packet with a "FTI Activation" string in the payload) through the module. 2. The module writes its serial number and the time of activation, after receiving this packet and after checking for potential previous activation, into the configuration file DSN/NF.conf in the flash memory. 3. A UDP (User Datagram Protocol) packet is sent to the computer that previously sent the activation packet, as an acknowledgment. 4. The activation program then verifies that the module was successfully activated and displays the message: "Box has been activated." 3.5 Trusted Distribution, Initial Startup, and the Role of the First Outgoing Message According to the FTI's Trusted Distribution system, each NetFortress® VPN is shipped to a customer's site in an activated condition and under appropriate security procedures, such as in a sealed case, with no power-on possibility. FTI personnel, traveling separately from the module's shipment, brings the keys for the security lock and for the zeroization switch to the customer's site to provide assistance installing the module by the crypto- officer. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 18 of 22 During installation, the intact (sealed) module is strategically placed between the protected LAN segment (a single machine, a specific area of a network, or the entire network) and the external communication link. During the initial start-up of the module by the crypto-officer (and/or FTI personnel), as part of the power-up self-test, the module checks that the module is activated. · Failure of the activation check prompts the FTI code to set the box_active flag to 0. If successful, the flag is set to 1. · The flag is tested when the client system's first message (e.g., PING, ARP request, or IP packet) transits the module. If the module is not activated the IP and MAC addresses of the client systems are not allowed to be written into the flash. Consequently, reproducible static key cannot be generated for the module. · If the module is activated, the IP address and MAC address (for a single client system), or the Class part of the IP address and MAC-address of the first client system (for a LAN module), are written into the flash (representing the second security step against fraudulent use of the module). The module is permanently tied to the client computer or to the LAN due to the burn-in process. Therefore, any attempt to breach security by moving a module to a site with a different IP address (i. e., stealing and using it fraudulently) would be a waste of effort, since the unit won't work. · Another result of the initial write-in is that the code now can generate reproducible static key. From this point, the reproducible static key will be an attribute (a property) of the module, allowing proper operation to resume after each reboot. 4.0 Customer Security Policy Issues It is to be emphasized that regardless of the features to avert security attacks built into the module, FTI expects that after the module's installation, any potential customer (government or commercial entity or division thereof) employs its own internal security policy covering all the rules under which the module(s) and the customer's network(s) must operate [4]. The customer's security policy would ensure that those responsible for security are kept current on hacker techniques and programs, regulate all access to/from the Intranet, and protect against insiders. This security policy is expected to include multilevel DACs. In addition, if needed, the customer systems are expected to be upgraded to contain appropriate security tools to enforce the internal security policy. DACs can be implemented in a variety of ways, including: · Using passwords, tokens or other security tools · Configuring servers to selectively restrict services (e.g., ftp, telnet, etc.) to specified terminals, IP addresses or users \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 19 of 22 · Proxy servers to shield sensitive node · Privileges to handle cryptographic material · Carefully granted super-user privileges 5.0 Summary The security rules, directives, and obligations imposed by the NetFortress® VPN Security Policy alone (disregarding the module's operational requirements) can be summarized as follows: · During manufacture, a unique Company Proprietary Signature (CPS) will be determined and assigned by an authorized FTI employee to each module that will be a member of a particular Virtual Private Network. FTI is obligated to provide the uniqueness and secure handling of the CPS. · The modules are delivered to the customer according to the procedures of FTI's Trusted Distribution System. Thus, an authorized FTI employee activates each sealed module before shipping. There is no possibility of power-on during shipment because the keys of the security lock and of the zeroization switch will be with FTI personnel traveling separately from the shipment. The keys will be given to the crypto-officer authorized by the customer. The crypto-officer, assisted by the FTI employee, will install the delivered module(s) (i.e., perform the initial start up and send the first outgoing message). After the installation, the crypto-officer will either assume the role of the user or he will designate and authorize the user to operate the module. The module enforces that only the crypto-officer(s), the bearer(s) of the security lock's key, and the user can operate the module. Similarly, the module enforces that only the crypto-officer, the bearer(s) of the key for the zeroization switch, can perform zeroization of the module and access to the MAIP. Both FTI and the customer will inventory the number on the keys. After installation, the module's security will be subjected to the customer's own security policy. · The module does not require scheduled maintenance. The metal construction of the unit, as well as the tamper evident seals (labels) over the tamper-resistant screws and edge of the Top Cover Plate, do not permit any type of hardware maintenance. The system diagnosis and software maintenance are performed through the secured MAIP. Both FTI and the customer will inventory the label number. FTI will not take any responsibility for malfunction of a tampered module or security breach due to tampering attacks. · To change the type or configuration of the module, or to change the unique Company Proprietary Signature, arrangements must be made with FTI. Any remanufacture \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 20 of 22 after zeroization, repair, maintenance, or test, etc., that requires human access to the module's interior can be performed only at FTI premises, under the controlled conditions described in Appendix: Maintenance at FTI Premises, of this document. 6.0 APPENDIX: Maintenance at FTI Premises Due to the module's design, the maintenance of the interior components is a rather complex task, and not a field-expedient process. Maintenance is considered a process that can be correctly and securely performed at a dedicated maintenance depot operated and controlled by the manufacturer. Thus, Vendor Requirement VE02.06.01 in the FIPS 140- 1 document, requiring detailing the field maintenance process, is not applicable. Maintenance actions or physical modifications (including changing the CPS) are done by opening the module case and testing or replacing the several hardware components contained within. Opening the module case breaches the tamper evident seals (labels) on the case exterior and provides evidence of the case opening. Only the vendor can replace this seal (label) with another one, which number will be again inventoried, after completion of the internal procedures to the module. Maintenance Zeroization. The critical data and security parameters contained inside the module, when powered on and in an operational state, are effectively zeroized, deleted when the zeroization switch/lock is activated. (Vendor Requirement VE 02.07.01). When this is done, the Host, MAC tables and cryptographic keys and other data that have been computed and stored in the volatile and flash memories are lost. In addition, if it is deemed necessary, the zeroization switch can be used by the crypto- officer at the client's site before sending the unit for maintenance, thus erasing everything from the flash. In this case, testing of the components is not possible; the flash has to be rewritten. Procedure for Authorized Maintenance (Change of the Company Proprietary Signature). Maintenance actions, as stated, requires returning the module to the vendor so that it may be opened and the internal components tested for proper operation. These tests (Vendor Requirement VE02.08.01) include the following items: 1. Visual inspection of the module on receipt, testing for case integrity, evidence of loose parts inside, ability of data interfaces to accept and retain standard network cables (RJ-45 type), inspecting status of all security labels, their integrity and serial numbers. 2. Module powered off and opened. Visual inspection of the physical integrity of all interior components, checking for loose connectors, hardware, fan, etc. 3. Module powered on, and the components are tested. \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 21 of 22 · Power Supply: Proper voltage output, proper ventilation/cooling with operating fan access unblocked. · System Board: Passes Power-On Self-Test (test with hardware diagnostic card). Boots to BIOS setting screen, parameters OK (test with video). Proper ventilation/cooling with operating fan properly mounted. Tests system board with hardware diagnostic card, if necessary. Tests of system memory (DRAM) for non-faulty operation, if necessary (can be part of above step, test done in place or externally). · Ethernet Cards Tests in diagnostic station, proper operation; proper configuration. · FlashDrive Tests in diagnostic station: Tests for proper boot-up, examines known memory location for valid activation string. Changes the CPS, if required. · General: Mechanical integrity of all option cards, jumpers, header pin connectors, riser card, and option cards fully seated in slot. Repairing items are generally limited to replacing the faulty component. In the case of any of the option cards (Ethernet or flash), reprogramming and return to service is a possibility. In the case of the system board, replacing the board is considered due to cost and availability of component- level repair of main boards. 4. Module assembled: Insert in test network and pass network traffic through the module, testing for connectivity using TCP/IP diagnostic (ICMP) packets or application type packets (typically FTP, file transfer protocol) between two end- point stations communicating through the module. Measure and record unit's performance. 5. Log information relative to the module, all part numbers, check that the activation string is present, attach the security labels and log the numbers on them, and return the module to the customer by the FTI Trusted Distribution (Section 3.5). 6. Replace the old module with a new one. Perform activation sequence on the replacement module, log all part numbers, attach the security labels and log the numbers on them, and return the new module to the customer by the FTI Trusted Distribution. -*-*-*- \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01 Security Policy for the Fortress Technology, Inc., NetFortress, Level 2, Multi-Chip Standalone Cryptographic Modules. Rev. 2 Page 22 of 22 7.0 Bibliography of References [1] FIPS140-1, "Security Requirements for Cryptographic Modules", Federal Information Processing Standards Publication 140-1, U.S. Department of Commerce/NIST, National Technical Information Service, Springfield, VA (1994). [2] "Information for FIPS 140-1 Certification of the Fortress Technologies, Inc. NetFortress 10 product". Fortress Technologies, Inc., Tampa, FL (July 1999). [2a] William N. Havener, Roberta J. Medlock, Lisa D. Mitchell, Robert J. Walcott: Derived Test Requirements for FIPS PUB 140-1, Security Requirements for Cryptographic Modules. Final March 1995. National Institute of Standards and Technology [3] Havener, W.N.; Medlock, J.; Mitchel, L.D; Walcott, R.J; "Derived Test Requirements for FIPS PVP140-1, Security Requirements of Cryptographic Modules", NIST/MITRE, (March, 1995). [4] NIST Special Publication 800-14, "Generally Accepted Principles and Practices for Securing Information Technology Systems", Swanson, M. and Guttman, B.; U.S. Department of Commerce, Technology Administration/NIST, (September, 1996). [5] Federal Information Processing Standard Publication (FIPS) 180-1, Secure Hash Standard. US Department of Commerce/National Institute of Standards and Technology, April 17, 1995 [6] NIST Validation Certification #100 for NetFortress 10. June 22, 2000 End of the " Security Policy for the Fortress Technology, Inc., NetFortress®, Level 2 Multi-Chip Standalone Cryptographic Modules. Rev. 2" Document \Fips\SecPol\SecPol_Rev2.doc S.K.,07/26/00 03/19/01