Protocol Simulations / TPM 2.0 PQC Playground

What you will do: Send raw TPM 2.0 commands from the Command Builder — TPM2_GetCapability, TPM2_CreatePrimary, TPM2_Encapsulate, TPM2_SignDigest — with ML-KEM or ML-DSA, then run Quote or Certify on the Attestation tab.

Worked example: On Attestation keep the ML-DSA-65 key, PCRs sha256:0,1,2,3,7 and the default nonce, press Run Quote: the result shows the 3309-byte signature, OpenSSL WASM verify says Signature Verified Successfully, plus a JSON bundle.

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: Run the eight tracks from Boot & discover to An honest TPM in the Learn tab, then use the Command Builder to send raw commands such as TPM2_GetCapability to the WebAssembly TPM: the Execution Log shows tags, return codes and the ML-KEM and ML-DSA primitives.
Security Architect: Track T3, Key establishment — transport vs encapsulation, and T6, Factory identity, show where a TPM's trust model changes under PQC; the V2.7 EKs and EK Certs tabs read the post-quantum endorsement key templates and certificates.
Researcher / Academic: Run the V1.85 Compliance Suite from the Command Builder and the ML-DSA Attestation tab's Quote / Certify with in-browser verify: track T8 shows how to detect fake crypto and spec drift yourself.

TPM 2.0 PQC Playground

Execute raw TPM 2.0 commands directly within the browser using the WebAssembly-compiledpqctpm emulator. Explore the new TCG V1.85 RC4 Post-Quantum primitives (ML-KEM and ML-DSA) via a dual-mode Semantic & Hex builder.

INITIALIZING WASM...

Core

Boot & discover — one chip, two cryptographic eras

The TPM booted when this page loaded. These steps interrogate the live chip: self-test, then the algorithm table — where RSA (0x0001) and ML-KEM (0x00A0) sit side by side — and finally a deliberate rule-break to see what an honest TPM refusal looks like.

TCG V1.85 (published March 2026) did not replace the TPM command set — it EXTENDED it. Everything classical still works; the PQC algorithms and commands were added alongside. GetCapability is the migration story in one response.

Waiting for the WASM TPM to initialize — steps enable once the engine is ready.

Steps

TPM2_SelfTest(fullTest=YES)
1. Run the full algorithm self-test
TPM2_GetCapability(TPM_CAP_ALGS)
2. Read the algorithm table — both eras in one list
TPM2_GetCapability(TPM_CAP_TPM_PROPERTIES)
3. Check the version this chip actually claims to be
TPM2_GetRandom(32)
4. Draw 32 bytes from the shared entropy source
TPM2_Startup (again)
5. Break a rule on purpose: start an already-started TPM

Glossary

