Release Notes

Product Description

CipherTrust Manager is the center of the CipherTrust Data Security Platform. It serves as the central point for managing configuration, policy and key material for data discovery, encryption, on-premise and cloud based use cases. It is the successor to both the Thales eSecurity (formerly Vormetric) DSM and the Gemalto (formerly SafeNet) KeySecure platforms.

Product Abbreviations

Release Description

This release is available on the Customer Support Portal in the following formats:

• An upgrade file for physical k570 and k470 CipherTrust Manager devices, and existing k170v Virtual CipherTrust Manager instances.

• An upgrade file for KeySecure Classic k450 and k460 devices.

• An OVA image file for deploying a new Virtual CipherTrust Manager on VMWare vSphere or Nutanix AHV.

• A VHDX image file for deploying a new Virtual CipherTrust Manager on Microsoft Hyper-V.

• A QCOW2 image file for deploying a new Virtual CipherTrust Manager on OpenStack.

In addition, 2.5.x Virtual CipherTrust Manager is available on the following public clouds:

• Amazon Web Services: SafeNet Cloud Provisioning System

• Google Cloud

• Microsoft Azure: Available as a BYOL image in the Microsoft Azure Marketplace

• Oracle Cloud

• IBM Cloud

  • An OVA image file for deploying a new Virtual CipherTrust Manager on IBM Cloud VMWare.

  • A QCOW2 image file for deploying a new Virtual CipherTrust Manager IBM Cloud Virtual Private Cloud Gen2.

2.5.x contains a number of new features and enhancements. Refer to Features and Enhancements for details. For the list of known issues, refer to Known Issues.

Features and Enhancements

Release 2.5.2

This release contains a critical security vulnerability fix, and KMIP interface bug fixes listed in Resolved Issues.

The release is available as a new virtual instance or an upgrade file on physical devices. The upgrade can be applied directly on CipherTrust Manager versions 2.5.x, 2.4.x, 2.3.x, and 2.2.x.

Security Vulnerability Fix

On upgrade to 2.5.1, some existing keys are incorrectly tagged as "global" keys. This allows the "global" user and users who belong to the Key Users group to potentially affect the integrity, confidentiality, and availability of those keys. If you are running release 2.5.1, we strongly recommend upgrading to 2.5.2 immediately. See security bulletin 20211015 for further details on the security vulnerability.

KMIP Change

We removed the KMIP client certificate renewal feature to improve its quality. We will reintroduce this feature in a future release. KMIP clients that configured the feature in 2.5.1 will retain communication with CipherTrust Manager after upgrade, without interruption.

Release 2.5.1

Platform

• Support for Microsoft Edge 91.0.864.37 or later

• Security review and enhancement of the shell access for the ksadmin user

• Support for Quorums for the DeleteKey operation

• Support for revocation of certificates signed by Local CA using Certificate Revocation List (CRL)

• Support for trusting proxy server's certificate for outgoing connections

• Secure transfer of system backups from the CipherTrust Manager to the external servers over SCP

• Migration of ProtectDB resources (database connections and error replacement values) from KeySecure Classic

• Support for Subject Alternative Name (SAN) field in the local CA and server certificate in the cloud-init configuration file

• Harmonization of key states across all interfaces.

  • The state field now defines state in all interfaces.

  • The naeState field in the meta attribute for a key in the REST API, GUI, and CLI is no longer valid and is not used to set an independent NAE-XML state. Only the NAE-XML interface can be used to update the NAE-specific states using the <KeyVersionState> element. All NAE-XML values for <KeyVersionState> map to an equivalent key state and no longer operate independently. Changing a <KeyVersionState> also changes the key state in all other interfaces, and changing a key state in any other interface also changes the <KeyVersionState> in NAE-XML.

  • After upgrade, some states are altered to reflect the new harmonization. In most cases, allowed operations remain the same before and after upgrade, so key usage is not disrupted. See the advisory note for details on the state remapping related to upgrade.

  • You can now reactivate a deactivated key through REST API, or CLI. This provides an equivalent functionality to the previous NAE state transition of moving a key from a Retired state to an operational Active state. KMIP does not allow this state transition, so you cannot reactivate a key through the KMIP interface.

