HSM / PKCS#11 / KMIP Control Plane

What you will do: Load a policy (Classical, PQC or auto-migrate-on-use), pick an algorithm or Auto — let the policy decide, then step through Create, Activate, Sign, Verify and Revoke on an in-browser KMIP 3.0 engine and WebAssembly HSM.

Worked example: Create an ECDSA-P256 signing key under Classical, switch to auto-migrate-on-use and press Sign: the result shows policy: Rekey → ML-DSA-65 as the legacy key is superseded, and Inspect records every step.

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

For your role

Developer / Engineer: Take the Guided Tour's ten steps in the Learn tab, from Provisioning a key through Certificate Services, then switch to Operate and Dev: every operation is a genuine KMIP 3.0 request answered by the Rust engine, and Inspect decodes the response tree.
Security Architect: Open the Policy tab, change one line of the Permissive (default) policy's algorithm disposition, and watch Operate switch operations from RSA-3072 to ML-DSA-65: crypto agility as a policy decision rather than a code change, with the Migration Estate tab showing which labels move.
Researcher / Academic: The spec status banner says KMIP 3.0 is an OASIS committee draft (CSD02); step 9, An honest HSM, lets you check that Destroy scrubs, read-only refuses and Locate filters, and Inspect shows the raw protocol version and correlation values.

KMIP Control Plane

View

What this means for you

Executive / Business Leader: In the guided view, the Learn tab opens with "Crypto agility in three steps" — set the policy, watch a request be refused, watch the estate rekey; the Dev tab is not shown for your role.
GRC / Risk & Compliance: On the Policy tab, "Which regime governs you?" loads a policy by regulator — US · NSA CNSA 2.0, US · FIPS 140-3, Germany · BSI — and the Inspect tab's Activity trail records every allow, deny or rekey decision.
Developer / Engineer: The Dev tab is a pipeline builder with Builder and Code views, a "Corpus (OASIS conformance)" palette, Run, and "Export .py"; switch View to expert and Inspect adds a "KMIP Wire" view of the TTLV bytes.
Security Architect: On Operate, "Plane 2 · KMIP Lifecycle" sends a real KMIP 3.0 request per button, with the algorithm set to "Auto — let the policy decide" or a named set; the Policy tab's Compare and Timeline ("As of" slider) show rules over time.
Researcher / Academic: The "CSD02" chip states that KMIP 3.0 is an OASIS committee draft, not a ratified standard; in expert view the Policy tab adds a YAML view of the exact rules and Inspect adds the raw "KMIP Wire" response.
Certification & Validation Engineer: On the Policy tab, "Which regime governs you?" includes US · FIPS 140-3; KMIP 3.0 is an OASIS committee draft (the "CSD02" chip), so nothing here is a validated configuration.
IT Ops / DevOps: The "Migration Estate" tab asks for keys by business label and lets the policy pick the algorithm; move from classical to hybrid to full PQC and "Key objects on this engine" shows rekeyed successors linked to deactivated predecessors.
Curious Explorer: Keep View on "guided" and press "Guided Tour" for step-by-step lessons; everything runs in this tab — no server, no Docker.

A real KMIP 3.0 control plane + PKCS#11 HSM, compiled to WebAssembly and running entirely in this tab — no server, no Docker. Every operation is a genuine KMIP request answered by the same Rust engine the appliance ships.

In scopecontrol plane + key management at rest · TLS handshake & persistence → full Docker sandbox

Spec statusKMIP 3.0 is an OASIS committee draft (CSD02, May 2026), not yet a ratified Standard —

Why crypto-agility, not just "post-quantum"

Data encrypted today with classical algorithms can be harvested now and decrypted later, once a cryptographically-relevant quantum computer exists — harvest-now, decrypt-later. The fix isn't swapping in a PQC algorithm once; it's a control plane that can migrate keys again whenever the roadmap changes, with no flag day and no application code change. Everything below is that idea made hands-on — flip the policy strip and watch the same request behave differently.

Crypto agility in three steps

Agility is the ability to change algorithm without changing the application. This is what that looks like when it works — three steps, about two minutes, running against a real control plane rather than a slide.