TPM_ALG_ECC0x0023Elliptic-curve cryptography. Advertised by this build’s GetCapability, but ECC key generation currently fails in the WASM build (TPM_RC_NO_RESULT) — a known fork bug the playground discloses rather than hides.
TPM_ALG_HASH_MLDSA0x00A2NEW in v1.85 — HashML-DSA (FIPS 204 §5.4): the pre-hash ML-DSA variant, usable with the streaming sequence commands.
TPM_ALG_MLDSA0x00A1NEW in v1.85 (Part 2 §6.3) — ML-DSA (FIPS 204), the module-lattice signature. Optional in the Library spec; PTP v1.07 makes ML-DSA-65 or -87 mandatory for PC-class TPMs.
TPM_ALG_MLKEM0x00A0NEW in v1.85 (Part 2 §6.3) — ML-KEM (FIPS 203), the module-lattice KEM. Optional in the Library spec; PC Client PTP v1.07 makes ML-KEM-768 or -1024 MANDATORY for PC-class TPMs.
TPM_ALG_NULL0x0010The “nothing here” algorithm ID: scheme=NULL on an unrestricted key means the caller picks the scheme per operation; a restricted key must pin a real scheme instead.
TPM_ALG_OAEP0x0017RSA-OAEP padding for encryption/key transport — the modern classical choice, and what TPM2_RSA_Encrypt uses in the T3 lesson.
TPM_ALG_RSA0x0001RSA — the pre-quantum workhorse, broken by Shor’s algorithm on a cryptographically relevant quantum computer. Still in the v1.85 algorithm table, side by side with its replacements.
TPM_ALG_RSASSA0x0014RSASSA-PKCS1-v1_5 signing scheme. TPMS_SIGNATURE_RSA embeds its hash algorithm — the ML-DSA signature layout does not.
TPM_ALG_SHA2560x000BSHA-256 — used as nameAlg (object naming/authorization) and as the scheme hash for classical signing. Grover’s algorithm only halves its effective strength, so SHA-256 survives the transition.
TPM_RC_INITIALIZE0x00000100TPM2_Startup called when already started. Expected — and an honest refusal this playground treats as a SUCCESSFUL lesson outcome, not an error to hide.
TPM_RC_NO_RESULT0x00000154The operation produced no usable result. Errata v1 §2.4 designates it the expected error when ML-DSA rejection sampling exceeds the iteration limit. Also what this wasm build currently (incorrectly) returns for ECC key generation — a known fork bug.
TPM_RC_OBJECT_MEMORY0x00000902Warning: no free transient slot (this build has 3). Flush a handle (TPM2_FlushContext) and retry.
TPM_RC_SUCCESS0x00000000Command completed successfully.
TPM_RC_SYMMETRICA symmetric-algorithm field is wrong. Notably: a restricted SIGNING key must have symmetric=NULL — the AES block belongs only to restricted DECRYPT/storage templates (the WS0 probe hit exactly this).
TPM_ST_DIGEST_VERIFIED0x8027NEW in v1.85 — ticket tag from TPM2_VerifyDigestSignature: the signature was verified over a DIGEST (or external µ). See errata §2.5 for the external-µ NULL-ticket preference.
TPM_ST_HASHCHECK0x8024Ticket tag proving a digest was computed by this TPM from non-restricted data. SequenceComplete produces one; TPM2_Sign consumes one (a NULL hashcheck is acceptable for unrestricted keys).
TPM_ST_MESSAGE_VERIFIED0x8026NEW in v1.85 — ticket tag from TPM2_VerifySequenceComplete: the signature was verified over a streamed MESSAGE. Distinguishable on the wire from digest-level verification.
TPM_ST_NO_SESSIONS0x8001Command/response tag: no authorization sessions attached. Used by public-key-only operations (Encapsulate, VerifySignature, ReadPublic…).
TPM_ST_SESSIONS0x8002Command/response tag: an authorization area follows the handles. Private-key operations require it (Decapsulate, Sign, RSA_Decrypt…).
TPM_ST_VERIFIED0x8022Ticket tag from classical TPM2_VerifySignature: “this TPM verified this signature.” The pre-quantum member of the verified-ticket family.
TPM2_Certify0x00000148Part 3 §18.2 — attests that a named object is loaded in this TPM, signed by an attestation key.
TPM2_CreatePrimary0x00000131Part 3 §24.1 — creates and loads a primary key derived deterministically from the hierarchy seed plus the public template: same template, same key, every time. Works identically for RSA-2048 and ML-KEM-768 — the template’s type field is what changes.
TPM2_Decapsulate0x000001A8Part 3 §14.11, NEW in v1.85 — ML-KEM decapsulation: recovers the shared secret from a ciphertext using the private key. FIPS 203 implicit rejection means a corrupted ciphertext still returns SUCCESS — with a different, useless secret.
TPM2_Encapsulate0x000001A7Part 3 §14.10, NEW in v1.85 — ML-KEM encapsulation: the TPM generates a fresh shared secret and returns it with the ciphertext. Note the shape: the caller never chooses the secret, unlike RSA_Encrypt.
TPM2_FlushContext0x00000165Part 3 §28.4 — releases a transient object, sequence, or session handle. This WASM build has 3 transient slots, so flushing between steps matters (TPM_RC_OBJECT_MEMORY otherwise).
TPM2_GetCapability0x0000017APart 3 §30.2 — enumerates what this TPM supports: algorithms (TPM_CAP_ALGS), loaded/persistent handles (TPM_CAP_HANDLES), ECC curves, and more. The migration story in one command: RSA and ML-KEM appear in the same algorithm table.
TPM2_GetRandom0x0000017BPart 3 §16.1 — returns bytes from the TPM’s DRBG. Both classical and PQC keys draw from this same entropy source.
TPM2_HashSequenceStart0x00000186Part 3 §17.4 — opens a classical hash sequence: the TPM accumulates chunks and returns digest + hashcheck ticket at SequenceComplete. Classical TPMs hash-then-sign; pure ML-DSA cannot, which is why v1.85 added the sign-sequence commands.
TPM2_NV_Read0x0000014EPart 3 §31.13 — reads data from an NV index, up to MAX_NV_BUFFER_SIZE per call. The V2.7 EK certificates live in NV slots 0x01C00060–0x01C00074.
TPM2_NV_ReadPublic0x00000169Part 3 §31.6 — reads an NV index’s public area (attributes, size). How the EK-cert reader learns a certificate blob’s size before chunked reads.
TPM2_Quote0x00000158Part 3 §18.4 — signs a report of selected PCR values with an attestation key: the heart of remote attestation. Errata v1 §2.6: with schemeless signatures (pure ML-DSA, EdDSA) pcrDigest uses the signing key’s Name algorithm.
TPM2_ReadPublic0x00000173Part 3 §12.4 — returns the public area (TPMT_PUBLIC) and Name of a loaded object. How you fetch a public key’s real bytes to compare sizes.
TPM2_RSA_Decrypt0x00000159Part 3 §14.3 — recovers an OAEP-wrapped secret with the RSA private key. A corrupted ciphertext FAILS LOUDLY — no implicit rejection, unlike ML-KEM Decapsulate.
TPM2_RSA_Encrypt0x00000174Part 3 §14.2 — OAEP-wraps a caller-chosen secret to an RSA public key: classical key transport, the primitive ML-KEM encapsulation replaces. Note who picks the secret — the caller here, the TPM in Encapsulate.
TPM2_SelfTest0x00000143Part 3 §10.2 — runs the TPM’s algorithm self-tests. fullTest=YES tests everything rather than deferring until first use.
TPM2_SequenceComplete0x0000013EPart 3 §17.8 — closes a hash sequence, returning the digest and a TPMT_TK_HASHCHECK ticket a follow-up TPM2_Sign can present as validation.
TPM2_SequenceUpdate0x0000015CPart 3 §17.7 — feeds message chunks into ANY open sequence: a v1.85 PQC verify sequence or a classical hash sequence. Addresses only the sequence object; no key handle.
TPM2_Sign0x0000015DPart 3 §20.5 — classical one-shot signing over a caller-supplied digest (RSASSA here). The command TPM2_SignDigest modernizes; an RSA-2048 signature is 256 B vs ML-DSA-65’s 3309 B.
TPM2_SignDigest0x000001A6Part 3 §20.7, NEW in v1.85 — one-shot ML-DSA signing. With allowExternalMu the digest parameter carries the 64-byte external µ (FIPS 204 Algorithm 7); PQC signing got a NEW command rather than extending TPM2_Sign.
TPM2_SignSequenceComplete0x000001A4Part 3 §20.6, NEW in v1.85 — appends the final chunk and returns the ML-DSA signature over the accumulated message. Consumes the sequence handle.
TPM2_SignSequenceStart0x000001AAPart 3 §17.5, NEW in v1.85 — opens a streaming ML-DSA signing sequence. Pure ML-DSA must see the whole message (hash-then-sign changes the security claim), so the message streams INTO the signing operation.
TPM2_Startup0x00000144Part 3 §9.3 — transitions the TPM from power-on to operational. Called automatically when the WASM module loads; calling it again is refused with TPM_RC_INITIALIZE, an honest-refusal you can trigger in Lesson T1.
TPM2_VerifyDigestSignature0x000001A5Part 3 §20.4, NEW in v1.85 — verifies an ML-DSA signature over a digest/µ, returning a TPM_ST_DIGEST_VERIFIED ticket. Errata v1 §2.5: over an external µ the ticket cannot serve TPM2_PolicyAuthorize, so a conforming TPM SHOULD return a NULL ticket instead — this engine (built from RC4) still returns the real ticket.
TPM2_VerifySequenceComplete0x000001A3Part 3 §20.3, NEW in v1.85 — tests a signature against the streamed message; success returns a TPM_ST_MESSAGE_VERIFIED ticket, distinguishable on the wire from the digest-verified kind.
TPM2_VerifySequenceStart0x000001A9Part 3 §17.6, NEW in v1.85 — opens a streaming verification sequence. The hint parameter MUST be empty for ML-DSA (only EdDSA uses it).
TPM2_VerifySignature0x00000177Part 3 §20.2 — classical verification; success returns a TPM_ST_VERIFIED (0x8022) ticket. Compare the two NEW v1.85 ticket tags for the PQC verify modes.

