Encryption is only as secure as the location of the encryption keys used to decipher it. Who has administrative access to the keys? Do you have exclusive control or is access shared with the cloud provider? These are some of the questions that individuals tend to ask themselves to define the way they want to manage their secrets. Fortunately, encryption key management solutions are more affordable and easier than ever - but, with that said, not all solutions are created equal - and the differentiating factors are crucial when the data you plan to migrate was classified as highly confidential.

In this blog post we’ll review AWS solutions - KMS and CloudHSM

AWS KMS

AWS KMS is a managed service that allows handling select key management lifecycle processes - creation, usage and management of encryption keys within your own applications via AWS SDK or supported AWS services (like S3, EBS, RDS, Redshift) . AWS KMS facilitates a two-tiered envelope encryption operational model using master Key (Customer Managed Key or AWS Managed Key – Default Key) and data keys. Master keys encrypt data keys used for encryption. Master keys supposedly do not leave AWS KMS service. AWS relies on IAM services to define and assign policies for users and roles to create, manage, use and delete keys. As KMS is a managed service,it manages the rotation of keys and assures highly available key storage for management via AWS IAM service and Key auditing through AWS CloudTrail services.

Change of certificates, re-encryption of storage and installing boot keys on new servers are only a few of the tasks that need to be done when key management processes are manually managed in-house. Service-managed keys can give you the assurances of per tenant and per subscription keys, with segregation of duties and auditing, without the headache of ongoing management - this means that the cloud provider is in full control of your encryption procedures

Cloud HSM

Cloud HSM is a physical appliance hosted in a secure cloud with real-time encryption key and access policy mirroring. Dedicated HSMs are hosted in geographically dispersed data centers under an ITIL-based control environment and are independently validated for compliance against PCI DSS and SOC frameworks.

CloudHSM is customer-owned and managed. AWS owns the responsibility of provisioning the HSM in the customer's VPC environment in AWS. In AWS CloudHSM, you create and manage HSM clusters, including creating users and setting their permissions. You also create the symmetric keys and asymmetric key pairs that the HSM stores.

The fundamental problem of an on-premises HSM is its limited scalability - because physical placement of additional HSMs across an organization’s multiple dispersed locations to accommodate increased data processing or geographic expansion can be untenable from a logistical or CapEx perspective. This is something that AWS CloudHSM definitely addresses.

Comparison

When solely comparing AWS KMS vs Cloud HSM one can look at the following factors:

• KMS is shared hardware tenancy - you keys are in their own partition of an encryption module shared with other AWS customers, each with their own isolated partition. Cloud HSM gives you your own hardware module, within a single-tenant storage.
• Outsourcing key management and cryptographic operations to a certified hardware appliance does not guarantee that the application architecture meets security or availability requirements. Most security vulnerabilities in networked applications stem from failures of input validation or error handling and even properly implemented crypto can be misused.
• API support and integration wise for KMS is done through AWS SDK/APIs designated for KMS while CloudHSM supports - PKCS#1 standard APIs, open SSL, Java cryptography, Microsoft CNG and Oracle TDE

Compliance

From a regulation point of view, there are several factors to consider when adopting one of AWS solutions:

Additional Challenges

Taking all the said above in mind, when managing a Hybrid Multi-Cloud environment one must consider the following factors on top:

• Separate updates and patches
• Separate SDKs and APIs
• Separate functionality and features and a different way of adding on custom modules/clusters for each.
• Processing of secrets, updates and maintenance is deferred to the cloud vendor or 3rd parties that provide the HSM service
• There is no set way to manage several different HSMs from different vendors in a single interface.
• Integrating existing HSM infrastructure with the cloud environment requires utilizing cloud-vendor SDKs - taking the additional R&D resources into consideration when planning a data protection strategy in the cloud is crucial.

Kindite solves these hurdles while allowing a unified solution which enables seamless integration to existing on-premise or cloud HSMs.

To learn more about Kindite click here.