Fortanix Data Security Manager (DSM) is a unified FIPS 140-2 Level 3 validated Hardware Security Module (HSM) and a Key Management Service (KMS). It allows you to generate, store, and manage keys, and use them for cryptographic operations, such as encryption, tokenization, and digital signatures.
DSM also lets you control the lifecycle of these keys and manage access controls and permissions for them. In many use cases, users create non-exportable keys and use Fortanix DSM REST API to perform cryptographic operations over the network.
This is often driven by organizations’ requirement that keys should be generated inside a FIPS 140-2 Level 3 validated HSM and should never leave the HSM.
This model works well for many use cases, such as Transparent Data Encryption (TDE) in databases, code signing, crypto wallets, etc.
When we designed DSM SaaS, we took careful consideration of the latency and throughput requirements for a majority of the use-cases, while delivering the highest level of security.
The DSM SaaS cluster is globally distributed across 15 Equinix data centers located near major cloud regions in US, EU, and APAC and offers an option for direct connections to cloud VPCs over the Equinix Fabric.
The cluster has been sized to account for a multifold increase in the current amount of traffic.
However, we often come across use cases, wherein performing all cryptographic operations over the network is not an option.
The following are some examples of such use cases:
- Ultra-low latency requirements - Some applications have ultra-low latency requirements for encryption or tokenization of data.
For example, a business intelligence (BI) application pulling data from Snowflake and performing in-line detokenization of data may require a million rows to be processed in under a minute, otherwise the query may fail.
Sending data over the network to the DSM to be de-tokenized may be prohibitive in such use cases.
- Ultra-high throughput requirements - The throughput of a Fortanix DSM cluster depends on the size of the DSM cluster. If there is a burst of traffic that the cluster is not sized for, there may be performance problems.
An example of a use-case with high throughput requirements is a one-time job of tokenization or encryption of data sitting in a large database, which may take several hours if the requests must be sent over the network.
- Organizational policies and concerns over data leakage - Some organizations have policies preventing them from sending data over the network outside the organization's infrastructure to be encrypted or tokenized.
The organization would rather get the key from Fortanix DSM and do the cryptographic operation locally.
- Operational overhead and availability - Getting a low latency connection to a Fortanix DSM cluster may require deploying DSM close to where the application lives or running the application close to a DSM SaaS location.
For a large organization with global presence and a distributed infrastructure, this may become prohibitive due to operational complexity and cost.
- Flaky network connection – For applications sending crypto operations to be performed over the network to Fortanix DSM, there is a strong requirement for a robust network connection.
This may not always be possible, for example, a restaurant using DSM to encrypt transactions may suffer a network outage where it can’t reach DSM, but it can’t stop serving incoming customers.
There is an apparent need to take the goodness of the DSM and apply it to use-cases wherein low-latency, high-throughput or operational and performance challenges need to be overcome.
To address this expanding set of use-cases, we’re excited to announce the Fortanix DSM Accelerator.
What is Fortanix DSM Accelerator?
The Fortanix DSM Accelerator is a brand-new feature that brings the cryptographic operations closer to the application by fetching keys from DSM and caching them in its memory and providing an interface for performing cryptographic operations.
The DSM Accelerator is available both as a library, as well as a web service.
As a library, the DSM Accelerator feature provides a language-specific API to an application. We are releasing two libraries currently:
- PKCS#11 library - This implements the PKCS#11 specification and is a drop-in replacement for the regular PKCS#11 library available with Fortanix DSM, or any other HSM. An application written to use the PKCS#11 interface does not need to change and can start getting the benefits of DSM Accelerator right away.
- Java library - This provides a Java API to applications. Applications written in Java can be modified to use the DSM Accelerator using this Java library.
As a web service, the DSM Accelerator exposes a subset of the Fortanix DSM API documented at https://www.fortanix.com/fortanix-restful-api-references/dsm. Notably, the DSM Accelerator does not implement the full API, but the implemented requests have the same signature as DSM. The DSM Accelerator web service is also available as a Docker container that can be launched close to the application.
Fortanix is supporting flexible deployment approaches for deploying the DSM Accelerator web service:
- As a sidecar to an application container - The application can just make API calls to the DSM Accelerator for crypto operations, and the instances can scale with the application.
- As a clustered service – The DSM Accelerator is a stateless application, so running a cluster means just running multiple instances behind a load balancer. There is no coordination needed. This can easily be done in a Kubernetes cluster. The size of the cluster can be adjusted based on the application's throughput requirements.
- As an elastic clustered service – The DSM Accelerator can be run with container orchestration solutions like AWS Fargate to scale up and down based on demand. As more requests come in, more instances can be spun up automatically using a Fargate configuration. A good example is when a burst of data needs to be detokenized periodically (e.g., when running batch queries on a Snowflake instance), and there is no need to run several instances of the DSM Accelerator constantly and incur cloud infrastructure costs.
How does key caching work?
Key caching in DSM Accelerator works similar to content caching in Content Distribution Networks (CDNs) which lowers the latency of accessing some websites.
If the key is marked exportable in the Fortanix DSM, the DSM Accelerator fetches the key on its first use and stores it in its memory.
Any subsequent call to use the key doesn't require a network round trip to DSM, as the DSM Accelerator can perform the crypto operation locally.
At no time does it write a cached key on the file system or the disk. It’s important to note that the DSM Accelerator cannot cache a non-exportable key, and any request to use such keys will fail.
Keeping keys in the memory for a long time may not be desirable for some users. The DSM Accelerator provides an API for clearing the cache.
This method can be used to remove keys from the process memory when they are no longer needed.
When should you consider purchasing the Add-on DSM Accelerator capability?
The benefits of Fortanix DSM Accelerator are most apparent when using an exportable key. There are many reasons why an organization may not want to create exportable keys - it could be due to security policy, or specific security and compliance requirements of the application using Fortanix DSM.
The good news is that the DSM Accelerator is an optional component that can accelerate your crypto operations, so you can use it only in situations where you need those specific benefits.
Hence it is a separately priced feature, that can be purchased when the use-cases outlined above are important.
Another important consideration is that when an encryption operation requires an initialization vector (IV) to be generated, they are generated locally in the DSM Accelerator, and not in the DSM service.
This may be important for applications where the IVs need to be generated with the same strength as an HSM.
It is also important to understand that the DSM Accelerator feature is not a replacement for the Fortanix DSM platform.
It is also not a light-weight DSM and should always be an add-on. It does not persist data, and it does not have the capability to generate keys.
It's also not a standalone piece of software, and it needs to be connected either to the Fortanix DSM SaaS or an on-premises deployment of the Fortanix DSM.
How would the DSM Accelerator leverage Confidential Computing?
While DSM Accelerator never writes a key on the disk, some users may be concerned about the presence of key material in the process memory.
To mitigate this risk, we are building a version of the DSM Accelerator that uses confidential computing to secure any cached keys at runtime.
In the initial release, we will provide a DSM Accelerator library as well as the web service that can run inside the Intel SGX secure enclave. In the future, we plan to offer the DSM Accelerator capability for other confidential computing platforms as well.
The DSM Accelerator capability is available now as of Release 4.12. You may contact your Fortanix sales person or channel partner to understand more about this capability and add it on to existing or new deployments.