Updating to NIST SP 800-131A security standards

National Institute of Standards and Technology (NIST) Special Publications 800-131A (SP 800-131A) standard offers guidance to migrate to the use of stronger cryptographic keys and more robust algorithms. To ensure that you are fully compliant, refer to the NIST SP 800-131A standard.

Before you begin

For runtime environments, ensure that your web server supports TLS 1.2, for example IBM HTTP Server 8.5.5 (plus interim fix PI05309).

About this task

To become NIST SP 800-131A compliant, ensure that your environment adheres to the following standards:

Digital signatures must use at least SHA-2 hashing algorithm, but SHA-1 hashing algorithm can continue to be used for validation. By default, WebSphere Commerce Version 8 uses SHA-2.
Ensure that cryptographic keys adhere to a minimum key strength of 112 bits.
In this task, you upgrading the encrypted data in the database and in configuration files to use AES-128 bit encryption, instead of Triple DES.
Note: After you migrate to an AES merchant key, the encryption algorithm for session data is also enhanced. The site can experience temporary session decryption errors for sessions that are generated before you migrate to an AES merchant key.
For runtime environments, enable TLS 1.2 for SSL and disable protocols less than TLS 1.2.

Procedure

Migrate encrypted data in the database to use AES 128-bit encryption. To complete this migration, you must run MigrateEncryptedInfo by using the Key Locator Framework (-k) to specify the new AES merchant key. Add the algorithm="AES" attribute to the new key definition in the custom key configuration file. Use 32 hex characters (128 bits) for the new key and optional key encryption key values.

Note: Switching to an AES merchant key can result in temporary session cookie decryption errors for any existing sessions that were created before you upgrade to the AES merchant key.
1. Specify that the new key in the keys configuration file is using AES algorithm by adding algorithm="AES" attribute to the new key definition in the custom keys configuration file.
  For example, create or update the WC_eardir/xml/config/CustomKeys.xml file to have a new key definition similar to the following example.
```
<key name="MerchantKey" providerName="WC" status="new" 
className="com.ibm.commerce.security.keys.WCExternalFileMerchantKeyImpl" version="2" algorithm="AES">
<config name="keyFile" value="merchantKey.xml"/>
<config name="keyEncryptionKeyFile" value="KeyEncryptionKey.xml"/>
<config name="newKeyFile1" value="newMerchantKey1.xml"/>
<config name="newKeyFile2" value="newMerchantKey2.xml"/>
</key>
```
  For more information about the Key Locator Framework, see Key Locator Framework (KLF).
2. Ensure that the new keys files combine to form 32 hex characters.
3. Ensure that the key encryption key, if specified, is also 32 hex characters.
4. Open a command prompt and go to the following directory:
  - WC_installdir\bin
  - WCDE_installdir\bin
5. Run the MigrateEncryptedInfo utility for each instance, with the Key Locator Framework (-k) option:
  - For runtime environments, you can run the MigrateEncryptedInfo utility when the server is offline or online. Follow the steps in Updating encrypted data using MigrateEncryptedInfo (server offline) or Updating encrypted data using MigrateEncryptedInfo (server online)
  - For a development environment, you must run the MigrateEncryptedInfo utility when the server is offline. Follow the steps in Updating encrypted data using MigrateEncryptedInfo (server offline).
Update the Business Audit Key that is defined in BusinessAuditDataCapture.xml so it can be used with AES. The default audit key is an encrypted 16 character audit key. To encrypt with AES, the key must be replaced by the encrypted value of a new default 32 character audit key.
1. Go to the following directory:
  - WC_installdir\wc.ear\xml\config
  - workspace_dir\WC\xml\config
