[4.0] - June 25, 2021

This release is superseded by July 31, 2021 release

Fortanix Data Security Manager (DSM) 4.0 comes with some exciting new features and enhancements.

WARNING
  • It is “REQUIRED” to upgrade Fortanix DSM to either the 3.25 or 3.27 version before upgrading to version 4.0.
  • If you are planning to upgrade to Fortanix DSM 3.27 version first, please take note of a known issue in the 3.27 version and review if it affects your applications.
NOTE
  • This release is applicable for Fortanix DSM series 1 and 2 appliances. For AWS/Azure/VMware deployments there will be a subsequent upgrade provided soon.
  • The expected time for a 3-node cluster upgrade (after the software package is uploaded) will take about 1 hour.

1. New Functionality/Feature(s)

1.1 HSM Key Management Policy (JIRA: PROD-2197)

The HSM Key Management Policy helps to manage virtual key changes in Fortanix DSM to the corresponding keys in the configured HSM. The users can select whether to apply or not apply changes performed on virtual keys such as destroying security objects, removing the private component of asymmetric keys, or key permissions changes to the corresponding keys in the HSM.

HSM_Policy.png

For more details refer to https://support.fortanix.com/hc/en-us/articles/360042056431#3-0-hsm-key-management-policy-0-15

1.2 Key undo Policy (JIRA: PROD-1178)

To stop accidental sensitive operations on keys, Fortanix DSM allows a user to add a “Key undo policy”. When the policy is added, the keys will go through a 2-step process in which the sensitive operations can be undone until a waiting period set by the user before the changes become permanent. The maximum period until which the changes can be undone is 180 days. As a best practice, a minimum period of 7 days is recommended.  The following sensitive operations can be undone:

  • Delete and destroy key
  • Deactivate and activate a key
  • Mark a key as compromised
  • Remove private key
  • Remove sensitive key operations encrypt, decrypt, sign, verify, and so on.

Key_Undo1.png

For more details refer to https://support.fortanix.com/hc/en-us/articles/4402562226580-User-s-Guide-Key-Undo-Policy 

2. Enhancements to Existing Features

  • Added "Rotate to SDKMS Key" checkbox in the Rotate key for AWS KMS backed group (JIRA: ROFR-2525):
    In this feature, when you rotate an AWS virtual key with a Fortanix DSM-backed key, the key material of the Fortanix DSM-backed key will be imported to AWS KMS and the newly created key in AWS KMS will carry the alias of the key rotated. Rotate_AWS.png

For more details refer https://support.fortanix.com/hc/en-us/articles/360055605471#4-3-rotate-aws-native-key-to-fortanix-self-defending-kms-owned-key-0-28

  • Added support for audit logging enable/disable for a security object under the Crypto Policy - Key Operations (group/account) (JIRA: ROFR-2484). 
    1. Crypto policy now supports enabling/disabling audit logging settings. Audit_log3.png
  • If an application is part of a Quorum policy, an approval request is created for the get "api key" (JIRA: ROFR-2481).
  • Key rotation is disabled when the security object is in a “deleted” state (JIRA: ROFR-2579).
  • Human-readable quorum policy improvements (JIRA: ROFR-2569).
  • Improvements to Audit logging setting on Security Objects (JIRA: ROFR-2540).
    1. Audit logging is now a toggle button (instead of checkbox) in the create SO form, and the description has been updated. Audit_log2.png
    2. The audit logging state change now shows clearly in the quorum approval screen. Audit_log1.png

3. Improvements

  • When retrieving tokenization objects, they should contain the fpe.name field for backward compatibility (JIRA: PROD-3117)
  • Mark the virtual keys when their mapped keys are deleted from AWS KMS. (JIRA: PROD-3038): AWS_VirtualKey_Mark.png

