← Week 1: HSM fundamentals + PKCS#11

Day 1: What Is an HSM? Hardware Security and Key Custody

Phase 5 · August 26, 2026

← Week 1: HSM fundamentals + PKCS#11

Agenda (2–3 hours)

  • Read (60 min): FIPS 140-2/3 overview; AWS CloudHSM concepts intro
  • Study (60 min): What makes an HSM different from a software key store
  • Write (30 min): Key custody model for your provisioning service
← Week 1: HSM fundamentals + PKCS#11

The Core Problem: Where Does the Key Live?

When your provisioning service calls acm-pca:IssueCertificate, ACM PCA:

  1. Receives a CSR from the caller
  2. Signs it with the CA's private key
  3. Returns the signed certificate

Where is that CA private key?

If it's on disk → a root compromise exposes all past and future certs.
If it's in memory → a process dump or snapshot reveals it.
If it's in an HSM → the key cannot be exported; the HSM performs the signing.

This is the fundamental security property that HSMs provide.

← Week 1: HSM fundamentals + PKCS#11

What Is an HSM?

An Hardware Security Module is a tamper-resistant device that:

  • Stores cryptographic keys inside protected hardware
  • Performs cryptographic operations (sign, encrypt, derive) using those keys
  • Never exports the private key material outside the hardware boundary
  • Detects physical tampering and zeroes keys if opened

What you can do:

  • Generate a key inside the HSM
  • Ask the HSM to sign with that key
  • Export the public key (safe to share)

What you cannot do:

  • Export the private key bytes (by design)
  • Clone the key to another machine (without special backup procedures)
← Week 1: HSM fundamentals + PKCS#11

FIPS 140-2 / 140-3: The Compliance Baseline

FIPS 140-2 and its successor FIPS 140-3 are NIST standards for
cryptographic module security requirements.

Four security levels:

Level Description Typical use
1 Correct algorithm implementation; software OK Basic compliance
2 Tamper evidence (seals, coatings); role-based auth General enterprise
3 Tamper resistance + response; identity-based auth CA key storage
4 Full tamper resistance; environmental failure protection Military / highest assurance

AWS CloudHSM: FIPS 140-2 Level 3
ACM PCA backing HSMs: FIPS 140-2 Level 3 (AWS-managed)

For a CA private key, Level 3 is the minimum you should accept.

← Week 1: HSM fundamentals + PKCS#11

Key Custody: Who Holds the Key?

Key custody defines who has access to a key and under what conditions.

Three models relevant to your provisioning service:

Model Key location Who controls signing Risk
Software Disk / memory Anyone with file access High
Self-managed HSM (CloudHSM) CloudHSM cluster IAM + HSM user credentials Medium
Managed CA (ACM PCA) AWS-managed HSM AWS controls hardware; you control issuance via IAM Low ops

The tradeoff: control vs. operational burden.

ACM PCA removes the burden of managing HSM hardware, backups, and firmware upgrades — but you trust AWS to protect the key material.

← Week 1: HSM fundamentals + PKCS#11

HSM vs. Software Key Store

Property Software (disk/memory) HSM
Key extraction Possible (file copy, memory dump) Not possible by design
Signing performance Fast (CPU) Slower (HSM API call)
Backup / DR Easy (copy file) Requires HSM-specific backup procedure
FIPS 140-3 Level 3 No Yes
Cost Free CloudHSM ~$1.60/hr per HSM instance
Failure mode Key file corrupt → CA down HSM cluster failure → CA down
Audit OS-level (not HSM-specific) HSM audit logs
← Week 1: HSM fundamentals + PKCS#11

Key Ceremony: The Root of Trust

A key ceremony is the controlled procedure for generating and activating
a CA's root private key. It establishes the chain of custody and is:

  • Performed offline (air-gapped machine)
  • Witnessed by multiple people (quorum)
  • Documented and recorded
  • The resulting key is loaded into the HSM; the generation machine is destroyed

For your provisioning service:

  • ACM PCA root: AWS performs the ceremony internally (FIPS 140-2 L3, audited)
  • Self-managed root: You would perform the ceremony → CloudHSM or offline HSM

Day 5 covers key ceremonies in detail.

← Week 1: HSM fundamentals + PKCS#11

Your Provisioning Service's Key Hierarchy

[Root CA]          Lives in: AWS-managed HSM (ACM PCA)
    │              Or: CloudHSM cluster (if self-managed)
    │
[Subordinate CA]   Lives in: ACM PCA (managed) or CloudHSM
    │              Purpose: sign issuance-tier CA certs
    │
[Issuance CA]      Lives in: ACM PCA (managed)
    │              Purpose: sign leaf certificates for devices / services
    │
[Leaf cert]        Lives in: device / service / SPIRE trust bundle
                   Purpose: TLS, mTLS, SVID, device identity

Each level has a different validity period:
Root 10–20 years → Sub 5–10 years → Issuance 1–3 years → Leaf 1h–1y

← Week 1: HSM fundamentals + PKCS#11

Challenge Assignment

Write a Key Custody Model section for your provisioning service
(add it to acm-pca-design.md as §0 or an introduction):

  1. What CA hierarchy does your service need?
    (How many tiers? What are the validity periods?)

  2. Who should control the root CA key?
    (AWS-managed ACM PCA, self-managed CloudHSM, offline HSM?)

  3. What are the key custody requirements from your security team?
    (FIPS 140-2 Level 3? Key quorum? Air-gap for root?)

  4. What is the blast radius if the issuance CA key is compromised?
    (How many certs? How long until rotation completes?)

Write 1–2 paragraphs per question. This becomes the foundation of your Phase 5 analysis.

← Week 1: HSM fundamentals + PKCS#11

Resources

  • AWS CloudHSM: docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html
  • ACM PCA root CA: docs.aws.amazon.com/privateca/latest/userguide/PcaCreateCa.html
  • FIPS 140-3: csrc.nist.gov/publications/detail/fips/140/3/final
  • "Understanding PKI" book, Chapter 8: HSMs and Key Ceremony