AK (Attestation Key)A restricted signing key used to sign attestations (Quote). Restricted = it only signs TPM-generated data, so a relying party knows a Quote wasn’t forged over arbitrary input.
EK (Endorsement Key)The manufacturer-provisioned identity key in the Endorsement hierarchy. Classically RSA (activated via OAEP key transport); in the V2.7 profile, ML-KEM EKs are activated via encapsulation.
HierarchyOne of the TPM’s key families — Owner (user keys), Endorsement (platform identity), Platform (firmware). Each has a seed; primary keys derive deterministically from seed + template, for classical and PQC keys alike.
NV indexNon-volatile storage slot with its own access controls. EK certificates are provisioned into well-known NV indices (V2.7 §5.3.1: 0x01C00060–74) so software can find them.
PCRPlatform Configuration Register — accumulates measurements via extend (new = H(old ‖ measurement)). TPM2_Quote signs a digest of selected PCRs to prove platform state.
Restricted keyA key limited to TPM-blessed payloads: a restricted signer only signs TPM-generated digests (attestation), and must PIN its scheme at creation with symmetric=NULL. Restricted decrypt keys (storage/EKs) instead carry a symmetric block for child-key protection.
Sequence objectA transient object accumulating streamed data across SequenceUpdate calls. Classical: hash sequences (hash-then-sign). v1.85 adds sign/verify sequences because pure ML-DSA must see the message itself.
TicketA small HMAC-backed structure the TPM issues to itself as transferable proof (hashcheck, verified). v1.85 added two new verified-ticket tags so digest-level and message-level PQC verification are distinguishable.
Transient vs persistent handlesTransient objects (0x80xxxxxx) live in scarce RAM slots — 3 in this build — and vanish on restart. Persistent handles (0x81xxxxxx) survive; the V2.7 EKs sit at 0x810100B0–B6.

