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

Features and Enhancements

Release 2.7.1

The 2.7.1 release some stability fixes described in the resolved issues list, as well as a resolution for the CVE-2022-0778 vulnerability. This 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.7.x, 2.6.x, 2.5.x, and 2.4.x.

Release 2.7.0

Platform

• Creating users in non-root domains feature is generally available (GA).

• Added support for alarms triggered by client records.

• Added the ability to schedule a domain-scoped backup on the web console.

• Added ability to reset a physical appliance through a serial connection without logging in as ksadmin. This operation, called "zero knowledge factory reset", is done in tandem with customer support.

• Added support to renew certificates of registered CipherTrust Manager clients (CTE and KMIP clients).

• Added ability to add connections to the SAP Data Custodian cloud.

• Ability to manage the usage of CA on individual CipherTrust Manager domains using Client Authentication.

• Certificate expiry notifications for registered KMIP/NAE clients.

• The RSA-AES-WRAP/UNWRAP mechanism is added for NAE-XML.

• Support for AES CMAC algorithm in the CipherTrust Manager.

• Made the Host and Port fields optional for creating the SMB connection.

• Added alarm and audit record when TLSv1.0 and TLSv1.1 are enabled on the CipherTrust Manager.

• Support for Extractable & NeverExtractable attributes in KMIP.

• Added support for creation of "PKCS#12 Password Link" and "PKCS#12 Certificate Link" through REST and KMIP interfaces.

  Note

  This release does not support:
  • Register and Export of PKCS#12 key format using "PKCS#12 Certificate Link" and "PKCS#12 Password Link" for REST interface.
  • Register and Export of PKCS#12 key format for KMIP interface.

• Support for client validation through NAE interface for CADP client.

• Tech Preview: Expansion of quorum for deleting Google External Key Manager (EKM) Endpoints operation.

• Tech Preview: Addition of a Prometheus metrics endpoint, which allows the Prometheus monitoring system to scrape the CipherTrust Manager continuously, providing metrics to help monitor overall system health, performance, and cryptographic activity. As well, there is a sample configuration available on Github, including Prometheus and Grafana data visualization application Docker containers.

Limitation(s)

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.

CCKM

• Support for SAP Data Custodian.

• Improved GUI for AWS key regionality, that is, single-region and multi-region keys.

• Allowed adding same AWS account in one CipherTrust Manager domain with different names, with each entry having a unique set of regions.

• Enhanced AWS Policy template to mark policies as verified/unverified.

• Workflows for managing Google Cloud External Key Manager (EKM) endpoints and Google Cloud External Key Manager Ubiquitous Data Encryption (EKM UDE) endpoints are consolidated. This means that you can now create, view, update, and delete both endpoint types through the same API endpoints, CLI commands, and web console navigation menus. As well, EKM UDE functionality is now considered complete and no longer a technical preview.

• Enhancements to EKM and EKM UDE endpoint policy management. This includes:

  • a "Basic View" UI display for policies, to allow policy editing without knowledge of Open Policy Agent policy engine.

  • More policies related to UDE Attestion, namely Zones, Project IDs and Instance Names.

• EKM endpoints can now be created with an asymmetric key, for signing operations and fetching the public key. The available asymmetric key types are:

  • RSA_SIGN_PSS_2048_SHA256

  • RSA_SIGN_PSS_3072_SHA256

  • RSA_SIGN_PSS_4096_SHA256

  • RSA_SIGN_PSS_4096_SHA512

  • RSA_SIGN_PKCS1_2048_SHA256

  • RSA_SIGN_PKCS1_3072_SHA256

  • RSA_SIGN_PKCS1_4096_SHA256

  • RSA_SIGN_PKCS1_4096_SHA512

  • EC_SIGN_P256_SHA256

  • EC_SIGN_P384_SHA384

• Performance measurements for EKM operations now available, to help you decide on the CPU for, memory for, and number of CipherTrust Manager nodes required to support your EKM throughput needs.

• Google Workspace CSE performance enhancement using caching.

• New UI display on the Licensing page of the number of cloud units currently consumed by CCKM.

CTE

• LDT Communication Groups. LDT clients within an LDT communication group can communicate with each other. An LDT communication group is mandatory when using a multi-node solution for LDT over NFS/CIFS.

  • An LDT client can only be added to one LDT communication group at any instance of time.

  • Although this release allows you to add multiple LDT communication groups to the CipherTrust Manager, only one group can be active at a time.

