AWS CloudHSM

Key Features & Concepts

Single-Tenant, Dedicated Hardware: Unlike shared services, you get your own HSM instances. No other AWS customers have access to the hardware you are using.
FIPS 140-2 Level 3 Validation: CloudHSM is validated at Level 3, a higher security standard than AWS KMS (which is Level 2). Level 3 includes mechanisms for tamper detection and response, providing a higher degree of assurance.
Customer-Controlled Keys: You have complete and exclusive control over the entire lifecycle of your keys, from generation to management and deletion. AWS personnel have no visibility or access to your keys.
High Availability and Durability: You provision CloudHSM instances in a cluster that spans multiple Availability Zones (AZs). The cluster automatically load-balances requests and provides redundancy. The service also performs automated, encrypted backups of your HSM contents to Amazon S3.
Standard Cryptographic APIs: Your applications connect to the HSM using standard libraries, including PKCS#11, Java Cryptography Extension (JCE), and Microsoft CryptoNG (CNG).

Provision a Cluster: You start by creating a CloudHSM cluster within your Amazon VPC. You specify the VPC and subnets (in different AZs) where the HSMs will be located.
Initialize the Cluster: After provisioning, you are responsible for initializing the cluster. This involves setting passwords and creating the initial set of users.
Manage Users: HSM users are completely separate from AWS IAM users. They are managed using command-line tools like the CloudHSM Management Utility (CMU). The key roles are:
- Crypto Officer (CO): The administrator of the HSM. Manages users, sets policies, and performs high-level key management tasks.
- Crypto User (CU): The "application user." A CU can access and use the keys to perform cryptographic operations like encrypting, decrypting, signing, and verifying.
Application Integration: Your applications (e.g., running on EC2 instances in the same VPC) use a client daemon and cryptographic libraries to connect to the HSM cluster's endpoint and perform operations.

CloudHSM is a specialized service. Use it when you have a specific requirement that can't be met by AWS KMS.

Meet Strict Compliance: Satisfy regulations that mandate the use of single-tenant, FIPS 140-2 Level 3 validated HSMs.
SSL/TLS Offloading: Offload the processing for SSL/TLS connections from your web servers to the HSM for enhanced security.
Protect Certificate Authority (CA) Keys: Securely store the highly sensitive private keys for your own private CA.
Transparent Data Encryption (TDE): Store the master keys for database encryption, such as TDE for Oracle databases.
Digital Rights Management (DRM): Protect the keys used to encrypt and decrypt media content.

Choosing between CloudHSM and KMS is a critical decision based on your specific needs.

| Feature | AWS CloudHSM | AWS Key Management Service (KMS) |

| :-------------- | :-------------------------------------------------------- | :------------------------------------------------------------- |

| Tenancy | Single-Tenant (Dedicated HSM for you) | Multi-Tenant (Shared hardware, logically isolated) |

| Validation | FIPS 140-2 Level 3 | FIPS 140-2 Level 2 |

| Key Control | Full control by you inside the HSM; AWS has no access. | You control key policies via IAM; AWS manages the key material. |

| Use Case | Strict compliance, direct application control (PKCS#11). | General-purpose encryption, easy integration with AWS services. |

| Management | Complex: You manage the cluster, users, and keys. | Simple: Fully managed service with easy-to-use APIs. |

| API | Standard libraries (PKCS#11, JCE, CNG). | AWS SDK/API. |

You are billed an hourly rate for each HSM instance you have provisioned in your cluster.
There are no upfront costs for the hardware. You pay as you go for the time the HSMs are active.