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, k470 and k160 CipherTrust Manager devices, and existing k170v Virtual CipherTrust Manager instances.

  Note

  The 2.12.2 patch is not supported for Thales TCT k160 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.12.x Virtual CipherTrust Manager will be available on the following public clouds, as the Community Edition:

• Amazon Web Services: SafeNet Cloud Provisioning System

• Google Cloud

  Note

  As 2.12.x is not the default version, you must use the gcloud CLI to retrieve it.

• 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.12.x contains a number of new features and enhancements. For the list of known issues, refer to Known Issues.

Features and Enhancements

Release 2.12.2

The 2.12.2 release includes bug fixes described in the resolved issues list list. This release also includes an internal client upgrade to maintain compatibility with the Thales Data Protection On Demand (DPoD) Luna Cloud HSM Service root-of-trust integration past January 28, 2025. Details on the Luna Cloud HSM compatibility change are available in knowledge base article KB0028422. The CipherTrust Manager change is tracked internally under reference number KY-85444.

This release is available as an upgrade file. The upgrade can be applied directly on CipherTrust Manager versions 2.12.0, 2.12.1, 2.11.0, 2.10.x, and 2.9.x.

This release does not address all security vulnerabilities discovered after the release of 2.12.0 minor version. To obtain current security fixes, upgrade to the latest feature release.

Release 2.12.1

The 2.12.1 release includes a stability fix for virtual CipherTrust Manager instances using disk encryption. The fix is described in the resolved issues list. This release is available as a new virtual instance, or as an upgrade file. The upgrade can be applied directly on CipherTrust Manager versions 2.12.0, 2.11.0, 2.10.x, and 2.9.x.

Release 2.12.0

Platform

• New secrets management feature introduced. CipherTrust Manager now partners with Akeyless to offer Akeyless Vault Platform application secrets, protected with optional HSM root-of-trust hierarchy.

• Support added to send email notifications for built-in alarms.

• Added capability to renew the expiring CA certificates (server and client) in the certificate chain.

• Added login authentication methods (User-Certificate and Username-Password Authentication for Web) for local users.

• Support added to view the consumption of KMIP licenses in all domains (Domain Level Usage), and in individual domains on UI.

• Added support to:

  • update non-High Availability (HA) Luna Connection to HA.

  • create a single partition HA Luna Connection.

• In a quorum, the approver name has been made a mandatory field for vote's array.

• Added provision to add custom password policies for new or existing users.

• Internal mechanism is implemented to avoid full disk usage.

• The expires_at flag is added to set the expiration date for the local users to limit the user account to a certain period.

• Enhanced the /v1/system/info API to get the serial number (chassis_serial_number) of the CipherTrust Manager Physical Appliance.

• Added the ability to map groups for the OpenID Connect (OIDC) connection to authenticate CipherTrust Manager users.

• Added support for authorization flow for the OpenID Connect (OIDC) connection to authenticate CipherTrust Manager users.

• Added the ability to rotate the HSM Key Encryption Key (KEK) for HSM-anchored domains.

• Enhancements to the UI web console:

  • New filter in the user detail page to view only the groups the user has a membership in.

  • New option to upload an external certificate as a file.

  • Added ability to limit user login based on client types such as unregistered, public, and confidential clients, previously available only on CLI and API. This setting is available when adding a new user or editing an existing user.

• CipherTrust Manager now enforces that nodes joining a cluster must have the same CipherTrust Manager software version as nodes already in the cluster. This ensures the stability and proper functioning of production clusters.

• Added support in the Elasticsearch log forwarder for Elasticsearch version 8.

Limitations

• If a domain has more than 1000 cryptographic objects (keys and opaque objects), to fetch keys, it is recommended to use KeyNamesRequest instead of KeyQueryRequest. The response time of KeyQueryRequest is proportional to the number of keys on the CipherTrust Manager, therefore, it may lead to a timeout exception on the client side.

• Currently, the log forwarders are not configured to use the system's proxy configuration. If proxy is configured, the log forwarders bypass the proxy servers.

• The backup and restore of users and groups in a domain only works among the domains of different CipherTrust Managers. This feature does not support backup and restore among different domains of the same CipherTrust Manager.

• During client renewal, if another client (which has authentication_mode mode set to dn) already exists in the system with a matching subject DN, the client renewal may fail. This applies to external or local CA clients. For external CA certificates, delete the client to be renewed and register a new client with a new certificate and different subject DN.
  However, for local CAs, it is not required to delete the client to be renewed, rather set the do_not_modify_subject_dn field to false. Refer to Renewing Local CA Clients for details.

