Architecture · Cryptographic signing

Ed25519. Your keys. Your KMS.

The signing layer is the load-bearing cryptographic surface of the platform. Veridra cannot sign on your behalf without you — by construction, not by policy.

We designed it so Veridra can't sign on your behalf without you: by construction, not by policy.

Algorithm choice

We sign every attestation with Ed25519 (RFC 8032). Ed25519 is deterministic, misuse-resistant, fast enough to run at decision-rate without batching, and widely supported by HSMs and managed KMSs. Signatures are 64 bytes, public keys are 32 bytes, and the construction avoids the side-channel leaks ECDSA nonce reuse can cause.

Payloads are canonicalized with RFC 8785 JCS before signing. Determinism is enforced across every SDK (Python, Node, Go, Java) by golden-vector tests in CI. A decision signed from Python and re-signed from Go over the same logical payload produces byte-identical signatures.

Key custody

The defining property of the signing layer is that Veridra doesn't hold the private key. It's a structural claim enforced by the data path, not a soft claim enforced by audit.

BYOK is the default, not an upsell

Each tenant is provisioned with their own signing key in their own KMS or HSM. There is no shared key, and no platform-level signing identity that can impersonate a tenant.

KMS-relative, not key-resident

The signer service holds a KMS reference (ARN, key URI, PKCS#11 handle), not key material. It requests signatures over mTLS; the key never leaves the HSM/KMS boundary. Revoke the reference and Veridra immediately loses the ability to sign for you.

Per-tenant isolation

The kms-adapter enforces tenant scope on every request. A signer pod handling tenant A physically cannot call the key associated with tenant B, because the SPIFFE identity on the mTLS session is not authorized for it.

Rotation without re-signing history

Keys rotate on schedule or on demand. Old public keys stay published for verification of historical signatures. A rotation event is itself a signed entry in the transparency log, so auditors can see exactly when custody changed.

Supported backends

The kms-adapter speaks a small internal protocol and a backend driver for each supported custodian. All drivers present the same Ed25519 interface upward; the signer has no awareness of which backend a tenant uses.

AWS KMS — Asymmetric Ed25519 CMK with per-tenant grants. Usage is bounded by CloudTrail, giving you your own audit log of every signature we requested.
Azure Key Vault / Managed HSM — Ed25519 key with per-tenant access policy. Managed HSM variant gives FIPS 140-2 Level 3 custody.
GCP KMS / Cloud HSM — Ed25519 key in a tenant-owned keyring. HSM protection level where required by residency or certification.
HashiCorp Vault (Transit) — Self-hosted option for customers who keep their root of trust on-prem.
PKCS#11 HSM — Direct integration with on-prem HSMs (Thales, Entrust, YubiHSM) for regulated environments where even managed cloud KMS is out of scope.

Why Ed25519

Determinism, misuse-resistance, speed

Unlike ECDSA, Ed25519 does not require a random nonce per signature, so nonce-reuse bugs can't leak private keys. Signing and verification are fast enough to run inline with decision flow. Every mainstream HSM and cloud KMS supports it, so BYOK never means picking a second-class algorithm.

Structural, not procedural

What 'we can't sign without you' actually means

The signer service holds only a reference to your KMS key. Every signature triggers an outbound mTLS call to your KMS. Disable the grant in your cloud console and the next signing request fails immediately — and that failure is itself a signed log entry. This is custody enforced by the data path, not custody promised in a DPA.

Signing, logging, and verification together

A signature proves a statement came from the holder of a specific key. The transparency log then proves when that statement entered the record, and that it hasn't been altered since. Together they give a regulator-admissible evidence chain.

Verification is open-source and doesn't require Veridra to be online. Customers, auditors, and adversaries can run the same CLI against the same public keys and the same witness-co-signed log roots, and get the same answer.

Request a review →Key management detail →Transparency log →