FIPS 140-2 Non-Proprietary Security Policy for the Xceedium GateKeeper™ Hardware Version 5 or 5a Firmware Version 5.2.1 Level 2 Validation Document Version: Version 3.5 April 20, 2011 FIPS 140-2 Security Policy – GateKeeper Page 1 of 18 © Copyright 2011 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 2.7 July 27, 2010 Ryan Maple, Xceedium Append hardware version 5a. 3.0 October 5, 2010 Ryan Maple, Xceedium Update for GateKeeper 5.2.0 3.1 November 17, 2010 Ryan Maple, Xceedium Revise with comments from EWA 3.2 November 24, 2010 Ryan Maple, Xceedium Added CAVP certificate numbers. 3.3 January 26, 2011 Ryan Maple, Xceedium Updates for GateKeeper 5.2.1 3.4 February 14, 2011 Ryan Maple., Xceedium Added CAVP certificate numbers and deprecation statement. 3.5 April 20, 2011 Ryan Maple, Xceedium Revise with comments from the CMVP. Table 1 - Security Policy Revision History FIPS 140-2 Security Policy – GateKeeper Page 2 of 18 © Copyright 2011 Xceedium TABLE OF CONTENTS REVISION HISTORY........................................................................................................................................................................ 2 TABLE OF CONTENTS ................................................................................................................................................................... 3 INTRODUCTION .............................................................................................................................................................................. 4 BACKGROUND................................................................................................................................................................................ 4 EXTERNAL RESOURCES ................................................................................................................................................................. 4 NOTICES ....................................................................................................................................................................................... 4 XCEEDIUM GATEKEEPER ............................................................................................................................................................. 5 PRODUCT OVERVIEW ..................................................................................................................................................................... 5 CRYPTOGRAPHIC MODULE SPECIFICATION ...................................................................................................................................... 5 VALIDATION LEVEL......................................................................................................................................................................... 6 MODULE INTERFACES..................................................................................................................................................................... 6 ROLES AND SERVICES.................................................................................................................................................................... 7 Crypto Officer Role................................................................................................................................................................. 7 User Role ............................................................................................................................................................................... 8 Authentication......................................................................................................................................................................... 9 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................................................ 11 SELF-TESTS ................................................................................................................................................................................ 12 Power-On Self-Tests ............................................................................................................................................................ 13 Conditional Self-Tests .......................................................................................................................................................... 14 MITIGATION OF OTHER ATTACKS................................................................................................................................................... 14 SECURE OPERATION OF THE GATEKEEPER........................................................................................................................... 15 CRYPTO OFFICER GUIDANCE........................................................................................................................................................ 15 Module Initialization and Configuration ................................................................................................................................ 15 Physical Security and Tamper Evidence.............................................................................................................................. 16 USER GUIDANCE.......................................................................................................................................................................... 16 APPROVED CRYPTOGRAPHIC ALGORITHMS ................................................................................................................................... 17 NON-FIPS APPROVED ALGORITHMS ............................................................................................................................................. 17 ACRONYM LIST............................................................................................................................................................................. 18 FIPS 140-2 Security Policy – GateKeeper Page 3 of 18 © Copyright 2011 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 4 of 18 © Copyright 2011 Xceedium XCEEDIUM GATEKEEPER Product Overview The Xceedium GateKeeper™, 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, Mac OS 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.2.1 on either hardware version 5 or 5a. The module is classified as a multi-chip standalone 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: FIPS 140-2 Security Policy – GateKeeper Page 5 of 18 © Copyright 2011 Xceedium Figure 1 – Physical Boundary Validation Level The following table lists the level of validation for each area in FIPS 140-2. Module FIPS 140-2 Section Title Validation DTR 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 / Electromagnetic Compatibility 2 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, and Status Output. The mapping of logical interfaces to module physical interfaces is provided in the following table: FIPS 140-2 Logical Interface Module Physical Interface Data Input 6 Gigabit Ethernet Interfaces Data Output 6 Gigabit Ethernet Interfaces Control Input 6 Gigabit Ethernet Interfaces On/Off Switch Reset Switch FIPS 140-2 Security Policy – GateKeeper Page 6 of 18 © Copyright 2011 Xceedium FIPS 140-2 Logical Interface Module Physical Interface 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. 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: 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 7 of 18 © Copyright 2011 Xceedium 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 system parameters, conducting maintenance tasks, and uploading new firmware. 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. Policy Utilize policy 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 KVM and power management features to be available for the user. Monitoring A default setting allowing the user to utilize the monitoring feature. User Account Management Allows the user to view and change their password and contact 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 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 Diffie Hellman Private Component • Diffie Hellman for key agreement with encryption strength of 80-bits, 96-bits, or 112-bits • RSA for: o Digital signature generation and verification 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 KVM and power management features to be available for the user. 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 Management Allows the user to view and change their password and contact 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 Diffie Hellman Private Component • Diffie Hellman for key agreement with encryption strength of 80-bits, 96-bits, or 112-bits FIPS 140-2 Security Policy – GateKeeper Page 8 of 18 © Copyright 2011 Xceedium • RSA for: o Digital signature generation and verification 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 15 characters (see mechanism 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 authentication The module supports a public key based authentication with 512, 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. 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 As described in the Secure Operation of the GateKeeper section, 512-bit and 768-bit RSA keys must not be used in FIPS mode 2 of operation. FIPS 140-2 Security Policy – GateKeeper Page 9 of 18 © Copyright 2011 Xceedium 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 supported, Java-enabled, Web browser and provide either a username and password or a valid digital certificate. A valid user name and password or a digital certificate 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 10 of 18 © Copyright 2011 Xceedium Cryptographic Key Management Table 7 provides a complete list of critical security parameters3 used within the module: KEY / IDENTIFIER DESCRIPTION STORAGE (FORMAT) DELETION CSP NAME Generated from non-FIPS approved PRNG in OpenSSL PRNG Seed code implemented in module; 1 RAM (plaintext) Generating a new seed and Seed Key used in ANSI X9.31 Appendix A.2.4 FIPS-approved PRNG (using AES) Resetting or rebooting the 2 Public keys Public keys of peers RAM (plaintext) module Deleting the certificate or Identity certificates for the module certificate request; The keys RSA itself and also used in TLS NVRAM (plaintext) are overwritten with dashes 3 public/private negotiations. The module via command sent by the keys supports 1024 and 2048 bit key Crypto Officer over the web sizes. interface. TLS Traffic Resetting or rebooting the 4 Used in HTTPS connections RAM (plaintext) Keys module NVRAM/Flash Memory User Overwriting the passwords 5 Secret (plaintext) and RAM Passwords with new ones (plaintext) NVRAM/Flash Memory Crypto Officer Overwriting the passwords 6 Secret (plaintext) and RAM Passwords with new ones (plaintext) Deleting the certificate or Xceedium certificate request; The default private key is overwritten 7 Used in HTTPS connections NVRAM (plaintext) with dashes via command certificate and private key sent by the Crypto Officer over the web interface. Diffie-Hellman Resetting or rebooting the 8 Key agreement for TLS sessions RAM (plaintext) Key Pairs4 module IPsec Traffic Resetting or rebooting the 9 Used to encrypt IPsec sessions RAM (plaintext) Keys module Client Resetting or rebooting the 10 Authenticate PKI peers RAM (plaintext) Certificates module HMAC Used to validate firmware Application of patch (see 11 NVRAM (plaintext) firmware load upgrade patches Crypto Officer Guidance) key Table 7 – Critical Security Parameters Public keys are not considered to be critical security parameters. 3 DH groups 2 (1024 bits), 5 (1536 bits) and 7 (2048 bits) are supported. 4 FIPS 140-2 Security Policy – GateKeeper Page 11 of 18 © Copyright 2011 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 11 1 2 3 4 5 6 7 8 9 User Role Access R RW R RW Authenticate RW R RW R R RW RW R Monitoring R R User Account Management RWD Crypto Officer Role Access R RW R RW Monitoring R R Authenticate RW R RW R R RW RW R Sessions R R RWD Config RWD RWD RWD RWD D RWD RWD RWD RWD RWD Services R R Users R WD RWD 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. To zeroize all keys, the Crypto Officer may reset GateKeeper to “factory defaults” by performing a reset of the system database. 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 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: FIPS 140-2 Security Policy – GateKeeper Page 12 of 18 © Copyright 2011 Xceedium 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. 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 """""""""""" FIPS 140-2 Security Policy – GateKeeper Page 13 of 18 © Copyright 2011 Xceedium 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 • Firmware load test 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. spfd is the GateKeeper Secure Port Forwarder Daemon. 5 FIPS 140-2 Security Policy – GateKeeper Page 14 of 18 © Copyright 2011 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.2.1. 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 their 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 neither 512-bit or 768-bit RSA keys are used in FIPS mode of operation. 5. Ensure that RADIUS and RSA SecureID 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. 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 their organization’s systems security policies for password storage. The GateKeeper supports the loading of new firmware if the given firmware is intended to be ran in a FIPS- approved mode of operation. FIPS-approved firmware upgrades issued by Xceedium are cryptographically signed and, should an error occur during upgrade, the GateKeeper will be put into a halted state until a Crypto Officer can clear the error. The firmware upgrade mechanism has an integrity check which uses an FIPS 140-2 Security Policy – GateKeeper Page 15 of 18 © Copyright 2011 Xceedium HMAC to verify the integrity of the new firmware. The Crypto Officer may zeroize the HMAC firmware load key by uploading a special patch (FIPS_ZEROIZE_FUHMAC.521.01.p.bin) provided by Xceedium. 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 their organization’s systems security policies to verify it is not 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 their organization’s systems security policies for password storage. FIPS 140-2 Security Policy – GateKeeper Page 16 of 18 © Copyright 2011 Xceedium Approved Cryptographic Algorithms In FIPS mode of operation, only the following FIPS approved algorithms are to be used: • AES encryption/decryption: Validation #1151 and #1572 • Triple DES encryption/decryption: Validation #833 and #1029 • RSA signing and verifying: Validation #765 • SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 hashing: Validation #1065 and #1392 • HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 for hashed message authentication: Validation #654 and #919 • ANSI X9.31 Appendix A.2.4 for PRNG: Validation #846 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 #483 • 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 Algorithm Deprecation Statements As of January 2011 the following algorithms are restricted or deprecated: • 2-key Triple DES • 1024 bit RSA • 1024 bit DSA • ANSI X9.31 RNG • SHA-1 • Diffie-Hellman Please refer to NIST Special Publication 800-131A for more information. FIPS 140-2 Security Policy – GateKeeper Page 17 of 18 © Copyright 2011 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 KVM............................................Keyboard, Video, Mouse 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 18 of 18 © Copyright 2011 Xceedium