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 existing k170v Virtual CipherTrust Manager instances.

• An upgrade file for some Thales TCT k160 CipherTrust Manager devices.

  Note

  The following support limitations apply for the Thales TCT k160 device:

  • The 2.10.0, 2.10.1, and 2.10.2 releases are only supported on Thales TCT k160 Standard devices. They are not supported on Thales TCT k160 High Assurance devices.

  • The 2.10.3 patch is not supported on either variant of the Thales TCT k160 device.

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

Features and Enhancements

Release 2.10.3

The 2.10.3 release 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-85446.

This release is available as an upgrade file. The upgrade can be applied directly on CipherTrust Manager version 2.7.x, 2.8.x, 2.9.x, 2.10.0, 2.10.1, and 2.10.2.

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

Release 2.10.2

The 2.10.2 release includes some security fixes and stability fixes described in Resolved Issues. This release is available as an upgrade file. The upgrade can be applied directly on CipherTrust Manager version 2.7.x, 2.8.x, 2.9.x, 2.10.0, and 2.10.1.

Release 2.10.1

The 2.10.1 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.7.x, 2.8.x, 2.9.x and 2.10.0.

Release 2.10.0

Platform

• Released the Quorum feature for general availability.

• Added connection management support for LDAP.

  • In 2.10, CTE agents are supported for this LDAP connection.

  • This connection is separate and additional to the existing LDAP connection available through Access Management.

• Added capability to browse LDAP users and groups using connections created in the LDAP connection manager.

• Added ability to verify whether the time is in sync between the CipherTrust Manager and AWS when testing AWS connections.

• Added capability to get the list of KMIP registration tokens using ksctl.

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

• Added capability to control allowed authentication methods for users.

• Added support for preventing deletion of in-use SMB connections.

• Added ability to create system policies to control login based on groups and interfaces.

• Added support for granular access (based on clients, users, groups) to group of keys.

• Added option to filter keys by effective permissions.

• Made the SSH interface port configurable.

• Enhanced the nodes API to specify additional cluster information.

• Added cluster information metrics for Prometheus log monitoring system.

• Added support for external certificates for Azure and Salesforce connections.

• Added capability to use certificates on multiple interfaces of same type.

• GUI enhancement: Made consistent use of the term username.

• Added support for nShield Connect HSM as root of trust.

• Enhancement to OIDC connection for CipherTrust Manager user authentication. CipherTrust Manager now checks and refreshes the signing keys from the identity provider on each authentication, to keep up with key rotation.

• Small user-friendly enhancements to the ks-upgrade.sh upgrade script.

• Due to design stability, the Prometheus metrics endpoint is now fully supported and no longer technical preview.

Limitations

• To fetch all keys, it is recommended to use KeyNamesRequest instead of KeyQueryRequest. The KeyQueryRequest response time is proportional to the number of keys on the CipherTrust Manager, hence 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 CipherTrust Manager logs forwarded to legacy Syslog server using TCP transport mode are limited to a size of 1024 bytes. After this size, the log message is truncated. However, you can use a Syslog log forwarder instead of the Syslog server to view the complete logs. The log forwarders support log messages larger than 1024 bytes.

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

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

• Added integration of CipherTrust Manager and Luna Network HSM with AWS External Key Store (XKS). External custom key stores allow you to select keys held in CipherTrust Manager or Luna Network HSMs and allow AWS KMS to use the keys for cryptographic operations on demand. The external custom key store (either CipherTrust Manager or Luna Network HSM) contains Hold Your Own Keys (HYOKs) and executes the cryptographic operations.

• Added support for GCP key purpose "MAC" for signing and verification for symmetric keys using the API.

• Added capability to automatically rotate keys after a specific number of days of the last key rotation.

• Added support for dynamically pushing policy updates to the associated AWS keys using the API.

• Added support for Technical Users for connecting to the SAP Data Custodian.

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

• Added capability to add schedules while creating AWS cloud keys.

• Added capability to select and modify policy and policy templates using the GUI.

• Added capability to include roles in AWS key policies. Now, key administrators and key users access can be granted to IAM roles.

• Added support for the Azure Key Vault Managed HSM cloud service using the GUI. Azure Managed HSM vaults support RSA-HSM and EC-HSM keys only. Other functionalities are the same as regular Azure vaults.

• Enabled support for Microsoft Confidential Computing for Luna Network HSM as a key source with Azure Managed HSMs or Premium Azure Key Vaults. For this, an exportable flag has been introduced for keys in Azure Key Vaults.

• GWS Workspace CSE: Added capability to attach multiple identity providers (IdP) to individual endpoints.

• GWS Workspace CSE: Added support for client side encryption of Gmail messages.

• Google EKM: Support for a new Key Access Justification Reason, MODIFIED_GOOGLE_INITIATED_SYSTEM_OPERATION.

• Added support to manage AWS CloudHSM Custom Key Stores.

• Officially documented instructions to prevent CCKM users from exporting source key material.

• Added capability to add a policy template at the time of AWS key creation.

CTE

• Added support for CipherTrust Manager's quorum control for CTE operations and resources. A CipherTrust Manager administrator can configure a quorum policy to have multiple approvers for supported operations.

• Added support for signature sets for CTE for Kubernetes clients.

• Added support for COS policies for Wasabi cloud storage.

• Enhanced the CTE clients GUI to display different client types - FS (CTE), CSI (CTE for Kubernetes), and CTE-U (CTE UserSpace).

• Enhanced CTE reports to filter reports based on client type - FS (CTE), CSI (CTE for Kubernetes), and CTE-U (CTE UserSpace).

CTE UserSpace

CTE UserSpace is a new kernel-independent file encryption product based on CTE and CTE UserSpace (rebranded ProtectFile FUSE). The CTE UserSpace version compatible with CipherTrust Manager 2.10 will be 10.0 (instead of 9.5).

• The resources of CTE UserSpace clients running 9.5 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

  Note

  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 9.5 or a higher version.

• Added support for CipherTrust Manager's quorum control for CTE operations and resources. A CipherTrust Manager administrator can configure a quorum policy to have multiple approvers for supported operations.

• Enhanced the CTE clients GUI to display different client types - FS (CTE), CSI (CTE for Kubernetes), and CTE-U (CTE UserSpace).

• Enhanced CTE reports to filter reports based on client type - FS (CTE), CSI (CTE for Kubernetes), and CTE-U (CTE UserSpace).

CIP

• Added support for NFS and SMB/CIFS DataStores

• Added capability to scan SMB/CIFS DataStores

• Added capability to generate reports for NFS/SMB/CIFS DataStores

• Extended policy support to NFS and SMB/CIFS GuardPoints

DDC

• Support for RHEL 8 Agents

• Support for SCRAM-SHA-256 authentication in PostgreSQL

• OneDrive for Business data store support

• BLOB support for Oracle, Microsoft SQL, PostgreSQL, MySQL, Teradata, and IBM DB2

• Collecting Agent logs for troubleshooting purposes

• Enhanced scan progress status allows you to see if a scan with a blocked percentage is stuck or is progressing

ProtectV

ProtectV will be End of Life based on the announcement shared in the past. CipherTrust Manager 2.11 onwards, registering ProtectV clients will no longer be supported and changes will be made to deprecate the ProtectV management API and UI.

End-of-Sale and End-of-Life Announcement SafeNet ProtectV

Resolved Issues

This table lists the issues resolved in 2.10.2.

This table lists the issues resolved in 2.10.1.

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

In CCKM with AWS XKS, Issue with Rotation of AWS HYOKs when CipherTrust Manager 2.10.0 is Used as Key Source

When using CipherTrust Manager version 2.10 as a key source within AWS XKS, do not rotate AWS HYOK keys. As documented in the known issue of KY-53594, data encrypted using older versions of a key cannot be decrypted. Release 2.10.1 addresses this issue.

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.

HSM-anchored Domains Unavailable in 2.10

HSM anchored domains are unavailable for this release while we continuously improve their quality and add new features. HSM-anchored domains are available in CipherTrust Manager version 2.9 as a technical preview, and will be returning in a future release.

The following recommendations apply to any CipherTrust Manager which has created an HSM-anchored domain in version 2.9:

• Reset the CipherTrust Manager before deploying it into production.

• Do not restore any backups from this CipherTrust Manager.

Contact customer support if you require assistance with previously created HSM-anchored domains.

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.10, 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 have been tested from releases 2.7, 2.8, and 2.9 to 2.10.x. Upgrades have been tested from lower 2.10.x versions to higher 2.10.x patches.

CipherTrust Manager 2.10.x can be downgraded to 2.9.x. 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.

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.

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

Sharepoint Connection

Sharepoint connection settings have changed. Instead of username and password, it is now re required to provide Client ID, Client Secret Key, and Tenant ID. Existing Sharepoint data stores in any upgraded CM instances will need to be modified with the new connection details.

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

Sharepoint Online Data Store

The Sharepoint Online datastore configured before the CM 2.10.0 release will no longer be accessible after upgrading to CM 2.10.0, if the authentication credentials are not changed. The user will see the "Internal Error" error while running any scan on a Sharepoint Online data store.

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 10.0

CipherTrust Transparent Encryption for Kubernetes

Minimum version 1.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:

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

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

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

CipherTrust Data Discovery and Classification

CipherTrust Transparent Encryption

ProtectApp

ProtectFile