4. Bug Fixes

  • When a security object is deleted from a Fortanix DSM Group, the security object delete page submits approval when not required (JIRA: ROFR-2596).
  • When a Fortanix DSM account has a lot of users, adding Quorum Policy to an existing group in that account fails (JIRA: ROFR-2593).
  • If an account has only 1 user and when you delete this user causing the account to be orphaned, the deletion fails but there is no error displayed in the UI (JIRA: ROFR-2580).
  • Masking token fails for SSN tokenization (JIRA: ROFR-2529).
  • Masking token fails for Military ID tokenization (JIRA: ROFR-2510).
  • Quorum approval policy should not be enforced in UI for creating a “Key undo policy” (JIRA: ROFR-2526).
  • When you add tags to virtual keys, the tags are not added to the corresponding keys in AWS KMS (JIRA: ROFR-2607).
  • Bearer token for old API key session fails with “Session has expired”. (JIRA: PROD-3323).
  • Panic on approving a request where the requester is missing (JIRA: PROD-3300).
  • The sdkms-cluster node label regular expression fails for valid labels which require a node reset and rejoin (JIRA: DEVOPS-1108).
  • A quorum approval request that is declined is still allowed to be approved (JIRA: PROD-1713).
  • Partial sync of AWS Customer Managed Key (CMK) keys due to access issues for some CMK keys (JIRA: PROD-3296).
  • The “sdkms-scheduled-operation” job fails with 400 bad request (JIRA: PROD-3252).

5. Security Fixes

  • 20.04 upgrade patches OS components.
  • Intel aesmd updated to 2.13.103.1

6. Quality Enhancements/Updates

  • Updated Cassandra + sdkms-backup container to version 20.04 (JIRA:DEVOPS-1285).
  • Added config.yaml/config map values to Fortanix DSM backup job (JIRA: DEVOPS-1297).
  • Elasticsearch:
    • Audit logs and stats will migrate stats from Elasticsearch to Cassandra (JIRA: PROD-3162).
    • For clusters with audit logs in Elasticsearch with more than 20 million counts, migration will not be done automatically.
    • Elasticsearch will be removed if audit logs/stats were migrated to Cassandra (JIRA: PROD-3174).
  • Updated Intel SGX driver (JIRA: PROD-3122).
  • Warm up the Nginx proxy cache on pod startup (JIRA: DEVOPS-1312).
  • Enable snapshot-based Cassandra backup (JIRA: DEVOPS-1308).
  • Support for reducing the health API logs in the backend container (JIRA: PROD-3268).

7. Known Issues

  • If the "Key undo policy" is configured on the group and setting an expiry date or deactivating a key, an empty Key History item might be shown (JIRA: PROD-3476).

8. Fortanix Self-Defending KMS Performance Statistics

8.1 Series 1

Key Types and Operations Throughput (Operations/second per 3-node cluster)
AES 256: CBC Encryption/Decryption

3803/3850

AES 256: GCM Encryption/Decryption

3847/3340

AES 256: FPE (Format-Preserving Encryption)

1942

AES 256 Key Generation

790

   
RSA 2048 Encryption/Decryption

3151/679

RSA 2048 Key Generation

26

RSA 2048 Sign/Verify

668/3118

EC NISTP256 Sign/Verify

565/317

   
Data Security Manager Plugin (Hello world plugin)

1193 (invocations/second)

__________________________________________________________________________________________

 

8.2 Series 2

Key Types and Operations Throughput (Operations/second per 3-node cluster)
AES 256: CBC Encryption/Decryption

5336/5390

AES 256: GCM Encryption/Decryption

5188/5292

AES 256: FPE (Format-Preserving Encryption)

2099

AES 256 Key Generation

1312

   
RSA 2048 Encryption/Decryption

5034/1056

RSA 2048 Key Generation

46

RSA 2048 Sign/Verify

1049/4377

EC NISTP256 Sign/Verify

626/336

   
Data Security Manager Plugin (Hello world plugin)

2040 (invocations/second)

9. Installation

To download the DSM SGX (on-prem/Azure) and Software (AWS/Azure/VMWare) packages, click here.

Comments

Please sign in to leave a comment.

Was this article helpful?
0 out of 0 found this helpful