Day 7: Week 1 Challenge — Key Ceremony Simulation + PKCS#11 Exploration

Phase 5 · September 1, 2026

Agenda (2–3 hours)

• Complete hsm-demo Week 1 subcommands (list-slots, generate-key, sign, verify, key-ceremony)
• Write (60 min): acm-pca-design.md §0 — Key Custody Model

Week 1 Deliverable: hsm-demo (Phase 1)

hsm-demo
├── list-slots     ✓ Day 3 — lists slots with token info
├── generate-key   ✓ Day 3 — generates ECDSA P-256 key pair in SoftHSM2
├── sign           ✓ Day 4 — signs data with HSM-bound private key
├── verify         ✓ Day 4 — verifies signature with exported public key
└── key-ceremony   ✓ Day 5 — simulated offline root CA key ceremony

All five subcommands must compile and run against SoftHSM2.
Today: clean up, wire together, write the analysis.

Integration Test: Full Key Lifecycle

Run this sequence end-to-end before declaring Week 1 complete:

# 1. Initialize SoftHSM2 token (if not already done)
softhsm2-util --init-token --slot 0 --label "test-hsm" \
  --so-pin 12345678 --pin 123456

# 2. List slots
cargo run -- list-slots

# 3. Key ceremony (generates root-ca-key)
cargo run -- key-ceremony

# 4. Sign a payload
cargo run -- sign --label root-ca-key --data "certificate signing request"
# Save the hex output as $SIG

# 5. Verify
cargo run -- verify --label root-ca-key \
  --data "certificate signing request" --sig $SIG
# Expected: "Signature verified OK"

# 6. Tamper test
cargo run -- verify --label root-ca-key \
  --data "TAMPERED data" --sig $SIG
# Expected: "signature verification failed"

Concepts Inventory: Week 1

Rate each: ✓ solid / ~ partial / ✗ need review

HSM Fundamentals

• [ ] Why private CA keys need hardware protection
• [ ] FIPS 140-2 Level 3 requirements and what they prevent
• [ ] Key custody model: who holds the key, under what conditions

PKCS#11

• [ ] Slot → Token → Session → Object hierarchy
• [ ] CKA_EXTRACTABLE = false and its implications
• [ ] C_GenerateKeyPair, C_Sign, C_FindObjects call sequence
• [ ] Session object vs. token object

CloudHSM

• [ ] Cluster model (multi-AZ key synchronization)
• [ ] CU vs. CO user roles
• [ ] Why the same cryptoki code works for both SoftHSM2 and CloudHSM
• [ ] Cost/complexity tradeoff vs. ACM PCA

acm-pca-design.md Section 0: Key Custody Model

Start your analysis document today. Write §0 Introduction and Key Custody Model:

# ACM Private CA Architecture: Leo Provisioning Service
## §0. Key Custody Model

### 0.1 CA Hierarchy Overview
<diagram or table: tiers, validity periods, where each key lives>

### 0.2 Root Key Custody Decision
<ACM PCA managed vs. CloudHSM self-managed — which and why>

### 0.3 Key Access Controls
<IAM policies, CloudHSM users, or ACM PCA resource policy>

### 0.4 Blast Radius Analysis
<If issuance CA key is compromised: how many certs? how long to rotate?>

Quality bar: this section should be readable by your security team lead
without prior PKCS#11 or HSM knowledge.

Hard Questions for Week 1

These don't have easy answers. Write your current best thinking:

1. Your provisioning service runs as a Lambda function. Lambda has no persistent process.
   Can Lambda authenticate to CloudHSM? To SoftHSM2?
   (Hint: Lambda can use the CloudHSM SDK — but what are the latency implications?)

2. ACM PCA charges per certificate issued (~$0.75 for private PKI).
   If your provisioning service issues 10,000 certs/month, what's the cost?
   Is that justified compared to running your own CA?

3. SoftHSM2 stores "key material" on disk in an encrypted file.
   Is SoftHSM2 suitable for any production use case?
   If so, which? If not, what makes a real HSM non-negotiable?

4. The PKCS#11 session pin is a password. Where does it live in your provisioning service?
   (AWS Secrets Manager? SSM Parameter Store? IAM role + CloudHSM quorum auth?)

Preview: Week 2

Week 2 shifts from hardware to managed service:

Week 1: How HSMs work (PKCS#11, SoftHSM2, CloudHSM)
         ↓
Week 2: How ACM Private CA works (CA hierarchy, templates, API)

You've built the mental model for why HSMs protect CA keys.
Week 2 shows how AWS packages that protection into a managed service
so you don't have to run the HSM cluster yourself.

Resources

• Your hsm-demo source code from Days 3–5
• cryptoki integration tests: github.com/parallaxsecond/rust-cryptoki/tree/main/cryptoki/tests
• SoftHSM2 limitations: github.com/opendnssec/SoftHSMv2#limitations
• CloudHSM key ceremony: docs.aws.amazon.com/cloudhsm/latest/userguide/getting-started.html