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

2.11.x is the first release to be designated as a Long Term Support (LTS) release. It is an enterprise-grade release focused on stability. Consult the CipherTrust Manager Release Model for details on support and patches.

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

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

  Warning

  Thales TCT k160 devices only support release 2.11.2-tct. They do not support any other 2.11 version. The 2.11.2-tct upgrade file is available directly from TCT and not the Thales customer support portal.

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

Features and Enhancements

Release 2.11.6

This release is available as an upgrade file. The upgrade can be applied directly on the latest patch of 2.8.x, latest patch of 2.9.x, latest patch of 2.10.x, 2.11.0, 2.11.1, 2.11.2, 2.11.3, 2.11.4, or 2.11.5 but not 2.11.1-tct or 2.11.2-tct. It fixes the bugs described in Resolved Issues.

Release 2.11.5

This release is available as an upgrade file. The upgrade can be applied directly on the latest patch of 2.8.x, latest patch of 2.9.x, latest patch of 2.10.x, 2.11.0, 2.11.1, 2.11.2, 2.11.3, or 2.11.4 but not 2.11.1-tct or 2.11.2-tct. It contains the following changes:

• Added support for externally signed server certificate for Luna Network HSM root of trust.

• Upgraded an internal client 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-85445.

• Fixed bugs described in Resolved Issues.

Release 2.11.4

The 2.11.4 release includes bug fixes described in Resolved Issues.

This release is available as an upgrade file. The upgrade can be applied directly on CipherTrust Manager version 2.8.x, 2.9.x, 2.10.x, 2.11.0, 2.11.1, 2.11.2, or 2.11.3, but not 2.11.1-tct or 2.11.2-tct.

Release 2.11.3

The 2.11.3 release includes bug fixes described in Resolved Issues.

This release is available as an upgrade file. The upgrade can be applied directly on CipherTrust Manager version 2.8.x, 2.9.x, 2.10.x, 2.11.0, 2.11.1, and 2.11.2, but not 2.11.1-tct or 2.11.2-tct.

Release 2.11.2-tct

This release is only supported on the Thales TCT k160. It is not supported on Thales TCT k570 or any other CipherTrust Manager model. It is only available directly from Thales TCT.

This release resolves an error identified in 2.11.1-tct that prevented successful restore operations in the k160. Thales TCT recommends installing 2.11.2-tct instead of 2.11.1-tct.

Release 2.11.2

The 2.11.2 release includes bug fixes described in Resolved Issues.

This release is available as an upgrade file. The upgrade can be applied directly on CipherTrust Manager version 2.8.x, 2.9.x, 2.10.x, 2.11.0 or 2.11.1, but not 2.11.1-tct.

Release 2.11.1-tct

With the release of 2.11.2-tct, 2.11.1-tct is deprecated and should not be used.

2.11.1-tct Changes

• Performance Improvements: Changes have been made to the startup process of the k160 to streamline boot up and performance.

• Maintenance Mode: The CipherTrust Manager k160 supports registration of more than one token HSM. In order to prevent unexpected system restarts when inserting and removing secondary token HSMs, a “maintenance mode” has been added. This maintenance mode should only be used when registering a secondary token HSM and disabled during normal system operations.

Maintenance Mode Usage

To use Maintenance Mode, you must first install the CLI tool from the CipherTrust Manager k160.

Turn on Maintenance Mode

ksctl hsm tokens maintenance set --maintenance-on

Turn off Maintenance Mode

ksctl hsm tokens maintenance set --maintenance-off

Get Maintenance Mode Status

ksctl hsm tokens maintenance status

A response is returned similar to the following:

{
    "mode": false
}

“mode”: true indicates that Maintenance Mode is ON

“mode”: false indicates that Maintenance Mode is OFF

Release 2.11.1

The 2.11.1 release includes bug fixes described in Resolved Issues.

This release is available in all the formats and locations detailed in the Release Description. The upgrade can be applied directly on CipherTrust Manager version 2.11.0, 2.10.x, 2.9.x, and 2.8.x.

Platform

• USB logs are now included in the host logs, to monitor activity on physical appliance USB ports. These logs are available in the downloadable debug logs tar.gz.zip and can be set to forward to an external syslog.

  We have recently determined that the USB ports on the physical appliance are enabled after the bootup sequence. We are working towards disabling them completely in a future release, and have added monitoring as an immediate mitigation.

  If you upgrade to 2.11 and have an existing syslog forwarder configured for host logs, USB logs are not forwarded immediately. Consult the advisory note for steps to manually force the syslog forwarder to forward USB logs.

• Registered the well known clients (KSCTL, NAE, Web-UI, and API playground) as public clients.