Deprecated Feature(s)

• Removed the ProtectV tile from the CipherTrust Manager. However, if you upgrade to CipherTrust Manager 2.12 from the lower versions, the ProtectV Admins, ProtectV Clients, and ProtectV Users groups still show up but are not usable. These groups can be manually removed if required.

• Removed support for the CTE symmetric keys migration from DSM to the CipherTrust Manager if Unique to Host flag is set for the keys.

Application Data Protection

• Added support for access policies that allow you to select how to display data in a RESTful API call during the reveal operation based on the user. The data can be revealed as:

  • Plaintext

  • CipherText

  • Masked Value

  • Error/Replacement Value

• Added licensing enforcement for DPG.

CCKM

• GA API support of Cloud KMS key management mode for Google EKM via a Virtual Private Cloud (VPC) connection to allow users to create, rotate, or destroy coordinated EKM keys through the Google console. Note that in this release, this feature is incorrectly tagged as "Tech Preview" in the CCKM API playground. This tag will be removed in the next release.

• Added capability to enable and disable success event logs for AWS XKS and Google EKM.

• Added capability to update AWS key store credential when key store is in a connected state.

• Added mutual TLS support for AWS Custom key store.

• Provided support for Salesforce mutual TLS.

• Support for Google Access Control Policy for Cryptospace EKM endpoints and Cryptospaces is now available.

• Re-adding removed Luna partitions now restore existing key relations.

• Added granular access control for reports.

• Added support for management of Azure key vaults based on Active Directory (AD) groups in the root domain.

• Added support for AWS bulk jobs to perform operations on multiple AWS keys in one attempt through the API. A maximum of 100 keys are supported for bulk operations.

• Restricted key version to "import only" for Google CMEKs through the API.

• Added capability to manage Dynamic Key References (DKR) for the SAP cloud through the API.

• Added capability to update the version of SAP cloud keys through the API.

CTE

• Added capability to the CTE for Windows Agent for detection of Ransomware and protection of sensitive data from Ransomware. The CTE Agents can monitor the volumes, analyze the data, and look for processes that might perform suspicious activities on the sensitive data.

• Added a dashboard to the Reports page. The dashboard shows the total number of:

  • Registered and unregistered clients

  • Consumed CTE, CTE UserSpace, and K8s licenses

  • GuardPoints configured on the clients

  • Active and inactive GuardPoints

• Added capability to specify whether a CTE for Windows client can be added to an LDT communication group. This feature can be used to ensure smaller and efficient groups, which will participate on LDT operations like rekey, are allowed to join an LDT communication group.

• Added ability to monitor CTE resources through Prometheus and Grafana on the CipherTrust Manager CTE Resources dashboard. This dashboard:

  • Shows the statistics for various CTE resources on the CTE Clients, CTE Groups, CTE GuardPoints, and CTE Clients Health Status graphs.

  • Displays the total number of operations performed with respective to the CTE Clients and CTE Groups.

CTE UserSpace

CTE UserSpace 10.0 is a new kernel-independent file encryption product based on CTE and CTE UserSpace (rebranded ProtectFile FUSE).

• The resources of CTE UserSpace clients running 10.0 and higher Agent versions are managed by the Transparent Encryption application on the CipherTrust Manager. These clients can't be managed by the ProtectFile & Transparent Encryption UserSpace application.

  This release does not support the following features:

  • Kernel Compatibility Matrix

  • Agent and System locks

  • CBC and XTS keys

  • COS, ESG, IDT, and LDT policies and GuardPoints

  To manage the clients running the previous versions of the CTE UserSpace Agent, use the ProtectFile & Transparent Encryption UserSpace application only. Alternatively, upgrade those clients to CTE UserSpace 10.0 or a higher version.

• Added a dashboard to the Reports page. The dashboard shows the total number of:

  • Registered and unregistered clients

  • Consumed CTE, CTE UserSpace, and K8s licenses

  • GuardPoints configured on the clients

  • Active and inactive GuardPoints

• Added ability to monitor CTE resources through Prometheus and Grafana on the CipherTrust Manager CTE Resources dashboard. This dashboard:

  • Shows the statistics for various CTE resources on the CTE Clients, CTE Groups, CTE GuardPoints, and CTE Clients Health Status graphs.

  • Displays the total number of operations performed with respective to the CTE Clients and CTE Groups.