CTE

• Ability to create LDT GuardPoints on CIFS/SMB paths on a single node using CSV

• Ability to upload and replace signed Compatibility Matrix files to the CipherTrust Manager

• Migration of IDT resources from a DSM backup file

CCKM

• Full support for Google Cloud Customer-Managed Encryption Keys (CMEK) and Google Cloud External Key Manager (EKM) services.

  • Designation changed from "technical preview" to "fully supported", meaning that these services are now suitable to integrate into production environments.

  • CLI support for EKM commands

  • Ability to rotate the Key Encryption Key associated with an endpoint

  • Licensing associated with Google Cloud Project. You can add a Google Project ID to CipherTrust Manager. When Google EKM service makes wrap and unwrap requests to CipherTrust Manager, CipherTrust Manager checks that the project ID in the request matches one of the project IDs registered with the appliance. One Google Cloud project consumes one CCKM license cloud unit.

• Support for Terraform automation

• Support for functional module enabled Luna Network HSMs

• Ability to append rotation date to AWS key alias (manual and automated schedules)

• Enhancements in AWS policy management

DDC

• Custom Infotypes: Support for adding advanced expressions and ability to edit them in the Expert View.

• Removal option for Datastores, Classification Profile and Reports - DDC basic functionality (CRUD) completeness.

• New Data Store Types:

  • MySQL

  • Teradata

  • MongoDB

  • Azure Tables

Resolved Issues

This table lists the issues resolved in 2.5.2.

This table lists the issues resolved in 2.5.1.

Advisory Notes

This section highlights important issues you should be aware of before deploying the CipherTrust Manager. There is also a full list of known issues associated with the release.

2.5.1 only: NAE and KMIP Interfaces Unavailable After Upgrade for Some KMIP Client Configurations

If KMIP clients are registered in domains other than the root domain, upgrading to 2.5.1 results in the NAE and KMIP interfaces becoming unavailable. If you have KMIP clients registered in non-root domains, upgrade directly to 2.5.2, skipping 2.5.1.

Some Key States Change After Upgrade

After upgrade to 2.5.x from 2.4, 2.3, or 2.2, some key states are remapped as a result of harmonizing NAE-only key states. In most cases, the allowed operations for a key remain the same before and after upgrade, so key usage is not disrupted.

• When a key has an NAE state of Retired and the deactivation date is set in the future, the key is set to Deactivated immediately upon upgrade. No cryptographic operations are allowed.

• When a key has an NAE state of Restricted and Protect Stop Date is set in future, the key is set to Active and the Protect Stop Date is set to the current time. Decryption, signature verification, unwrapping, and MAC verification are allowed.

• When a key has an NAE state of Active and Activation Date is not set, the activation date is set to the current time. All cryptographic operations are allowed.

• When a key has an NAE state of Active and Activation Date is set in the future, the key is set to a Pre-Active state and the Activation Date is retained. No cryptographic operations are allowed until the Activation Date is reached.

• When a key has a state of Deactivated before upgrade, its state will be unchanged after upgrade. However, the allowed operations for the Deactivated state change for 2.5.x. The key loses its ability to decrypt, verify signatures, unwrap, and verify MACs. You can re-activate the key after upgrade and set the ProtectStop date to restore those operations.

ECIES Decryption Can Fail After Upgrade in Rare Cases

If you encrypted data with ECIES at version 2.2 or 2.3, you might not be able to decrypt the data with the same EC key after upgrade to 2.5.x. This is because, in very rare cases, the ECIES function of the NAE interface derived an encryption and authentication key due to incorrect padding. Release 2.4.x and 2.5.x fix this rare incorrect key derivation, which means that the derived key can be different from previous releases, and decryption operations can fail. If you have trouble decrypting with an EC key after upgrade, decrypt the data with an older version of CipherTrust Manager and re-encrypt it with CipherTrust Manager version 2.5.x.

System Upgrade and Downgrade Supported Releases

