This appendix outlines what components of CA NSM r11.2 are FIPS-140-2 compliant, what data is protected in a compliant manner, details about the eTrust PKI, FIPS configuration and migration information for each component, and other FIPS-related information.
This section contains the following topics:
CA NSM r11.2 does not provide full FIPS 140-2 compliance. However, several areas of the product support this level of encryption and use FIPS-140-2 compliant cryptographic libraries to protect passwords and other sensitive data.
Components in CA NSM r11.2 that support FIPS 140-2 give you the option to encrypt all sensitive data using FIPS-compliant algorithms provided by the eTrust PKI (ETPKI). The ETPKI is a SDK included with CA NSM that enables certain components to support FIPS encryption through use of its cryptographic libraries and encryption algorithms.
The following CA NSM components provide FIPS 140-2 compliant encryption:
The following component provides FIPS 140-2 encryption support in certain situations:
Systems Performance provides FIPS 140-2 encryption support using the ETPKI for all sensitive data. The ETPKI wraps the FIPS 140-2 validated RSA BSAFE Crypto-C Micro Edition cryptographic module. Systems Performance uses the AES encryption algorithm with a 256-bit strength key to encrypt keys and data. It also uses SHA-1 (Secure Hash Algorithm) to hash the keys to make sure they are not tampered with.
Note: When FIPS mode is not enabled, Systems Performance uses the PKCS #5 v2.0 algorithm to generate a password generated key.
By default, FIPS encryption is disabled. You must enable the encryption, at which time any sensitive data is re-encrypted. Data is encrypted to a Systems Performance-specific library using a Data Encryption Key (DEK), which must be distributed to all Systems Performance servers where encryption and decryption is required.
The following Systems Performance data is encrypted when using FIPS mode:
Includes the SNMPv3 security name, authentication password and protocol, and privacy password and protocol used to access SNMPv3 devices and their MIBs. This information is created by Performance Configuration and decrypted by Performance Scope for real-time monitoring and the Performance Agent for historical monitoring.
Files: Stored by the Performance Domain Server in files named resource.ext and <machine>.cmp. Copied by the Performance Distribution Server to Performance Agents configuration file Hpaagent.cfg if it is configured to monitor an SNMP device.
Includes SNMPv1/v2 community string information. This information is encrypted by Performance Configuration when accessing a MIB or device, and it is decrypted by Performance Scope for real-time monitoring and the Performance Agent for historical monitoring.
Files: Stored by the Performance Domain Server in files named resource.ext and <machine>.cmp. Copied by the Performance Distribution Server to Performance Agents configuration file Hpaagent.cfg if it is configured to monitor an SNMP device.
Includes computer access credentials used by Performance Trend Batch Reporting to successfully generate and output reports. Batch Reporting must supply credentials to Unicenter Workload that let it interact with the desktop. These credentials are encrypted by Performance Trend Batch Reporting after being entered into the Performance Trend Batch Reporting Wizard, and they are decrypted by the Performance Trend Batch Reporting Generator when executing the Batch Reporting Profile.
Location: Stored by Performance Trend in the Performance Trend Batch Reporting Profile files (*.tbp) held within the Performance Trend area of the <Logged in User> or <All Users> application data area of the computer.
Includes MDB connection credentials used by the Performance Domain Server to publish summary performance data to the MDB. These credentials are created through the Systems Performance Installer or the Performance Domain Server configuration utility (cfgutil), and they are decrypted by the Performance Domain Server when accessing the MDB to publish summary data.
File: dbcred.dat in the Performance Domain Server
Includes MDB connection credentials that you enter before a response file-generated installation so that the Performance Domain Server can publish Performance Data to the MDB, and Performance Reporting can use the WorldView section of the MDB for reporting. The response file is created by the Systems Performance Installer, and the MDB credentials are decrypted by the Systems Performance Installer when running an installation in response file mode.
Location: Stored in a response file for later use in response file-driven installations. The response file is stored in a user specified file.
Includes the user names and domain names used to gain access to the Performance Domain Server and Performance Distribution Server data and operations. The user names and domains are created by the user on the Performance Domain Server, and they are decrypted by the Performance Domain Server and Performance Distribution Server hosts.
File: Maintained by the Performance Domain Server in a file named users.dat and distributed to the Performance Distribution Server so that it can also validate data requests.
Includes Unicenter Management Portal and Web Reporting Service connection details that are required for Performance Trend to publish reports to either of these tools. These credentials are encrypted by Performance Trend Batch Reporting after being entered into the Performance Trend Batch Reporting Wizard, and they are decrypted by the Performance Trend Batch Reporting Generator when publishing reports to Unicenter Management Portal or Web Reporting Service.
Location: Maintained by Performance Trend in Portal Profiles (*.pop) that are held within the Performance Trend area of the <Logged in User> or <All Users> application data area of the computer.
In Systems Performance, sensitive data is encrypted in FIPS mode by ETPKI using a 256-bit Data Encryption Key (DEK). By default, Systems Performance uses an embedded key to perform FIPS-based encryption, but you can create a custom non-embedded key.
Custom keys are protected by an additional Key Encryption Key (KEK) embedded within Systems Performance. We recommend also securing custom keys using operating system file security. The keyfile is in the Systems Performance installation directory at the following location:
%CASP_PATH%\appdata\keystore
We recommend giving only administrators permissions to access the directory and keyfiles for Performance Manager and Performance Agent servers and read access to non-admin users on servers running UI components.
By default, FIPS encryption is not enabled in Systems Performance. You must turn on FIPS mode manually using the CASP_FIPS_MODE environment variable.
To turn on FIPS mode, locate the CASP_FIPS_MODE environment variable and set its value to '1' on all Domain Server and Performance Trend servers.
This enables FIPS 140-2 encryption in Systems Performance. Any sensitive data is re-encrypted using the new FIPS compliant algorithm.
If necessary, you can switch back to non-FIPS mode at any time by setting the CASP_FIPS_MODE variable value to anything but '1' or removing the variable.
Note: For more information about the complete process you must perform to ensure that the switch to FIPS mode is complete and without errors, see How to Switch to FIPS Mode.
You can perform an initial manager installation of Systems Performance in any of the following ways:
We recommend that you perform an initial installation with FIPS mode turned off (the default setting), in which the installer continues to encrypt all data using password-based encryption. If earlier versions of Performance Agents exist in your enterprise, the manager may not be able to configure these agents with FIPS mode enabled. Once all Performance Agents are upgraded to r11.2 levels, you can enable FIPS encryption.
Note: FIPS mode cannot be enabled if earlier releases of the Performance Agents are to be installed on platforms not currently supported by CA NSM r11.2. These earlier agents will be unable to decrypt the encrypted configuration information.
No special steps are required when reinstalling manager components, UI components, or Performance Agents with FIPS mode turned on or off.
For more detailed information about how the FIPS encryption option affects your installation and several deployment scenarios, see the Systems Performance documentation. For a description of the recommended installation scenario, see How to Install Systems Performance with FIPS Mode Off.
When installing or upgrading to CA NSM r11.2, we recommend performing the Systems Performance Manager installation with FIPS mode turned off, so that the manager can configure any earlier versions of Performance Agents. Complete the following process to install Systems Performance with FIPS mode off and enable FIPS encryption after installation.
Note: See the Systems Performance documentation for more information, including detailed installation instructions and other deployment scenarios, such as performing a clean installation with FIPS mode enabled and performing a response file-driven installation using FIPS encryption.
setup.exe /genkey <File path>
Specifies the full path of an existing directory, including the key file name, where you want to store the key file.
Note: By default, Systems Performance uses an embedded key to perform the FIPS-based encryption and decryption and does not require the creation of a custom key.
Windows
Windows\NT\SystemsPerformance\data
UNIX/Linux
/data/sysperf_key
When you place the key file on the image, the Systems Performance installer automatically copies it to the installed system.
Note: You can deploy additional Performance Agents after the initial setup process. For more information, see the Systems Performance documentation.
Performance Agents continue to run with the configurations encrypted using non-FIPS based encryption until you redeliver all profiles.
If you want to switch Systems Performance to run in FIPS mode, you must ensure that all appropriate servers in your enterprise are switched and all existing data is reencrypted. Complete the following process to ensure that your switch to FIPS mode is complete and without error:
Note: This process applies only when you are using the default embedded encryption key. If you want to create a new key, you must do so before starting the process. For more information, see How to Change the FIPS Encryption Key.
At this point all old data is still readable but not FIPS encrypted, and new data is encrypted using FIPS.
At this point all old data is still readable but not FIPS encrypted, and new data is encrypted using FIPS.
Performance Agents continue to run with the configurations encrypted using non-FIPS based encryption until you redeliver all profiles.
If you want to change the FIPS encryption key to a newly generated one, you must distribute the key to all appropriate servers and reencrypt all existing data using the new key. Complete the following process to ensure that your migration to the new key is complete and without error.
Note: If you want to switch to FIPS mode in addition to generating a new custom key, complete the first two steps of this process, and then follow the steps in How to Switch to FIPS Mode. If switching to FIPS mode, you do not have to copy the previous key as in Step 2.
Note: To ensure that the key is copied to the correct location on the target servers, use the -i parameter of the CASPKeyUtil utility and specify the correct file to install the key to. The CASPKeyUtil utility also automatically copies the existing key to key.old.
Note: Perform Steps 7-9 only if changing from one non-embedded key to another non-embedded key, and if you feel that the old key is compromised.
Performance Agents continue to run with the configurations encrypted with the existing key until you redeliver all profiles. Once the agent receives a configuration encrypted using the new key, it automatically deletes the previous key.
To switch from FIPS mode back to non-FIPS mode, you must do so on all appropriate servers and reencrypt all existing data. Complete the following process to ensure that your switch back to non-FIPS mode is complete and without errors.
Note: Non-FIPS mode is the default encryption mode, so you do not have to switch off FIPS mode unless you have previously turned it on.
At this point all new or updated data is encrypted using non-FIPS mode encryption. However, existing data remains encrypted in FIPS mode and is still accessible by all applications.
At this point all new or updated Batch Reporting profiles are encrypted using non-FIPS mode encryption. However, existing profiles remain encrypted in FIPS mode and are still readable by Performance Trend.
Performance Agents continue to run with the configurations encrypted in FIPS mode until you redeliver all profiles.
Note: Perform Steps 7-9 only if you used a non-embedded key for FIPS encryption and you feel that the key is compromised. Before deleting keys, make sure that all FIPS encrypted data has been reencrypted, because FIPS encrypted data cannot be decrypted without the encryption keys. Use the -purgeall parameter in the CASPKeyUtil utility to delete all keys.
When you upgrade Systems Performance from a previous release (3.1, r11, or r11.1), we recommend that you perform the upgrade in non-FIPS mode so that all Performance Agents are able to read their configurations. Following is the basic upgrade process:
The process is similar to installing Systems Performance with FIPS mode off. For details, see How to Install Systems Performance with FIPS Mode Off. For more information about how to upgrade, see the Systems Performance documentation.
When deploying the Performance Agent to an enterprise where FIPS is enabled, we recommend that you include the current FIPS key in the master image. When the key is copied to the master image, it is automatically deployed to the agent server, allowing it to decrypt any SNMP credentials provided in its initial configuration.
Complete the following process to copy the current FIPS key to the master image and install the Performance Agent:
CASPKeyUtil -e <FILE>
Specifies the name of the file to export the active key to.
Windows
Windows\NT\SystemsPerformance\data
UNIX or Linux
/data/sysperf_key or /<Platform>/data/sysperf_key
The current key is automatically deployed to the Performance Agent server.
An alternative method is to copy the key to the target system after the Performance Agent has been installed. Complete the following process to copy the appropriate encryption key to the Performance Agent server after installation:
CASPKeyUtil -e <FILE>
Specifies the name of the file to export the active key to.
CASPKeyUtil -i <FILE>
Specifies the name of the key file exported from the Performance Domain Server.
You may need update the domain access file (users.dat) periodically to add or remove user and domain names used to access the Performance Domain Server and Performance Distribution Server data and operations. This file cannot be encrypted when you edit it. Complete the following process to un-encrypt, edit, and reencrypt the users.dat file.
CASPEncrypt -x
Note: You can only run this command on the Performance Domain Server.
%CASP_PATH%\DomainServer\data\users.dat
Note: For more information about how to update the users.dat file, see the Inside Systems Performance guide.
CASPEncrypt -y
The CASPKeyUtil command line utility lets you generate a new data encryption key if you do not want to use the provided key. With this utility, you can also view information about existing keys, delete existing keys, and specify the location of existing keys and the new key.
This utility has the following format:
CASPKeyUtil [ -i, --install [FILE] -c, --create <FILE> -e, --export <FILE> -p, --purge -p, --purgeall -f, --info [FILE] -?, --help]
Generates and installs a new key into the key store. If you specify a file, this key is installed into the key store.
Creates a new key into the specified file, but does not install it into the key store.
Exports the active key to the specified file name.
Purges the old key in the key store.
Purges all of the keys in the key store.
Displays the properties for either the active or specified key.
Displays the utility's help.
Important! The CASPKeyUtil utility maintains only two keys at a time - key and key.old. Therefore, you must ensure that all sensitive data has been reencrypted using the CASPEncrypt utility before you create a second custom key. When you create a second custom key, the original key is permanently deleted, and you will not be able to recover the data encrypted by that key if you have not reencrypted it.
Valid on Windows
The CASPEncrypt.exe utility lets you reencrypt data that has been previously encrypted with a different mode or different key. When you change the encryption mode or the encryption key, the data encrypted using the previous key or mode becomes invalid and requires reencryption. When you run this utility, Domain Server data, Performance Trend profiles, or both are reencrypted using the new key or mode, with the old key or mode being used to decrypt the existing data.
This utility has the following format:
CASPEncrypt [ -d, --domain -t, --trend -a, --all -h, --help -i, --info -x, --usersdec -y, --usersenc]
Reencrypts only Domain Server files.
Reencrypts only Performance Trend files.
Reencrypts Domain Server and Performance Trend files.
Displays usage information.
Displays whether FIPS is enabled. Use this parameter at any time to confirm whether a switch to FIPS mode or non-FIPS mode was successful.
Un-encrypts the user access control file (users.dat) for editing.
Reencrypts the user access control file (users.dat) after editing.
Active Directory Management (ADM) provides FIPS 140-2 support using the ETPKI library to encrypt user passwords. The ETPKI wraps the FIPS 140-2 validated RSA BSAFE Crypto-C Micro Edition (ME) encryption library. Passwords are encrypted using the AES encryption algorithm with a 256-bit strength encryption key.
The following Active Directory Management data is encrypted:
Includes the password required to access Active Directory forest and domain information. This information is created by the ADEM Connection Settings tool (ADEMConfig) and decrypted by the ADEM Service.
File: Stored by ADEMConfig in a file named forest.py and read from the file by the ADEM Service.
Active Directory Management encrypts passwords with a 256-bit data encryption key. The encryption key is contained in the file util_crypt.pyc, which is part of library.zip. This file is in the installation directory at the following location:
Install_path\SC\CCS\ADEM\bin
We recommend securing the file using Operating Systems file security, and giving read permissions to only ADM administrators and the local system account.
When you perform a clean installation of ADM, it automatically uses FIPS mode encryption.
When you upgrade from a CA NSM r11.1 patch that contains ADM, the configuration utility ademinstall.exe automatically converts passwords in the forest.py file to the new encryption format. A new parameter 'filever = 2' is added to forest.py to specify the new format.
When you uninstall ADM, forest.py is removed automatically.
Note: For more information about installing, upgrading, or uninstalling ADM, see the ADM documentation.
ADM automatically uses FIPS encryption in the forest.py file upon installation and upgrade. However, you may need to manually convert forest.py to use FIPS encryption if restoring an r11.1 backup file, for example.
To manually convert forest.py to use FIPS encryption, run the ADEMConfig utility.
The tool converts the file automatically on startup and notifies you of the change in a message box.
Note: For more information about the ADEMConfig utility, see the Inside Active Directory Management guide.
The Agent Technology component of CA NSM provides FIPS 140-2 encryption support using the RSA Crypto-C ME encryption library through the ETPKI. Agent Technology uses the AES CFB algorithm with a 128-bit strength encryption key, the 3DES CBC algorithm with a 64-bit strength encryption key, and the SHA-1 algorithm to encrypt configuration files, communications with other CA NSM components, and SNMPv3 communications.
The following Agent Technology data is encrypted in a FIPS 140-2 compliant manner:
Includes files containing sensitive data such as passwords.
Includes encrypted content transported over a network using SNMPv3. This encryption is done using the AES CFB algorithm with a 128-bit key or the 3DES CBC algorithm with a 64-bit key.
Includes all data exchanges with other CA NSM components.
The data encryption keys used with Agent Technology are derived from passwords that protect the key and the sensitive data protected by the key. You can further augment key protection by creating an additional DLL to add another layer of protection to your encryption environment.
You must turn on 'FIPS-only' mode for Agent Technology to use FIPS 140-2 compliant libraries and algorithms to protect sensitive data and communications.
After an upgrade, all new files are encrypted using FIPS algorithms. Encrypted Agent Technology data from previous versions works with CA NSM r11.2 after an upgrade. Some of the existing data is reencrypted automatically during the initial run-time, while other data requires you to reencrypt it manually If you want to make this data FIPS 140-2 compliant.
The CA Common Communications Interface (CACCI) component of CCS r11.2 provides FIPS 140-2 encryption support using the ETPKI. ETPKI provides an abstraction layer from the underlying certified encryption libraries.
CCI uses RSA's BSAFE Crypto C Micro Edition Version 2.0 for encrypting data sent over the Common Communications Interface. The encryption algorithm used is the AES Cipher Block Chaining (CBC) algorithm with a 256-bit strength key, or any other cipher suite used by the ETPKI that is FIPS compliant and compatible with CA OpenSSL TLS.
Note: FIPS encryption is only supported for CCI through the remote service and is unavailable through the quenetd.
Data exchanged between CA NSM components using the Common Communications interface is encrypted using FIPS compliant libraries and algorithms. Everything sent from the local to remote hosts, including the data itself, CCI headers, and user data, is encrypted.
For CCI to use FIPS compliant libraries to encrypt data exchanged between components, you must turn on FIPS mode.
To turn on FIPS mode
FIPS mode is turned on.
CCI encrypts all communications using FIPS compliant methods.
You must do the following to enable FIPS compliant encryption after installing CCI:
For more information about enabling SSL support, see the chapter "Securing CA NSM".
While the Management Command Center (MCC) is not fully FIPS 140-2 compliant, several types of protection and communication use or can be configured to use FIPS compliant encryption:
The following MCC data is encrypted in a FIPS 140-2 compliant manner:
Includes the user names and passwords entered to access the following web-based applications: AEC Web Editor, Configuration Management (UCM), Adaptive Dashboard Services (ADS), Discovery Configuration, eHealth Report Server, Web Reporting Service (WRS), and Unicenter Service Desk. These credentials are encrypted and stored in the MCC WebApplications directory located under the user's home directory whenever the user indicates that the credentials should be remembered.
File: savedsettings.xml
Includes data sent between the MCC and other web applications that are hosted by Tomcat. These applications include AEC Web Editor, UCM, ADS, Discovery Configuration, eHealth Report Server, WRS, and Unicenter Service Desk.
Includes data sent between the MCC and WorldView and Event Management using CA Messaging (CAM).
Includes data sent between the MCC and Alert and Event Management using DIA.
The 128-bit private key used for data encryption of web application login credentials is generated by MCC and stored in a keyfile located under the user's home directory, allowing for access level control using operating system level file security.
For communications between the MCC and Tomcat-hosted applications, you can configure Tomcat to use the Java Key Store (JKS) or a PKCS12 keystore. The keystore can be located anywhere on the server. You can point to the keystore using the keystoreFile attribute. Secure the keystore using operating system level file security.
DIA uses a 256-bit private key to encrypt DIA-based communications between the MCC and Alert and Event Managers. The keystore is located in the configuration directory for DIA, and you can secure the keystore using operating system level file security.
During installation of MCC, a private Java Runtime Engine (JRE) is installed for use by MCC and other CA NSM components. The jsafeJCEFIPS.jar file containing the RSA BSAFE Crypto-J JCE Provider Module is installed in the extensions directory of this private JRE. At run-time, the MCC triggers the JRE to load the BSAFE JCE provider module. Therefore, FIPS compliant encryption of login credentials for web-based applications requires no post-installation steps.
Encryption of communications between the MCC and web applications must be enabled manually after installation by configuring Apache Tomcat to use TLS encryption. For detailed step-by-step instructions for configuring Apache for TLS, see Configure Tomcat with SSL in the Implementation Guide.
When configuring Tomcat to use SSL, you can also specify to use only FIPS 140-2 compliant algorithms by setting the "ciphers" attribute of the Connector element and listing the allowed algorithms. Specify the ciphers using the JSSE cipher naming convention. For more information about configuring Tomcat to use specific ciphers, see the Apache Tomcat and Sun JSSE web sites for details.
For encryption of communications between MCC and the WorldView and Event Management components, you must configure CA Messaging (CAM) to use TLS encryption. For more information, see Configure CAM to Use TLS Encryption.
You must enable encryption of DIA-based communications between MCC and Event and Alert Managers by configuring DIA to use FIPS 140-2 compliant encryption. For detailed steps on how to configure DIA encryption, see Configure Communications for Encryption in the Implementation Guide.
Login credentials encrypted using a prior release of MCC are decrypted using the previous algorithm upon the first launch of MCC and automatically reencrypted when the MCC session ends.
For communications between the MCC and WorldView and Event Management to be encrypted, you must configure CAM, which handles the data transport between the MCC and these components, to use TLS encryption.
For details about the command line utility required to configure CAM for TLS, see Configure SSA to Enable CAM to use SSL/TLS.
For more information about configuring CAM, see the CA Message Queuing Service (CAM) section in the chapter "Using Ports to Transfer Data."
Remembering of login credentials for the WorldView and Event Management components is accomplished through CA Messaging (CAM) using password caching, which is not FIPS compliant. You may want to turn off this password caching if you are concerned about the level of security it provides. The password caching is turned on by default.
To turn off password caching for CAM login credentials
default.SEC.bypass_cache
Save and close the file.
Password caching is turned off.
While Unicenter Management Portal does not fully support FIPS 140-2 encryption, the encryption algorithm has been improved for r11.2. Unicenter MP uses the encryption libraries installed, registered, and maintained by the CleverPath Portal PEK, which has been upgraded to r4.72.
Unicenter MP supports remembering credentials with AES encryption for persistent user names and passwords using the RSA BSAFE Crypto-J JCE Provider Module version 3.5. Unicenter MP uses the AES Cipher Block Chaining (CBC) algorithm with a 128 bit strength key for encryption.
You can also configure Apache Tomcat to use TLS (Transport Layer Security) encryption to protect data exchanged between Unicenter MP and web-based applications that Tomcat hosts. By default, Tomcat uses the Java Secure Socket Extension from Sun (JSSE) for implementation of TLS support. The algorithm used for encryption with TLS is negotiated between the server and the client, although you can configure to restrict use to only certain algorithms.
The following Unicenter MP data is encrypted using FIPS 140-2 compliant libraries:
Includes persistent user names and passwords.
File: database.properties
Includes database user names, passwords, and JDBC URLs entered in Unicenter MP to access MDB data.
File: database.properties
Includes Unicenter NSM login names and passwords entered in Unicenter MP to establish connections with CA NSM components.
Includes data sent between Unicenter MP and other web applications that are hosted by Tomcat. These applications are AEC Web Editor, Configuration Management (UCM), Adaptive Dashboard Services (ADS), Discovery Configuration, eHealth Report Server, Web Reporting Service (WRS), and Unicenter Service Desk.
The 128 bit private key used for data encryption of persistent user names and passwords, database passwords, and CA NSM passwords is stored in the INSTALL_PATH\CCS\WRS\webpages\WEB-INF\lib\ca-common-crypto-12.0.39.0.jar resource file. You can secure this file on the local file system using operating system level file security.
For communications between Unicenter MP and Tomcat-hosted applications, you can configure Tomcat to use the Java Key Store (JKS) or a PKCS12 keystore. The keystore can be located anywhere on the server. You can point to the keystore using the keystoreFile attribute. Secure the keystore using operating system level file security.
Encryption of communications between Unicenter MP and web applications must be enabled manually after installation by configuring Apache Tomcat to use TLS encryption. For detailed step-by-step instructions for configuring Apache for TLS, see Configure Tomcat with SSL in the Implementation Guide.
When configuring Tomcat to use SSL, you can also specify to use only FIPS 140-2 compliant algorithms by setting the "ciphers" attribute of the Connector element and listing the allowed algorithms. Specify the ciphers using the JSSE cipher naming convention. For more information about configuring Tomcat to use specific ciphers, see the Apache Tomcat and Sun JSSE web sites for details.
While Web Reporting Server (WRS) does not fully support FIPS 140-2 encryption, the encryption algorithm has been improved for r11.2. WRS uses the encryption libraries installed, registered, and maintained by the CleverPath Portal PEK, which has been upgraded to r4.72.
WRS supports remembering credentials with AES encryption for persistent user names and passwords using the RSA BSAFE Crypto-J JCE Provider Module version 3.5. WRS uses the AES Cipher Block Chaining (CBC) algorithm with a 128 bit strength key for encryption.
The following WRS data is encrypted using FIPS 140-2 compliant libraries:
Includes persistent user names and passwords for components that use WRS.
The 128 bit private key used for data encryption of persistent user names and passwords is stored in the INSTALL_PATH\CCS\WRS\webpages\WEB-INF\lib\ca-common-crypto-12.0.39.0.jar resource file. You can secure this file on the local file system using operating system level file security.
WRS requires a post-installation configuration of Apache Tomcat to use TLS to encrypt Tomcat-enabled communications using FIPS-compliant libraries. For detailed instructions for configuring Tomcat to use TLS, see Configure Tomcat with SSL in the Implementation Guide.
|
Copyright © 2010 CA.
All rights reserved.
|
|