FIPS 140-2 Security Policy – Xsuite Page 1 of 19
© Copyright 2012 Xceedium
FIPS 140-2 Non-Proprietary Security Policy
for
Xceedium Xsuite™
Hardware Version 5, 5a or 5b
Firmware Version 1.0.0
Level 2 Validation
Document Version: Version 3.8
September 30, 2014
FIPS 140-2 Security Policy – Xsuite Page 2 of 19
© Copyright 2012 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
Dave Olander, Xceedium
Update for GateKeeper 5.0.0
2.1 August 7, 2009 Ryan Maple, Xceedium
Dave Olander, Xceedium
Revise with comments from EWA
2.2 August 18, 2009 Ryan Maple, Xceedium
Dave Olander, Xceedium
Revise with comments from EWA
2.3 August 20, 2009 Ryan Maple, Xceedium
Dave Olander, Xceedium
Revise with comments from EWA
2.4 February 11, 2010 Ryan Maple, Xceedium
Dave Olander, Xceedium
Revise with comments from NIST
2.5 March 15, 2010 Ryan Maple, Xceedium
Dave Olander, Xceedium
Revise with further comments from NIST.
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.
3.6 December 2, 2011 Ryan Maple, Xceedium <Reverted/dead>
3.7 November 12, 2012 Ryan Maple, Xceedium Rename GateKeeper 5.2.1 to Xsuite 1.0.0.
3.8 September 30, 2014 Ryan Maple, Xceedium Inclusion of SSD 5b
Table 1 - Security Policy Revision History
FIPS 140-2 Security Policy – Xsuite Page 3 of 19
© Copyright 2012 Xceedium
FIPS 140-2 Security Policy – Xsuite Page 4 of 19
© Copyright 2012 Xceedium
TABLE OF CONTENTS
REVISION HISTORY........................................................................................................................................................................2
TABLE OF CONTENTS ...................................................................................................................................................................4
INTRODUCTION ..............................................................................................................................................................................5
BACKGROUND................................................................................................................................................................................5
EXTERNAL RESOURCES .................................................................................................................................................................5
NOTICES .......................................................................................................................................................................................5
XCEEDIUM XSUITE.........................................................................................................................................................................6
PRODUCT OVERVIEW .....................................................................................................................................................................6
CRYPTOGRAPHIC MODULE SPECIFICATION......................................................................................................................................6
VALIDATION LEVEL.........................................................................................................................................................................7
MODULE INTERFACES.....................................................................................................................................................................7
ROLES AND SERVICES....................................................................................................................................................................8
Crypto Officer Role.................................................................................................................................................................8
User Role ...............................................................................................................................................................................9
Authentication.......................................................................................................................................................................10
CRYPTOGRAPHIC KEY MANAGEMENT............................................................................................................................................12
SELF-TESTS ................................................................................................................................................................................13
Power-On Self-Tests............................................................................................................................................................14
Conditional Self-Tests ..........................................................................................................................................................15
MITIGATION OF OTHER ATTACKS...................................................................................................................................................15
SECURE OPERATION OF XSUITE...............................................................................................................................................16
CRYPTO OFFICER GUIDANCE........................................................................................................................................................16
Module Initialization and Configuration ................................................................................................................................16
Physical Security and Tamper Evidence..............................................................................................................................17
USER GUIDANCE..........................................................................................................................................................................17
APPROVED CRYPTOGRAPHIC ALGORITHMS ...................................................................................................................................18
NON-FIPS APPROVED ALGORITHMS.............................................................................................................................................18
ACRONYM LIST.............................................................................................................................................................................19
FIPS 140-2 Security Policy – Xsuite Page 5 of 19
© Copyright 2012 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 Xsuite 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.
Xceedium Xsuite v1.0.0 was previously known/released as Xceedium GateKeeper v5.2.1.
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 Xsuite 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 – Xsuite Page 6 of 19
© Copyright 2012 Xceedium
XCEEDIUM XSUITE
Product Overview
Xceedium Xsuite™, which may also be referred to simply as Xsuite, 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. Xsuite 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.
Xsuite 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 Xceedium Xsuite, running firmware version 1.0.0 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 – Xsuite Page 7 of 19
© Copyright 2012 Xceedium
Figure 1 – Physical Boundary
Validation Level
The following table lists the level of validation for each area in FIPS 140-2.
FIPS 140-2
DTR Section
Section Title
Module
Validation
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 Security Policy – Xsuite Page 8 of 19
© Copyright 2012 Xceedium
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
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 Xsuite 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 Xsuite, 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 Xsuite section of this document for more details)
FIPS 140-2 Security Policy – Xsuite Page 9 of 19
© Copyright 2012 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
FIPS 140-2 Security Policy – Xsuite Page 10 of 19
© Copyright 2012 Xceedium
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
 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