Direct system upgrades on a single device have been tested from releases from 2.2.x, 2.3.x, 2.4.x, and 2.5.x.

CipherTrust Manager 2.5.x can be downgraded to 2.4.0. For release-specific upgrade/downgrade information, refer to the release notes for your release.

Refer to the System Upgrade page for instructions to perform an upgrade or downgrade on a single device.

Refer to the Cluster Upgrade section for instructions to perform an upgrade on a cluster of devices.

Restoring a backup from release 1.5.0 or later is supported; however, restoring a newer backup to an older version is never supported.

SSH Key Fingerprint Change After Upgrade

Upgrading to 2.5.x from version 2.2 introduces a new SSH server key, using the stronger ED25519 algorithm in comparison to the existing RSA key. If you upgrade the CipherTrust Manager and then SSH to the appliance as ksadmin, you can be presented with a warning the fingerprint has changed. This warning is expected and can be safely disregarded.

If you want to verify the presented SSH key fingerprint, you can also log into the console through a serial cable (for physical appliances) or your virtual platform's console access tools. The console displays all of the SSH key fingerprints.

Default TLS Setting Can Cause Loss of KMIP/NAE/Web Connection After Upgrade

As compared to release 2.2, the 2.5.x release introduces changes to the TLS ciphersuites associated with the KMIP, NAE, and web interfaces. When you upgrade, the existing TLS ciphersuites for these connections might not be included in the 2.5.x default TLS ciphersuites, which results in a loss of connection to the interface. CBC-based ciphersuites, for example, are disabled upon upgrade from 2.2 to 2.5.x.

For security reasons, we recommend that you ensure clients to your KMIP, NAE, and web interfaces use one of the 2.5.x default TLS ciphersuites before upgrade.

If you cannot change the TLS ciphersuites for your clients, plan for some downtime for the interface(s) after upgrade. After upgrade, you can manually enable the previous ciphersuites to restore the connection.

Clusters with a Large Number of Transactions

Clusters that support a large number of transactions should have audit logging disabled and only syslog should be used for capturing audit logs. This significantly reduces cluster wide traffic and disk usage. This is a cluster wide setting and needs to be set on only one node in the cluster. Use the ksctl properties command to disable audit logging.

To disable local audit logging

Set the property ENABLE_RECORDS_DB_STORE to false using the ksctl command:

$ ksctl properties modify -n ENABLE_RECORDS_DB_STORE -p false

If configured, Audit logs will be still be sent to a syslog server.

Cluster Synchronization

Correct cluster synchronization relies on all nodes in a cluster having the same time. It is strongly advised to use NTP to set the time in a new node before it joins a cluster. NTP settings are not copied between nodes - they must be set individually for each CipherTrust Manager server.

Protect the ksadmin Private SSH Key

The private SSH key for the ksadmin account is critical to system security and must be carefully protected. Failure to do so could allow an attacker to compromise the system.

TLS/SSL Must be Enabled in a Production System

As it may be useful for troubleshooting, it is possible to disable TLS/SSL for the NAE interface. This will lead to an insecure system. Therefore, TLS/SSL should always be enabled for a production system.

Clusters with DDC

• Only one CipherTrust Manager node in the cluster can have DDC activated. To access DDC, create a new DNS entry to point to the active CipherTrust Manager node.

• DDC functionality cannot be accessed through the CipherTrust Manager FQDN. DDC requests sent to an inactive CipherTrust Manager node fail (and return the impression that DDC fails randomly).

DDC Licensing

Overlapping licenses are not supported (except for the trial license).

DDC Scalable Reports Processing

Previous DDC versions needed PQS and HDFS Hadoop services, but starting from version 2.4 DDC requires HDFS and Livy. Refer to the latest Thales Data Platform Deployment Guide for information on how to install Spark, Livy and Tez and DDC Deployment Guide for configuring them in CipherTrust Manager.

As DDC no longer uses PQS to store new data, it is no longer possible to modify its configuration through the UI. Please use the API if you need to update the Knox hostname, credentials or TLS certificate. The upgrade will not delete any data stored in PQS. Please consider deleting it when you no longer need access to legacy reports.

