How to Re-Encrypt Existing Sensitive Data

Installation and Upgrade Guides › SiteMinder Upgrade Guide › Using FIPS-Compliant Algorithms › How to Re-Encrypt Existing Sensitive Data

How to Re-Encrypt Existing Sensitive Data

Complete the following procedures to re-encrypt existing sensitive data using FIPS-compliant algorithms:

Gather environment information.
Set FIPS-migration mode for all Policy Servers.
Re-encrypt the policy store key.
Re-encrypt the policy store administrator password.
Re-encrypt the CA SiteMinder® Super User password.
Set FIPS-migration mode for all Agents.
Re-encrypt policy and key store data.
(Optional) If your environment uses Basic Password Services, verify that Password Blobs are re-encrypted.

Gather Environment Information

Re-encrypting existing sensitive data while the Policy Server operates in FIPS-migration mode requires specific environment information.

Policy store key—For each Policy Server in the environment, copy the policy store encryption key from the EncryptionKey.txt file and save them to a single location from which you can copy them. The EncryptionKey.txt file is located in policy_server_home\bin.

policy server home

Specifies the Policy Server installation path.
Super User account name and password— Identify the Super User account name and password. CA SiteMinder® tools you use to re-encrypt data require this information.
Note: This is the account that is used for all administrative tasks that do not require direct access to the Administrative UI. These are not the credentials for the Administrative UI administrator account with Super User privileges.
Policy store administrator password—Identify the policy store administrator password. This is the password that was supplied when the connection between the policy store and the Policy Server was configured.

Set a Policy Server to FIPS-Migration Mode

You set the Policy Servers to FIPS-migration mode so the environment can continue to use the existing CA SiteMinder® encryption algorithms as you re-encrypt existing sensitive data using FIPS-compliant algorithms.

Follow these steps:

Open a command prompt on the computer hosting the Policy Server and run the following command:
```
setFIPSmigration
```
MIGRATION appears in the command window.
Stop the Policy Server.
Note: For more information about stopping and starting the Policy Server, see the Policy Server Administration Guide.
Complete one of the following steps:
- If the Policy Server is installed on a Windows system, reboot the system.
- If the Policy Server is installed on a UNIX system, complete the following steps:
  1. Log in as the user that is used to start the Policy Server.
  2. Open a command prompt.
  3. Navigate to policy_server_home.
  4. Run the following command:
```
. ./ca_ps_env.ksh
```
Start the Policy Server.

Open the smps.log file and verify that the following line appears:

Policy Server migrating from classic SiteMinder to FIPS-140 cryptographic algorithms.

Close the log file.
The Policy Server is set to operate in FIPS-migration mode.
Repeat the previous steps for each Policy Server in the environment.

You can now re-encrypt the policy store key for each Policy Server in the environment.

Re-encrypt a Policy Store Key

You re-encrypt the policy store key to replace the existing key with a version that is encrypted using FIPS-compliant algorithms.

To re-encrypt the policy store key

Open a command prompt from the computer hosting the Policy server and run the following command:
```
smreg -cf MIGRATE -key key_value
```
-cf MIGRATE

Specifies that smreg run in FIPS-migration mode.

Note: When smreg runs in FIPS-migration mode, the policy store key is re-generated using FIPS-compliant algorithms.

-key key value

Specifies the current policy store key.

smreg generates a new policy store key and encrypts it using FIPS-compliant algorithms.
Open the EncryptionKey.txt file, and verify that a new encryption key is present and prefixed with a FIPS-compliant algorithm.
Prefix example: {AES}

The policy store key is re-encrypted.
Repeat the latter steps for each Policy Server in the environment.

You may now re-encrypt the policy store administrator password.

Re-Encrypt the Policy Store Administrator Password

You re-encrypt the policy store administrator password to be sure that the data is encrypted using FIPS-compliant algorithms.

Follow these steps:

