# Data Encryption at Rest with KMS and CloudHSM

> Chapter 4 of the Courseiva AWS-SECURITY-SPECIALTY curriculum — https://courseiva.com/learn/aws-security-specialty/data-encryption-at-rest

**Official objective:** 2.1 — Design and implement encryption at rest

## Introduction

Data encryption at rest. It is the single most important security control for any organisation storing sensitive data in the cloud. For the SCS-C02 exam, you must understand how AWS encrypts data while it is stored on disk, and the two main services that do it: AWS Key Management Service (KMS) and AWS CloudHSM.

## The 17-Drawer Filing Cabinet Analogy

4 key parts of your house each have their own lock. You have 4 keys: one for the front door, one for the back door, one for your bedroom, and one for your safe. Your parents have a master key ring that opens all 4 locks, but they only use it when you are not home. They also have a separate key for the safe that only they can use. You are AWS Key Management Service (KMS) – you create and manage keys, each key for a different lock, and you hand out temporary copies of your keys to trusted cleaners who need to clean specific rooms. Your parents are AWS CloudHSM – they control a single, super-secure master key ring that never leaves their pocket, and they never give anyone a copy of the safe key.  

 Now imagine a thief breaks in. With KMS, the thief could steal your key ring and unlock everything because you gave out key copies. With CloudHSM, the thief cannot steal the safe key because it never left your parents' pocket – they only use it to lock or unlock the safe when you ask them to, in their own secure room.

## Core explanation

Imagine you write a secret message on a piece of paper and put it in a locked safe. The paper is your data. The lock on the safe is encryption. The key that opens the lock is a cryptographic key – a long, random number used to scramble (encrypt) or unscramble (decrypt) your data.  

 Encryption at rest means your data is scrambled while it sits on a hard drive or in a database. If an attacker steals the physical drive, they only see gibberish. They cannot read your data without the correct key.  

 AWS offers two main services to manage these keys: KMS and CloudHSM. Both encrypt data, but they differ drastically in how they protect the keys themselves.  

 First, KMS (Key Management Service). KMS is a fully managed service. AWS creates, stores, rotates, and deletes your encryption keys for you. You never see the key material – the actual random number. You only interact with the key through an Amazon Resource Name (ARN), a unique identifier. KMS uses Hardware Security Modules (HSMs) – specialised hardware – to protect the keys, but AWS manages those HSMs. You pay per key and per API call (each request to encrypt, decrypt, or re-encrypt).  

 KMS keys are regional. A key created in us-east-1 cannot decrypt data encrypted in eu-west-1 unless you explicitly replicate the key. This is called regional isolation. KMS also integrates with many AWS services such as S3, EBS, RDS, and Lambda – you can enable encryption with just a checkbox in the console.  

 Second, CloudHSM (Hardware Security Module in the cloud). CloudHSM gives you a dedicated HSM appliance that only you control. AWS provisions the hardware, but you manage the keys, the users, the policies, and the HSMs. CloudHSM uses a different key hierarchy. You generate keys inside the HSM itself. The private key – the most sensitive part – never leaves the HSM in plaintext. You interact with the HSM through industry-standard APIs like PKCS#11 (Public-Key Cryptography Standard #11), a standard interface for cryptographic tokens.  

 The main difference: with KMS, AWS controls the HSMs that protect your keys. With CloudHSM, you control the entire HSM, including the keys inside. This is the key distinction for the exam.  

 Why does this matter? Regulatory compliance often requires you to control the hardware that stores your keys. For example, the Payment Card Industry Data Security Standard (PCI DSS) for credit card data sometimes demands that the organisation itself manages the hardware security module. CloudHSM satisfies that requirement; KMS does not.  

 Now, how do these services actually work in practice?  

 KMS uses a two-tier key hierarchy:  