The Hadoop settings (HDFS and Livy) must be added as if it was a fresh deployment. The HDFS settings that the user could had up to now are not kept, but the PQS settings are automatically stored to make sure the information stored for scans and reports is not lost. For the HDFS connection, it is recommended to configure a different HDFS folder.

The scans created in the DDC Scans section are stored but the executions can not be used for new reports. The user will have to run the scans to make new reports for these scans. It is not possible to create new reports for the scan executions that were completed with a previous DDC version. The reports that were generated using a previous DDC version are accessible and will be marked with an "L" icon, which means that it is a legacy report and can not be updated any more. For the reports generation, the user will need to run new executions of the scans, since the legacy scan executions cannot be used. The user will notice that after an upgrade, when trying to generate new reports, scan executions completed with previous DDC version are not displayed in the reports wizard.

Compatibility

This section documents known compatibility topics to be considered before deploying the CipherTrust Manager.

TLS Compatibility

This table identifies the supported TLS versions for each of the CipherTrust Manager interfaces. The default minimum value reflects the default minimum_tls_version setting. This setting controls the lowest acceptable TLS version allowed for connections to the interface.

By default, CipherTrust Manager accepts the following ciphersuites for TLS 1.2+ connections:

• TLS_AES_256_GCM_SHA384 (TLSv1.3)

• TLS_CHACHA20_POLY1305_SHA256 (TLSv1.3)

• TLS_AES_128_GCM_SHA256 (TLSv1.3)

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS Deprecation Notices

• Use of TLS 1.0 and 1.1 protocols is deprecated. This support will be discontinued in a future release. Upgrade all applications connecting to CipherTrust Manager interfaces to TLS 1.2 or higher as soon as feasible.

• Use of the following CBC-based ciphersuites is deprecated, and support will be discontinued in a future release:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_CBC_SHA

Client Platforms

The following client Platforms are supported by the CipherTrust Manager.

CipherTrust Application Data Protection

• ProtectApp JCE: minimum version 8.6.1

• ProtectApp .NET: minimum version 8.11.0

• ProtectApp ICAPI: minimum version 8.10.0

• ProtectApp Oracle TDE: minimum version 8.9.0

• ProtectApp SQL EKM: minimum version 8.3.2

CipherTrust Cloud Key Manager

Minimum version 1.6.3.20532

CipherTrust Database Protection

• ProtectDB Oracle: minimum version 8.8.0

• ProtectDB SQL: minimum version 8.9.0

• ProtectDB DB2: minimum version 8.7.0

• Transformation Utility: minimum version 8.4.3

CipherTrust Transparent Encryption

Minimum version 7.0.0

CipherTrust Transparent Encryption UserSpace

Minimum version 9.0.0

CipherTrust Vaulted Tokenization

• Tokenization Manager: minimum version 8.7.1

• Vaultless Tokenization Manager: minimum version 8.8.0

CipherTrust Batch Data Transformation

Minimum version 2.2.0.2816

CipherTrust Vaultless Tokenization

Minimum version 2.5.2.19

CipherTrust Teradata Protection

Minimum version 6.4.0.12

ProtectFile

Minimum version 8.10.11

ProtectV

Minimum version 4.7.3

Data Discovery and Classification Agents

Linux minimum kernel version is 2.6.

There are no changes in Agent requirements if you are upgrading from CM 2.4 to 2.5.x. If you are upgrading from a version older than 2.4 please refer to Upgrading Agents.

TDP Version Compatibility

Data Discovery and Classification requires TDP 3.1.5.1 or newer.

• If you have an existing TDP 3.1.5 cluster, you should apply the patch 3.1.5.1.

  Following the TDP upgrade users are required to Configure TDP service HDFS again and also Configure TDP service Livy.

Known Issues

This section lists the issues known to exist in the product at the time of release.

CipherTrust Manager

CipherTrust Cloud Key Manager

CipherTrust Database Protection

CipherTrust Data Discovery and Classification

CipherTrust Transparent Encryption

ProtectFile