CRQCCryptographically Relevant Quantum Computer — one big enough to run Shor’s algorithm against real key sizes, breaking RSA and ECC. The reason the v1.85 algorithm table grew.
EK Credential Profile v2.7The published TCG EK Credential Profile v2.7 defines PQC EK templates and their certificate NV slots — the basis for this playground’s V2.7 EKs tab. The issuer here is an ephemeral dev CA, honestly labeled as such.
External µ (Mu)FIPS 204 Algorithm 7: µ = H(tr ‖ message) can be computed OUTSIDE the TPM and handed to TPM2_SignDigest when the key sets allowExternalMu — the 64-byte digest parameter in the T4 lesson. Errata §2.5 limits what the resulting verify ticket can be used for.
Implicit rejectionFIPS 203: ML-KEM decapsulation never errors on a bad ciphertext — it returns a deterministic pseudorandom secret instead, denying attackers a failure oracle. RSA-OAEP fails loudly; the T3 lesson shows both behaviors live.
KEM vs key transportRSA key transport: the caller picks a secret and encrypts it. A KEM: the algorithm GENERATES the secret during encapsulation. Not a drop-in swap — protocols must be re-plumbed, which is why v1.85 added new commands instead of overloading RSA_Encrypt.
PC Client PTP v1.07The published PC Client Platform TPM Profile v1.07 (2026) MANDATES ML-KEM and ML-DSA support for PC-class TPMs — the Library spec keeps them optional. Requirements live in profiles, not only the Library.
Spec vs engine driftThis engine was built from v1.85 RC4 (Dec 2025); TCG published the final spec + Errata v1 on 2026-03-12. The T8 lesson shows where the two now differ (e.g. the errata’s NULL-ticket preference) — knowing HOW to spot drift is part of the curriculum.

Try it

Track T5 says pure ML-DSA must see the whole message. What TPM command difference does that produce?

Next step

Turn it into a plan: Infrastructure Modernization Planner

This tool practises the Secure Boot & Firmware PQC module, phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase.

Next in Protocol Simulations

TLS 1.3 Simulator PQC VPN Simulator

Protocol Simulations / TPM 2.0 PQC Playground

TPM 2.0 PQC Playground

Boot & discover — one chip, two cryptographic eras

Related content