CIP

• Added capability to display remediation status and progress while remediation is in progress for the following:

  • Standard and LDT policies for Linux local storage and NFS

  • Standard and LDT policies for Windows local storage

  • LDT policies for Windows NFS

• Added support for OpenSSL(3.x) for Windows

DDC

• Enhanced Agent Selection Flow - During the scan execution validation phase, agent selection is always triggered again if no available agent is found, and the data store is scanned using an available agent. The data store is also updated to be associated with the new agent as part of this flow.

• Integrated CTE Remediation Status - Reports are now generated with the CIP information included only after Remediation is applied. This way the user knows which files were remediated at each execution.

• Hide Labelling for NFS - The labelling option is hidden for the NFS Data Store in the UI.

• Advanced Scan Settings - Advanced scan configuration parameters added in the first step of the Scan Wizard ("General Info" > "Advanced Configuration").

• Data Store Documentation Improvements - Each data store section has been updated to include a brief introduction, connection configuration, and target configuration, with examples where appropriate.

Resolved Issues

This table lists the issue resolved in 2.12.2.

This table lists the issue resolved in 2.12.1.

This table lists the issues resolved in 2.12.0.

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.12.0: Virtual CipherTrust Manager Instances with Disk Encryption Lose Network Connectivity After an Hour

If you use the disk encryption feature on a virtual CipherTrust Manager 2.12.0 instance, the instance loses network connectivity after approximately one hour. Upgrade to 2.12.1 for a permanent fix.

If you cannot upgrade to 2.12.1, you can restart the NetworkManager service to prevent or recover from this situation as a workaround.

To prevent this from happening:

If you still have network connectivity to the instance, login as ksadmin to the web console and run the following command:

sudo systemctl restart NetworkManager

To recover from this state:

Access the serial console, login as ksadmin, and run the following command:

sudo systemctl restart NetworkManager

USB Host Logs are Not Immediately Forwarded on Upgrade

If you have an existing syslog forwarder configured for host logs, and upgrade to 2.12, the USB host logs are not immediately forwarded. You need to manually force the syslog forwarder to update completely. This can be achieved by:

• Using the modify command.

  1. Use kscfg syslog forwarder modify --id <syslog_forwarder_id> --<another_option> <temporary_value> force the update.

  2. Use kscfg syslog forwarder modify --id <syslog_forwarder_id> --<another_option> <original_value> to reset to the original value.

• Deleting and recreating the syslog forwarder.

  1. View the syslog forwarder's current configuration values with kscfg syslog forwarder get --id. Note down or otherwise retain these configuration values.

  2. Delete the existing the syslog forwarder with kscfg syslog forwarder delete --id <syslog forwarder_id>.

  3. Re-create the syslog forwarder with kscfg syslog forwarder add, including any options necessary to set the original configuration values. These options are documented here.

NextGen KeySecure and ProtectFile End-of-Support in 2023

NextGen KeySecure firmware and the ProtectFile connector will be End of Support in December 2023.

In most cases, you can upgrade from NextGen KeySecure to CipherTrust Manager directly. If you are running the legacy k450 or k460 hardware model, you must migrate data to the k470 or k570 model.

We strongly recommend migrating ProtectFile to CTE or CTE Userspace.

Luna Network HSM 5.x and 6.x are no longer supported as Root-of-Trust for CipherTrust Manager

As Thales has passed the end-of-support date for Luna Network HSM 5.x and 6.x, CipherTrust Manager no longer supports those versions for root of trust. CipherTrust Manager does not enforce against setting up those versions for root-of-trust, so upgrading will not disrupt existing root-of-trust connections to our knowledge. Consult the End of Sale and End of Support announcement, Luna Network HSM 7 documentation, and Data Protection on Demand and Luna Cloud HSM documentation for migration information.

Quorum

Do not enable quorum on the ManagePolicyAttachment and DeletePolicy operations until all the CipherTrust Manager nodes in a cluster are upgraded to 2.10 or a higher version.

SMB Connection

The Host and Port fields must be specified together, or do not specify any of them. If Host and Portare not specified while creating an SMB connection, these fields cannot be added later.

Recommendation for Secure Initialization Vector in DESede CBC, AES CBC, and AES GCM Encryption Requests

When generating a new AES or DESede key CipherTrust Manager currently generates and stores a Default IV associated with the new key. This is mainly used to support specific legacy integrations and applications.