• Expansion of the quorum feature for CTE specific bulk operations using API.

• Support added for RSA-PSS padding with pre-computed hash for Sign/SignVerify operations.

• Added ability to monitor KMIP and NAE cryptographic and key management operations through Prometheus and Grafana.

• Extended support for Secure Trusted Channel (STC) mode to Luna network HSM connections in connection manager using the GUI.

• Added support to modify the network interface settings for existing interfaces (NAE/KMIP/WEB).

• Provision to re-encrypt the data using the REST interface.

• Administer user login based on client types such as unregistered, public, and confidential clients.

• Added control of user impersonation behavior for KMIP and ProtectApp/NAE clients

• Auto registration support for NAE clients.

• Option to allow unregistered clients to register them on CipherTrust Manager using NAE interface.

• Support added to deploy the CipherTrust Manager AMI in AWS China region.

• Introduced Prometheus metrics for CTM resources (licensing, user-management, key-rotations, and backups).

• Expansion of the quorum feature to delete GWS CSE endpoints.

• Support added for domain level backup and restore for CCKM resources (Projects, Google External Key Manager (EKM) Endpoints and Cryptospaces).

• The default setting of the system generated auto key rotation scheduler for new deployments is now disabled. However, in the previous releases, it was enabled.

• The ProtectV tile has been removed from the CipherTrust Manager GUI. Refer to ProtectV for details.

• Introduced new alarm which triggers when one or more licenses is set to expire in fewer than 90 days.

• Support for upgrading the embedded PCIe HSM in the TCT CipherTrust Manager k570 appliance model.

• Support for using a Luna Backup HSM to backup and restore root of trust keys for Thales CipherTrust Manager k570 appliance models.

  Caution

  Ensure that the Thales CipherTrust Manager k570 meets the required configuration before restoring root of trust keys. Failing to do so can result in the CipherTrust Manager application becoming unavailable after reboot, requiring customer support to recover.

• New offline in-place cluster upgrade available from 2.10.x or 2.11.0 to 2.11.1, which allows for upgrade in fewer steps as compared to existing cluster upgrade methods. This upgrade requires an additional cmupdate utility available on support portal.

• Support for supplying existing HSM keys to be root of trust keys.

• Added GUI options for creating, editing, and deleting HSM-anchored domains.

• HSM-anchored domains are now fully supported and no longer technical preview.

• Added support for Elasticsearch version 8 with the CipherTrust Manager Elasticsearch log forwarder.

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)

• Local database logging for server and client records is now deprecated, and disabled by default to reduce cluster traffic and disk usage. We recommend viewing records using the Loki Grafana microservice instead, visible in the GUI under Records > Loki Audit Records.

The CipherTrust Manager version 2.9 onward:

• The 'global' user doesn't get generated on restart.

• The 'global' user cannot be created.

  While upgrading to CipherTrust Manager 2.9, the 'global' user gets deleted.

  In CipherTrust Manager 2.8 and 2.9 mixed cluster environment, if a 'global' user exists, you cannot login as a 'global' user.

  While upgrading to CipherTrust Manager 2.9 or in mixed cluster environment, if a 'global' user is deleted, the keys owned by the 'global' user will be accessible to the 'Key admin' or 'admin' groups. The NAE/KMIP users can also access these keys.

Application Data Protection

Added trial licensing enforcement for DPG.

CCKM

• Provided GUI to manage Azure certificates and Azure secrets.

• Enhanced the Scheduler GUI to automatically rotate AWS and Azure keys after a specific number of days of their creation or the last rotation.

• Added capability to schedule key rotation at the Azure key vault level using the GUI.

• Added support for migration of CCKM Enterprise source keys from Data Security Manager (DSM) to the CipherTrust Manager.

• Added support for migration from CCKM Appliance with CipherTrust Manager as Key Source to the CipherTrust Manager.

• Added capability to generate and verify Hash-based Message Authentication Codes (HMAC) for AWS symmetric keys.

• Ability to get alerts/notifications for the AWS and Azure cloud key expiry events.

• Added support for 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.

• Added support for Google EKM through a VPC.

• Added capability to allow the selection of all of the versions of an existing CipherTrust Manager key when creating an EKM endpoint.

• The XKS performance numbers for both the CipherTrust Manager and Luna HSM (as key sources) have improved for this 2.11.1 release.

• Added the Google Cloud EKM Records public query to the available Loki filters on the GUI.

CTE

• Added capability to collect and download the latest information about individual CTE Agents to the CipherTrust Manager GUI.

• Added capability to automatically execute supported quorum operations as soon as the last approver approves the quorum.

• Extended CipherTrust Manager's quorum control support to bulk deletion of clients and GuardPoints.

