AWS solutions - CloudHSM vs KMS
- Denisse Soker
- 2020-16-06
- 3 minute read
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:
Cloud HSM |
KMS |
|
Tenancy |
Single-Tenant |
Multi-Tenant |
Crypto Keys |
-Symmetric – AES (Modes supported CBC, GCM and ECB) -Asymmetric – RSA, ECC -Hashing – SHA-256, SHA-512, RSA, ECDSA |
-Symmetric -Asymmetric -AES in XTS mode only |
Access and Authentication Policy |
Quorum based K of N principle |
AWS IAM Policy |
Crypto API |
PKCS#11 standard APIs, open SSL, Java cryptography, Microsoft CNG and Oracle TDE |
AWS SDK/APIs designated for KMS |
Key Accessibility |
Can be accessed and shared across multiple VPC |
Accessible in multiple regions (Keys outside the region in which created cant be used) |
High Availability |
Create various HSMs in different AWS Availability Zones |
AWS Managed Service |
Audit Capability |
CloudTrail Cloud Watch MFA support |
CloudTrail Cloud Watch |
- 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:
Cloud HSM |
KMS |
|
FIPS |
CloudHSM is built on hardware that is validated at Federal Information Processing Standard (FIPS) 140-2 Level 3 |
KMS uses FIPS 140-2 validated HSMs. It also allows requests to API endpoints that terminate TLS sessions using a FIPS 140-2 validated cryptographic software module. |
PCI-DSS |
Answers concerns raised in relevant clauses - 3.5.1 (restriction of access) and 3.5.2 |
Having KMS responsible for both DEK and KEK, both concerned with clear-text does not satisfy the same requirements. |
HIPAA and HITECH |
No requirement to protect encryption keys |
Not inherently compliant - relevance to each service has to be considered. |
Additional Challenges
Taking all the said above in mind, when managing a Hybrid Multi-Cloud environment one must consider the following factors on top:
When adopting vendor based solutions you need to deal with:- 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.