2. Open BusinessAuditDataCapture.xml for editing.
3. Optional: If you modified the default audit key to a custom value, rename the original AuditKey to CustomAuditKey.
  The CustomAuditKey node must be defined to continue validating existing records/signatures in the database.
  1. Search for the default audit key value: <AuditKey value="rZ15ws0ely9yHk3zCs3sTMv/ho8fY17s" />
  2. If the value matches your search, then you do not have to rename to CustomAuditKey. Continue to 2.d.
  3. If the value does not match your search, copy the <AuditKey> node.
  4. Paste the node into the file.
  5. For the node that you pasted, replace the word "AuditKey" with "CustomAuditKey".
4. Update the <AuditKey> node with the following 32 character audit key:
```
<AuditKey value="Jmz6ON1Y+573xkNVuOPbfRhZLEJTcW0kqgbCVJv4Jv7UlAGSVFHw6g=="/>
```
5. Save and close the file.
6. Deploy this file for each production instance. For steps on how to deploy a single file, see Deploying J2EE assets for a single file.
Update the instance configuration file, for each instance, to include the AES_DB="true" parameter.
1. In a text editor, open the WebSphere Commerce configuration file for the instance:
  - WC_installdir\instances\instanceName\xml\instance_name.xml
  - WCDE_installdir\workspace\WC\xml\config\wc-server.xml
2. In the configuration file, search for the parameter AES_DB. If the parameter does not exist, add the parameter.
  Example
```
<config>
   <InstanceProperties name="Instance Properties">
		...	
  <Security AES_DB="true"
            AdminPwd="0gYsW5onfbvbp7Q3MYrc917pU0EFWcJPgwsgCjE/Btg="
            AdminUser="configadmin" AuthMode="" Realm="" RunAsID=""
            RunAsPwd="" enabled="false" enabledGlobal="true" passwordpolicy="true"/>
		...
    </InstanceProperties>
    ...
</config>
```
  If the parameter exists, ensure that the value is set to "true".
3. Save and close the file.
4. If your site uses a clustered environment, you must manually sync the nodes by using the deployment manager for the changes to take effect.
5. Propagate the changes that are made to the WebSphere Commerce configuration file. For steps on how to propagate changes, see Propagating changes to the WebSphere Commerce configuration file.
Update product.xml to include the AES_DB="true" parameter on production instances.
1. Open WC_installdir\xml\product.xml
2. Search for the parameter, AES_DB. If the parameter does not exist, add the parameter.
  For example:
```
<websphere>
	<commercesuite>
		...
		<security>
			<AES_DB>true</AES_DB>
		</security>
	</commercesuite>
</websphere>
```
  If the parameter exists, ensure that the value is set to "true".
3. Save and close the file.
4. Deploy this file for each production instance. For steps on how to deploy a single file, see Deploying J2EE assets for a single file.
Restart the server.
Run the MigrateEncryptedFiles utility.
For the utility to complete successfully, ensure that the WebSphere Application Server is continuously up and running during the process.
1. In a command prompt, go to the following directory:
  - WC_installdir/bin
  - WC_installdir\bin
  - WCDE_installdir\bin
2. Run the following command:
  - MigrateEncryptedFiles.sh
  - MigrateEncryptedFiles.bat
  - MigrateEncryptedFiles.bat
  To verify that the utility ran successfully, in each of the wc-server.xml or product.xml files that you updated in step 3 and step 4, ensure that the AES_FILES parameter is set to "true".
For more information about the MigrateEncryptedFiles utility, see MigrateEncryptedFiles utility.
Restart the WebSphere Application Server.

Enable AES on the Search server:

Set the following namespace bindings in the WebSphere Application Server for each Search machine.

In the WebSphere Commerce Search server WebSphere Application Server administrative console, go to Environments > Naming > Name space bindings > scope:Node=demo_search_node,Server=solrServer.
Add the following name-value pair.
Table 1.

Name Value

com.ibm.commerce.foundation.server.services.search.aes.files true
Update the following name-value pair.
Table 2.

Name Value

com.ibm.commerce.foundation.server.services.commerce.integration.sessionkey The sessionKey value from the WebSphere Commerce wc-server.xml file.