1Set the policy
One rule, written once, in the control plane rather than in any application: this estate no longer issues classical signing keys. Nothing is rewritten and nothing is redeployed — the rule is data, not code.
Cost: the policy itself is a few lines. What it replaces is a change request against every application that mints a key — which is the reason most estates cannot do this at all.
In the console below: Activate a policy in the Policy plane
2Watch a request be refused
Ask the control plane for exactly what the policy forbids. It says no, gives the rule it applied, and writes the refusal to the audit trail. This is the step that matters: the enforcement is central, so it holds for applications nobody has reviewed.
Cost: the refusal is the control working, not an outage — the caller retries with a compliant algorithm. What you are buying is that you never have to ask each team whether they complied.
In the console below: Run a scenario the policy refuses
3Watch the estate rekey
Rotate the affected keys to the post-quantum algorithm. The control plane reissues them and the applications carry on against the same key names — 7 keys in this worked estate, and the same operation at any size.
Cost, stated: signatures grow 64 B → 3,309 B, so certificate chains, tokens and firmware headers all get bigger, and an HSM that does 20,000 ECDSA P-256 signatures per second manages roughly 150 with ML-DSA-65. That is the capacity conversation this migration actually is — not whether to move, but what to buy.
In the console below: Run the rekey in the Migration plane

That is the whole argument for agility: the algorithm changed, the applications did not, and there is a record of both. An estate that cannot do this has to repeat the whole migration the next time an algorithm is retired — and there will be a next time.

Then take it further: Command Center · Compliance landscape · Migration catalog

Every KMIP session starts the same way: ask the server to make you a key pair, then flip it live. This lesson uses that lifecycle to introduce the object model everything else in this lab builds on — including the honest limits of what "modernizing" a key actually means.

Classical

RSA-3072 (classical)

PKCS#1 v1.5 / FIPS 186-5 · Integer factorization · pub 384 B · priv 1,770 B · sig 384 B

1.Create an RSA-3072 key pair
2.Activate the private key

Provision the post-quantum equivalent

Compare

	RSA-3072 (classical)	ML-DSA-65 (FIPS 204)