mechanism
Passwords must be a minimum of 6 characters and a maximum of 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.
FIPS 140-2 Security Policy – Xsuite Page 11 of 19
© Copyright 2012 Xceedium
Authentication Type Strength
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
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.
2 As described in the Secure Operation of Xsuite section, 512-bit and 768-bit RSA keys must not be used in FIPS mode of
operation.
FIPS 140-2 Security Policy – Xsuite Page 12 of 19
© Copyright 2012 Xceedium
Cryptographic Key Management
Table 7 provides a complete list of critical security parameters3 used within the module:
IDENTIFIER
KEY /
CSP NAME
DESCRIPTION STORAGE (FORMAT) DELETION
1
PRNG Seed
and Seed Key
Generated from non-FIPS
approved PRNG in OpenSSL
code implemented in module;
used in ANSI X9.31 Appendix
A.2.4 FIPS-approved PRNG
(using AES)
RAM (plaintext) Generating a new seed
2 Public keys Public keys of peers RAM (plaintext)
Resetting or rebooting the
module
3
RSA
public/private
keys
Identity certificates for the module
itself and also used in TLS
negotiations. The module
supports 1024 and 2048 bit key
sizes.
NVRAM (plaintext)
Deleting the certificate or
certificate request; The keys
are overwritten with dashes
via command sent by the
Crypto Officer over the web
interface.
4
TLS Traffic
Keys
Used in HTTPS connections RAM (plaintext)
Resetting or rebooting the
module
5
User
Passwords
Secret
NVRAM/Flash Memory
(plaintext) and RAM
(plaintext)
Overwriting the passwords
with new ones
6
Crypto Officer
Passwords
Secret
NVRAM/Flash Memory
(plaintext) and RAM
(plaintext)
Overwriting the passwords
with new ones
7
Xceedium
default
certificate and
private key
Used in HTTPS connections NVRAM (plaintext)
Deleting the certificate or
certificate request; The
private key is overwritten
with dashes via command
sent by the Crypto Officer
over the web interface.
8
Diffie-Hellman
Key Pairs4
Key agreement for TLS sessions RAM (plaintext)
Resetting or rebooting the
module
9
IPsec Traffic
Keys
Used to encrypt IPsec sessions RAM (plaintext)
Resetting or rebooting the
module
10
Client
Certificates
Authenticate PKI peers RAM (plaintext)
Resetting or rebooting the
module
11
HMAC
firmware load
key
Used to validate firmware
upgrade patches
NVRAM (plaintext)
Application of patch (see
Crypto Officer Guidance)
Table 7 – Critical Security Parameters
3 Public keys are not considered to be critical security parameters.
4 DH groups 2 (1024 bits), 5 (1536 bits) and 7 (2048 bits) are supported.
FIPS 140-2 Security Policy – Xsuite Page 13 of 19
© Copyright 2012 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
Services by Role
1
2
3
4
5
6
7
8
9
10
11
User Role
Access R R W R R W
Authenticate R W R R W R R R W R W R
Monitoring R R
User Account Management R W D
Crypto Officer Role
Access R R W R R W
Monitoring R R
Authenticate R W R R W R R R W R W R
Sessions R R
Config R W D R W D R W D R W D D R W D R W D R W D R W D R W D R W D
Services R R
Users R W D R W D R W R R W
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 Xsuite 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 – Xsuite Page 14 of 19
© Copyright 2012 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:
""""""""""""
Xsuite
In FIPS mode
""""""""""""
FIPS 140-2 Security Policy – Xsuite Page 15 of 19
© Copyright 2012 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.
5 spfd is the Xsuite Secure Port Forwarder Daemon.
FIPS 140-2 Security Policy – Xsuite Page 16 of 19
© Copyright 2012 Xceedium
SECURE OPERATION OF XSUITE
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 1.0.0.
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.
Xsuite 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.
Xsuite 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, Xsuite 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 HMAC to verify the
FIPS 140-2 Security Policy – Xsuite Page 17 of 19
© Copyright 2012 Xceedium
integrity of the new firmware. The Crypto Officer may zeroize the HMAC firmware load key by uploading a
special patch (FIPS_ZEROIZE_FUHMAC.100.01.p.bin) provided by Xceedium.
Physical Security and Tamper Evidence
The enclosure cover of Xsuite is secured to the rear of the chassis with two (2) Torx T10 screws. A single,
serialized, tamper evidence label is placed on Xsuite 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 – Xsuite Page 18 of 19
© Copyright 2012 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 – Xsuite Page 19 of 19
© Copyright 2012 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