FIPS 140-2 Non-Proprietary Security Policy for the Xceedium GateKeeperTM Hardware Version 5 Firmware Version 5.0.0 SP3 Level 2 Validation Document Version: Version 2.5 March 15, 2010 FIPS 140-2 Security Policy ­ GateKeeper Page 1 of 21 © Copyright 2010 Xceedium REVISION HISTORY The table below provides revision history of this document. Version Date Author(s) Comments 1.0 March 2, 2007 Apex Assurance Group Initial Draft for submission to EWA 1.1 April 16, 2007 Apex Assurance Group Revise with comments from EWA 1.2 July 12, 2007 Apex Assurance Group Address comments from NIST 1.3 July 27, 2007 Apex Assurance Group Address additional comments from NIST 2.0 July 21, 2009 Ryan Maple, Xceedium Update for GateKeeper 5.0.0 Dave Olander, Xceedium 2.1 August 7, 2009 Ryan Maple, Xceedium Revise with comments from EWA Dave Olander, Xceedium 2.2 August 18, 2009 Ryan Maple, Xceedium Revise with comments from EWA Dave Olander, Xceedium 2.3 August 20, 2009 Ryan Maple, Xceedium Revise with comments from EWA Dave Olander, Xceedium 2.4 February 11, 2010 Ryan Maple, Xceedium Revise with comments from NIST Dave Olander, Xceedium 2.5 March 15, 2010 Ryan Maple, Xceedium Revise with further comments from NIST. Dave Olander, Xceedium Table 1 - Security Policy Revision History FIPS 140-2 Security Policy ­ GateKeeper Page 2 of 21 © Copyright 2010 Xceedium FIPS 140-2 Security Policy ­ GateKeeper Page 3 of 21 © Copyright 2010 Xceedium TABLE OF CONTENTS REVISION HISTORY ....................................................................................................................................... 2 TABLE OF CONTENTS.................................................................................................................................... 4 INTRODUCTION ............................................................................................................................................ 5 BACKGROUND ...................................................................................................................................................5 EXTERNAL RESOURCES .........................................................................................................................................5 NOTICES .............................................................................................................................................................5 XCEEDIUM GATEKEEPER .............................................................................................................................. 6 PRODUCT OVERVIEW ..........................................................................................................................................6 CRYPTOGRAPHIC MODULE SPECIFICATION ..........................................................................................................6 VALIDATION LEVEL ..............................................................................................................................................7 MODULE INTERFACES ..........................................................................................................................................7 ROLES AND SERVICES ..........................................................................................................................................8 Crypto Officer Role ............................................................................................................................ 9 User Role ............................................................................................................................................ 10 Authentication.................................................................................................................................. 11 CRYPTOGRAPHIC KEY MANAGEMENT ................................................................................................................13 SELF-TESTS.........................................................................................................................................................15 Power-On Self-Tests .......................................................................................................................... 16 Conditional Self-Tests ....................................................................................................................... 17 MITIGATION OF OTHER ATTACKS ........................................................................................................................17 SECURE OPERATION OF THE GATEKEEPER................................................................................................ 18 CRYPTO OFFICER GUIDANCE ............................................................................................................................18 Module Initialization and Configuration........................................................................................ 18 Physical Security and Tamper Evidence ....................................................................................... 19 USER GUIDANCE...............................................................................................................................................20 APPROVED CRYPTOGRAPHIC ALGORITHMS .......................................................................................................20 NON-FIPS APPROVED ALGORITHMS ..................................................................................................................20 ACRONYM LIST........................................................................................................................................... 21 FIPS 140-2 Security Policy ­ GateKeeper Page 4 of 21 © Copyright 2010 Xceedium INTRODUCTION Background Federal Information Processing Standards Publication 140-2 -- Security Requirements for Cryptographic Modules specifies requirements for cryptographic products to be deployed in a Sensitive but Unclassified environment. More information about the FIPS 140-2 standard and validation program is available on the NIST website at http://csrc.nist.gov/groups/STM/cmvp/index.html . This non-proprietary Cryptographic Module Security Policy for the GateKeeper from Xceedium provides an overview of the product and a high-level description of how it meets the security requirements of FIPS 140-2. This document contains details on the module's cryptographic keys and critical security parameters. This Security Policy concludes with instructions and guidance on running the module in a FIPS 140-2 mode of operation. External Resources The Xceedium website (http://www.xceedium.com) contains information on the full line of products from Xceedium, including a detailed overview of the GateKeeper solution. The NIST Cryptographic Module Validation Program website (http://csrc.ncsl.nist.gov/groups/STM/cmvp/index.html) contains Xceedium contact information for answers to technical or sales-related questions. Notices This document may be freely reproduced and distributed in its entirety without modification. FIPS 140-2 Security Policy ­ GateKeeper Page 5 of 21 © Copyright 2010 Xceedium XCEEDIUM GATEKEEPER Product Overview The Xceedium GateKeeperTM, which may also be referred to simply as GateKeeper, provides many of the required day-to-day IT functions for organizations in a 1U, rack-mountable appliance. It provides TLS-secured, in- band and out-of-band management and monitoring of networking equipment, UNIX, Linux, Macintosh and Windows servers and workstations, as well as remote power-management to either turn on, turn off, or reboot any attached device. The GateKeeper offers the following functions: · All-in-one web-based remote in-band access, · Web-enabled serial console for remote out-of-band access, · Web-based Virtual Desktop to bring secure remote management of your UNIX (X-Windows and CDE), Windows, Linux, and Macintosh desktops right to any web-browser without the need to install processor intensive, bandwidth hungry, large applications from other vendors on every desktop and server, · Web-based Secure Shell (SSH) and Telnet access to all computer desktops and workstations as well as network devices and terminal servers, · Encrypted connectivity without Virtual Private Networks (VPN) ­ No expensive VPN tunnels to worry about everywhere your support staff travels ­ lowers total cost of ownership, and · Multi-level Authentication. The GateKeeper features include: · Web-based access to establish telnet, SSH, and standard operating system specific GUI sessions to devices over TCP/IP, · IPsec and SSL-VPN support, · Remote power management ­ allowing you to turn attached devices on or off, and · External LCD display for entering initial host connection information without needing access to a laptop of other terminal, as well as checking on system configuration. · The ability for multiple concurrent operators to be logged in at the same time. Cryptographic Module Specification The module is the Xceedium GateKeeper, running firmware version 5.0.0 SP3 on hardware version 5. The module is classified as a multi-chip standalone FIPS 140-2 Security Policy ­ GateKeeper Page 6 of 21 © Copyright 2010 Xceedium cryptographic module. The physical cryptographic boundary is defined as the module's case and all components within the case. The BIOS is excluded from the requirements of FIPS 140-2. The physical boundary is pictured in the image below: Figure 1 ­ Physical Boundary Validation Level The following table lists the level of validation for each area in FIPS 140-2. FIPS 140-2 Module DTR Section Title Validation Section Level 1 Cryptographic Module Specification 2 2 Cryptographic Module Ports and Interfaces 2 3 Roles, Services, and Authentication 3 4 Finite State Model 2 5 Physical Security 2 6 Operational Environment N/A 7 Cryptographic Key Management 2 8 Electromagnetic Interference / 2 Electromagnetic Compatibility 9 Self-Tests 2 10 Design Assurance 3 11 Mitigation of Other Attacks N/A Table 2 ­ Validation Level by DTR Section Module Interfaces The interfaces for the cryptographic boundary include physical and logical interfaces. The physical interfaces provided by the module are mapped to four FIPS 140-2 defined logical interfaces: Data Input, Data Output, Control Input, FIPS 140-2 Security Policy ­ GateKeeper Page 7 of 21 © Copyright 2010 Xceedium and Status Output. The mapping of logical interfaces to module physical interfaces is provided in the following table: FIPS 140-2 Logical Module Physical Interface Interface Data Input 6 Gigabit Ethernet Interfaces Data Output 6 Gigabit Ethernet Interfaces Control Input 6 Gigabit Ethernet Interfaces On/Off Switch Reset Switch Status Output 6 Gigabit Ethernet Interfaces LCD Panel LEDs RJ-45 RS-232 Serial Interface Power Power Plug Unused Interface 2 USB Interfaces* Table 3 ­ Logical Interface / Physical Interface Mapping * The USB interfaces are wired; however, the Xceedium software does not allow any communications through these interfaces. Driver support for the USB interfaces is not compiled into the shipping image, and it is disabled at the BIOS level. Roles and Services In the FIPS-approved mode of operation, the module is accessed via a Web browser over HTTPS/TLS (see Secure Operation of the GateKeeper section of this document for more details). As required by FIPS 140-2, there are two roles (a Crypto Officer role and User role) in the module that operators may assume. The module supports identity-based authentication, and the respective services for each role are described in the following sections. The module supports basic management via the LCD panel. This unauthenticated service is used to define basic network configuration, reset to factory defaults, reboot or shut down the GateKeeper, or to initialize the module for FIPS mode of operation. When in FIPS mode, the LCD Management is completely disabled. Additionally, the power-up self-tests that are run when FIPS mode is enabled are an unauthenticated service. FIPS 140-2 Security Policy ­ GateKeeper Page 8 of 21 © Copyright 2010 Xceedium Crypto Officer Role The Crypto Officer role is responsible for the configuration and maintenance of the module and authenticates via Web browser over HTTPS/TLS1. The Crypto Officer services consist of the following FIPS services: Service Description Authenticate Allows the Crypto Officer to authenticate to access the services available to the role. Sessions Utilize administrative features such as viewing active logins, sessions, logs, and reporting. Config Utilize the configuration features, such as setting parameters and conducting maintenance tasks. Services Create custom access methods to run either local clients or launch a URL Users Utilize user management features, such as create, update, and delete. Devices Utilize device management features, such as create, update, and delete. Associations Utilize association management features, such as create, update, and delete. Access A default setting allowing the user to utilize the assigned access methods. This also allows the Manage features (discussed on the following row) to be available for the user. Manage A default setting allowing the user to utilize the power management feature. Please note that this is not the LCD management discussed above but rather control of external power devices. Monitoring A default setting allowing the user to utilize the monitoring feature. User Account Allows the user to view and change his/her password and contact Management information Global Settings Utilize the global settings feature to enable customization of policies for passwords, timeouts, services, and user warnings. Table 4 ­ Crypto Officer Services and Descriptions 1 Except for the initial configuration for FIPS mode of operation, where the Crypto Officer will first use the LCD panel (see Secure Operation of the GateKeeper section of this document for more details) FIPS 140-2 Security Policy ­ GateKeeper Page 9 of 21 © Copyright 2010 Xceedium The Crypto Officer Role may perform zeroization of all the CSPs listed in Table 7 and may also check the status of the module. Note that all services are invoked via HTTPS session using the following algorithms in the TLS protocol: · FIPS-approved PRNG for generation of DH Secret Component · Diffie Hellman for key agreement with encryption strength of 80-bits, 96- bits, or 112-bits · RSA for: o Digital signature generation for self-signing of certificates using 1024- bit and 2048-bit key lengths o Key transport with encryption strength of 80-bits, 96-bits, 112-bits, 128-bits, or 160-bits · HMAC SHA (all variants) for message integrity checking · AES or TDES for data encryption encrypted via symmetric encryption algorithm (AES or TDES). User Role The User Role authenticates via Web browser over HTTPS/TLS. The User services available in the module consist of the following FIPS services: Service Description Access A default setting allowing the user to utilize the assigned access methods. This also allows the Manage features (discussed on the following row) to be available for the user. Manage A default setting allowing the user to utilize the power management feature. Monitoring A default setting allowing the user to utilize the monitoring feature. Authenticate Allows the user to authenticate to access the services available to the role. User Account Allows the user to view and change his/her password and contact Management information. Table 5 ­ User Services and Descriptions The User Role may only perform zeroization of User Passwords. Note that all services are invoked via HTTPS session using the following algorithms in the TLS protocol: · FIPS-approved PRNG for generation of DH Secret Component · Diffie Hellman for key agreement with encryption strength of 80-bits, 96- bits, or 112-bits · RSA for: FIPS 140-2 Security Policy ­ GateKeeper Page 10 of 21 © Copyright 2010 Xceedium o Digital signature generation for self-signing of certificates using 1024- bit and 2048-bit key lengths o Key transport with encryption strength of 80-bits, 96-bits, 112-bits, 128-bits, or 160-bits · HMAC SHA (all variants) for message integrity checking · AES or TDES for data encryption encrypted via symmetric encryption algorithm (AES or TDES). The services accessing the Critical Security Parameters (CSP)s, the type of access and the role accessing the CSPs are listed in Table 8 ­ Role and Service Access to Security Relevant Data Items. Authentication The module supports either a username and password or digital certificates for authenticating operators. The table below provides estimated strength of the authentication mechanisms: Authentication Type Strength Username and Password Passwords must be a minimum of 6 characters and a maximum of mechanism 15 characters (see Secure Operation section of this document). The password can consist of alphanumeric values, [a-zA-Z0-9], yielding 62 choices per character. The probability of a successful random attempt is 1/62^6, which is less than 1/1,000,000. For the Super and Config accounts, assuming 10 attempts per second via a scripted or automatic attack, the probability of a success with multiple attempts in a one minute period is 600/62^6, which is less than 1/100,000. For accounts other than the Super account, the module will lock an account after 3 failed authentication attempts; thus, the maximum number of attempts in one minute is 3. Therefore, the probability of a success with multiple consecutive attempts in a one minute period is 3/62^6 which is less than 1/100,000. Certificate-based The module supports a public key based authentication with 512, authentication 768, 1024, and 2048 (for RSA) bit keys2. A 1024-bit RSA key has at least 80-bits of equivalent strength. The probability of a successful random attempt is 1/2^80, which is less than 1/1,000,000. Assuming the module can support 60 authentication attempts in one minute, the probability of a success with multiple consecutive attempts in a one minute period is 60/2^80 which is less than 1/100,000. 2As described in the Secure Operation of the GateKeeper section, 512-bit and 768-bit RSA keys must not be used in FIPS mode of operation. FIPS 140-2 Security Policy ­ GateKeeper Page 11 of 21 © Copyright 2010 Xceedium Authentication Type Strength A 2048-bit RSA key has at least 112-bits of equivalent strength. The probability of a successful random attempt is 1/2^112, which is less than 1/1,000,000. Assuming the module can support 60 authentication attempts in one minute, the probability of a success with multiple consecutive attempts in a one minute period is 60/2^112 which is less than 1/100,000. Table 6 ­ Estimated Strength of Authentication Mechanisms To authenticate to the module for management purposes (i.e., accessing available services defined in the Crypto Officer Role and User Role sections), an operator must connect to the module via a Web browser and provide a username and password. A user name and password is required for all services accessed through a browser. Note that all services are available when accessing the module via certificate- based authentication. FIPS 140-2 Security Policy ­ GateKeeper Page 12 of 21 © Copyright 2010 Xceedium Cryptographic Key Management Table 7 provides a complete list of critical security parameters3 used within the module: KEY / STORAGE IDENTIFIER DESCRIPTION DELETION CSP NAME (FORMAT) Generated from non-FIPS approved PRNG in OpenSSL code PRNG implemented in module; Generating a new 1 Seed and RAM (plaintext) used in ANSI X9.31 seed Seed Key Appendix A.2.4 FIPS- approved PRNG (using AES) Resetting or Public 2 Public keys of peers RAM (plaintext) rebooting the keys module Deleting the certificate or Identity certificates for certificate request; the module itself and RSA The keys are also used in TLS NVRAM (plaintext) 3 public/priv overwritten with negotiations. The module ate keys dashes via command supports 1024 and 2048 sent by the Crypto bit key sizes. Officer over the web interface. Resetting or TLS Traffic Used in HTTPS 4 RAM (plaintext) rebooting the Keys connections module NVRAM/Flash Overwriting the User Memory 5 Secret passwords with new Passwords (plaintext) and ones RAM (plaintext) NVRAM/Flash Crypto Overwriting the Memory (plaintext) 6 Officer Secret passwords with new and RAM Passwords ones (plaintext) Deleting the certificate or Xceedium certificate request; default The private key is certificate Used in HTTPS 7 NVRAM (plaintext) overwritten with and connections dashes via command private sent by the Crypto key Officer over the web interface. 3 Public keys are not considered to be critical security parameters. FIPS 140-2 Security Policy ­ GateKeeper Page 13 of 21 © Copyright 2010 Xceedium KEY / STORAGE IDENTIFIER DESCRIPTION DELETION CSP NAME (FORMAT) Diffie- Resetting or Key agreement for TLS 8 Hellman RAM (plaintext) rebooting the sessions Key Pairs4 module IPsec Resetting or Used to encrypt IPsec 9 Traffic RAM (plaintext) rebooting the sessions Keys module Client Resetting or 10 Certificate Authenticate PKI peers RAM (plaintext) rebooting the s module Table 7 ­ Critical Security Parameters 4 DH groups 2 (1024 bits), 5 (1536 bits) and 7 (2048 bits) are supported. FIPS 140-2 Security Policy ­ GateKeeper Page 14 of 21 © Copyright 2010 Xceedium The services accessing the Critical Security Parameters (CSP)s, the type of access and the role accessing the CSPs are listed in the following table: Identifier 10 Services by Role 1 2 3 4 5 6 7 8 9 User Role Access R R Authenticate RW R RW R R RW RW R Manage R RW R RW Monitoring R R User Account RW Management D Crypto Officer Role Access R R Manage R RW R RW Monitoring R R Authenticate RW R RW R R RW RW R Sessions R R RW RW RW RW RW RW RW RW RW Config D D D D D D D D D D Services R R RW Users R WD D RW R RW Devices R R Associations R R LCD Management Global Settings R = Read W = Write D = Delete Table 8 ­ Role and Service Access to Security Relevant Data Items The module does support entry of usernames and passwords for authentication, but these parameters are not distributed outside the cryptographic boundary. The module supports electronic key entry; the Crypto Officer may load RSA private keys and certificates to replace the default Xceedium private key and certificate for the module identity. The parameters are loaded via the secured Web interface. The private key and public key certificate associated with the default Xceedium certificate may be output by the Crypto Officer via the secure Web interface in the non-FIPS approved mode of operation. Self-Tests The module includes an array of self-tests that are run during startup and periodically during operations to prevent any secure data from being released FIPS 140-2 Security Policy ­ GateKeeper Page 15 of 21 © Copyright 2010 Xceedium and to ensure all components are functioning correctly. The module supports OpenSSL for all IPsec and SSL-VPN operations as well as HTTPS communications. The following sections discuss the module's self-tests in more detail: Power-On Self-Tests The module implements the following power-on self test: · Module integrity check via SHA-1 The module implements the following power-on self-tests for the OpenSSL algorithm implementations: · RSA KAT (signing and signature verification) · AES KAT (encryption and decryption) · Triple DES KAT (encryption and decryption) · SHA-1 KAT · HMAC SHA-1 KAT · HMAC SHA-224 KAT · HMAC SHA-256 KAT · HMAC SHA-384 KAT · HMAC SHA-512 KAT · PRNG KAT The module implements the following power-on self-tests for the Linux IPsec Kernel Module algorithm implementations: · AES KAT (encryption and decryption) · Triple DES KAT (encryption and decryption) · SHA-1 KAT · HMAC SHA-1 KAT · HMAC SHA-224 KAT · HMAC SHA-256 KAT · HMAC SHA-384 KAT · HMAC SHA-512 KAT The module performs all power-on self-tests automatically at boot when FIPS mode is enabled. All power-on self-tests must be passed before a User/Crypto Officer can perform services. The power-on self-tests are performed after the cryptographic systems are initialized but prior to the initialization of the Gigabit Ethernet ports, which prevents the module from passing any data during a power-on self-test failure. FIPS 140-2 Security Policy ­ GateKeeper Page 16 of 21 © Copyright 2010 Xceedium An operator can discern that all power-on self-tests have passed via normal operation of the module, which is indicated with the following text on the LCD panel: """""""""""" GateKeeper In FIPS mode """""""""""" For OpenSSL self-test failure: spfd5 will not run, and an error status is sent by spfd to the log table. When spfd stops, there will be no connections to the module because no process is listening on port 443 (Port 443 is the only way to connect to the module). The module will also provide the following indication of a self- test failure via the LCD: FIPS mode failed / System halted, and the user will reboot manually. When rebooted, the module is not running in FIPS mode, and Network Setup is displayed on the LCD panel. The module will indicate a failure of the integrity test via the LCD; the message GK SI failure / System halted is displayed on the LCD. The module writes a log entry to the log table only if the database is initialized prior to the failure. Conditional Self-Tests The module performs the following conditional self-tests: · Pairwise consistency test for RSA · Continuous Random Number Generator Test for the FIPS-approved PRNG · Continuous Random Number Generator Test for the non-approved PRNG in the OpenSSL code portion of the cryptographic module The module will provide the following indication of a conditional self-test failure via the LCD: FIPS mode failed / System halted, and the user will reboot manually. A log entry is written to the module database. The module does not support a bypass function because it only transmits encrypted data. Mitigation of Other Attacks The module does not mitigate other attacks in a FIPS-approved mode of operation. 5 spfd is the GateKeeper Secure Port Forwarder Daemon. FIPS 140-2 Security Policy ­ GateKeeper Page 17 of 21 © Copyright 2010 Xceedium SECURE OPERATION OF THE GATEKEEPER This section describes how to configure the module for FIPS-approved mode of operation. Operating the module without maintaining the following settings will remove the module from the FIPS-approved mode of operation. Crypto Officer Guidance Module Initialization and Configuration Crypto Officer must configure and enforce the following initialization procedures: 1. Verify that the firmware version is 5.0.0 SP3. 2. Configure the minimum password length for all accounts to 6 characters. Note: Stronger, more secure passwords should have a combination of letters and numbers and should not contain any recognizable words that may be found in a dictionary. The module does not enforce this; the Crypto Officer must follow his/her organization's systems security policies and adhere to the password policies set forth therein. 3. Change the default password of the Crypto Officer. 4. Ensure that 768-bit RSA keys are not used in FIPS mode of operation. 5. Ensure that RADIUS, RSA SecureID, and PKI/CAC authentication mechanisms are not used in FIPS mode of operation. 6. Ensure that DSA is not used in FIPS mode of operation. 7. Configure the Password Failures Limit to 3. This ensures that accounts are locked after 3 unsuccessful authentication attempts. 8. Turn on FIPS mode via the Web interface or LCD panel. 9. Reboot the module. The GateKeeper should be configured such that plaintext data (e.g. recorded session data) is not output via the same port (physical interface) that is used for ciphertext data. FIPS 140-2 Security Policy ­ GateKeeper Page 18 of 21 © Copyright 2010 Xceedium The Crypto Officer should consider replacing the default Xceedium certificate with another certificate. Additionally, the Crypto Officer must not disclose passwords and must store passwords in a safe location and according to his/her organization's systems security policies for password storage. The GateKeeper supports the loading of new firmware. This service is not FIPS- approved, and the GateKeeper cannot be considered as being in a FIPS- approved mode of operation running any new, externally-loaded, firmware, even if the instructions in this section are followed to put the firmware in a FIPS mode of operation. Physical Security and Tamper Evidence The enclosure cover of the GateKeeper is secured to the rear of the chassis with two (2) Torx T10 screws. A single, serialized, tamper evidence label is placed on the GateKeeper at the time of manufacture covering one of these Torx T10 screws while the other screw is directly to the right. This security label is very fragile and cannot be removed without clear signs of damage to the label; any attempt to open the device will damage the tamper evidence label or the material of the module cover. The label is placed on the back of the module, as shown in Figure 2 ­ Tamper Evidence Label Placement below: Figure 2 ­ Tamper Evidence Label Placement The Crypto Officer should record the serial number of the tamper evident label. The Crypto Officer should inspect the tamper evidence label periodically according to his/her organization's systems security policies to verify it is not FIPS 140-2 Security Policy ­ GateKeeper Page 19 of 21 © Copyright 2010 Xceedium damaged and to verify that the serial number on the tamper evident label matches the recorded value as a means of confirming that the label has not been replaced by a different label. User Guidance 1. The User must not disclose passwords and must store passwords in a safe location and according to his/her organization's systems security policies for password storage. Approved Cryptographic Algorithms In FIPS mode of operation, only the following FIPS approved algorithms are to be used: · AES encryption/decryption: Validation #1151 and #1152 · Triple DES encryption/decryption: Validation #833 and #834 · RSA signing and verifying: Validation #544 · SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 hashing: Validation #1065 and #1066 · HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 for hashed message authentication: Validation #654 and #655 · ANSI X9.31 Appendix A.2.4 for PRNG: Validation #637 Non-FIPS Approved Algorithms The module implements the following non-FIPS-approved cryptographic algorithms: · Diffie-Hellman (allowed for use in FIPS mode / key establishment methodology provides 80-bits, 96-bits, or 112-bits of encryption strength) · DSA (non-compliant): Validation #373 · RSA encryption/decryption (allowed for key transport in FIPS mode / key establishment methodology provides 80-bits, 96-bits, 112-bits, 128- bits, or 160-bits of encryption strength; non-compliant less than 80-bits of encryption strength) · PRNG included in the OpenSSL code for the cryptographic module FIPS 140-2 Security Policy ­ GateKeeper Page 20 of 21 © Copyright 2010 Xceedium ACRONYM LIST AES..................................... Advanced Encryption Standard ANSI ................................... American National Standards Institute CAC................................... Common Access Card CBC ................................... Cipher Block Chaining CFB .................................... Cipher Feedback CSP .................................... Critical Security Parameter DES..................................... Data Encryption Standard DH ...................................... Diffie-Hellman DSA .................................... Digital Signature Algorithm DTR..................................... Derived Test Requirements ECB .................................... Electronic Codebook FIPS..................................... Federal Information Processing Standard GUI..................................... Graphical User Interface HMAC................................ Hashed Message Authentication Code HTTPS.................................. Secure Hypertext Transfer Protocol IP ........................................ Internet Protocol KAT..................................... Known Answer Test LCD.................................... Liquid Crystal Display MAC .................................. Message Authentication Code NIST .................................... National Institute of Standards and Technology NVRAM.............................. Non-Volatile Random Access Memory OFB .................................... Output Feedback PKI ...................................... Public Key Infrastructure PRNG................................. Pseudo-Random Number Generator RADIUS .............................. Remote Authentication Dial In User Service RAM ................................... Random Access Memory RNG ................................... Random Number Generator RSA .................................... Rivest, Shamir, Adleman SHA .................................... Secure Hash Algorithm SPFD................................... Sender Policy Framework Daemon SSH ..................................... Secure Shell SSL...................................... Secure Sockets Layer TCP..................................... Transmission Control Protocol TDES ................................... Triple DES TLS ...................................... Transport Layer Security VPN.................................... Virtual Private Network FIPS 140-2 Security Policy ­ GateKeeper Page 21 of 21 © Copyright 2010 Xceedium