Re-Encrypt Existing Sensitive Data for FIPS Migration

This content describes how to re-encrypt existing sensitive data for FIPS migration.
casso10
This content describes how to re-encrypt existing sensitive data for FIPS migration.
2
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. The  tools you use to re-encrypt data require this information.
    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 Single Sign-On
encryption algorithms as you re-encrypt existing sensitive data using FIPS-compliant algorithms.
Follow these steps:
  1. Open a command prompt on the computer hosting the Policy Server and run the following command:
    setFIPSmigration
    MIGRATION appears in the command window.
  2. Stop the Policy Server.
  3. 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
  4. Start the Policy Server.
  5. Open the smps.log file and verify that the following line appears:
    Policy Server migrating from classic SiteMinder to FIPS-140 cryptographic algorithms.
  6. Close the log file.
    The Policy Server is set to operate in FIPS-migration mode.
  7. 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.
Follow these steps:
  1. 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.
      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.
  2. 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.
  3. 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:
  1. Start the Policy Server Management Console, and click the Data tab.
  2. Re–enter the administrator password in the Password field, and click Apply.
    The administrator password is encrypted using FIPS-compliant algorithms.
  3. (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
    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 Single Sign-On
super user password.
Re-encrypt the Super User Password
You re-encrypt the
CA Single Sign-On
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 Super User password, open a command prompt and run the following command:
textsmreg -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.
    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 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 Single Sign-On
encryption algorithms as you re-encrypt sensitive data using FIPS-compliant algorithms.
Follow these steps:
  1. Ensure that the Shared Secret Rollover option is enabled. For information, see Shared Secret for a Trusted Host.
  2. Open the SmHost.conf file with a text editor.
    The following line appears in the file:
    fipsmode="COMPAT"
  3. Edit the line to read:
    fipsmode="MIGRATE"
  4. Save and close the file.
  5. Restart the machine that is hosting the Agent.
    The agent is operating in FIPS-migration mode.
  6. 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
    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
Follow these steps:
  1. Log into the Administrative UI and click Administration, Policy Server, Shared Secret Rollover.
    The Shared Secret Rollover pane appears.
  2. Select the Rollover Shared Secret every radio button.
    Rollover Now becomes active.
  3. 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
Follow these steps:
  1. 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
    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 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.
     
  2. 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 Single Sign-On
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 policy store or policy and key store, respectively.
Re-encrypting the Policy and Key Store Data for Existing Stores
To create a new policy store or policy and key store for your current software version:
  1. Export the key data using smkeyexport.
    XPSExport does not export keys that are stored in a policy or key store.
  2. Export the policy store data using XPSExport.
    Create a new policy store or policy and key store.
  3. Import the key data into the new policy store, or if created, the new key store using smkeyimport.
  4. Import the policy store data into the new policy store using XPSImport.
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.
Follow these steps:
  1. Open a command prompt from the computer hosting the Policy server and run the following command:
    smkeyexport -d
    admin_name
    -w
    admin_password
    -o
    output_file_name
    -l -v -t-cf
     
    • -dadmin_name
      Specifies the name of the
      CA Single Sign-On
      administrator account.
    • -wadmin_password
      Specifies the password for the 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.
      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.
  2. Run the following command:
    smkeyimport -i
    input_file_name
    -d
    admin_name
    -w
    admin_password
    -l -v -t -cf
     
    • -iinput_file_name
      Specifies the name of the output file you created.
      Ensure that the file name you specify includes the .smdif extension.
    • -dadmin_name
      Specifies the name of the
      CA Single Sign-On
      administrator account.
    • -wadmin_password
      Specifies the password for the 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
Follow these steps:
  1. Open a command prompt from the machine hosting the Policy Server.
  2. Navigate to the location where you want to export the policy store data file.
  3. Run the following command:
    XPSExport outputfile -xe -xp -pass
    <passphrase>
    -vT -vI -vW -vE -vF -e
    file_name
    -l
    log_file
    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.
    • 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.
      The passphrase must be contain at least:
      • Eight (8) characters
      • One (1) digit
      • One (1) upper-case character
      • One (1) lower-case character
      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 where you ran the tool.
     
  4. 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.
      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 where 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 can 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.
Follow these steps:
  1. 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}.
     
  2. Identify the users whose Password Blobs are not prefixed with {AES}. The Policy Server has not re-encrypted these Password Blobs.
  3. Notify these users that they must either log in or change their password.
    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.
casso10
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.