- Customer master key (CMK) – the top-level key stored in KMS. You create and manage this key. It never leaves KMS.  
- Data key – an encryption key generated by KMS when you ask for one. The data key is a temporary key used to encrypt your actual data (files, databases, etc.). KMS encrypts the data key with the CMK before handing it back to you. You store the encrypted data key alongside your data. When you need to decrypt, you send the encrypted data key back to KMS, which decrypts it with the CMK and returns the plaintext data key. This way, the CMK itself is never exposed.  

 CloudHSM does not use a two-tier hierarchy. You define your own. You typically generate a key inside the HSM, then use that key to encrypt data directly. The HSM enforces who can use the key based on user credentials (CU – Crypto User accounts).  

 For the SCS-C02 exam, focus on understanding:  
- What each service does (KMS: managed, CloudHSM: dedicated).  
- When you use each (KMS: default for most AWS services; CloudHSM: when compliance demands dedicated hardware).  
- The key management differences (AWS controls the HSM in KMS; you control it in CloudHSM).  
- How key rotation works (KMS can rotate automatically; CloudHSM requires manual rotation).  
- Integration limits (KMS integrates with dozens of AWS services; CloudHSM integrates with fewer, typically older databases and custom applications).

## Real-world context

A healthcare company called MedSecure needs to store patient health records in AWS S3. They must comply with HIPAA (Health Insurance Portability and Accountability Act), which requires encryption at rest and strict control over encryption keys.  

 Step 1: MedSecure's IT team creates a KMS key in the us-east-1 region. They enable automatic rotation so that every year, KMS generates a new cryptographic key material but retains the old one to decrypt old data. They then apply an S3 bucket policy that denies any request that does not use encryption – specifically, server-side encryption with KMS (SSE-KMS).  

 Step 2: When a doctor uploads a patient record, S3 calls KMS, asking for a data key. KMS generates a new data key, encrypts it with the CMK, and sends back both the plaintext and ciphertext (encrypted) versions. S3 uses the plaintext data key to encrypt the object, then immediately discards the plaintext version. S3 stores the ciphertext data key as metadata alongside the object.  

 Step 3: When a nurse downloads the record, S3 sends the encrypted data key back to KMS, which decrypts it and returns the plaintext data key. S3 uses that key to decrypt the object for the nurse. The nurse never sees the key.  

 Step 4: MedSecure is audited. The auditor asks: 'Show us that you control the hardware that stores the keys.' MedSecure realises that KMS is insufficient because AWS controls the underlying HSM. They purchase an AWS CloudHSM cluster.  

 Step 5: MedSecure creates a CloudHSM cluster with two HSMs in two different Availability Zones for high availability. They configure a Crypto Officer (CO) user and a Crypto User (CU) user inside the HSM. The CO user generates a key inside the HSM. The key never leaves the HSM in plaintext.  

 Step 6: Applications that need to encrypt or decrypt data send API calls to the CloudHSM cluster using the PKCS#11 interface. The HSM performs the cryptographic operation inside its own hardware and returns only the result.  

 The day-to-day tasks of the MedSecure IT professionals include:  
- Monitoring CloudWatch logs for KMS key usage (who accessed which key).  
- Rotating KMS keys manually if automatic rotation is not enabled (not needed here).  
- Backing up CloudHSM keys by exporting them in an encrypted form (using a different key).  
- Replacing a failed HSM in the CloudHSM cluster.  
- Ensuring that IAM policies for KMS are least-privilege (e.g., only specific IAM roles can decrypt specific keys).

## Exam focus

The SCS-C02 exam tests encryption at rest heavily. Expect around 8-12 questions on KMS and CloudHSM across the whole exam. The exam specifically tests your ability to choose between KMS and CloudHSM based on compliance requirements, key control, and integration needs.  

 Key concepts tested:  
