On November 29, 2022, AWS announced the eXternal Key Store (XKS) capability for AWS Key Management Service (KMS). It allows customers who have a regulatory need to store and control their encryption keys on-premises or outside of the AWS cloud to do so through AWS KMS. As a result, customers can use their existing hardware security module (HSM) infrastructure to effectively store and manage their AWS KMS Customer Managed Keys (CMKs) on-premises or at any location of their choice.

Customers are therefore able to easily encrypt data with externally managed keys with their applications and more than 100 AWS services.

In a previous blog titled Ownership, Control, and Possession – A New AWS Feature For Key Management with the Cloud, we focused on AWS KMS XKS integration with the Entrust enterprise key and secrets management solution KeyControl. In this blog, we’ll provide more detail relating to the AWS KMS XKS integration directly with an Entrust nShield HSM.

AWS Cloud

When data is encrypted for a customer within AWS, a unique data encryption key is generated, which is then encrypted with a CMK following a scheme known as envelope encryption. XKS enables this CMK to be protected and managed externally, such as within a tamper resistant and FIPS 140-2 Level 3 or FIPS 140-3 Level 31 certified HSM.

Instead of storing and managing the CMKs entirely within AWS KMS, with XKS they are additionally encrypted by an external key which resides and remains entirely outside the AWS cloud and under the sole control of the customer organization.

Customers are responsible for providing and managing the infrastructure necessary to securely hold and manage such external keys themselves, which does introduce an additional operational burden and some greater risks to availability and performance. However, this can enable cloud use cases for several regulated workloads where encryption keys are required to be directly held by specific organizations and/or in particular geographic jurisdictions.

Controlling access to these externally managed CMKs provides for a customer “break glass” capability so that they can easily control access and use of CMKs supplied to their applications and other AWS services. By disabling or removing access to the externally stored key, data within the cloud can be rendered inaccessible on a temporary or permanent basis.

Customers have two options for building infrastructure to integrate with AWS KMS XKS:

  • Customers can use an AWS KMS XKS proxy, which is provided as sample code online. This option uses the Public Key Cryptography Standards (PKCS)#11 interface in order to support any compatible hardware security module. Entrust nShield HSMs integrate with PKCS#11 compatible applications and are already deployed within organizations and enterprises for keeping their cryptographic key material protected on-premises.
  • Several organizations (including Entrust) offer multi-cloud key management systems, that can interface with a number of cloud service providers (CSPs), including AWS, for importing and managing CMKs using a Bring Your Own Key (BYOK) approach, as well as enabling usage of CMKs through XKS with the Hold Your Own Key (HYOK) approach. These provide customers with a comprehensive lifecycle management capability and a single platform for consistent operations of multiple key types across an organization. Typically, they also use an HSM for protecting the keys within such system.

Using Entrust nShield HSMs in conjunction with an AWS KMS XKS proxy can be straightforwardly achieved using a suitable configuration file that references the PKCS#11 library, allowing the proxy code to work with any number of nShield Security World AES-256 keys. For increased availability, and to maintain the continued operation of applications and integrated AWS Services dependent on XKS managed CMKs, it is recommended to deploy the AWS KMS XKS proxy and nShield HSMs in multiple locations or geographies.

With either deployment type, internet bandwidth requirements will need to be measured, monitored, and accommodated to ensure that any network bottlenecks introduced using the AWS KMS XKS proxy or key management system do not impede or impact the operation of applications running on AWS.

Not all data classification categories will require external storage of keys, so AWS recommend only using this capability for scenarios where there is a regulatory or compliance need – for example, keep minimal data protected by XKS to meet requirements, but continue using AWS KMS CMKs for the rest of your data. It is important to remember that if an external key is permanently lost or deleted, any ciphertext encrypted under the associated KMS keys will be unrecoverable.

So, if you are already using AWS services and thinking about utilizing their KMS XKS capability or are planning to migrate to the cloud in the near future and are concerned about the impact of the control of your cryptographic keys, consider Entrust nShield HSMs in conjunction with AWS KMS XKS.

Note 1: nShield 5c and 5s FIPS 140-3 certifications currently FIPS pending (In coordination)