HSM / PKCS#11 / Firmware Signing
What you will do: Upload a firmware binary (or use the mock UEFI manifest), pick PQC, classical and hash algorithms, then Generate Both Keys, Sign Both and Verify Both Signatures across the four wizard steps.
Worked example: With the defaults — ML-DSA-65 against RSA-2048 with SHA-256 — both signatures come back VERIFIED and the Migration Comparison table shows the signature growing from 256 B to 3,309 B (12.9×).
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 Secure Boot & Firmware PQC
For your role
- Developer / Engineer
- Select ML-DSA-65 beside RSA-2048 in Upload & Configure, use the mock UEFI manifest or your own binary, and walk the four steps: the CMS output shows the pure-mode signing the RFC 9882 comment in the configuration refers to.
- Security Architect
- The side-by-side keys, signatures and CMS output show the size a firmware image grows by under ML-DSA-65, which is the number your boot ROM and update channel must have room for.
- Researcher / Academic
- Run the Secure Boot PQC Known Answer Tests panel, then compare the classical and post-quantum CMS structures produced from the same manifest.
- Certification & Validation Engineer
- Run the Secure Boot PQC Known Answer Tests panel, then sign the mock UEFI manifest with ML-DSA-65 beside RSA-2048 in Upload & Configure: the panel is algorithm evidence, while the CMS output is what the device's verifier will actually have to accept.
- IT Ops / DevOps
- Sign the mock UEFI manifest with both algorithms and keep the two CMS outputs: they are what a signing service and a verifier on the device exchange, and the difference between them is your update-pipeline change.
Firmware Signing Migrator
Sign firmware with both a classical algorithm and a post-quantum algorithm side-by-side. Compare keys, signatures, and CMS output. All PKCS#11 operations execute in SoftHSM3 WASM.
Initializing SoftHSM…
C_Initialize → C_InitToken → C_OpenSession → C_Login
Upload & Configure
Select algorithms, upload a firmware binary (or use the mock UEFI manifest), and review the pure-mode signing configuration.
// Pure mode per RFC 9882 §3.1 / RFC 9814 §1.2
// No caller pre-hashing — algorithm handles internallyWhy firmware signing matters
- UEFI Secure Boot verifies every firmware image against signed db certificates at boot
- TPM PCR measurements attest firmware integrity — signatures must survive quantum attacks
- Supply chain compromise via forged signatures is a critical threat — PQC eliminates Shor's algorithm risk
ML-DSA uses SHAKE-256 internally; SLH-DSA-SHA2-128S uses SHA-256/SHA-512 internally (the "SHA2" in the name). No caller pre-hashing is needed. HashML-DSA (pre-hash) is explicitly excluded from CMS and X.509 (RFC 9882, RFC 9881). Your hash selection applies to: firmware digest display + classical signature mechanism (e.g. CKM_SHA256_RSA_PKCS).
Why HashML-DSA is excluded from CMS
- No separate hash dependency. HashML-DSA (pre-hash mode) introduces a second cryptographic hash algorithm as an independent security requirement. If that outer hash is weak, it becomes an attack surface — even if ML-DSA itself is sound. Pure mode avoids this entirely.
- SHAKE-256 is part of the security definition. FIPS 204 defines ML-DSA with SHAKE-256 bound into the algorithm's security proof. The security guarantees hold for the full message — pre-hashing by the caller steps outside that proof boundary.
- HashML-DSA is for constrained environments only. Pre-hash mode was designed for devices that cannot buffer the full message (e.g. streaming IoT sensors). In CMS, the complete content is always available — so RFC 9882 §3.1 mandates pure mode to prevent misuse.
Drop firmware binary here
or click to browse — any file format
▸ Using mock UEFI firmware manifest (no file uploaded)
| Component | Size | Hash |
|---|---|---|
| PEI Core | 512 KB | a3f2c1d4e5b6a7f8... |
| DXE Core | 1.2 MB | b4c3d2e1f0a9b8c7... |
| UEFI Shell | 256 KB | c5d4e3f2a1b0c9d8... |
| Setup UI | 384 KB | d6e5f4a3b2c1d0e9... |
| Network Stack | 192 KB | e7f6a5b4c3d2e1f0... |
PQC Algorithm
Classical Algorithm
Hash Algorithm
Choosing an algorithm
- ML-DSA-44 — NIST Level 2 · smallest ML-DSA keys/sigs · non-critical firmware where size matters
- ML-DSA-65 — NIST Level 3 · balanced · recommended general-purpose firmware signing
- ML-DSA-87 — NIST Level 5 · CNSA 2.0’s general-purpose signature (its firmware-signing pick is LMS/XMSS, SP 800-208)
- SLH-DSA-SHA2-128S — NIST Level 1 · smallest pubkey (32 B) but very large signature (7,856 B) · suited for root-of-trust and infrequent signing only (e.g. UEFI PK/KEK), not per-image signing
Note: Hash applies to classical signing mechanism (CKM_SHA256_RSA_PKCS) and digest display. PQC algorithms (ML-DSA-65) use SHAKE-256 internally — pure mode per RFC 9882/9814.
Note: Simulation mode active. Algorithm selection, comparison table, and CMS structure are always shown. Generated keys are for educational purposes only.
KAT note: The known-answer tests below validate ML-DSA-87 and SHA-256/SHA-512 fixed vectors (FIPS 204 / FIPS 180-4 ACVP) — independent of the algorithm selected above.
Secure Boot PQC Known Answer Tests
UEFI 2.10 · TPM 2.0 · FIPS 204 · FIPS 205 · FIPS 180-4
Click Run validation tests to run 4 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.; Functional round-trip — Output produced by an implementation is consumed by the same or paired implementation..
Reference samples from the public NIST ACVP-Server repository · UEFI 2.10 · TPM 2.0 · FIPS 204 · FIPS 205 · FIPS 180-4 · Generated keys are for educational use only.
Try it
The signing configuration says "pure mode, no caller pre-hash". What does that mean for the firmware image?
Next step
Turn it into a plan: Infrastructure Modernization PlannerThis tool practises the Secure Boot & Firmware PQC module, phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase.
Related content
Next in HSM / PKCS#11