We strongly recommend future crypto applications use a secure, unique initialization vector (IV) for each AES CBC, AES GCM, and DESede CBC encryption request, rather than relying on a default IV provided by CipherTrust Manager for the security of your data. For example, unpredictable, unique IVs for AES CBC requests protect against oracle attack techniques such as ROBOT, DROWN, POODLE, and BEAST.

We recommend to use CipherTrust Manager's random number generation to produce secure IVs, or you can provide your own IV with each AES CBC, AES GCM or DESede CBC encryption request following the security guidelines for constructing secure IVs in NIST SP800-38A and NIST SP800-38D.

In the KMIP interface, always set the RandomIV object in the Cryptographic Parameters attribute to true or provide your own secure IV in the Request Payload as an IV/Counter/Nonce object.

In the REST and NAE interfaces, use CipherTrust Manager's random number generation to produce secure IVs for cryptographic requests, or provide your own secure IV.

Some Key States Change After Upgrade

After upgrade from 2.4 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.

As you cannot upgrade directly from 2.4 to 2.12, these changes take effect when you first upgrade from 2.4 to an intermediate minor version, 2.5, 2.6, or 2.7.

• 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. 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.

System Upgrade and Downgrade Supported Releases

System upgrades on a single unclustered device have been tested from releases 2.9.x, 2.10.x, and 2.11.0. Upgrades have also been tested from lower 2.12.x versions to higher 2.12.x patches.

An unclustered CipherTrust Manager can be downgraded to the previous minor version. 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.

The cluster upgrade section provides instructions to perform an upgrade on a cluster of devices. Supported upgrade paths depend on the method used to upgrade the cluster.

• Cluster remove/rebuild is supported from 2.9.x, 2.10.x, 2.11.0, and 2.12.0.

• In-place cluster upgrade is generally performed from one minor version at a time, so there is no limit on starting version.

  The only exception is that if you are at 2.10.x, you skip 2.11.x and upgrade directly to 2.12.0. This is because upgrade from 2.11.1-2.11.6 to 2.12 is unsupported, and 2.11.0 is no longer available.

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

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.

Key Usage Mask Selection

If you want to perform any operation (for example, Wrap/Unwrap) from the NAE/KMIP connector, set the usage mask explicitly for that operation while creating keys through UI.

DDC

Clusters

• 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).

Licensing

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

Upcoming End of Support for Platforms and Features

• Linux 2.4 Node Agents

• Email Targets - Microsoft Exchange (EWS)

• Microsoft 365 - Exchange Online (EWS)

• Web Browser - Internet Explorer

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

• CADP for .NET Core: minimum version 8.11.0

• CADP for C: minimum version 8.14.0

• CADP for Java: minimum version 8.13.0

CipherTrust Application Key Management

• CAKM for Oracle TDE: minimum version 8.10.0

• CAKM for Microsoft SQL Server EKM: minimum version 8.5.0

CipherTrust Cloud Key Manager

Minimum version 1.6.3.20532

CipherTrust Database Protection

• CDP for Oracle: minimum version 8.12.0

• CDP for MSSQL: minimum version 8.12.0

• CDP for DB2: minimum version 8.12.0

• CDP pdbctl: minimum version 1.5.1

• CipherTrust Teradata Protection: minimum version 6.4.0.12

• Transformation Utility: minimum version 8.4.3

CipherTrust Transparent Encryption

Minimum version 7.0.0

CipherTrust Transparent Encryption UserSpace

Minimum version 10.0

CipherTrust Transparent Encryption for Kubernetes

Minimum version 1.0.0

CipherTrust Vaulted Tokenization

Minimum version 8.7.1

CipherTrust Batch Data Transformation

Minimum version 2.2.0.2816

CipherTrust Vaultless Tokenization

Minimum version 2.5.2.19

ProtectFile

Minimum version:

• ProtectFile Windows 8.12.3

• ProtectFile Linux 8.12.3, 8.12.4p02 (for migration to CTE)

The latest three GA versions of ProtectFile are tested with CipherTrust Manager. Older versions are expected to work, but they are not tested explicitly.

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.1. 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 Application Data Protection (CADP for C)

CipherTrust Cloud Key Manager

CipherTrust Database Protection

Application Data Protection

CipherTrust Data Discovery and Classification

CipherTrust Secrets Management

CipherTrust Transparent Encryption

Batch Data Transformation (BDT)

ProtectApp

ProtectFile

CipherTrust Intelligent Protection