AWS announced eXternal Key Store (XKS) support for its Key Management Service (KMS) at the AWS re:Invent conference in November 2022.

XKS enables next-level control and ownership of keys for a growing range of AWS services that use KMS. With XKS, AWS users can externally generate, host, and manage Root Keys for data encryption keys that are used in AWS KMS.

Fortanix Data Security Manager (DSM) integration with AWS XKS enables organizations to protect the data in AWS with keys stored in Fortanix DSM.

With this capability, Fortanix customers can now migrate privacy-sensitive workloads for highly regulated industries such as financial services and healthcare, to the public cloud and comply with the highest data privacy regulations.

As shown in the following diagram, XKS allows AWS KMS to use external, customer-managed Root Keys, which increases the customer’s control of their key management and data protection initiatives.

The customer’s Root Keys are generated, protected, and used wholly within Fortanix DSM. AWS KMS calls DSM to unwrap Data Encryption Keys (DEKs) for use by the AWS services it supports.

DSM enforces granular access control and key usage policies. DEKs protected by an XKS are doubly enveloped (encrypted): once by KMS, and once by DSM.

Every time the key is used by a KMS client, KMS requests Fortanix DSM to open the blue envelope and we send the gray envelope back to them to decrypt. This way, Fortanix never sees the customer’s keys.

The user gains full control over the data encryption policies within AWS. This control includes defining where the keys reside, and from where they may be accessed.

DSM provides granular audit logs, so the customer can prove that their security controls comply with regulations such as the GDPR, including restrictions defined by the Schrems II ruling.

AWS provides strong key protection, and Fortanix does not compete with these functions. Instead, Fortanix provides Segregation of Duties with external, granular access control.

Key provenance records metadata such as who created the key, when, what cryptographic model was used, key authorization, and the need for its creation.

Key provenance is applied throughout the key lifecycle and provides details on how keys are stored, accessed, used, and destroyed.

Organizations can track key origins, location, backup history, and other characteristics.

Key centralization reduces operational complexity in hybrid multicloud architectures. Keys are always accessible, whether needed on-premises, in AWS, or on other cloud platforms.

It provides users with:

• Best-practice security by segregating secure data and encryption keys (Segregation of Duties), enabling workloads to run in the public cloud.
• A single system of record to store their keys and control their lifecycle to reduce secret sprawl.
• Uniform workflows and access policies to simplify the on-boarding process of new developers and simplify the auditing process.

With AWS XKS, organizations can fully control data encryption keys and store them on premises.

This allows them to bar AWS’s access to their keys and their data, which could be mandated under the CLOUD ACT, for example.

Organizations can control the access and use of keys and maintain a complete provenance of the root key.

The use of custom key stores is completely transparent to AWS KMS users. As such, all 100+ AWS services that use KMS can access XKS key stores.

The AWS KMS team is validating and documenting each service’s ability for XKS use.

Per AWS, the biggest consumers of KMS are:

• Amazon S3
• Amazon DynamoDB
• AWS Lambda
• Amazon Simple Notification Service
• Amazon Simple Queue Service (SQS)
• Amazon Kinesis

Fortanix DSM is available as an on-premises solution and SaaS offering with a FIPS 140-2 Level 3 certified™ HSM protection.

• In an AWS XKS with DSM SaaS integration, the AWS service reaches out to the Fortanix DSM service to access the Customer’s Root Key.
• For on-premises Fortanix DSM clusters, the customer needs to allow network access from AWS.

Fortanix BV (Netherlands office) is a separate European entity. We have datacenters in Europe.

Any European entity would not be allowed by contract to transfer information to the USA, and this entity's ownership doesn't allow an American court to request the encryption keys through the Cloud Act.

Using the on-premises DSM or DSM SaaS as an External Key Store makes your services dependent on the availability of the DSM solution.

Fortanix defines a Service Level Agreement for DSM SaaS, and the availability of on-premises DSM clusters may be impacted by network connectivity, firewall rules, and so on.

The decision to use XKS should be made with both data protection and availability requirements in mind, and a trade-off between the two must be considered.

The network trip outside AWS to open KMS key envelopes should be considered when defining the total application’s latency budget.

The extra latency is directly related to the network distance between AWS and the DSM SaaS service.

Tests using a distributed. ICMP Ping service1 suggest:

• Between 1 and 20 milliseconds between continental US POPs and amer.smartkey.io
• About 1 millisecond from continental Europe to eu.smartkey.io
• 40-50ms between various Asia-Pacific countries and apac.smartkey.io
• Sub-millisecond between Sydney and au.smartkey.io.

Of course, these numbers may vary depending on network conditions.

Fortanix has no control over KMS or the services that use it, and no insight into how long those services keep the keys that they are served.

While we have observed that some services do cache their keys for a short time, Fortanix has no control over this behavior.