- KMS key types: Customer managed key, AWS managed key, AWS owned key. Know the difference. Customer managed keys are created and managed by you. AWS managed keys are created and managed by AWS on your behalf (e.g., aws/s3). AWS owned keys are used by multiple AWS accounts – you cannot view or manage them.  
- KMS key hierarchy: CMK (master key) and data keys. Know how data keys are used to encrypt large objects. The exam loves asking: 'What is the best way to encrypt a 1 GB file with KMS?' The answer: Use KMS to generate a data key, encrypt the file with the data key, then discard the data key.  
- Envelope encryption: This is the same as the two-tier hierarchy. The CMK encrypts the data key. The data key encrypts the data. The exam often asks: 'Why does KMS use envelope encryption?' Answer: To protect the CMK and to efficiently encrypt large amounts of data.  
- Key rotation: Automatic rotation is enabled only for customer managed keys. AWS managed keys rotate every year automatically. Know that old key material is retained to decrypt old data.  
- Cross-account access: KMS keys cannot be used directly across accounts. You must create a key policy that grants access to another account's IAM role. The exam tests this with scenarios.  
- CloudHSM vs KMS differences: CloudHSM gives you control over the hardware; KMS does not. CloudHSM supports FIPS 140-2 Level 3; KMS supports Level 2 overall (though some HSMs behind KMS are Level 3). CloudHSM requires you to manage users, keys, and backups; KMS is fully managed.  
- Integrating with services: KMS integrates with S3, EBS, RDS, Lambda, and many others. CloudHSM integrates with Oracle databases, custom applications, and legacy systems. The exam might ask: 'Which service can you use to encrypt an EBS volume?' Answer: KMS (EBS encryption with KMS is native).  
- Key policies versus IAM policies: Key policies control who can use the key directly. IAM policies grant permissions to users and roles, but you also need a key policy to allow IAM policies. The exam tests the interplay.  
 
 Traps the exam sets:  
- They might describe a scenario where you need to encrypt data at rest for a legacy Oracle database with strict compliance requirements. Many candidates pick KMS because it is easier, but the correct answer is CloudHSM because the database may require dedicated HSMs for TDE (Transparent Data Encryption).  
- They might ask: 'You need to encrypt 100 TB of data. What is the most cost-effective way?' The answer is to use S3 default encryption with SSE-KMS or SSE-S3, not to manually encrypt with a single CMK.  
- They might test regional isolation: 'A key created in us-east-1 can decrypt data in eu-west-1.' False unless you replicate the key.  
- They might test key rotation with a trick: 'KMS rotates the key, and the old key is deleted after 30 days.' False – old key material is retained indefinitely for decryption.  

 Definitions to memorise:  
- Envelope encryption: encrypting a data key with a master key.  
- CMK: the master key in KMS.  
- Data key: a temporary key used to encrypt data.  
- HSM: a tamper-resistant hardware device that stores cryptographic keys.  
- FIPS 140-2: a US government security standard for cryptographic modules. Level 2 requires tamper evidence; Level 3 requires tamper detection and identity-based authentication.

## Step by step

1. **Create a KMS Customer Managed Key (CMK)** — You log into the AWS Console, navigate to KMS, and create a symmetric key. You choose key type (symmetric is used for most encryption at rest). You also define a key policy that determines which IAM roles and users can use this key.
2. **Enable Automatic Key Rotation** — You enable automatic annual rotation. KMS generates new cryptographic key material for the same CMK but retains the old material. This ensures that new data is encrypted with a fresh key while old data remains decryptable.
3. **Encrypt an S3 Bucket Using SSE-KMS** — In the S3 console, you set the default encryption of your bucket to 'AWS-KMS' and choose the CMK you created. Every object uploaded will automatically be encrypted using KMS-generated data keys, without any application code changes.
4. **Download and Decrypt an Object** — When a user or application requests the object, S3 sends the encrypted data key from the object's metadata to KMS. KMS decrypts it with the CMK and returns the plaintext data key. S3 uses that key to decrypt the object and returns the plaintext to the user.
5. **Provision a CloudHSM Cluster (Alternative)** — If compliance requires dedicated hardware, you launch a CloudHSM cluster in your VPC. You initialise the HSM with a security officer password, create Crypto User (CU) accounts, and generate keys inside the HSM. The private key never leaves the HSM.
6. **Use CloudHSM with an Application** — Your application uses the PKCS#11 library to communicate with the HSM. When encrypting data, the application sends the plaintext to the HSM, which encrypts it inside the hardware and returns the ciphertext. The key is never exposed to your application.

## Comparisons

### KMS vs CloudHSM