Start the Policy Server Management Console, and click the Data tab.
Note: For more information about starting the Policy Server Management Console, see the Policy Server Administration Guide.
Re–enter the administrator password in the Password field, and click Apply.
The administrator password is encrypted using FIPS-compliant algorithms.
(Optional) If you have configured a separate database for one or more of the following stores, re-encrypt the administrator password for each:
- key store
- audit logs
- token data
- session store
Important! A Policy Server operating in FIPS-only mode cannot decrypt a database password that remains encrypted with algorithms that are not FIPS–compliant.

You can now re-encrypt the CA SiteMinder® superuser password.

Re-encrypt the CA SiteMinder® Super User Password

You re-encrypt the CA SiteMinder® Super User password to ensure that the data is encrypted using FIPS-compliant algorithms.

Note: This is the password for the default administrator account. This account is used for all administrative tasks that do not require direct access to the Administrative UI. This is not the password for the Administrative UI administrator account with Super User privileges.

To reset the CA SiteMinder® Super User password, open a command prompt and run the following command:

smreg -cf MIGRATE -su password

-cf MIGRATE

Specifies that smreg run in FIPS-migration mode.

Note: When smreg runs in FIPS-migration mode, the existing Super User password is saved using FIPS-compliant algorithms.

password

Specifies the existing Super User password.

Note: You do not have to supply a new password. You are entering the same password to ensure that the data is encrypted using FIPS-compliant algorithms.

The CA SiteMinder® Super User password is encrypted using FIPS-compliant algorithms.

You may now set each of the Agents in the environment to FIPS-migration mode.

Set an Agent to FIPS-Migration Mode

You set the Agents to FIPS-migration mode so the environment can continue to use existing CA SiteMinder® encryption algorithms as you re-encrypt sensitive data using FIPS-compliant algorithms.

To change the FIPS mode of an agent

Open the SmHost.conf file with a text editor.
The following line appears in the file:
```
fipsmode="COMPAT"
```
Edit the line to read:
```
fipsmode="MIGRATE"
```
Save and close the file.
Restart the machine that is hosting the Agent.
The agent is operating in FIPS-migration mode.
Repeat the previous steps for each machine in the environment on which a trusted hosted is registered.

You may now encrypt agent shared secrets.

Re-encrypt Client Shared Secrets

You re-encrypt the agent shared secrets to replace the existing secrets with secrets that are encrypted using FIPS-compliant algorithms. You re-encrypt shared secrets either:

Manually rolling over the shared secret from the Administrative UI.
Using smreghost in FIPS-migration mode
Note: You only have to use smreghost if the agent was not configured for shared secret rollover when you registered the trusted host.

Use the Administrative UI to Re-encrypt a Shared Secret

To rollover the shared secret from the Administrative UI

Log into the Administrative UI and click Administration, Policy Server, Shared Secret Rollover.
The Shared Secret Rollover pane appears.
Select the Rollover Shared Secret every radio button.
Rollover Now becomes active.
Click Rollover Now.
The Policy Server rolls over the shared secrets for all trusted hosts configured to allow shared secret rollover.

You may now re-encrypt sensitive policy and key data in the policy store.

Use smreghost to Re-encrypt a Shared Secret

To use smreghost to re-encrypt a shared secret

Open a command prompt and run the following command:
```
smreghost -i policy_server_ip_address -u administrator_user_name
-p administrator_password -hn hostname_for_registration -hc host_config_object
-f path_to_host_config_file -o -cf MIGRATE
```
Note: If the "-p Administrator_password" argument is not specified in the smreghost command, you are prompted to specify the password.

-i policy server ip address

Specifies the IP address of the Policy Server to which the trusted host is registered.

-u administrator user name

Specifies the name of the CA SiteMinder® administrator with the rights to register a trusted host.

- p administrator password

Specifies the password of the administrator who is allowed to register a trusted host.

-hn hostname for registration

Specifies the current name of the host that is registered.

-hc host configuration object

Specifies the Host Configuration Object configured at the Policy Server.

-f path to host config file

Specifies the full path to the file that contains the registration data. The default file name is SmHost.conf.

Note: If you do not specify a file path, the updated file is saved in the location where you are running smreghost.

-o

