AWS KMS vs CloudHSM

Let’s talk about CloudHSM, also doing a comparative, AWS KMS vs CloudHSM. In my previous post, we cover a lot about AWS KMS, and examples of how to use the command line.

So we have situations where data protection solutions that handle encryption keys or digital signatures demanding the use of private keys are critical.

What is AWS CloudHSM?

Hardware Security Modules or HSMs provide a tamper-resistant environment for handling these keys.

In this article, we’re going to discuss CloudHSM, which is an Amazon product too, and similar to KMS.

Two situations where your encryption keys are subordinate to corporate or regulatory requirements and therefore require validated authority.

Thus CloudHSM is a dedicated hardware security module product.

It adjusts to FIPs 140-2 level 3.

The FIPS is a U.S. Government computer security standard.

That’s used to validate cryptographic modules, and it has diverse different agreement levels.

So, compliance level 3 is where physical protection mechanisms might require the use of vital information and tamper detection or response systems that zero out the whole of your plain text cryptographic protection providers when the removable doors or protection of the cryptographic module within opened up.

Besides that, remember when we discussed KMS? KMS is level two compliant, which means it requires to exhibit proof of tampering.

What is the difference between the KMS and CloudHSM?

The difference between KMS and CloudHSM is that you control your keys with CloudHSM.

CloudHSM gives a single-tenant multi-AZ cluster, and it’s exclusive to you.

KMS is multitenant; however, it uses HSMs within, but those are distributed over customer accounts, so it’s not exclusive only for you.

So, because it’s a managed service, you don’t possess any access to the AWS-managed component of CloudHSM.

Instead, you hold control above your access keys, and AWS themselves don’t have any access to your keys, and CloudHSM works inside a VPC in your account.

We’ll talk more about the architecture in just a second.

CloudHSM API

So like I said, CloudHSM is a single-tenant dedicated hardware solution that works in a multi-AZ cluster for high availability. It additionally operates with industry-standard APIs. Unfortunately, there are no AWS APIs available for CloudHSM.

So if you have software productions that demand compliance with PKCS11, Java cryptography extensions (JCE), or Microsoft crypto (NG), CloudHSM is the product for you.

Furthermore, see that you have to hold your keys secure with CloudHSM.

If you lose your keys, they’re unrecoverable.

Then now, let’s analyze the architecture for CloudHSM.

How is CloudHSM Deployed

You primary need to build a cluster either on your current VPC or a new VPC. So how this operates is that CloudHSM will work inside its VPC, devoted to CloudHSM from a safety isolation viewpoint, CloudHSM will extend ENIs or elastic network interfaces within the VPC of your choice.

And this is how your applications interact with the CloudHSM cluster within which you’ll build particular instances of HSMs.

It’s worth remembering that CloudHSM is not highly available by default.

You’ll need to provision HSMs over availability zones explicitly.

CloudHSM use cases: CloudHSM Multi AZ

The CloudHSM on multi-AZ cluster for high availability

If any of these HSMs fail or AZ becomes unavailable, you’ll yet have the other HSM instances.

The best approach, you’ll want to put one HSM by a subnet in each availability zone with a minimum of 2 AZs, as you notice on the diagram above, which is what’s prescribed by AWS.

Conclusion

You know now that if you have severe regulatory compliance obligations or FIPs 140-2 level 3 for your environment or product, you’ll plausibly need to pick CloudHSM.

In our topic AWS KMS vs CloudHSM, we saw that those services are almost equal.

So that’s about all I needed to cover on CloudHSM. If you have any comments, feel free to reach out.