HSM / PKCS#11 / TEE-HSM Secure Channel

What you will do: Open a trusted channel from an enclave to the HSM: an ML-DSA-65 attestation key, ML-KEM key agreement, and an AES key wrapped across the channel.

Worked example: Run the flow end to end; the PKCS#11 call log shows which call each algorithm makes, and the generated-keys panel shows what ended up where.

Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.

Browse all Crypto Lab tools · Learn with Confidential Computing & TEEs

For your role

Security Architect
Choose one of the presets such as Intel SGX + Thales Luna or AMD SEV-SNP + Entrust nShield, then Execute (Live WASM): the tool loads that pairing's documented integration architecture and shows which keys end up in the enclave and which in the HSM.
Researcher / Academic
Open What runs live vs. simulated? before reading the results: the ML-DSA-65 attestation key, ML-KEM key agreement and the AES key wrap run in the PKCS#11 call log, and the attestation transport is simulated.

Design and explore TEE-HSM integration architectures with mutual attestation and PQC key provisioning. Select a TEE vendor and HSM vendor to visualize the trusted channel.

Live HSM Mode Active

SoftHSM3 · PKCS#11 v3.2 · Rust · session open

Scenario Selector

Select a TEE vendor and HSM vendor below. The tool will load the documented integration architecture and live provisioning demo for that combination. Not all pairings are supported — try using a preset below.

TEE Vendor:
HSM Vendor:
Quantum Threat Analysis
Quantum Threat Analysis — TEE & HSM Components

Each component of a TEE-HSM deployment faces distinct quantum risks. Vectors marked HNDL are subject to harvest-now-decrypt-later attacks — adversaries recording traffic today can decrypt it once a cryptographically-relevant quantum computer (CRQC) is available.

CRITICALHNDLECDSA Attestation Chain ForgeryRemote Attestation

Shor's algorithm breaks ECDSA in polynomial time. An attacker with a CRQC can forge attestation quotes, impersonate legitimate enclaves, and bypass all trust decisions based on attestation.

PQC fix:ML-DSA-65/87 for attestation key signing. Hybrid ECDSA+ML-DSA during transition period. Certificate chain re-issuance from vendor root CAs.
Timeline: Intel: 2027, ARM: 2028, AMD: 2028, AWS: TBD· Effort: 4/5
HIGHSealing Key Recovery via Side-Channel + QuantumKey Management

Grover's algorithm halves AES key strength. If sealing keys use AES-128, effective post-quantum security is 64-bit — feasible for a CRQC to brute-force. Combined with side-channel leakage of key bits, recovery becomes more practical.

PQC fix:Upgrade sealing key derivation to AES-256 (128-bit post-quantum security). Add PQC KDF (HKDF-SHA3-256) for key derivation chain.
Timeline: Requires next-gen CPU silicon: Intel 2027+, AMD 2028+· Effort: 5/5
MEDIUMMemory Encryption Grover HalvingMemory Encryption

Grover's algorithm reduces AES-128 (NIST Category 1) effective security to 64-bit. While brute-forcing AES-128 memory encryption keys in real-time is unlikely even with a CRQC (requires sustained high qubit count), it leaves a much thinner margin than AES-256 (Category 5).

PQC fix:AES-XTS-256 memory encryption in next-gen CPUs. Alternatively, software-layer encryption with AES-256-GCM inside the enclave for sensitive data.
Timeline: Intel (Granite Rapids+): 2027, AMD (Zen 6+): 2028· Effort: 5/5
CRITICALHNDLTEE-HSM TLS Channel Key Exchange CompromiseTEE-HSM Communication

Shor's algorithm breaks ECDH key exchange. An attacker recording TLS sessions between a TEE and HSM can retroactively decrypt all key provisioning data once a CRQC is available (HNDL attack on key material in transit).

PQC fix:Hybrid ML-KEM-768 + ECDH P-256 for TLS 1.3 key exchange (forward secrecy). Requires PQC-capable TLS stacks on both TEE and HSM sides.
Timeline: OpenSSL 3.5+ (2025), wolfSSL (available), BoringSSL (available)· Effort: 3/5
HIGHFirmware Signature ForgerySupply Chain

Shor's algorithm can forge firmware signatures. An attacker could sign malicious TEE firmware, security monitor updates, or microcode patches that pass signature verification. Particularly dangerous for remote firmware update channels.

PQC fix:ML-DSA-65/87 or SLH-DSA for firmware signing. Dual-signature (classical + PQC) during transition. Hardware root of trust must support PQC verification.
Timeline: Requires silicon refresh: Intel (2027+), AMD (2028+), ARM (SoC vendor dependent)· Effort: 4/5
Memory Encryption Engines — Quantum Impact

Enclave sealing keys and memory encryption are often AES-128 (NIST Category 1), which Grover's algorithm halves to 64-bit effective post-quantum security — a much thinner margin than AES-256 (Category 5).

Intel TME-MKGrover Halved
AES-XTS-128 · 128-bit key

AES-128 (NIST Category 1) effective security drops to 64-bit under Grover's algorithm — a much thinner margin than AES-256 (Category 5). Upgrade path: AES-XTS-256 in future CPU generations.

Sealing: Platform root key (fused) → CPU SVN → Enclave identity (MRENCLAVE/MRSIGNER) → Sealing key via EGETKEY
AMD SME/SEV Encryption EngineGrover Halved
AES-XTS-128 · 128-bit key

AES-128 effective security drops to 64-bit under Grover. AMD has not announced AES-256 memory encryption for future EPYC generations. RMP integrity is hash-based (quantum-safe for collision resistance).

Sealing: AMD Secure Processor root key (fused) → TCB version → VM encryption key (VEK) derived per-VM via ASP key derivation
ARM TrustZone CryptoQuantum Safe
Vendor-specific (typically AES-256 inline encryption) · 256-bit key

AES-256 (NIST Category 5) provides 128-bit effective post-quantum security under Grover. However, TrustZone relies on access control (TZASC) rather than encryption for most isolation, which is not cryptographically affected by quantum.

Sealing: Hardware Unique Key (HUK, fused per-SoC) → Key derivation via Secure World service (vendor-specific KDF)
AWS Nitro Platform EncryptionQuantum Safe
Hardware-managed (Nitro Security Chip) · 256-bit key

AWS Nitro uses a hardware security chip for platform-level encryption with 256-bit keys (Grover-resilient). The primary protection mechanism is hypervisor-enforced isolation rather than memory encryption.

Sealing: Nitro Security Chip root key → Instance-specific key via Nitro attestation → Enclave key via KMS attestation policy

Run TEE-HSM Key Provisioning (Classical)

Note: HSM PQC firmware details and vendor comparison are covered in the HSM & PQC Operations module. Use the PKCS#11 Simulator to explore the HSM side of this integration.

Try it

After Execute, which key is generated as the attestation key in the PKCS#11 call log?

Next step

Turn it into a plan: Infrastructure Modernization Planner

This tool practises the Confidential Computing & TEEs module, phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase.