Non-Proprietary Security Policy for the FIPS 140-2 Level 2 Validated FC-X Firmware Version 5.1.2 (Document Version 2.5) December 2009 This security policy of Fortress Technologies, Inc., for the FIPS 140-2 Fortress Controller – X (FC-X), defines general rules, regulations, and practices under which the FC-X (or referred to as BRIDGE in the document) was designed and developed and for its correct operation. These rules and regulations have been and must be followed in all phases of security projects, including the design, development, manufacture service, delivery and distribution, and operation of products. Page 1 of 32 Copyright © 2009 Fortress Technologies, Inc., 4025 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Page 2 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Contents CONTENTS ................................................................................................................................... 3 LIST OF FIGURES AND TABLES ............................................................................................ 5 1.0 INTRODUCTION .............................................................................................................. 6 1.1 THE PURPOSE OF THIS DOCUMENT ................................................................................... 6 1.2 PRODUCTS ......................................................................................................................... 6 1.3 GLOSSARY OF TERMS........................................................................................................ 6 1.4 FUNCTIONAL DESCRIPTION............................................................................................... 9 1.5 PORTS AND INTERFACES ................................................................................................. 10 1.6 MOBILE SECURITY PROTOCOL (MSP) ............................................................................ 13 1.7 SECURE SOCKETS LAYER (SSL) ..................................................................................... 13 1.8 SECURE SHELL ................................................................................................................ 13 1.9 SECURE CONFIGURATION PROPAGATION (SCP)............................................................. 13 1.10 MANAGEMENT ................................................................................................................ 14 1.11 ALGORITHMS................................................................................................................... 14 1.12 OVERALL AND INDIVIDUAL FIPS 140-2 LEVELS............................................................ 16 2.0 IDENTIFICATION AND AUTHENTICATION POLICY.......................................... 17 2.1 ROLES.............................................................................................................................. 17 2.2 SERVICES......................................................................................................................... 17 2.3 AUTHENTICATION AND AUTHENTICATION DATA........................................................... 17 2.3.1 Authentication Methods ........................................................................................... 17 2.3.2 Authentication Server Methods................................................................................ 18 2.3.3 Authentication Strength ........................................................................................... 19 3.0 CRYPTOGRAPHIC KEYS AND CSP .......................................................................... 20 3.1 FOR MSP......................................................................................................................... 20 3.2 FOR SSL (TLS) AND SSH ............................................................................................... 21 3.3 CRITICAL SECURITY PARAMETERS ................................................................................. 22 4.0 ACCESS CONTROL POLICY....................................................................................... 23 4.1 ROLES EACH SERVICE IS AUTHORIZED TO PERFORM ...................................................... 23 4.2 ROLES WHO HAS ACCESS TO KEYS OR CSPS .................................................................. 23 4.3 ZEROIZATION .................................................................................................................. 24 4.4 UPGRADES....................................................................................................................... 25 4.4.1 Introduction ............................................................................................................. 25 4.4.2 Getting the Upgrade Software ................................................................................. 25 4.4.3 Integrity of the Upgrade BRIDGE Image ................................................................ 25 5.0 PHYSICAL SECURTY POLICY ................................................................................... 26 Page 3 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge 5.1 TAMPER EVIDENCE APPLICATION .................................................................................. 26 5.2 TAMPER EVIDENCE INSPECTIONS ................................................................................... 26 5.3 HARDWARE AND FIRMWARE DISTRIBUTION .................................................................. 26 6.0 FIRMWARE SECURITY ............................................................................................... 27 7.0 OPERATING SYSTEM SECURITY ............................................................................. 28 8.0 FIPS SELF TESTS ........................................................................................................... 29 9.0 SECURITY POLICY FOR MITIGATION OF OTHER ATTACKS POLICY ........ 30 10.0 EMI/EMC.......................................................................................................................... 31 11.0 CUSTOMER SECURITY POLICY ISSUES ................................................................ 32 11.1 FIPS MODE ..................................................................................................................... 32 11.2 ALTERNATING BYPASS MODE...................................................................................... 32 12.0 MAINTENANCE ISSUES............................................................................................... 32 Page 4 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge List of Figures and Tables Figure 1: BRIDGE Top Level Configuration ............................................................................. 6 Figure 2: Example Configuration................................................................................................ 9 Figure 3: Position of Intrusion Detection Screws ................................................................... 26 Table 1: Active Devices ................................................................................................................ 10 Table 2: Physical Ports .................................................................................................................. 11 Table 3: Logical Interface ............................................................................................................. 12 Table 4: FIPS Approved Algorithms............................................................................................ 15 Table 5: Non-FIPS Approved Algorithms................................................................................ 16 Table 6: Individual FIPS Level ..................................................................................................... 16 Table 7: Authentication Data..................................................................................................... 18 Table 8: Probability of Guessing the Authentication Password........................................... 19 Table 9: MSP Keys..................................................................................................................... 20 Table 10: SSL (TLS) and SSH Crypto Keys........................................................................... 21 Table 11: Other Keys and Critical Security Parameters ....................................................... 22 Table 12: Roles each Service is authorized to Perform ....................................................... 23 Table 13: Roles who has Access to Keys or CSPs............................................................... 24 Table 14: Defaults and Zeroization .......................................................................................... 25 Table 15: Recommended Physical Security Activities.......................................................... 26 Table 16: Self Tests ................................................................................................................... 29 Page 5 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Introduction 1.0 The Purpose of this Document 1.1 This security policy defines all FIPS 140-2 overall level 2 security rules under which the FC-X (also referred to as Bridge) complies with and enforces. The Bridge is a multi-chip standalone module. Products 1.2 The current Bridge products this Security Policy is relevant to are identified as: Hardware: FC-X Where X = 250, 250SB(Suite B), 500, 500SB, 1500, 1500SB Firmware Version: 5.1.2 The top level configurable hierarchy is shown in Figure 1. Figure 1: BRIDGE Top Level Configuration Glossary of Terms 1.3 • AES (Advanced Encryption Standard): also known as Rijndael, is a block cipher adopted as an encryption standard by the U.S. government. • ANSI (American National Standards Institute): a private non-profit organization that oversees the development of voluntary consensus standards for products, services, processes, systems, and personnel in the United States • CBC (cipher-block chaining): A mode of operation where each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block is dependent on all plaintext blocks processed up to that point. Also, to make each message unique, an initialization vector must be used in the first block. • Crypto Officer (Crypto Officer): an operator or process (subject), acting on behalf of the operator, performing cryptographic initialization or management functions. Page 6 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge • CTR (Counter): generates the next keystream block by encrypting successive values of a "counter". The counter can be any simple function which produces a sequence which is guaranteed not to repeat for a long time. It allows a random access property during decryption. The IV/nonce and the counter can be concatenated, added, or XORed together to produce the actual unique counter block for encryption. • Diffie-Hellman: is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher. • ECB (Electronic codebook): This is the simplest of the encryption modes. The message is divided into blocks and each block is encrypted separately. The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all. • EAP (Extensible Authentication Protocol): is a universal authentication framework frequently used in wireless networks and Point-to-Point connections. • EAP-TLS: is an IETF open standard that is the original standard wireless LAN EAP authentication protocol, and is well-supported among wireless vendors. • HMAC (Hash Message Authentication Code): a keyed Hash Message Authentication Code is a type of message authentication code (MAC) calculated using a specific algorithm involving a cryptographic hash function in combination with a secret key. • HTTPS: Hypertext Transfer Protocol over Secure Socket Layer • MAC (Message Authentication Code): a short piece of information used to authenticate a message. • MIC (Message Integrity code): is a short piece of information used to check the integrity of a message. This is the same as a MAC. Normally in communications this would be called a MAC (Message Authentication Code) however since the term MAC is used in IEEE 802 products to mean the physical address of a Network Interface Card the term MIC was created. • Mode: In cryptography, a block cipher operates on blocks of fixed length, often 64 or 128 bits. Because messages may be of any length, and because encrypting the same plaintext under the same key always produces the same output (as described in the ECB), several modes of operation have been invented which allow block ciphers to provide confidentiality for messages of arbitrary length. • Multi-factor Authentication™: The BRIDGE guards the network against illicit access by checking three levels of access credentials before allowing a connection. o Network authentication mandates that connecting devices use the correct shared identifier for the network. The Fortress Security System requires all members of a secure network to authenticate with the correct Access ID. o Device authentication mandates that a connecting device is individually recognized on the network through its unique device identifier. The Fortress Security System requires each device to authenticate on the secure network with the unique Device ID generated for that device. Page 7 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge User authentication requires the user of a connecting device to enter a o recognized user name and valid credentials, a password, for example, or a digital certificate. The Fortress Security System can authenticate users locally • Nonce: stands for number used once. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. • PRNG (pseudorandom number generator): is an algorithm for generating a sequence of numbers that approximates the properties of random numbers. The sequence is not truly random in that it is completely determined by a relatively small set of initial values, called the PRNG's state. • RNG (Random Number Generator): is a computational or physical device designed to generate a sequence of numbers or symbols that lack any pattern, i.e. appear random. • SHA (Secure Hash Algorithm): these are a set of cryptographic hash functions designed by the National Security Agency (NSA) and published by the NIST as a U.S. Federal Information Processing Standard. • TRNG (True Random Number Generator): This is the Fortress implementation of a non-deterministic Random Number Generator. The design of the TRNG contains two free-running oscillators, a fast and slow one. Neither is intentionally related in any way, and indeed the relationship changes with physical affects. The basic principle of operation is that the slow oscillator samples the fast one, and it is the thermal jitter effects present on the slow oscillator which are “measured” as the sources of random entropy. The TRNG is used to generate real cryptographically strong random numbers to use as seeds into the PRNG. The PRNG are started from this arbitrary starting state, using the TRNG ‘random’ seed state. • TLS (Transport Layer Security): Along with its predecessor the Secure Sockets Layer (SSL) are cryptographic protocols that provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. TLS in this module is implemented by using SSL 3.1. • ANSI X9.31 PRNG: This is a cryptographically secure pseudo-random number generator with properties that make it suitable for use in cryptography. Page 8 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Figure 2: Example Configuration Functional Description 1.4 The Bridge is a standalone hardware and firmware cryptographic module and security gateway designed to prevent a hacker from “sniffing” and reading data transferred across a wired or wireless network. Here -X in FC-X suffix indicates the number of active devices served by the module as shown in Table 1. This is determined by the License Key that is entered into the GUI. The License key will dictate the performance (therefore Maximum Active Devices) or whether Suite B is enabled in the product. The initial License Key is configured at manufacturing however a customer can upgrade by purchasing the appropriate License Key. When Suite B is installed the module configuration is becomes an “SB” as shown in the table below (for instance FC-250SB). Page 9 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Table 1: Active Devices Module Maximum Active With Configuration Devices Suite B FC-250 500 FC-250SB 500 √ FC-500 1000 FC-500SB 1000 √ FC-1500 3300 FC-1500SB 3300 √ This is a security appliance that provides a secure edge to the corporate network by protecting communications between other wireless devices and the rest of the network as shown in Figure 2. Because the Bridge implements encryption at the Media Access Control (MAC) layer, not only does it protect important network information, it functions as a transparent LAN BRIDGE so it can be quickly and transparently integrated into an existing network. Operation is almost automatic, requiring no or little administrator intervention as it protects data transmitted on WLANs (wireless LANs) and between WLAN devices and the wired local area network and over an IP network. The Bridge’s hardware is a 1U rack mount unit. The Bridge can be quickly and transparently integrated into an existing network to provide enhanced FIPS 140-2 security. The Bridge has two data Input or output interfaces, one Console interface and one Aux interface (not used). Either of the interfaces can be used within a Clear Text Zone1 or Encrypted Zones2. The unit is powered with standard AC current. The Bridge can accept secure or unsecured connections from the wireless or wired devices. Ports and Interfaces 1.5 Only data entering and leaving the physical ports through logical interfaces is processed by the cryptographic module. 1 Clear Text Zone refers to the portions of the network that are trusted and that the FC-X will normally only send and receive packets that have not been FIPS encrypted. These could be packets that have come from a encrypted zone that have been decrypted or packet that have originated from the FC-X like from the GUI, CLI or SNMP. 2 Encrypted Zone refers to the portions of the network that are untrusted and that the FC-X will normally only send or receive encrypted packets. Page 10 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Physical Ports Table 2: Physical Ports Physical Ports Description LAN – Ethernet- Encrypted A Ethernet Interface that is used to connect to the encrypted zone. Optical – Encrypted A high speed optical interface that is used to connect to the encrypted zone. LAN – Ethernet- Unencrypted A Ethernet Interface that is used to connect to the unencrypted zone. Optical – Unencrypted A high speed optical interface that is used to connect to the unencrypted zone. Aux – Ethernet (Not Used) Not Used Console Serial port used to connect to a terminal Power AC Power Input Front Panel LCD LCD Display used for limited system monitoring Front Panel Push Button Push Buttons used to scroll through line menu viewed on the LCD LED LEDs used for limited alerts Page 11 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Logical Interfaces Table 3: Logical Interface Type Logical Interface Description Data In Plaintext data can come in or be Plaintext User Data and sent out through this logical Data Out interface. Ciphertext or encrypted user Ciphertext User Data data can come in or sent out. this (AES, 3DES, RSA) logical interface. Control A crypto officer can connect to GUI Input the MODULE using a Browser for control and configuration. A crypto officer can connect to CLI the MODULE using a terminal, terminal emulator or a SSH connection for control and configuration. Can be used to reset the Front Panel Interface BRIDGE to a default configuration. Status Out A crypto officer can connect to GUI the MODULE using a Browser to view configuration and status information. A crypto officer can connect to CLI the MODULE using a terminal, terminal emulator or a SSH connection to view configuration and status information. Four LEDs are shown: LED • Power: Power On • Status: FIPS Error • Cleartext: Bypass Mode • Failover: Not used Used to view limited information Front Panel Interface about the BRIDGE. Notes • The MODULE GUI uses a standard “off the shelf” workstation and browser and CLI uses a standard terminal or a workstation using SSH. • The operation of the buttons or switches are explained in the respective User Guide. • Direct connect CLI (uses a terminal or terminal emulator). • SSL (TLS) GUI, SSH CLI and SNMP operate using the IP protocol over a FIPS secure connection from a workstation. These packets enter over the Ethernet Page 12 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge ports along with data packets. Once the packets are decoded and queued they are processed separately. Data packets are encrypted or unencrypted and passed through to the other Ethernet interface. Control and status packets are either absorbed by the device or sent out as an IP packet. Mobile Security Protocol (MSP) 1.6 MSP is used to secure connections between an End User and the BRIDGE. MSP uses the Diffie-Hellman (D-H) or Elliptical Curve Cryptography Diffie-Hellman (ECDH) for key generation and agreement, AES-CBC for encryption and Multi-factor Authentication for added protection for clients The BRIDGE supports the National Security Agency Suite B recommendations using the 384 bit prime-modulus curve. Once it’s installed and configured, operation is automatic, requiring no or little administrator intervention as it protects data transmitted on WLANs and between WLAN devices and the wired LAN. For peer-to-peer packets MSP uses a dual Diffie-Hellman or ECDH key generation method that will not only protect user packets but will also protect against “Man in the Middle” attacks. The Dynamic Secret Encryption Key results from the Diffie-Hellman key agreement process. User’s Peer-to Peer packets are AES encrypted using this Dynamic Secret Encryption Key. The encryption keys used for AES are equal to or greater than 80 bit strength as defined by NIST Special Publication 800-57 and the key establishment method as defined in NIST Special Publication 800-56A. Secure Sockets Layer (SSL) 1.7 The SSL or TLS protocols are used to secure HTTPS connections into the BRIDGE GUI that a Crypto Officer can use for administration. SSL and TLS provides confidentiality, integrity, and message digest services. OpenSSL toolkit version 1.1.1 with patch was used in the creation of the SSL and TLS library. Secure Shell 1.8 The SSH protocol is used to secure remote terminal connections into the BRIDGE that a Crypto Officer can use for administration. The SSH protocol uses the same cryptographic algorithms as SSL. Secure Configuration Propagation (SCP) 1.9 In a mesh network of bridges, a user can designate one of them as the network’s Secure Configuration Propagation (SCP) master bridge and then use the SCP master to automatically propagate configuration changes to the rest of the network Bridges. SCP runs only over AES encrypted MSP interfaces3, so the Crypto Officer must pre- configure and deploy a network connected only through interfaces in the Bridge’s encrypted zone. 3 It will use the active configuration, default if nothing was configured or the current configuration. Page 13 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge The Bridge to be included in an SCP network or must be at their factory-default settings. The SCP slave Bridges receive and adopt the settings propagated from the master Bridge. Management 1.10 The BRIDGE is managed by the following: • Internet browser through the Graphical User Interface (GUI); • A directly connected terminal plugged into the Console Port through the Command Line Interface (CLI); • A remote workstation using SSH through the CLI; • using SNMP Version 3 Network Station or Utility. Algorithms 1.11 This software contains three different security methods MSP, SSL (TLS) and SSH. MSP secures End User data while SSL (TLS) and SSH will secure Crypto Officer connections to the BRIDGE. The non-FIPS algorithms are detailed in Table 5. Page 14 of 32 Copyright © 2009 Fortress Technologies, Inc., 4023 Tampa Rd., Suite 2200, Oldsmar, FL 34677 This document can be reproduced and distributed only whole and intact, including this copyright notice. Security Policy for the Fortress Secure Bridge Table 4: FIPS Approved Algorithms Algorithm Cert Implementation Operational Val Date Modes/States/Key sizes/ # Environment Description/Notes AES ECB(e/d; 128,192,256); CBC(e/d; 852 Fortress Secure Broadcom MIPS 8/28/2008 128,192,256) Bridge Algorithms Processor AES CBC(e/d; 128,192,256) 389 FC-X Algorithms Xilinx Spartan 5/12/2006 FPGA AES ECB(e/d; 128,192,256); CBC(e/d; 853 Fortress Secure Broadcom MIPS 8/28/2008 128,192,256); CFB8(e/d; 128,192,256); Bridge Algorithms Processor CFB128(e/d; 128,192,256); OFB(e/d; (SSL) 128,192,256) TDES TECB(e/d; KO 1,2); TCBC(e/d; KO 1,2); 703 Fortress Secure Broadcom MIPS 8/28/2008 TCFB8(e/d; KO 1,2); TCFB64(e/d; KO 1,2); Bridge Algorithms Processor TOFB(e/d; KO 1,2) (SSL) RSA ALG[RSASSA-PKCS1_V1_5]; SIG(gen); 488 Fortress Secure Broadcom MIPS 3/12/2009 SIG(ver); 2048 , SHS: SHA-1 Bridge Algorithms Processor (SSL) SHA SHA-1 (BYTE-only) 845 Fortress Secure Broadcom MIPS 8/28/2008 SHA-256 (BYTE-only) Bridge Algorithms Processor SHA-384 (BYTE-only) SHA-512 (BYTE-only) SHA-1 SHA-1 (BYTE-only) 721 Fortress SWAB FPGA Xilinx Spartan 1/17/2008 Algorithms FPGA SHA-256 SHA-256 (BYTE-only) 722 Fortress SWAB SHS Xilinx Spartan 1/17/2008 SHA-512 (BYTE-only) and HMAC FPGA SHA-512 SHA-384 SHA-384 (BYTE-only) 715 Fortress SWAB SHS- Xilinx Spartan 12/31/2007 384 Algorithm FPGA SHS SHA-1 (BYTE-only) 846 Fortress Secure Broadcom MIPS 8/28/2008 SHA-224 (BYTE-only) Bridge Algorithms Processor SHA-256 (BYTE-only) (SSL) SHA-384 (BYTE-only) SHA-512 (BYTE-only) HMAC Fortress Secure 469 Broadcom MIPS 8/28/2008 HMAC-SHA1 (Key Sizes Ranges Tested: Bridge Algorithms Processor KS=BS ) SHS Cert#845 HMAC-SHA256 ( Key Size Ranges Tested: KS=BS ) SHS Cert#845 HMAC-SHA384 ( Key Size Ranges Tested: KS=BS ) SHS Cert#845 HMAC-SHA512 ( Key Size Ranges Tested: KS=BS ) SHSCert#845 HMAC Fortress SWAB FPGA 371 Xilinx Spartan 1/17/2008 HMAC-SHA1 (Key Sizes Ranges Tested: Algorithms FPGA KS