Overwrites an existing trusted host. If you do not use this argument, you will have to delete the existing trusted host using the Administrative UI. We recommend using smreghost with this argument.

-cf MIGRATE

Specifies that smreghost run in FIPS-migration mode.

Note: When smreghost runs in FIPS-migration mode, the shared secret created and encrypted using FIPS-compliant algorithms.

smreghost re-registers the trusted host and creates a new shared secret that is encrypted using FIPS-approved algorithms.
Open the file that contains the trusted host registration data and verify that a new shared secret is present and prefixed with a FIPS-approved algorithm.
The shared secret is encrypted using FIPS-compliant algorithms.

Prefix example: {AES}

You may now re-encrypt sensitive policy and key data in the policy store.

Re-encrypt Policy and Key Store Data

You re-encrypt policy and key store data to ensure that sensitive data that is encrypted using existing CA SiteMinder® algorithms is encrypted using FIPS-compliant algorithms.

Options for Re-encrypting Policy and Key Store Data

There are three ways to re-encrypt policy and key store data. You can:

Re-encrypt the policy and key store data in an existing policy store.
Re-encrypt policy data in an existing policy store and key data in an existing key store.
Re-encrypt the policy and key store data, and migrate the data into a new 12.51 policy store or policy and key store, respectively.

This guide details the steps for re-encrypting the policy and key store data for existing stores.

If you want to create a new 12.51 policy store or policy and key store:

Export the key data using smkeyexport.
Note: XPSExport does not export keys that are stored in a policy or key store. More information on using smkeyexport exists in the Policy Server Administration Guide.
Export the policy store data using XPSExport.
Note: More information on using XPSExport exists in the Policy Server Administration Guide.
Create a 12.51 policy store or policy and key store.
Note: More information on creating a policy and key stores exists in the Policy Server Installation Guide.
Import the key data into the new policy store, or if created, the new key store using smkeyimport.
Note: More information on using smkeyimport exists in the Policy Server Administration Guide.
Import the policy store data into the new policy store using XPSImport.
Note: More information on using XPSImport exists in the Policy Server Administration Guide.

Re-encrypt Keys Stored in the Policy or Key Store

You re-encrypt the keys stored in the policy or key store to replace the existing keys with versions that are encrypted using FIPS-compliant algorithms.

To re-encrypt the keys stored in the policy or key store

Open a command prompt from the computer hosting the Policy server and run the following command:
```
smkeyexport -dadmin_name -wadmin_password -ooutput_file_name -l -v -t -cf
```
-dadmin_name

Specifies the name of the CA SiteMinder® administrator account.

-wadmin_password

Specifies the password for the CA SiteMinder® administrator account.

-ooutput_file_name

(Optional) Specifies the name of the exported file. If you do not specify a file name, the default file name is stdout.smdif.

Note: Ensure that the file name contains the .smdif extension.

Example: pskeys.smdif

-l

Specifies that a log file be created.

-v

(Optional) Enables verbose mode for troubleshooting.

-t

(Optional) Enables tracing for troubleshooting.

-cf

Specifies that smkeyexport run in FIPS-migration mode.

Note: When smkeyexport runs in FIPS-migration mode, the keys stored in the policy store are exported and re-encrypted using FIPS-compliant algorithms.

smkeyexport exports an smdif file that contains the re-encrypted keys.
Run the following command:
```
smkeyimport -iinput_file_name -dadmin_name -wadmin_password -l -v -t -cf
```
-iinput_file_name

Specifies the name of the file output file you created.

Note: Ensure that the file name you specify includes the .smdif extension.

-dadmin_name

Specifies the name of the CA SiteMinder® administrator account.

-wadmin_password

Specifies the password for the CA SiteMinder® administrator account.

-l

Specifies that a log file be created.

-v

(Optional) Enables verbose mode for troubleshooting.

-t

(Optional) Enables tracing for troubleshooting.

-cf

Specifies that smkeyimport run in FIPS-migration mode.

smkeyimport imports the re-encrypted keys into the respective store.

You may now re-encrypt policy store data.

Re-encrypt the Policy Store Data

