iDirect Technologies Secure Satellite Broadband Solutions with iDS version 7.1.2 (Hardware: 7350 iNFINITI Satellite Router (Part #9130-0062-0002), iConnex-700 (Part #9101- 2040-0201), iConnex-100 (Part #9101-2040-0202), and M1D1-T ULC (Part #9101-0040-0008)) FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document Version 2.0 Prepared for: Prepared by: iDirect Technologies Corsec Security, Inc. 13865 Sunrise Valley Drive 10340 Democracy Lane, Suite 201 Herndon, VA 20171 Fairfax, VA 22030 Phone: (866) 345-0983 Phone: (703) 267-6050 Fax: (703) 648-8014 Fax: (703) 267-6810 http://www.idirect.net http://www.corsec.com © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Table of Contents 1 INTRODUCTION ...............................................................................................................................................3 1.1 PURPOSE .........................................................................................................................................................3 1.2 REFERENCES...................................................................................................................................................3 1.3 DOCUMENT ORGANIZATION ...........................................................................................................................3 2 SECURE SATELLITE BROADBAND SOLUTIONS.....................................................................................4 2.1 OVERVIEW......................................................................................................................................................4 2.2 MODULE INTERFACES.....................................................................................................................................5 2.3 ROLES AND SERVICES .....................................................................................................................................7 2.3.1 Crypto-Officer Role ...............................................................................................................................7 2.3.2 User Role .............................................................................................................................................10 2.3.3 Client User Role ..................................................................................................................................11 2.4 PHYSICAL SECURITY ....................................................................................................................................11 2.5 OPERATIONAL ENVIRONMENT ......................................................................................................................13 2.6 CRYPTOGRAPHIC KEY MANAGEMENT ..........................................................................................................13 2.7 SELF-TESTS ..................................................................................................................................................15 2.8 DESIGN ASSURANCE .....................................................................................................................................15 2.9 MITIGATION OF OTHER ATTACKS.................................................................................................................15 3 SECURE OPERATION....................................................................................................................................16 3.1 CRYPTO-OFFICER GUIDANCE .......................................................................................................................16 3.1.1 Initialization.........................................................................................................................................16 3.1.2 Management ........................................................................................................................................16 3.2 USER GUIDANCE ..........................................................................................................................................17 3.3 CLIENT USER GUIDANCE ..............................................................................................................................17 4 ACRONYMS......................................................................................................................................................18 Table of Figures FIGURE 1 - IDIRECT NETWORK DEPLOYMENT ................................................................................................................4 FIGURE 2 - CRYPTOGRAPHIC MODULE BLOCK DIAGRAM ...............................................................................................6 FIGURE 3 - 7350 INFINITI SATELLITE ROUTER ...........................................................................................................12 FIGURE 4 - 700-T INFINITI ICONNEX AND M1D1-T UNIVERSAL LINE CARD .............................................................12 FIGURE 5 - ICONNEX-100 .............................................................................................................................................12 Table of Tables TABLE 1 - SECURITY LEVEL PER FIPS 140-2 SECTION ...................................................................................................5 TABLE 2 - FIPS 140-2 LOGICAL INTERFACES .................................................................................................................7 TABLE 3 - MAPPING OF CRYPTO-OFFICER ROLE'S GENERAL SERVICES TO CSPS AND TYPE OF ACCESS .......................8 TABLE 4 - MAPPING OF CRYPTO-OFFICER M1D1-T PLATFORM SPECIFIC SERVICES TO CSPS AND TYPE OF ACCESS ....9 TABLE 5 - MAPPING OF CRYPTO-OFFICER REMOTE PLATFORM SPECIFIC SERVICES TO CSPS AND TYPE OF ACCESS.....9 TABLE 6 - MAPPING OF USER ROLE'S SERVICES TO INPUTS AND OUTPUTS ..................................................................11 TABLE 7 - MAPPING OF CLIENT USER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS .............11 TABLE 8 - LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS .....................................13 TABLE 9 - ACRONYMS ..................................................................................................................................................18 iDirect Secure Satellite Broadband Solutions Page 2 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Secure Satellite Broadband Solutions from iDirect Technologies. This Security Policy describes how the Secure Satellite Broadband Solutions with iDS version 7.1.2 (hardware: 7350 iNFINITI Satellite Router (Part #9130-0062-0002), iConnex-700 (Part #9101-2040- 0201), iConnex-100 (Part #9101-2040-0202), and M1D1-T ULC (Part #9101-0040-0008)) meet the security requirements of FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/cryptval/ The Secure Satellite Broadband Solutions with iDS version 7.1.2 (7350 iNFINITI Satellite Router, iConnex-700, iConnex-100, and M1D1-T ULC) are referred to in this document as the cryptographic modules, the hardware modules, or the modules. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: · The iDirect website (http://www.idirect.net) contains information on the full line of products from iDirect. · The CMVP website (http://csrc.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: · Vendor Evidence document · Finite State Machine · Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to iDirect. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to iDirect and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact iDirect. iDirect Secure Satellite Broadband Solutions Page 3 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 2 Secure Satellite Broadband Solutions 2.1 Overview An iDirect Time Division Multiple Access (TDMA) network is composed of a single outroute Single Channel Per Carrier (SCPC) and multiple inroute TDMA carriers. The iDirect TDMA network is optimized for satellite transmissions, squeezing the maximum performance out of the bandwidth provided by satellite links. The system is fully integrated with iDirect's Network Management System that provides configuration and monitoring functions. The iDirect network components consist of the network management server, protocol processor, Hub Line Card (also known as Universal Line Card), and the Ethernet switch with remote modem. In a star topology, the protocol processor acts as the central network controller, the Universal Line Card (ULC) is responsible for the hub side modulation and demodulation (modem) functions, and the remote modem provides modem functionalities for the Ethernet switch. iDirect's Transmission Security (TRANSEC) feature enables encryption to all Data Link Layer traffic flowing between the ULC and Remote modem using Advanced Encryption Standard (AES). The hardware modules provide TRANSEC features to the TDMA network. The module encrypts the layer 2 traffic with a single global AES 256 key, common to all components. Authentication and key distribution information is protected with Rivest Shamir Adlemann (RSA) 2048 using X.509 certificates. A common deployment of the iDirect network components is shown below. Figure 1 - iDirect Network Deployment TRANSEC is managed by software. One key set is created for the entire network. All participants of the network then share the key set. Encryption of data occurs in FPGA firmware. TRANSEC encrypts all data in Layer 2, so even the High-level Data Link Control (HDLC) sources and destinations of packets are encrypted. Multicast and broadcast data is also encrypted. Since the key set is shared among the network, every members of the network can receive and decrypt all data. TRANSEC makes a particular effort to prevent traffic analysis by outside parties. Link Encryption occurs completely in software. Each remote and its counterpart layer in the protocol processor creates a transmit key (Link Encryption Key, See Table 8) and distributes this to its peer, using the same key transport method as TRANSEC. Link encryption is point-to-point, so each remote has a unique key for receiving and transmitting data. Layer 2 data such as sources and destination link addresses is not encrypted. Broadcast and multicast traffic is not encrypted either. Therefore, link level information, such as HDLC destinations, is not protected by Link Encryption. iDirect Secure Satellite Broadband Solutions Page 4 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 The cryptographic modules, known as the Secure Satellite Broadband Solutions, provide the secured traffic routing services. The hardware module runs Linux version 2.4.24-uc0-iDirect0 operating system. The platforms for the cryptographic module are Printed Circuit Boards (PCBs) for the 7350 iNFINITI Satellite Router (Part #9130-0062- 0002), iConnex-700 (Part #9101-2040-0201), iConnex-100 (Part #9101-2040-0202), and M1D1-T ULC (Part #9101-0040-0008). The Secure Satellite Broadband Solutions are validated at the following FIPS 140-2 Section levels: Table 1 - Security Level per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 4 Finite State Model 1 5 Physical Security 1 6 Operational Environment 1 7 Cryptographic Key Management 1 8 Electromagnetic Interference (EMI) / 1 Electromagnetic Compatibility (EMC) 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Interfaces The Cryptographic boundaries of the modules are the iDirect PCBs that run the iDS software, which is referred to as "falcon". Per FIPS 140-2 terminology, the Secure Satellite Broadband Solutions are multi-chip embedded modules that meets overall level 1 security requirements. Physically, the PCB is the cryptographic boundary. Figure 2 depicts the physical block diagram and the cryptographic boundary of the modules, which is indicated below using the blue broken line. iDirect Secure Satellite Broadband Solutions Page 5 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Figure 2 - Cryptographic Module Block Diagram Physical ports do not differ on different platforms to be validated. The following is a list of the physical ports for the modules that are enabled in the FIPS mode of operation: · Receiver Coaxial Connector (Rx) · Transmitter Coaxial Connector (Tx) · Power connector · 10/100 Ethernet ports (RJ45) · One console port (serial over an RJ45) · Light Emitting Diodes (LEDs) The numbers of Ethernet ports are not the same for all modules. The 7350 iNFINITI Satellite Router has nine (9) Ethernet ports. The iConnex-700, iConnex-100, and M1D1-T ULC have two (2) Ethernet ports. For the iConnex-700, iConnex-100, and M1D1-T ULC, the choice of how to display the LEDs is determined by the integrator of the PCBs. The LED functions are handled by the falcon application. For the 7350 iNFINITI Satellite Router, the meanings of LEDs are defined as follows. · The Power LED indicates whether the unit is powered On or Off. · The Status LED indicates the unit's overall status. · The Network LED indicates the unit's network acquisition status. · The Tx LED indicates the unit's transmitter status. · The Rx LED indicates the unit's receiver status. The 7350 iNFINITI Satellite Router has two (2) Ethernet ports marked "ICC In" and "ICC Out" that are disabled in firmware and software. All of the interfaces that are enabled, as well as physical interfaces, can be categorized into logical interfaces defined by FIPS 140-2, as described in the following table: iDirect Secure Satellite Broadband Solutions Page 6 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Table 2 - FIPS 140-2 Logical Interfaces FIPS 140-2 Logical Interface Secure Satellite Broadband Solutions Port/Interface Data Input Rx, Ethernet ports Data Output Tx, Ethernet ports Control Input Rx, Ethernet ports, console port Status Output Tx, Ethernet ports, console port, LEDs (7350 iNFINITI Satellite Router only) Power Not applicable 2.3 Roles and Services The module supports role-based authentication. There are three roles in the module that operators may assume: Crypto-Officer role, User role, and Client User role. 2.3.1 Crypto-Officer Role The Crypto-Officer role is implicitly assumed when performing installation, configuration and monitoring services for the module. The Crypto-Officer accesses the module locally over the console port or remotely over a secured session. There are four different interfaces that can be used for management purposes: · Console ­ The Crypto-Officer locally manages the module by directly connecting through the console port (RJ45 over Serial port). The Crypto-Officer has to authenticate with account name "admin" and a password to access any services. The Crypto-Officer is authorized to change its own password and the passwords of User Role accounts ("user" and "diagnostic"). · Remote Command Line Interface (CLI) ­ The module can be configured and monitored over a remote CLI management interface using Secure Shell (SSH). The Crypto-Officer authenticates with a password to access any services. The module performs a Diffie-Hellman (DH) key agreement mechanism to initialize the SSH session. · Management Interface over Transport Layer Security (TLS) ­ The module can also be configured and monitored using a Graphical User Interface (GUI) over a TLS session, such as the iBuilder and iMonitor applications which require a user name and password for access. The module performs RSA authentication and key transport during the TLS handshake (the Crypto Officer password is not required). · Management over Satellite ­ Over the satellite channel, the module can perform low-level configuration and monitoring (all non-security-relevant). This consists of low-level link management (such as timeplans) sent by the protocol processor to the modules for which authentication is not required. The protocol processor will only sent Layer 2 Reset messages when prompted to do so by a password authenticated user. Telnet is not an external interface, but it is available internal to the Linux operating system. On the console, in order to login as "admin", the Crypto-Officer has to first log into the Linux operating system using the "root" account and the applicable password and then telnet to the localhost (telnet 0). The Crypto-Officer must then enter "admin" and the password at the prompt. When the Crypto-Officer accesses the module via SSH, he is able to bypass the "root" authentication and logs into the CLI interface directly with the "admin" account and the appropriate password. Table 3, Table 4, and Table 5 list all CLI services for to a Crypto-Officer. The services available to the User role (see Table 6) are also available to a Crypto-Officer. The CLI services can be categorized in three different groups: 1. General Services: Common functions to the iDS software. 2. Hub Specific Services: These services are only accessible on the M1D1-T ULC platform. iDirect Secure Satellite Broadband Solutions Page 7 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 3. Remote Specific Services: Services specific to the 7350 iNFINITI Satellite Router, iConnex-700, and iConnex-100 platforms. Crypto-Officer enters commands with the appropriate parameters to access the services of the module and the module outputs the command response. Descriptions of the services available to the Crypto-Officer role are provided in the tables below. The following tables also list all Critical Security Parameters (CSPs) involved in the services and associated access controls. Table 3 - Mapping of Crypto-Officer Role's General Services to CSPs and Type of Access Service Description CSP and Type of Access arp Address Resolution Protocol (ARP) control Secured Session Key ­ Read cpu Show Central Processing Unit (CPU) utilization Secured Session Key ­ Read percentage csp enable/disable csp mode Secured Session Key ­ Read delay Usage: delay Secured Session Key ­ Read dgm_pkg_rx Datagram Package Download Receiver control Secured Session Key ­ Read dma Direct Memory Access (DMA) status Secured Session Key ­ Read dumpb Dumps bursts received on hub Secured Session Key ­ Read ENTER_ERROR_STATE Enter Error state Secured Session Key ­ Read eth Configure a network interface Secured Session Key ­ Read extras Extras option file manipulation Secured Session Key ­ Read fll Allows to query the status of the hardware's frequency Secured Session Key ­ Read lock loop hdlc HDLC stats Secured Session Key ­ Read hookstatus (not available in Protocol hookup status Secured Session Key ­ Read FIPS mode) igmp Multicast control Secured Session Key ­ Read ip Router control Secured Session Key ­ Read keyroll_mgr Keyroll manager command Global Session Key ­ Read/Write Secured Session Key ­ Read mac Media Access Control (MAC) control Secured Session Key ­ Read mux (not available in FIPS Multiplexer (MUX) Table Dump Secured Session Key ­ Read mode) netstat Checks network configuration and activity Secured Session Key ­ Read nmsr Debug network management system Reporting object Secured Session Key ­ Read (event message sender) oob Out of Band (OOB) control Secured Session Key ­ Read options Options file manipulation Secured Session Key ­ Read params View/edit global parameters Secured Session Key ­ Read pasoc Command for the packet socket layer Secured Session Key ­ Read passwd Change password Password - Write Secured Session Key ­ Read pcmd Periodic console Command Secured Session Key ­ Read iDirect Secure Satellite Broadband Solutions Page 8 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Service Description CSP and Type of Access peek Raw memory read - can be dangerous Secured Session Key ­ Read ping Ping Utility Secured Session Key ­ Read poke Raw memory write - can be dangerous Secured Session Key ­ Read service Service start/stop command Secured Session Key ­ Read status show status of stack Secured Session Key ­ Read systray Debugs systray messages (mulicast messages sent on Secured Session Key ­ Read the Local Access Network or LAN) timer Timer control Secured Session Key ­ Read tls Transport Layer Security (TLS) control Secured Session Key ­ Read tls_mnc Debugs the secure MnC control server Secured Session Key ­ Read transec TRANSEC related Field Programmable Gate Array Secured Session Key ­ Read (FPGA) registers stats transec_layer Management command for the protocol layer which Secured Session Key ­ Read communicates packet by packet instructions to the FPGA firmware uptime System and application uptime Secured Session Key ­ Read x509 Manage X509 Certificates and RSA keys X.509 Certificate - Read/Write Secured Session Key ­ Read zeroize Zeroize all CSPs All CSPs ­ Delete Table 4 lists Crypto-Officer services that are provided on the M1D1-T ULC platform only. Table 4 - Mapping of Crypto-Officer M1D1-T Platform Specific Services to CSPs and Type of Access Service Description CSP and Type of Access cert_mgr cert manager command X.509 Certificate ­ Read/Write Secured Session Key ­ Read da_tunnel Shows statistics for the tunnel between an external process Secured Session Key ­ Read and the hub line card diagnostic Diagnostic Command Secured Session Key ­ Read na_tunnel Shows the statistics parameters for a tunnel from the hub line Secured Session Key ­ Read card and an external process standby Standby Command Secured Session Key ­ Read tplog Timeplan Log Secured Session Key ­ Read tunnel Tunnel control Secured Session Key ­ Read tunnel_control Tunnel controller command Secured Session Key ­ Read Table 5 lists Crypto-Officer services that are provided on the 7350 iNFINITI Satellite Router, iConnex-700, and iConnex-100 platforms. Table 5 - Mapping of Crypto-Officer Remote Platform Specific Services to CSPs and Type of Access Service Description CSP and Type of Access acq Enables acquisition debugging Secured Session Key ­ Read iDirect Secure Satellite Broadband Solutions Page 9 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Service Description CSP and Type of Access csp enable/disable csp mode Secured Session Key ­ Read delay Usage: delay Secured Session Key ­ Read dhcp DHCP server command Secured Session Key ­ Read enc Encryption control command Secured Session Key ­ Read encs Encryption session control command Secured Session Key ­ Read gre Generic Routine Encapsulation (GRE) protocol Secured Session Key ­ Read icmp Internet Control Message Protocol (ICMP) inspection layer console Secured Session Key ­ Read command ipv4 IPv4 protocol acceleration control layer Secured Session Key ­ Read ktun Kernel Tunnel Command Secured Session Key ­ Read ll Link Layer control Secured Session Key ­ Read mesh Forces the remote out of mesh Secured Session Key ­ Read meshdebug Mesh Debug Secured Session Key ­ Read oob OOB control Secured Session Key ­ Read ota Over-The-Air statistics Secured Session Key ­ Read pad Packet Assembler Disassembler (PAD) control Secured Session Key ­ Read qos QoS control Secured Session Key ­ Read remotestate Displays the current remote state Secured Session Key ­ Read rlock Locks the remote to work in a specific network Secured Session Key ­ Read rmtarp Mesh ARP table Secured Session Key ­ Read rmtstat Toggle printing Remote Status messages Secured Session Key ­ Read phy read physical layer status register Secured Session Key ­ Read pm Pad upper Mux stats Secured Session Key ­ Read sar Segementation and Reassembly (SAR) control Secured Session Key ­ Read satmac Debugs the satellite MAC layer Secured Session Key ­ Read sd Sar lower Mux stats Secured Session Key ­ Read spoof Spoof Command Secured Session Key ­ Read systray Debugs systray messages (mulicast messages sent on the Local Access Secured Session Key ­ Read Network or LAN) ucp Display UCP information Secured Session Key ­ Read udp UDP Command Secured Session Key ­ Read udp_compress UDP Payload compress Secured Session Key ­ Read vlan Virtual Local Area Network (VLAN) control Secured Session Key ­ Read 2.3.2 User Role The User has the ability to access the falcon console over the satellite network. On the console, the User is authenticated with account name "user" or "diagnostic" and a password to access any services. In order to login as "user" or "diagnostic", the User has to first log into the Linux operating system with the "root" account and the applicable password and then telnet to the localhost (telnet 0). The User must then enter iDirect Secure Satellite Broadband Solutions Page 10 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 "user" or "diagnostic" and the appropriate password at the prompt. Accounts "user" and "diagnostic" employ the same password authentication mechanism. Passwords are configured and controlled by the Crypto-Officer with the "admin" account. The "user" and "diagnostic" accounts do not have the privilege to change passwords. The services available to the User role ("user" and "diagnostic" accounts) do not involve viewing or modifying CSPs. See Table 6. Table 6 - Mapping of User Role's Services to Inputs and Outputs Service Description Input Output DID Show identification number Command Identification number sn Show modem serial number Command Serial number clear Clear screen Command Screen cleared eloop Display event loop status Command Event loop status reset Reset machine or service Command Command status packages Get detailed installed package information Command Package information ps Report the process status Command Process status version Get build information Command Build information mem Get resource information Command Resource information heap Get memory usage information Command Memory usage laninfo View IP address/netmask Command IP address and netmask latlong Report Global Positioning System (GPS) information Command GPS information of a locally of a locally attached GPS device, if one is present. attached GPS devic versions_report Display full operating environment report Command Full operating environment report 2.3.3 Client User Role The Client User accesses the module over the Ethernet ports and utilizes the module's traffic routing and link encryption services. The Client User role is implicitly assumed by a network device or application routing traffic through the module. Table 7 - Mapping of Client User Role's Services to Inputs, Outputs, CSPs, and Type of Access Service Description Input Output CSP and Type of Access Traffic Routing Secured traffic routing at the data-link layer Data Link layer Data Link layer Global Session Key packet packet - Read Multicast Packet After individual component of the multicast "Reset" option is Command No Reset packet is extracted and written to the modem's checked status flash memory, the modem resets if the "Reset" option was checked. 2.4 Physical Security The Secure Satellite Broadband Solutions are multi-chip embedded cryptographic modules per FIPS 140-2 terminology. The 7350 router platform is a PCB that is surrounded by a metal case entirely enclosing the internals of the module and the case itself is removable using screws or hand screws. The 7350 router, shown in Figure 3 below, is being validated as a multi-chip embedded module for level 1. iDirect Secure Satellite Broadband Solutions Page 11 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Figure 3 - 7350 iNFINITI Satellite Router 700-T iNFINITI iConnex, iConnex-100, and M1D1-T Universal Line Card are PCBs that consist of production grade components and are validated as multi-chip embedded modules. Figure 4 - 700-T iNFINITI iConnex and M1D1-T Universal Line Card iConnex-100, shown in Figure 5 below, is very similar to 700-TiNFINITI iConnex. Figure 5 - iConnex-100 iDirect Secure Satellite Broadband Solutions Page 12 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 2.5 Operational Environment The module is installed in its compiled form as an executable software running on customized Linux version 2.4.24- uc0-iDirect0. The operating system protects memory and process space from unauthorized access. The software integrity test protects against unauthorized modification of the module itself. 2.6 Cryptographic Key Management The cryptographic module implements the following FIPS-approved algorithms: · AES in CBC and CFB modes ­ encrypt/decrypt 256-bit key (certificate 527, 528) · TDES in CBC mode ­ encrypt/decrypt 1, 2, 3 keying options (certificate 534) · SHA-1 ­ FIPS 180-2 (certificate 600) · PRNG ­ American National Standards Institute (ANSI) X9.31 Appendix A.2.4 (certificate 303) · RSA ­ signature verification 2048-bit key (certificate 238) The cryptographic module implements the following FIPS-approved key agreement/key establishment technique: · Diffie-Hellman 1024 bits key (PKCS #3, key agreement/key establishment methodology provides 80 bits of encryption strength) Additionally, the module utilizes the following non-FIPS-approved algorithm implementation: · Non-approved PRNG for seeding the ANSI X9.31 PRNG · RSA 2048 bits key encrypt/decrypt (PKCS#1, key wrapping; key establishment methodology provides 112 bits of encryption strength) The module supports the following critical security parameters: Table 8 - List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key/Compo Type Generation / Output Storage Zeroization Use nent/CSP Input iDirect RSA 2048-bit Externally Never exits the Hard coded in Never Performs software Signed Key public key generated module the module zeroized integrity check during power-up and upgrade Global AES-256 CBC Externally Never exits the Resides in By global Provides Session Key key generated, entered module volatile memory zeroize confidentiality to in encrypted form in plaintext command data over Satellite channel Secured AES-256 CBC Generated Never Resides in Zeroized Provides secured Session Key key internally using volatile memory after session channel for Diffie-Hellman in plaintext is over management Link AES-256 CBC Internally Exits in encrypted Resides in Zeroized Provides Encryption and CFB key generated or form volatile memory after session confidentiality to Key entered in in plaintext is over Layer 3 data encrypted form RSA Private RSA 2048-bit Internally Never exits the In flash in By global Authenticates TLS Key private key generated module, but can be plaintext zeroize channel and viewed by the command transports Global Crypto-Officer in Session Key and plaintext Link Encryption Key iDirect Secure Satellite Broadband Solutions Page 13 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Key/Compo Type Generation / Output Storage Zeroization Use nent/CSP Input RSA Public RSA 2048-bit Internally Exits in plaintext, In flash in By global Authenticates TLS Key public key generated can be viewed by plaintext zeroize channel and the Crypto-Officer command transports Global in plaintext Session Key and Link Encryption Key Diffie- 1024-bit DH Internally Never exits the Resides in Zeroized Establishes Secured Hellman private generated module volatile memory after session Session Key during private key exponent in plaintext is over SSH or TLS sessions Crypto- Password Entered in plaintext Never exits the Hash value of By global Authenticates the Officer module the password is zeroize Crypto-Officer role Password stored in flash command User Password Entered in plaintext Never exits the Hash value of By global Authenticates the Password module the password is zeroize User role stored in flash command ANSI X9.31 16 bytes of Independently Never exits the Resides in Zeroized Seeds the ANSI PRNG Seed seed and 32 generated by the module volatile memory after session X9.31 PRNG and Seed bytes of seed non-approved in plaintext is over Key key PRNG The iDirect Signed Key is a 2048-bit RSA public key hard coded into the module. This key is externally generated and is used for verifying the integrity of the module's software during power-up and upgrade. The iDirect Signed Key is stored in flash and never zeroized. Global Session keys are AES CBC 256-bit keys that are used to encrypt/decrypt routing traffic flowing across the satellite network. AES cipher operation using Global Session keys is performed by the FPGA implementation of the module. These keys are generated by the Protocol Processor blade, external to the cryptographic boundary and entered into the module in encrypted form (RSA key transport). The module does not provide any Application Programming Interface (API) access to the Global Session keys. These AES keys are stored in volatile memory in plaintext and can be zeroized by using the global zeroize command issued from the CLI. Secured Session keys are also AES CBC 256-bit keys that are used to provide a secure management session over SSH and TLS. The Secure Session Key is generated internally during DH key agreement. Cipher operation for the secured management interface is done in a software implementation of the module. The AES key is stored only in volatile memory and is zeroized after the session is over. When a modem is configured to have link encryption enabled, it will generate a Link Encryption Key upon initialization. A Link Encryption Key is a 256-bit AES key with CBC or CFB mode. A link Encryption Key is the unique key used to encrypt and decrypt Layer 3 data with a remote. Each remote uses a different Link Encryption Key. Notice that in the FIPS mode of operation, link encryption without TRANSEC is not allowed. The RSA public and private key pair is generated internally by the module and is used for TLS authentication and key transport. The key pair is stored in flash in plaintext and zeroized by the global zeroize command ("zeroize all"). The RSA key pair can be viewed by the Crypto-Officer in plaintext. At least two independent actions are required to view the RSA private key, which includes logging into "root" with the appropriate password. The module performs key agreement during SSH sessions using DH (1024-bit exponent) mechanism. The DH private key is calculated during session initialization and resides only in volatile memory in plaintext. The module does not provide any API to access the DH private key. The private key is zeroized after the session is over. The Crypto-Officer and the User authenticate with passwords. The module stores a SHA-1 based hash value for each password onto the flash and never outputs it. The hash value can be zeroized by using the module's zeroization command. iDirect Secure Satellite Broadband Solutions Page 14 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 The X9.31 PRNG seed and seed keys are generated from the internal FIPS non-approved PRNG. These values are stored in volatile memory and can be destroyed by powering down the module. 2.7 Self-Tests The Secure Satellite Broadband Solutions performs the following self-tests at power-up: · Software integrity check using a RSA digital signature · Known Answer Tests (KATs) o AES CBC 256-bit key KAT for encrypt/decrypt o Triple-DES CBC KAT for encrypt/decrypt o RSA KAT for sign/verify o HMAC-SHA-1 KAT o X9.31 PRNG KAT The module does not use HMAC-SHA-1. The KAT for HMAC-SHA-1 is intended to test SHA-1. The Secure Satellite Broadband Solutions performs the following conditional self-tests: · Continuous random number generator test · Continuous random number generator test for the entropy gathering · RSA pair wise consistency check · Software upgrade test If any of the power-up self-tests fail, the module writes an indicator message in the Event log. In this state all interfaces except the console port are disabled. The Crypto-Officer may execute on demand self-tests by resetting the module or cycling the module's power. 2.8 Design Assurance iDirect utilizes Concurrent Versioning Systems (CVS) for its version control system. iDirect maintains a unique branch for each major release and on occasion creates branches for special or experimental releases. The FIPS- specific version of iDirect software is maintained on a dedicated branch, with strict controls on any modification. iDirect refers to its entire software package as iDS. iDirect maintains all project software, configuration files, documentation, FPGA code, bill of material), 3rd party software, and 3rd party binary executables within its Configuration Management system. Additionally, Microsoft Visual SourceSafe version 6.0 was used to provide configuration management for the module's FIPS documentation. A revision history is maintained by Visual SourceSafe. 2.9 Mitigation of Other Attacks No claims are made that the modules mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. iDirect Secure Satellite Broadband Solutions Page 15 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 3 Secure Operation The Secure Satellite Broadband Solutions meet Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in a FIPS-approved mode of operation. 3.1 Crypto-Officer Guidance The Crypto-Officer is responsible for installing, configuring, and monitoring the module. The Crypto-Officer accesses the module locally over the console port or remotely over a secured session. Remote secured sessions are provided via TLS, SSH, or the satellite channel. 3.1.1 Initialization While the modules are shipped with the Linux OS configured for single user mode, they must be configured for use in a TRANSEC-enabled network using a TRANSEC enabled Protocol Processor and the iBuilder application. All network elements that are subsequently created under a TRANSEC-enabled protocol processor will become part of the TRANSEC-compliant network. This process involves configuring each respective module in iBuilder (entering the device type, serial number, Satellite and LAN IP addresses, db threshold, etc.), uploading the resulting `options file', issuing the Certificate Authority via the CA Foundry utility in the Network Management Server (NMS), un-checking the `Disable Authentication' option in iBuilder and finally re-uploading the new options file and resetting each module. The resulting TRANSEC-enabled network operates in the FIPS-approved mode. In-depth and detailed guidance for configuring, operating, and maintaining an iDirect satellite network is detailed in the iDirect Network Management System iBuilder's User Guide. The Crypto-Officer should monitor the module's status by regularly checking the Statistics log information. If any irregular activity is noticed or the module is consistently having errors, then iDirect Technologies customer support should be contacted. 3.1.2 Management According to FIPS 140-2 requirements, the operating system of the module must be configured in the single user mode. For a Linux operating system to be in the single user mode, it must meet the following requirements · All login accounts except "root" should be removed. · Network Information Service (NIS) and other named services for users and groups need to be disabled. · All remote login, remote command execution, and file transfer daemons should be turned off. iDirect follows the following procedures to configure Linux operating system in single user mode. 1. Log in as the "root" user. 2. Edit the system files /etc/passwd and /etc/shadow and remove all the users except "root" and the pseudo- users. Make sure the password fields in /etc/shadow for the pseudo-users are either a star (*) or double exclamation mark (!!). This prevents login as the pseudo-users. 3. Edit the system file /etc/nsswitch.conf and make "files" the only option for "passwd", "group", and "shadow". This disables NIS and other name services for users and groups. 4. Reboot the system for the changes to take effect. When the module is received by the Crypto-Officer, the Linux operating system has already been configured in the single user mode. It is suggested that the Crypto-Officer confirm that the above steps have been taken in order to ensure that the operating system is in fact running in single user mode. iDirect Secure Satellite Broadband Solutions Page 16 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 By default the module is not usable in the network. In order to initialize the module, the Crypto-Officer must define the module in their iBuilder under a TRANSEC enabled protocol processor and generate options for the module. For detailed information on initialization, please refer to the iDirect Network Management System iBuilder's User Guide. 3.2 User Guidance The User role is able to access the module over the satellite network and execute certain commands that are not security-relevant. See Table 6 for a list of commands available to the User role. 3.3 Client User Guidance The Client User role utilizes the module's traffic routing services. The Client User role is implicitly assumed by a network device or application routing traffic through the module. There are no special instructions for the Client User to use the module securely. The Client User should make sure the network is configured with TRANSEC feature (i.e. the FIPS mode of operation) before participating in the network. iDirect Secure Satellite Broadband Solutions Page 17 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 4 Acronyms Table 9 - Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface CA Certification Authority CBC Cipher Block Chaining CLI Command Line Interface CMVP Cryptographic Module Validation Program CPU Central Processing Unit CSP Critical Security Parameter CVS Concurrent Versioning Systems DH Diffie-Hellman EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard FPGA Field Programmable Gate Array GPS Global Positioning System HDLC High-level Data Link Control HMAC Hash Message Authentication Code ICMP Internet Control Message Protocol IP Internet Protocol KAT Known Answer Test LAN Local Access Network LED Light Emitting Diode MAC Media Access Control MUX Multiplexer NIS Network Information Service NIST National Institute of Standards and Technology OOB Out of Band PCB Printed Circuit Board PRNG Pseudo Random Number Generator RSA Rivest, Shamir, and Adleman Rx Receive Coaxial Connector SCPC Single Channel Per Carrier SHA Secure Hash Algorithm iDirect Secure Satellite Broadband Solutions Page 18 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Non-Proprietary Security Policy, Version 2.0 June 20, 2007 Acronym Definition SSH Secure Shell TDES Triple Data Encryption Standard TDMA Time Division Multiple Access TLS Transport Layer Security TRANSEC Transmission Security Tx Transmitter Coaxial Connector ULC Universal Line Card VPN Virtual Private Network iDirect Secure Satellite Broadband Solutions Page 19 of 19 © 2007 iDirect Technologies ­ This document may be freely reproduced and distributed whole and intact including this Copyright Notice.