Table 1.
Name	Value
com.ibm.commerce.foundation.server.services.search.aes.files	true

Table 2.
Name	Value
com.ibm.commerce.foundation.server.services.commerce.integration.sessionkey	The `sessionKey` value from the WebSphere Commerce wc-server.xml file.

Required if application security is enabled on the Search server:

Set the following namespace binding in WebSphere Application Server for each WebSphere Commerce Authoring and Production machine:In the WebSphere Commerce server WebSphere Application Server administrative console, go to Environments > Naming > Name space bindings > scope:Node=WC_demo_node,Server=server1.

Update the following name-value pair.

Table 3.
Name	Value
com.ibm.commerce.foundation.server.services.search.application.security.password	The Search server's application security password, encrypted by the wcs_encrypt utility in WebSphere Commerce. You do not need to specify the merchant key because WebSphere Commerce and Search are now using AES protocol. For more information, see Generate encrypted data (wcs_encrypt).

Set the following namespace binding in WebSphere Application Server for each Search Production and Repeater machine. In the Search server WebSphere Application Server administrative console, go to Environments > Naming > Name space bindings > scope:Node=demo_search_node,Server=solrServer.

This step is only required if you are using the Commerce Insights BAC SFTP Server password (used by Commerce Insights Product Sequencing), and assuming that WebSphere Commerce is already using AES for its files.
1. Edit or create the file Search_eardir/xml/config/com.ibm.commerce.foundation/wc-component.xml.
2. Set the property <_config:property name="BACSFTPServerSetting/userPassword" value="" /> by running the wcs_encrypt utility (without the merchant key) from the WC_install/bin directory.
3. Set the AES flags to true in under Search_eardir/xml/config/com.ibm.commerce.foundation/wc-component.xml:
```
<_config:property name="CommerceServerSetting/Security/AESDBEnabled" value="true"/> 
<_config:property name="CommerceServerSetting/Security/AESFilesEnabled" value="true"/>
```
4. Restart the servers that were updated above.

Edit the file Search_eardir/xml/config/com.ibm.commerce.foundation/wc-component.xml. Set the AES flags in the file to true.

<_config:property name="CommerceServerSetting/Security/AESDBEnabled" value="true"/> 
<_config:property name="CommerceServerSetting/Security/AESFilesEnabled" value="true"/>

Restart the search server.
Ensure proper support for TLS 1.2 on your runtime environments.
- Configure your web server to require TLS 1.2 as a minimum. For example, for IBM HTTP Server 8.5.5, add the following directive to your httpd.conf web server configuration file to disable HTTPS protocols lower than TLS 1.2 for all virtual hosts with the SSLEnable directive enabled:
```
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
```
- If WebSphere Commerce is integrated with LDAP using SSL, set the SSL protocol to TLS 1.2.
- If outbound email is used over SSL, configure email to use TLS 1.2.
- Ensure that browsers that are interacting with WebSphere Commerce are using TLS 1.2, for example Internet Explorer 8 or later on Windows 7 or later.
Ensure that web certificates and certificates that are used to integrate WebSphere Commerce with other applications (such as Sterling OMS) are upgraded to satisfy the following NIST SP 800-131A specifications:
- All certificates with RSA or DSA keys that are shorter than 2048 bits must be replaced with certificates that are 2048 bits or higher.
- Certificates with elliptic curve keys shorter than 160 bits must be replaced with longer keys. Contact your certificate authority issuer (CA) for new certificates.
- All certificates must be signed by an allowed signature algorithm. For example, SHA-256, SHA-384, or SHA-512. SHA-1 digest algorithms are no longer allowed.
Configure WebSphere Application Server for NIST SP 800-131A:
- For a production environment, Enable NIST SP 800-131A strict mode.
- For a staging environment, Enable NIST SP 800-131A transition mode.
Restart your WebSphere Commerce server.