**KMS:**
- Fully managed by AWS – you only interact via API.
- Key material is stored in multi-tenant HSMs that AWS controls.
- Integrates natively with over 50 AWS services out of the box.

**CloudHSM:**
- You provision and manage a dedicated HSM appliance.
- Key material never leaves your single-tenant HSM in plaintext.
- Integrates with custom applications and legacy databases via PKCS#11.

### Symmetric CMK vs Asymmetric CMK

**Symmetric CMK:**
- Same key used to encrypt and decrypt.
- Ideal for encrypting large volumes of data (envelope encryption).
- Cannot be exported – key material stays in KMS.

**Asymmetric CMK:**
- Uses a public key for encryption and a private key for decryption.
- Used for digital signatures or encrypting data where the public key is shared.
- Public key can be downloaded; private key never leaves KMS.

### Automated Key Rotation in KMS vs Manual Key Rotation in KMS

**Automated Key Rotation in KMS:**
- AWS rotates the key material annually with no intervention.
- Old key material is retained indefinitely for decryption.
- Cannot specify a custom rotation schedule (only annual).

**Manual Key Rotation in KMS:**
- You create a new CMK and re-encrypt data keys with the new key.
- Old key remains active until you retire it after re-encryption.
- Provides full control over the rotation schedule and key lifecycle.

### KMS Key Policy vs IAM Policy

**KMS Key Policy:**
- Attached directly to the CMK – controls who can use the key.
- Needed for cross-account access to the key.
- Can grant permissions to users outside your AWS account.

**IAM Policy:**
- Attached to IAM users or roles – controls their overall permissions.
- Requires a key policy to be usable – the key policy must allow IAM policies.
- Cannot grant cross-account access to a key on its own.

## Diagram

_This diagram shows the envelope encryption flow: KMS generates a data key (plaintext and encrypted), the plaintext version encrypts the data, and the encrypted version is stored alongside. Decryption reverses the process._

```mermaid
flowchart TD
    A[User Application] -->|Encrypt request| B[KMS API]
    B --> C[CMK stored in HSM]
    C --> D[Generate Data Key]
    D --> E[Encrypted Data Key]
    D --> F[Plaintext Data Key]
    F --> G[Encrypt Data in S3/EBS/RDS]
    G --> H[Ciphertext stored on disk]
    E --> H
    H -->|Decrypt request| B
    B --> C
    C --> I[Decrypt Data Key]
    I --> J[Return Plaintext Data Key]
    J --> K[Decrypt Ciphertext]
    K --> L[Plaintext Data to User]
```

## Common misconceptions

- **Misconception:** KMS and CloudHSM do the same thing, so you can use either interchangeably. **Reality:** KMS is a managed service where AWS controls the underlying HSM. CloudHSM gives you dedicated, single-tenant HSMs that you control. They are not interchangeable for compliance requirements that demand dedicated hardware. (Both services encrypt data with HSMs, so beginners assume they are identical. The difference in control and compliance is subtle but critical for certifications.)
- **Misconception:** KMS allows you to download the cryptographic key material for your CMK. **Reality:** KMS never exposes the plaintext key material of a CMK to you. You can only obtain an encrypted copy of the key material for backup purposes, under strict conditions. (People think 'my key' means they can see the actual bits. In KMS, 'your key' means you control the policy and lifecycle, but AWS stores the key securely.)
- **Misconception:** CloudHSM is easier to use than KMS because it does not require any setup. **Reality:** CloudHSM requires significant setup: you must initialise the HSM, create users, generate keys, and manage network connectivity. KMS is far simpler to use out of the box. (Beginners hear 'fully managed' for KMS and 'dedicated' for CloudHSM and incorrectly assume CloudHSM is a plug-and-play appliance. It is actually more complex to operate.)
- **Misconception:** If you use KMS, AWS can decrypt your data if they want to. **Reality:** AWS cannot decrypt your data because the CMK is encrypted with a tenant-specific key that is itself protected by the HSMs. AWS admins have no direct access to the plaintext key material. (Because AWS manages the HSMs, people worry about insider threats. In reality, the service is architected so that even AWS employees cannot see your keys.)
- **Misconception:** Encryption at rest only applies to data stored in databases, not to file systems or backups. **Reality:** Encryption at rest applies to any data stored on persistent media: hard drives, SSDs, backups, snapshots, and databases. AWS services like S3, EBS, RDS, and Glacier all support encryption at rest. (Beginners often think of encryption as something for databases only, but storage services like S3 and EBS are more common targets for encryption.)

