Security Architecture of Running Fortanix DSM in a non-SGX Virtual Environment (on-prem only)


Fortanix Data Security Manager (DSM) relies on two secret master keys, which are not known to anyone:

  • The Cluster Master Key (CMK) is shared by all nodes in the cluster.
  • The Node Platform Key is a unique key for each node and is used to protect the information that helps in deriving the CMK.

key-hierarchy-horizontal-Non-SGX-New.png Figure 1: Fortanix Data Security Manager Key Hierarchy (Non-SGX)

When Fortanix DSM is deployed as a physical hardware appliance, which is certified to FIPS 140-2 Level 3, the CMK is generated inside the appliance, and the Node Platform Key is derived from the Intel SGX sealing key built into the CPU.

When Fortanix DSM is deployed as a virtual appliance in a public/private cloud, which is certified to FIPS 140-2 Level 1, the CMK is derived using a secret stored in an external HSM, called Cluster Deployment Key (CDK). This external HSM could be a Fortanix DSM hardware appliance cluster, Fortanix DSM SaaS, or any 3rd party HSM that supports a PKCS#11 interface (including nShield, Luna, or AWS CloudHSM).

In the Non-SGX version of Fortanix DSM, secrets are stored in the following places and used as explained below:

  • In the external HSM
    • CDK is generated and stored in an external HSM.
    • The CMK is not stored directly anywhere. It is derived from the CDK and a random seed value. The CDK is stored in the external HSM and is exported each time it is used.  For each node, the seed value is wrapped with that node's Platform Key and stored in the database.
  • In Kubernetes secrets
    • Platform seed is stored as a Kubernetes secret. Each node's Platform Key is derived from this Kubernetes secret, the node id, and the hash of the software binary.
    • The credentials to the external HSM are stored in a Kubernetes secret.
  • In the database
    • All user data in the database is encrypted with an Account Key, which is unique to each account. The Account Keys are stored in the database, wrapped with a key derived from the CMK.


After cluster creation, the user is prompted for the credentials to connect to the external HSM. If the external HSM is a Fortanix DSM cluster or Fortanix DSM SaaS, the API key and URL need to be provided. If the external HSM is a non-Fortanix HSM, such as nShield or Luna, the IP address of HSM Gateway and slot & PIN for HSM need to be provided. This information is stored as a Kubernetes secret.

The secret generation, key generation, and storing happen at the time of cluster creation.

  • Fortanix DSM requests the external HSM to generate the CDK (AES-256) and make it exportable. Next, it obtains the ID of the CDK that was generated in external HSM.
  • Fortanix DSM generates the Kubernetes secret (Platform Seed) that is used to derive the Platform Key. This value is used to derive the Platform key as explained earlier.
  • Fortanix DSM generates a random seed value. This random seed value is used in CMK derivation.
  • Fortanix DSM wraps the random seed value and the ID of the CDK with the Platform Key and stores it in the database.

Node Reboot

Upon boot up, the node unwraps the seed value and CDK ID using its Platform Key. It exports the CDK from the HSM and combines it with the seed to derive the CMK. The node does not need to access the HSM again until it reboots or performs a software update.

Adding a New Node to Cluster

When a new node is added to an existing Fortanix DSM cluster, it goes through a handshake and verification check. An existing node unwraps its (seed, CDK ID) pair, and sends it to the new node. The new node wraps this pair with its own Platform Key and stores it in the database. The new node uses the seed value and CDK ID to derive the CMK.

Software Update

The Node Platform Key which is used to wrap the (seed, CDK ID) pair depends on the hash of the application binary. When there is a software update, the hash of the application binary changes, so the Node Platform Key changes as well, and the (seed, CDK ID) pair needs to be re-wrapped with the new Node Platform Key.

Frequently Asked Questions

What if the external HSM is not available?

If the external HSM is not available, the service will not come back up on a node in case of a reboot or restart of the Fortanix DSM pod on that machine. New nodes cannot be added to the cluster either.

What if the CDK gets accidentally deleted?

When using Fortanix DSM as the external HSM, the CDK should be protected from deletion by configuring a quorum policy on the group which contains the key. A key undo policy should also be configured to restore the key in case of accidental deletion.

When using a non-Fortanix HSM, the customer should follow the vendor’s guidelines for backing up the key and protect from disaster.

How is the CDK protected in backups?

The credentials used to access CDK are excluded from backups.

How are CMK and CDK rotated?

The CDK and CMK must be rotated in tandem. To perform the rotation, an API call is issued. This causes Fortanix DSM to generate a new seed value and send a request to the HSM to generate a new CDK.  The new (seed, CDK ID) pair is wrapped with each node's Platform Key and stored in the database. The user data is re-encrypted lazily, so the old CDK must be kept in order to read old data.




Please sign in to leave a comment.

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