VTS to CT-VL
Prerequisites
Data Security Manager (DSM) is up and running at a supported version.
A supported version of Vormetric Tokenization Server (VTS) is configured.
CipherTrust Manager is up and running at a supported version. Refer to CipherTrust Manager Deployment for details.
Note
If you are running an unsupported version, upgrade your environment to a supported version before proceeding. Refer to the corresponding product documentation for upgrade instructions.
Supported Versions
Current Setup
| Product | Version |
|---|---|
| VTS/CTS | 2.6.0 or higher |
| DSM | 6.4.5 or higher |
Target Setup
| Product | Version |
|---|---|
| CT-VL | 2.6.0 or higher |
| CipherTrust Manager | 2.4 or higher |
Note
If you are using CT-VL version lower than 2.6.0, or version higher than or equal to 2.3.0, you need to upgrade to the minimum supported CT-VL version 2.6.0 for the CipherTrust Manager.
Refer to Migrating from CT-VL Lower Versions to 2.9.0 for details on how to migrate to CT-VL 2.9.0.
Migration Approaches
Use either of the following migration approaches:
Setting up New CT-VL Cluster
This is the recommended approach. It allows you to retain an existing CT-VL cluster if the migration fails and roll back the migration.
Migrate your DSM to the CipherTrust Manager. Refer to Migrate from Data Security Manager for details.
After successfully migrating from DSM to CipherTrust Manager, reconfigure the existing VTS cluster with CipherTrust Manager.
Note
The password length for CipherTrust Manager must not exceed 30 characters.
Back up the existing VTS cluster. Refer to the VTS Documentation for details.
Create a new CT-VL virtual machine (VM).
Restore the VTS backup to the newly created VM (created in above step).
Note
You can only restore tokenization and crypto configurations from the backup. Configurations such as LDAP, remote Syslog, and SNMP cannot be restored. These configurations must be configured on each node in the CT-VL cluster.
Create another VM and join it to the first VM to create a cluster. Similarly, based on your requirement, you can create multiple VMs and add them to the cluster.
Verify that all the nodes in the cluster are replicating correctly.
Log on to the CLI of the first node in the CT-VL cluster. Configure that node to connect to and register with the CipherTrust Manager. Refer to the CT-VL Documentation for details.
Repeat previous step for all the remaining nodes in the cluster.
(If Random Mode tokenization is used) Verify that the random tables are successfully generated on all the nodes.
Verify that the migration is successful. Perform the following steps:
Test tokenization and cryptographic operations on each node. For example, you can perform tokenization on one node and detokenization on another node. This ensures the cluster is operating correctly.
Take some tokenized or encrypted data from the existing VTS cluster (tokenized or encrypted using DSM) and detokenize or decrypt it using the newly created CT-VL cluster. This ensures successful migration of DSM keys to the CipherTrust Manager.
If the migration is not successful or you run into any issues with the CipherTrust Manager, you can roll back the migration. Refer to Rolling Back Migration (New Cluster) for details.
Switch the load balancer from the old VTS cluster to the new CT-VL cluster.
Migrating Existing VTS Cluster
To migrate an existing VTS cluster:
Migrate your DSM to the CipherTrust Manager. Refer to Migrate from Data Security Manager for details.
After successfully migrating from DSM to CipherTrust Manager, reconfigure the existing VTS cluster with CipherTrust Manager.
Note
The password length for CipherTrust Manager must not exceed 30 characters.
Disconnect the VTS cluster from the load balancer.
Note
Do not perform tokenization or cryptographic operations until all the nodes of the VTS cluster are migrated and configured to use the CipherTrust Manager.
Back up the VTS cluster. Refer to the VTS Documentation for details.
Verify that all the nodes in the cluster are replicating correctly.
Log on to the CLI of each node in the cluster. Configure them to connect to and register with the CipherTrust Manager. Refer to the CT-VL Documentation for details.
Verify that all the nodes in the cluster now point to the CipherTrust Manager, not the DSM. To ensure this, shut down the DSM.
Restart the
vts serviceon all the nodes to ensure that DSM caching is not being used.Verify that the migration is successful. Perform the following steps:
Test tokenization and cryptographic operations on each node. For example, you can perform tokenization on one node and detokenization on another node. This ensures the cluster is operating correctly.
Take some tokenized or encrypted data from the existing VTS cluster (tokenized or encrypted using DSM) and detokenize or decrypt it using the newly created CT-VL cluster. This ensures successful migration of DSM keys to the CipherTrust Manager.
If the migration is not successful or you run into any issues with the CipherTrust Manager, you can roll back the migration. Refer to Rolling Back Migration (Existing Cluster) for details.
Add the load balancer to the CT-VL cluster.
Note
It is not necessary to break the CT-VL cluster. But, if a node fails to replicate, remove that node from the cluster and rejoin it.
Rolling Back Migration (Undo Migration)
Rolling Back Migration (New Cluster)
Discard the newly created CT-VL cluster.
Activate the old VTS cluster and restore the load balancer.
Rolling Back Migration (Existing Cluster)
If VTS is using DSM, log on to the CLI of each node in the cluster and disable
icapi. This step automatically reestablishes the connection between VTS and DSM.Verify that each node in the cluster is connected to the DSM. Run the CLI
vae show --statuscommand to check the status of each node. If any node is unable to connect to the DSM, reregister that node to the DSM.If VTS is using the CipherTrust Manager, reconfigure the VTS node to connect to and register with the CipherTrust Manager.
Run the
icapi testcommand to verify that each node in the VTS cluster is connected to the CipherTrust Manager.Verify that tokenization and cryptographic operations are successfully performed on all the nodes.
Restore the load balancer.
Limitations
Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager.
The following Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager:
Custom attributes for symmetric and asymmetric keys
Opaque objects
Key alias feature
NIST key states
AES-CTR and AES-GCM modes of encryption
Encrypt, decrypt, sign, and verify with RSA keys
The following Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager:
Custom attributes for symmetric and asymmetric keys
Opaque objects
Key alias feature
NIST key states
AES-CTR and AES-GCM modes of encryption
Deletion of key chains
The following Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager:
Custom attributes for symmetric and asymmetric keys
Opaque objects
Key alias feature
NIST key states
Deletion of key chains
The following algorithms are not supported with the CipherTrust Manager:
Sign/Verify: HS1
Digest: MD5 and S1
Encrypt/Decrypt: AES-ECB (for non 16-byte plaintext/ciphertext)
Custom attributes for symmetric and asymmetric keys
Opaque objects
Key alias feature
NIST key states
Deletion of key chains
Note
For running the import key API with DSM, CT-VL requires that the first letter of a key label is an alphabet. However, with the CipherTrust Manager, CT-VL doesn't have this restriction.
While running the patch key API with DSM, CT-VL returns errors for invalid scenarios. However, with the CipherTrust Manager, CT-VL doesn't return any error.
While running the decrypt API with DSM, CT-VL decrypts the ciphertext with any random IV successfully. However, with the CipherTrust Manager, CT-VL returns an error. It requires the IV that was used for encryption.