## Key takeaways

- KMS uses envelope encryption: a customer master key (CMK) encrypts data keys, which then encrypt your actual data.
- CloudHSM provides dedicated, single-tenant hardware security modules that you control, meeting stricter compliance requirements like PCI DSS.
- KMS integrates natively with over 50 AWS services; CloudHSM integrates with custom applications and legacy databases via industry-standard APIs.
- KMS keys are regional and can only be used in the same region unless explicitly replicated.
- Automatic key rotation is only available for customer-managed KMS keys, and old key material is always retained to decrypt existing data.
- KMS key policies and IAM policies both control access to a CMK, and you must configure both for cross-account access.
- CloudHSM keys never leave the HSM in plaintext, providing the highest level of key protection for compliance.

## FAQ

**What is the difference between KMS and CloudHSM?**

KMS is a fully managed encryption service where AWS controls the HSMs. CloudHSM gives you a dedicated HSM that you control. Use KMS for most AWS services; use CloudHSM when compliance requires you to manage the hardware.

**Can I use KMS to encrypt my on-premises data?**

Yes, you can use the KMS API to encrypt data from on-premises, but you need network connectivity to AWS. The data key generated by KMS can be used to encrypt data locally, but you must store the encrypted data key alongside the data.

**Does KMS support asymmetric keys?**

Yes, KMS supports both symmetric and asymmetric CMKs. Asymmetric keys use a public/private key pair and are used for digital signing or encryption where the public key can be shared. The private key never leaves KMS.

**How do I rotate a KMS key?**

You can enable automatic annual rotation in the KMS console. Manual rotation involves creating a new CMK and re-encrypting your data keys with the new CMK. Automatic rotation is simpler and recommended.

**What is a data key in KMS?**

A data key is a temporary symmetric encryption key generated by KMS when you call GenerateDataKey. It is used to encrypt your actual data. KMS returns both a plaintext and an encrypted version of the data key. You discard the plaintext version after use.

**What does FIPS 140-2 Level 3 mean?**

FIPS 140-2 is a US government security standard for cryptographic hardware. Level 2 requires tamper-evident coatings. Level 3 requires active tamper detection and identity-based authentication. CloudHSM is certified at Level 3; KMS uses HSMs that are generally Level 2 overall.

## Check your understanding

1. **What is the main reason KMS uses envelope encryption instead of encrypting data directly with the CMK?**

   Answer: Envelope encryption allows you to encrypt large amounts of data efficiently without exposing the CMK, and it enables independent management of data keys from the master key.

2. **Which AWS service should you choose to encrypt data at rest for a legacy Oracle database if the compliance requirement demands dedicated, tamper-resistant hardware that you control?**

   Answer: You should choose AWS CloudHSM because it provides single-tenant HSMs that you control, satisfying compliance standards like PCI DSS that require dedicated hardware.

3. **True or False: An AWS managed KMS key created in us-east-1 can be used to decrypt data in eu-west-1 without any additional configuration.**

   Answer: False. KMS keys are regional. You must replicate the key to the other region to use it for decryption there.

4. **What happens to the old key material when automatic rotation is enabled for a KMS CMK?**

   Answer: The old key material is retained indefinitely so that data encrypted with the old key can still be decrypted. Only new encryption operations use the new key material.

5. **A company needs to encrypt an S3 bucket with a customer-managed KMS key. What must the company configure to ensure that an IAM user in the same account can use the key?**

   Answer: The company must configure the KMS key policy to allow the IAM user (or a role the user can assume) to perform the required cryptographic operations, and the IAM policy must also grant the same permissions.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-security-specialty/data-encryption-at-rest