To re-encrypt the policy store data

Open a command prompt from the machine hosting the Policy Server and navigate to the location to which you want to export the policy store data file.
Run the following command:
```
XPSExport outputfile -xe -xp -pass <passphrase> -vT -vI -vW -vE -vF -e file_name -l log_file
```
Note: Although you can use XPSExport to export one or more granular objects, this procedure provides the arguments for exporting all of the policy store data. This ensures that the export includes all of the sensitive data. More information on exporting one or more granular objects exists in the Policy Server Administration Guide.
outputfile

Specifies the name of the XML output file.

Note: The file name must be unique. The export fails if a file with the same name exists.

Example: psdata

-xe

Exports the object types that are related to the execution environment.

-xp

Exports the object types that are related to the policies.

-pass <passphrase>
Specifies a passphrase required for encryption of sensitive data. Record this value as it is required to import the sensitive data back into the policy store.

Limit: The passphrase must be contain at least:
- Eight (8) characters
- One (1) digit
- One (1) upper-case character
- One (1) lower-case character
Note: If the passphrase contains spaces, enclose it in quotes (").
-vT

(Optional) Sets verbosity level to TRACE.

-vI

(Optional) Sets verbosity level to INFO.

-vW

(Optional) Sets verbosity level to WARNING (default).

-vE

(Optional) Sets verbosity level to ERROR.

-vF

(Optional) Sets verbosity level to FATAL.

-l log_path

(Optional) Outputs log to the specified path.

-e file_name

(Optional) Specifies the file to which errors and exceptions are logged. If omitted, stderr is used.
XPSExport exports the policy store data and places the data file in the directory from which you ran the tool.
Run the following command:
```
XPSImport input_file -pass <passphrase> -vT -vI -vW -vE -vF -l log_path
```
input_file

Specifies the input XML file.

-pass <passphrase>

Specifies the passphrase required for the decryption of sensitive data.

Limit: The phrase must match the phrase you specified during export or the decryption fails.

-vT

(Optional) Sets verbosity level to TRACE.

-vI

(Optional) Sets verbosity level to INFO.

-vW

(Optional) Sets verbosity level to WARNING (default).

-vE

(Optional) Sets verbosity level to ERROR.

-vF

(Optional) Sets verbosity level to FATAL.

-l log_path

(Optional) Outputs log to the specified path.

-e file_name

(Optional) Specifies the file to which errors and exceptions are logged. If omitted, stderr is used.

XPSImport imports the data into the policy store. Sensitive data is encrypted using FIPS-compliant algorithms.

If your environment users Basic Password Services, you may now verify that the Password Blobs are re-encrypted using FIPS-approved algorithms.

Verify that Password Blobs are Re-encrypted

You verify that the Policy Server has re-encrypted every Password Blob in the user store to prevent users from losing their password history and being locked out by Password Services.

When you configured the user store connection for password policies, you specified the Password Data user profile attribute. This value represents where Password Blobs are stored in the user store and is the value you use to identify Password Blobs that are not re-encrypted.

To verify that Password Blobs are re-encrypted

Using the directory server or database-specific tool, search for Password Data entries that are not prefixed with:
```
{AES}
```
Example: If "audio" is the value you specified in the Password Data field when configuring the user store connection, search for all entries stored in "audio" that are not prefixed with {AES}.
Identify the users whose Password Blobs are not prefixed with {AES}. The Policy Server has not re-encrypted these Password Blobs.
Notify these users that they must either log in or change their password.
Note: How the password policy is configured determines when the Policy Server re-encrypts the Password Blob:
- If the password policy is configured to track successful and/or failed logins, the Policy Server re-encrypts the Password Blob when the user logs in.
- If the password policy is not configured to track logins, the Policy Server re-encrypts the Password Blob when the user changes the password.

Important! Password Services locks out users whose Password Blobs are not re-encrypted when the Policy Server is operating in FIPS-only mode. A user cannot regain access until you have deleted the Password Blob and cleared any disabled flags. Deleting the Password Blob results in the loss of the user's password history.