• Removed the Unique to Client check box from the CTE tab of the Keys details page.

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 capability to collect and download the latest information about individual CTE Agents to the CipherTrust Manager GUI.

• Added capability to automatically execute supported quorum operations as soon as the last approver approves the quorum.

• Extended CipherTrust Manager's quorum control support to bulk deletion of clients and GuardPoints.

• Removed the Unique to Client check box from the CTE tab of the Keys details page.

DDC

• Agent upgrade to version 2.6.1. This resolves a few problems, such as support for filters in the Exchange and Sharepoint data stores. See the Advisory Notes below for more information.

• Support for scanning binary data in MongoDB and SAP HANA.

• Support for the Exchange Server data store.

• Removed support for legacy reports.

• Support for remediation of the root path in the SMB network storage data store.

• Support for different weights per InfoType. The risk in formulas for in Data Objects and Data Stores will now be calculated based on the value and occurrences of each InfoType.

• Enhanced Singaporean NRIC data type to include the new prefix "M" for Foreign Identification Numbers (FINs).

ProtectV

ProtectV is End-of-Life based on the announcement shared in the past. CipherTrust Manager 2.11 onward, the ProtectV tile has been removed from the CipherTrust Manager GUI and registering ProtectV clients is no longer supported.

Refer to End-of-Sale and End-of-Life Announcement SafeNet ProtectV for details.

CDP

Added support for the following operations on CipherTrust Manager UI for Oracle, MSSQL, and DB2:

For details, refer to the CDP Admin Guide.

Resolved Issues

This table lists the issues resolved in 2.11.6.

This table lists the issues resolved in 2.11.5.

This table lists the issues resolved in 2.11.4.

This table lists the issues resolved in 2.11.3.

This table lists the issues resolved in 2.11.2.

This table lists the issues resolved in 2.11.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.

Key Refresh Issue with Unlinked AWS XKS (HYOK) Keys

In CCKM v2.10.0, v2.10.1, and v2.10.2, AWS XKS (HYOK) in unlinked mode is not working properly. Keys created on CCKM in the unlinked mode disappear from the AWS keys list after the Refresh action on the UI or Sync operation on the API.

Conversely, if an unlinked AWS XKS (HYOK) key is created on the AWS console, a new key will appear on the CCKM AWS Key List with an incorrect origin (HYOK-External) after a Refresh or Sync operation on the UI or API.

Thales recommends customers running CCKM with AWS XKS (HYOK) in unlinked mode to not trigger the Refresh or Sync operation on the UI or API and upgrade to version 2.11.1, 2.12.0, or higher when available.

USB Host Logs are Not Immediately Forwarded on Upgrade

If you have an existing syslog forwarder configured for host logs, and upgrade to 2.11, 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.

KeySecure Classic Hardware No Longer Supported

CipherTrust Manager firmware version 2.8 or above is not supported on KeySecure Classic k450 and k460 hardware. Refer to Migrate from KeySecure Classic for information on migrating KeySecure Classic data to CipherTrust Manager hardware.

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.11, 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 the latest patch versions of 2.8.x, 2.9.x, and 2.10.x. As well, we tested upgrades from a lower 2.11.x patch version, such as 2.11.2, to a higher patch version, such as 2.11.5.

An unclustered CipherTrust Manager 2.11.x can be downgraded to 2.10.x for test purposes. 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.

• In-place offline cluster upgrade is supported from 2.10.x, 2.11.0, 2.11.1, 2.11.2, or 2.11.3.

• Cluster remove/rebuild is supported from 2.8.x, 2.9.x, 2.10.x, 2.11.0, 2.11.1, 2.11.2, or 2.11.3.

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

Restoring a backup from release 2.8 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

Upgrading DDC

After you upgrade to version 2.11 you will not be able to downgrade it to any of the previous versions.

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

EOS for Legacy Reports

The support for Legacy Reports has been dropped in DDC 2.11.

EOS for KCT Datastore

End of Support for KCT Datastore Format in DDC 2.11.

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 Cloud Key Manager

{
    "name": "Google CSE policy",
    "allow": true,
    "effect": "allow",
    "resources":["kylo::cckm:"],
    "actions": ["GoogleWorkspaceCSE"],
    "conditions": [],
    "obligations": [],
    "includeDescendantAccounts": false
}

{
    "policy": "<policy-id>",
    "principalSelector": { "cust":{ "groups": [ "CCKM Admins" ] }},
    "jurisdiction": ""
}

CipherTrust Database Protection

Application Data Protection

CipherTrust Data Discovery and Classification

CipherTrust Transparent Encryption

ProtectApp

ProtectFile