Operation	CreateKeyPair	CreateKeyPair
Public key size	384 B	1,952 B (5.1×)
Private key size	encoding-dependent (PKCS#1/#8)	4,032 B, fixed by FIPS 204
Lifecycle states available	Pre-Active → Active → … → Destroyed	Pre-Active → Active → … → Destroyed

"Modernizing" does not transform the RSA key in place — it is a brand-new object with its own UniqueIdentifier. The old key keeps working (e.g. to verify signatures made before the switch) until you deliberately retire it.

The request/response SHAPE is identical except the CryptographicAlgorithm value and the size of what comes back. That equivalence is crypto-agility at the protocol level.

Why it matters

If your integration code only ever reads PrivateKeyUniqueIdentifier / PublicKeyUniqueIdentifier off the response and treats them as opaque handles — never parsing key material client-side — this flip IS the entire migration for object creation. No code change, just a policy/config change (see the Agility tab).

Check your understanding

1. What does "modernizing" the RSA key to ML-DSA actually do?
2. What changed between the RSA-3072 request and the ML-DSA-65 request on the wire?
3. Why must you Activate a freshly created key before using it?

Try it yourself in Reference:

Glossary

AdjustmentTypeAdjustAttribute's arithmetic operator: Increment, Decrement, or Negate.
AdjustmentValueThe amount to adjust by, if not the implicit default of 1.
Attribute0x420008A single named property attached to a managed object — its algorithm, usage mask, or a custom governance tag.
AttributeName0x42000AThe name half of an Attribute pair.
AttributeReferenceWhich attribute (by name) an Attributes operation targets.
Attributes0x420125A named bundle of Attribute values attached at object creation, or fetched via GetAttributes.
AttributeValue0x42000BThe value half of an Attribute pair.
BatchErrorContinuationOption0x42000EHow a batch handles a failed item: Continue (run them all), Stop (halt at the first failure), or Undo (halt AND roll back earlier successes).
BatchItem0x42000FOne operation inside a batch — a single Request/Response Message can carry several of these in one wire round trip.
Certificate0x420013One candidate in the chain Validate checks — an outer wrapper around the raw CertificateValue DER.
CertificateRequest0x420018The inbound PKCS#10 CSR (Certificate Signing Request), DER-encoded — see CSR below.
CertificateRequestType0x420019Which CSR format follows — this server only accepts PKCS10; CRMF and PEM are recognized codepoints but not implemented.
CertificateValue0x42001EThe actual X.509 certificate, DER-encoded — what a browser or `openssl x509` would parse.
chain validationConfirming a certificate chain both parses and cryptographically checks out: every non-root certificate's signature verifies against its issuer's public key, every certificate is within its validity window, and the chain reaches a trust anchor.
CommonAttributes0x420126For CreateKeyPair: attributes shared by both halves of the pair (e.g. the algorithm both keys must agree on).
CredentialTypeWhich credential shape follows — UsernameAndPassword here; KMIP also defines device and attestation credential types.
CryptographicAlgorithm0x420028Which algorithm this object or operation uses — the single field crypto-agility hinges on. Swap this value and everything downstream (key/signature/ciphertext sizes) follows.
CryptographicLength0x42002AKey size in bits (256 for AES-256, 3072 for RSA-3072). PQC parameter sets like ML-DSA-65 already fix this, so it is often omitted.
CryptographicParametersMechanism-level overrides for an operation — padding, block mode, hash, or (for Sign) an explicit algorithm — layered on top of the key's own CryptographicAlgorithm.
CryptographicUsageMask0x42002CA bitmask of what the key may be used for — Sign, Verify, Encrypt, Decrypt, KeyAgreement, … The server enforces this at every operation, independent of any Plane-1 policy.
CSRCertificate Signing Request (PKCS#10, RFC 2986) — a subject's public key plus a self-signature proving they hold the matching private key, submitted to a CA for issuance. Certify verifies that self-signature before issuing.
Data0x4200C2The actual bytes being operated on — plaintext to Encrypt, a message to Sign, a KEM ciphertext to Decapsulate. Carried as a ByteString (hex on the wire).
DataLengthHow many random bytes to return from RNGRetrieve.
DefaultsInformationSetDefaults' payload wrapper.
DerivationDataThe KDF’s label/context bytes mixed into the derivation.
DerivationMethodWhich KDF DeriveKey uses to turn a base key into a new one — e.g. NIST SP 800-108 Counter Mode.
DerivationParametersWraps the KDF's inputs for DeriveKey.
EndpointRoleDeclares whether this endpoint is acting as a Server or Client — relevant for peer-to-peer KMIP deployments.
HashingAlgorithmWhich hash function Hash (or a signature's mechanism parameters) should use — SHA-256, SHA-384, SHA-3, …
IVCounterNonce0x42003DThe initialization vector / nonce for a symmetric mode like AES-GCM. Must travel with the ciphertext — the recipient needs it to decrypt.
Key0x42003FGeneric container tag for key data in some response shapes.
KeyBlock0x420040The structure wrapping a key's actual bytes plus the metadata (format, algorithm, length) needed to interpret them.
KeyFormatType0x420042How the key material inside KeyBlock is encoded — Raw, PKCS#1, PKCS#8, TransparentECPublicKey, …
KeyMaterial0x420043The raw key bytes themselves, inside KeyValue.
KeyValue0x420045Wraps KeyMaterial (and, for a private key, may wrap it again for wire-level protection).
LeaseTimeHow long (seconds) a Login session stays valid before re-authentication is required.
LogMessageFree-text diagnostic string carried by Log — for client-side event forwarding, not policy-relevant.
MACDataThe MAC tag MACVerify checks against a freshly-computed one.
Modulus0x420052RSA-specific key component, visible when a key is exported/registered in a transparent (non-opaque) key format.
Name0x420053A human-assigned label for a managed object — distinct from its UniqueIdentifier, purely for the operator's convenience.
NewAttributeThe replacement value wrapper used by AddAttribute / ModifyAttribute / SetAttribute.
ObjectDefaultsThe attribute defaults the server should apply to future objects of a given type.
ObjectType0x420057What kind of managed object this is — SymmetricKey, PublicKey, PrivateKey, Certificate, SecretData, OpaqueObject, SplitKey.
OffsetFor ReKey/ReKeyKeyPair: seconds after now to set the new key's activation date — lets you pre-provision a successor key. Re-certify reuses the same tag the same way, for the renewed certificate's activation date.
Operation0x42005CWhich of the KMIP 3.0 operations this batch item invokes.
PasswordThe credential's password field.
PasswordCredentialThe username+password pair for CreateCredential / Login.
PKCS11FunctionThe specific PKCS#11 (Cryptoki) C function being invoked through the passthrough operation.
PKCS11InputParametersThat function's raw input parameters.
PrivateExponent0x420063RSA-specific private key component.
PrivateKey0x420064The managed-object container for a private key.
PrivateKeyAttributes0x420127CreateKeyPair attributes that apply only to the private half.
ProtocolVersion0x420069The KMIP protocol version client and server negotiate.
ProtocolVersionMajor0x42006AMajor version — 3 here.
ProtocolVersionMinor0x42006BMinor version — 0 here (draft CSD02).
PublicExponent0x42006CRSA-specific public key component — conventionally 65537.
PublicKey0x42006DThe managed-object container for a public key.
PublicKeyAttributes0x420128CreateKeyPair attributes that apply only to the public half.
QueryFunction0x420074Which category of server capability you're asking about — QueryOperations, QueryObjects, QueryServerInformation, …
ReplaceExistingImport's flag for whether to overwrite an object already registered under the same UID.
RequestCountCaps how many requests a leased Login session may make.
RequestHeader0x420077The envelope wrapping every request: protocol version, batch count, and options.
RequestMessage0x420078The outermost element of any KMIP request.
RequestPayload0x420079The operation-specific fields — shaped completely differently from op to op.
ResponseHeader0x42007AThe response's mirror of the request header: protocol version, timestamp, batch count.
ResponseMessage0x42007BThe outermost element of any KMIP response.
ResponsePayload0x42007CThe operation-specific result fields.
ResultMessage0x42007DA human-readable string explaining the ResultStatus, when present.
ResultReason0x42007EWHY an operation failed — a specific enumerated cause (PermissionDenied, OperationNotSupported, InvalidMessage, …) distinct from the pass/fail ResultStatus.
ResultStatus0x42007FDid the operation succeed? Success, Operation Failed, Operation Pending, or Operation Undone (the last only appears inside a batch rolled back by Undo continuation).
RevocationReason0x420081Wraps the reason code Revoke records against a key.
RevocationReasonCode0x420082Why a key was revoked — required by Revoke, kept in the object's history.
ServerInformation0x420088Vendor-specific server metadata returned by Query.
SignatureData0x4200C3The actual signature bytes Sign returns / SignatureVerify checks — the field whose size jumps hardest under PQC.
State0x42008DWhere this object sits in the KMIP lifecycle: Pre-Active → Active → Deactivated → Compromised → Destroyed. Several operations are gated purely by this — Sign requires Active regardless of any policy.
SymmetricKey0x42008FThe managed-object container for a symmetric key, holding a KeyBlock.
TicketAn opaque session credential returned by Login and presented on Logout / later requests.
TimeStamp0x420092When the response was generated, server-side.
trust anchorA self-signed (root) certificate a validator is willing to trust without further checking — Validate's chain must terminate in one PRESENT IN THE SUPPLIED SET (this server holds no separate trust-anchor store) to return Valid.
TTLVTag-Type-Length-Value — the binary wire encoding every KMIP message uses: each field is a tag (what), a type (how to read it), a length, then the value bytes.
UniqueIdentifier0x420094The server-assigned handle for a managed object — opaque to the client, used in every later request that touches this object. CreateKeyPair returns two: one for the private key, one for the public key.
UsageLimitsCountHow many more operations (or bytes) this key is permitted before the server retires it.
UsernameThe credential's username field.
ValidityDate0x42009AThe instant Validate checks each certificate's not-before/not-after window against — omit it to mean "now".
ValidityIndicator0x42009BSignatureVerify's or Validate's answer: Valid, Invalid, or Unknown — the one field your verification code should actually branch on. For Validate specifically, Unknown means "couldn't be affirmed" (e.g. the chain's issuer wasn't supplied) — never a false Valid.
VendorIdentification0x42009DA free-text string identifying the server implementation, returned by Query.

Asynchronous correlation valueThe claim ticket for an asynchronous job (§9.1): a server-generated byte string returned with OperationPending, later redeemed via Poll / Cancel / Process / Query Asynchronous Requests.
Asynchronous processingKMIP 3.0 §8.1.2: a request marked 'Asynchronous Indicator = Mandatory' is enqueued as a real background job instead of blocking — the response is OperationPending plus a correlation value, and Poll's eventual answer is identical to what the synchronous op would have returned.
BatchOne Request Message can carry several Batch Items, each its own operation, submitted — and, depending on continuation option, rolled back — together: a single wire round trip, not N of them.
Crypto-agilityArchitecting so the algorithm is a swappable parameter, not something baked into your integration code.
Label-only agilityThe Migration estate's contract: the application passes only a business key NAME (e.g. firmware-release-signing); the active policy's name_pattern rules decide every crypto parameter. Flip the policy and the same labels resolve to quantum-safe algorithms.
Managed objectAnything the server tracks with its own UniqueIdentifier and lifecycle State — a key, a certificate, a secret, an opaque blob.
Object lifecycle statePre-Active → Active → Deactivated → Compromised → Destroyed. Several operations are gated purely by state — e.g. Sign requires Active — independent of any Plane-1 policy decision.
Operation vs. PayloadA request names an Operation (e.g. Sign) and carries one RequestPayload shaped specifically for it — payload fields differ completely from op to op.
ReKey sweepMigrating keys proactively with ReKey / ReKeyKeyPair rather than waiting for each key's first use — the "migrate all remaining" pass. With substitution-aware policies, the sweep retargets each key to its policy-chosen successor algorithm.
Split key (M-of-N shares)A key divided into N share objects where any M — the threshold — reconstruct it and fewer genuinely cannot (Create Split Key / Join Split Key, §6.1.12/§6.1.33). The polynomial methods are Shamir secret sharing; the XOR method needs every share.
ThresholdThe M in M-of-N secret sharing: the minimum number of shares that must combine to recover the split key. Below it, the shares reveal nothing about the key — that is the mathematical point of the scheme.
Zeroization / scrubbingActually erasing key material — overwriting the bytes in memory and securely deleting them from storage — rather than merely marking the object Destroyed. "The key material SHALL be destroyed" is a claim about bytes, not about a status flag.

FIPS 203 / 204 / 205NIST's finalized PQC standards (Aug 2024): FIPS 203 = ML-KEM (key establishment), FIPS 204 = ML-DSA (signatures), FIPS 205 = SLH-DSA (hash-based signatures).
Grover's algorithmA quantum algorithm giving only a quadratic speedup at unstructured search — halves a symmetric key's effective strength. AES-256 loses headroom it already had to spare.
Hash-based signatureSecurity rests on nothing but the hash function's own security (preimage/PRF-type properties, deliberately NOT collision resistance — the design is collision-resilient by construction) — the most conservative assumption class available. SLH-DSA is hash-based: tiny keys, large signatures.
Hybrid / compositeRunning a classical and a PQC algorithm together so the construction stays secure even if one of the two is broken. KMIP 3.0 (CSD02) has two first-class hybrid KEMs (X25519MLKEM768, SecP256r1MLKEM768); hybrid signatures have no native KMIP algorithm yet.
KEM (Key Encapsulation Mechanism)A primitive shaped as Encapsulate (recipient's public key → ciphertext + shared secret) / Decapsulate (ciphertext + private key → the same shared secret). ML-KEM is a KEM; classical Diffie-Hellman is not — it's a different shape entirely.
Lattice-based cryptographySecurity rests on the hardness of geometry problems in high-dimensional lattices (e.g. Learning With Errors) — believed hard even for a quantum computer. ML-KEM and ML-DSA are lattice-based.
Shor's algorithmA quantum algorithm giving an exponential speedup at integer factorization and discrete logarithms — breaks RSA, ECDSA, ECDH outright once a large enough quantum computer exists. The reason asymmetric crypto must migrate.

Want the full-fidelity version with TLS transport and the REST control plane? Run the real pqctoday-kmip server from the Docker sandbox.

Try it

In the Policy tab, change the disposition for RSA-3072. Where do you see the effect?

Next step

Put it in your report

Your readiness report is where the results of the Playground tools become recommendations.

Next in HSM / PKCS#11

HSM Capacity Calculator Hybrid KEM + ECDH

HSM / PKCS#11 / KMIP Control Plane

KMIP Control Plane CSD02

Crypto agility in three steps

RSA-3072 (classical)

Related content

KMIP Control Plane