HSM / PKCS#11 / SP 800-108 KDF
What you will do: Retrieve a QKD key over ETSI QKD 014, import it into the HSM, and derive a session key from it with SP 800-108 counter-mode KDF over PKCS#11.
Worked example: One QKD key in, one session key out, with the label and context that bind the derived key to its purpose — then the session key is used.
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 KMS & PQC Key Management
For your role
- Developer / Engineer
- Press Fetch QKD Key to start from the ETSI QKD 014 REST step, then follow the SP 800-108 counter-mode derivation: the label and context inputs are what bind the derived key to one purpose, and the same call applies to a KEM shared secret or a PSK.
- Security Architect
- Read KBKDF vs HKDF — Choosing the Right KDF before the run: it says when SP 800-108 counter mode and when HKDF is the right choice for splitting one master secret into encryption, MAC and IV keys.
- Researcher / Academic
- Open What runs live vs. simulated? to see that the QKD retrieval is a modelled REST exchange while the derivation runs in the PKCS#11 log; the QKD/HSM PQC Known Answer Tests panel runs the KDF checks and labels each result with its evidence class.
- Certification & Validation Engineer
- Follow the SP 800-108 counter-mode derivation in the PKCS#11 log, then run the QKD/HSM PQC Known Answer Tests panel: each KDF check carries its evidence class, and What runs live vs. simulated? says the QKD retrieval is modelled.
Live HSM Mode Active
SoftHSM3 · PKCS#11 v3.2 · Rust · session open
SP 800-108 Key Derivation — Beyond QKD
NIST SP 800-108 counter-mode KDF is a universal primitive used wherever a master secret must produce multiple purpose-specific keys. This demo uses QKD as the input source, but the same KDF applies to:
KBKDF vs HKDF — Choosing the Right KDF
This demo uses KBKDF because the QKD secret is imported as a non-extractable HSM key. HKDF would require the raw key bytes to be visible in the software layer — acceptable for KEM-based TLS but undesirable for QKD where the secret must never leave the HSM.
QKD scenario below: This demo follows the ETSI GS QKD 014 key retrieval API → PKCS#11 v3.0 HSM import → NIST SP 800-108 counter-mode KDF pipeline. Both Alice and Bob run identical steps independently — the session key is never transmitted.
Step 1: ETSI QKD 014 REST Key Retrieval
GET /api/v1/keys/{SAE_ID}/1Authorization: Bearer {client_cert}Both Alice and Bob independently call their local QKD key managers. They request the same key_ID — the secret bytes are identical on both sides because they were produced by the QKD hardware.
QKD/HSM PQC Known Answer Tests
ETSI GS QKD 014 · NIST FIPS 198-1 (HMAC-SHA-256) · SP 800-108r1 + RFC 5869 (HKDF)
Click Run validation tests to run 2 use-case scenarios. Evidence in this set: NIST ACVP-Server reference sample — Expected values copied from the public NIST ACVP-Server repository with immutable source identity.; Published standard KAT — Expected values printed in a cited standard or consensus RFC..
Reference samples from the public NIST ACVP-Server repository · ETSI GS QKD 014 · NIST FIPS 198-1 (HMAC-SHA-256) · SP 800-108r1 + RFC 5869 (HKDF) · Generated keys are for educational use only.
Try it
What binds the derived session key to its purpose in the SP 800-108 step?
Next step
Turn it into a plan: Infrastructure Modernization PlannerThis tool practises the KMS & PQC Key Management module, phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase.
Related content
Next in HSM / PKCS#11