• Domain-level CTE reporting. Administrators can now generate reports of CTE resources that belong to specific CipherTrust Manager domains.

• Tech Preview (CTE for Kubernetes): Native support for Kubernetes through the implementation of a Container Storage Interface (CSI) driver. CTE for Kubernetes protects Kubernetes Persistent Storage Claims that are backed up by the storage with file system semantics.

• Customized groups for CTE to control permissions on CTE resources.

• Ability to restrict/allow updates to policies in use by active GuardPoints.

CIP

• Protection of existing classified data. A new option, Reclassify, is included to protect data that is already scanned and classified.

• Automated intelligent protection. The DDC scans can be created automatically. A new option, Intelligent Protection, is added to the Create GuardPoint dialog box to enable automated intelligent protection.

• Access only policies. These policies provide access control only, they do not encrypt data.

CTE UserSpace

• GUI Enhancements:

  • Rules now display the linked Access Policy Group.

  • Editable Client Description field is added to briefly describe a client.

• Ability to update user/group and process names in access policies. This release supports editable policies using the API only.

Data Discovery and Classification

• Scan Trend report - provides the visibility of the scan trend data, such as the number of sensitive items discovered, analyzed and protected.

• Improved CIP flow - to facilitate the possibility of protecting sensitive Data Object based on a scan execution, after it has ended successfully. Thanks to it, CipherTrust Transparent Encryption can be configured and triggered after the discovery phase has ended.

• Identify ACL only - provides specific information when an ACL policy has been applied to a Data Object.

• Manual agent assignment - brings the option of assigning a specific selected agent to a Data Store.

• Automatic scan pause - facilitates the capability of pausing a scan automatically when necessary, for instance, during peak hours.

• Improved scan reporting - filtering is enabled by the data displayed in the Scan Aggregated report, such as: Data Object name, path, risk, and type of the Data Object.

• New InfoTypes - a set of new built-in InfoTypes for India, such as driving license, MGNREGA Job Card, bank account number, phone number, name, Indian Ration card number, and marital status.

Application Data Protection

• Added support for Central Management. It allows clients to fetch configuration and policies from the CipherTrust Manager.

• Added support to define Applications and decide how to protect them.

• Added support for Client Registration. Currently, only DPG can be registered on the CipherTrust Manager.

• Added support for Single Pane of Glass for applications defined on CipherTrust Manager.

Resolved Issues

This table lists the issues resolved in 2.7.1

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

Upgrading a k570 Appliance from 2.6.1: Lose of CipherTrust Manager Services after Reboot

Upgrading a k570 appliance from 2.6.1 to 2.7.x or 2.8.x makes the PCI HSM unavailable, and after reboot, CM services do not start. During upgrade the following message is displayed: Starting k7 (via systemctl): k7.serviceJob for k7.service failed because the control process exited with error code.

If you encounter this issue, contact customer support for assistance.

CipherTrust Manager Versions Hosted on Microsoft Azure Marketplace

Microsoft Azure Marketplace has removed all virtual CipherTrust Manager versions prior to 2.6. If you require an Azure deployment for earlier Virtual CipherTrust Manager versions, contact Thales customer support for a virtual machine file.

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.

Upgrade from 2.6 to 2.7.0: Network Connection Loss After Rebooting Microsoft Azure Instances

If you upgrade Virtual CipherTrust Manager instances hosted on Microsoft Azure from version 2.6 to 2.7.0, after two reboots the instance does not correctly initialize the network interface and so becomes unreachable.

We strongly recommend upgrading directly to 2.7.1 if you are running Azure-hosted instances at version 2.6.x or 2.7.0.

Follow these steps if you have already upgrade to 2.7.0 and lost network access to the CipherTrust Manager GUI, CLI, or REST API, but have password access to the serial console.

1. Open an SSH session with Virtual CipherTrust Manager as the ksadmin user.

2. Contact Thales Support for support shell access.

3. After you are logged in as root, run the following two commands:

   # rm /etc/netplan/50-cloud-init.yaml
   # echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
   

4. Reboot the instance when convenient.

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 to 2.7, 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. 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.4.0, 2.5.0, and 2.6.0.

CipherTrust Manager 2.7.0 can be downgraded to 2.6.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.

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.

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.

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

CipherTrust Database Protection

CipherTrust Data Discovery and Classification

CipherTrust Transparent Encryption

Application Data Protection

ProtectApp

ProtectFile