Common Key Management System Models for the Cloud

In this pattern, the public or private cloud service expands upon the Cloud Native Key Management System by allowing key material to be imported from the customer’s on premise key management system and hardware security module (HSM). This model reflects the basic expectations of “bring your own key” (BYOK), which is supported by Cryptomathic CKMS.

(C) Cloud Service Using External Key Management System

In this pattern, the public or private cloud service has a cloud key management system with a private, dedicated hardware security module (HSM) that is under the control of the customer but is hosted physically within the cloud provider’s data center, by a third-party or a combination of both. The customer has an on premise key management system, such as Cryptomathic’s CKMS and a private HSM.

(D) Multi-Cloud Key Management Systems (MCKMS)

In this pattern, the customer has an on premise key management system that is used for multi-cloud KMS integration/management. The public or private cloud contains a private hardware security module (HSM). Cryptomathic’s CKMS can be hosted in the cloud or on premise and is linked to a cryptographic module on premise.

Cryptomathic’s Approach to Providing Banking-Grade Security and Compliance

To provide flexible banking-grade security and compliance, Cryptomathic’s Cryptographic Key Management System (CKMS) is able to support the B, C and D models of key management. If privacy and real ownership of key usage is paramount, then models C and D would be the appropriate choice.

Below we explore these two patterns further and how customers can benefit from using CKMS in either of these two scenarios.

Cloud Service Using External Key Management System

As previously stated, the External Key Management System uses a cloud service, but the key management system is hosted outside of the cloud service either on the customer’s premises, by a third party that the customer has chosen, or a combination of both. Regardless of whether the customer or cloud provider owns the hardware, it is provisioned for the sole use of the customer. The cloud provider may provide support for a dedicated cloud hardware security module (HSM) or a co-location model where the customer’s hardware is hosted.

The customer manages the key management system and agrees to the cloud provider's service-level agreement considerations in the event of a service incident caused by the KMS. In order to achieve complete data privacy from the provider, no key wrapping or unwrapping can be performed by the CSP.

Benefits of this Model

There are numerous benefits to adopting the External Key Management System model including:

• Customers maintain a high degree of control where they know and can configure protocols, key lengths, and algorithms
• Separation of duties for KMS and cloud service activities, in addition to activities within CKMS are supported
• Key material is never shared with the cloud provider
• Improved portability because most, if not all key management functions are conducted outside the cloud
• Complete freedom to add or remove patterns
• Provides customer-driven FIPS compliance for all keys
• Requirements for customer key generation are met

Challenges and Strengths of this Model

Yes, there are challenges to choosing an External Key Management System. It is not used as often as other patterns and some cloud providers may not be able to accommodate it. This model is typically incompatible with SaaS or other services where the cloud provider’s systems must process customer data in plaintext, which goes against keeping the customer’s data secret. However, Cryptomathic’s CKMS strengths focus on cloud solutions like Microsoft Azure, which is able to manage encrypted data in the symmetric key infrastructures without compromising key security.

When Should External Key Management Be Chosen?

It is recommended that the External Key Management model be chosen when:

• The cloud provider does not have a native KMS
• The customer wants a single KMS to use on-premises and in the cloud
• It is required to keep plaintext private from the cloud provider
• A higher level of FIPS certification is needed

This is typically the case for all companies and institutions handling critical or sensitive data, like banks, governments, manufacturing organizations, providers of connected mobility, etc. 

Multi-Cloud Key Management Systems

The Multi-Cloud Key Management Systems model allows for blended approaches controlled by a central and external KMS.  

There are multiple benefits to choosing the Multi-Cloud Key Management Systems model, including:

• Attributing factors such as implementation time, cost, control, complexity, performance, scale, and interoperability as functions of other implemented cloud KMS patterns
• Allows for cloud-scale fault-tolerance because it provides the ability to leverage one cloud’s KMS as a backup to another cloud’s KMS
• Can help encourage fast adoption of additional cloud services because of the investment in resources and expertise
• Data can migrate between various clouds and data-centers, but still managed by one central key management system which is in control of the data owner
• The data owner can conduct compliance audits from the central locations of the key management system.
  
  

Challenges and Strengths of this Model

The Multi-Cloud Key Management System model is typically reserved as a more strategic approach to key management. It does require a greater level of expertise, more time to design and implement, and a greater investment in operational and/or licensing costs. But aside from these challenges, this model provides the greatest degree of fault tolerance, portability, and scalability because the customer is leveraging multiple public cloud providers. And typically it emerges over time, often starting with a local data center approach, then progressively expanding to various clouds - without changing the security architecture.

When Should the Multi-Cloud Key Management System Be Chosen?

It is recommended that the Multi-Cloud Key Management System be chosen when the customer:

• Needs a higher level of resilience and scalability
• Requires flexibility due to their organization’s dynamic composition if it has frequent acquisitions or divestitures
• Must meet complex compliance requirements for security data
• Has mature technology architectures

References and Further Reading

• Key Management in Cloud Services: Understanding Encryption’s Desired Outcomes and Limitations (October, 2020), by the Cloud Security Alliance
• Key Management Guidelines, SP 800-57 (May 2020), by NIST

• Selected articles on Bring Your Own Key (2017 - today), by Matt Landrock, Stefan Hansen, Ulrich Scholten and more

• Selected articles on Key Management (2012-today) by Dawn M. Turner, Guillaume Forget, Peter Landrock, Peter Smirnoff, Stefan Hansen and more
• Selected articles on Key Management in the Cloud (2017-today) by Edlyn Teske, Matt Landrock, Rob Stubbs, Stefan Hansen, Ulrich Scholten, Joe Lintzen and more

• CKMS Product Sheet (2016), by Cryptomathic