Built to be checked, not believed
A provenance platform is only as good as its own security. Here is exactly how Krusade handles keys, credentials, and infrastructure — including the parts still in progress.
Certificate & key custody
Signing keys never touch application disk
Production C2PA claim signing is designed around HashiCorp Vault Transit: the private key is generated inside Vault and every signature is produced by Vault itself. The signing service sends digests in, gets signatures out — no process outside Vault can read the key material.
One shared certificate, held by us
Krusade signs all customer content under a single Krusade certificate. You never manage certificates, CSRs, or key rotation — manifests read as signed by Krusade as the claim generator.
Certificate status — honest answer
Local and current deployments sign with a development certificate, so verifiers report the issuer as untrusted. A CA-issued C2PA certificate (chained into the C2PA Trust List) is the next milestone on our public roadmap; when it lands, custody moves to Vault Transit on day one.
Isolated signing service
Manifest construction runs in a dedicated Rust service built on c2pa-rs (the Content Authenticity Initiative's reference implementation), reachable only from the API over TLS with a shared service credential — never exposed to the internet.
Credential & account security
Nothing secret is stored in plaintext
API keys, session tokens, and email verification tokens are stored as SHA-256 hashes. Passwords use bcrypt. A database leak does not yield usable credentials.
API keys shown once
Your krsd_ API key is displayed a single time at creation or rotation. We cannot recover it — only replace it.
OAuth done properly
Google and GitHub sign-in use state validation and PKCE, and require verified email addresses. No fake or placeholder login flows.
Payments never touch our servers
Card details go directly to Stripe. Webhook events are verified with constant-time HMAC signature checks and replay-window enforcement; credit grants are idempotent, so a replayed event can never double-credit or double-charge.
Infrastructure posture
TLS everywhere
Public traffic terminates at a hardened reverse proxy with automatic certificates; internal API-to-signer traffic is TLS as well.
Minimal attack surface
Only the API and site are publicly routed. The database, cache, metrics, and Vault are internal-only with no public ports. Intrusion detection (CrowdSec) fronts the proxy.
Resource-bounded signing
The signing service runs with hard memory, CPU, and process limits, and upload sizes are capped — a malicious or malformed file cannot exhaust the host.
Failed signs are free
Metering reserves quota or credits before signing and refunds on any failure. You are only ever charged for signatures that succeeded.
Standards conformance
Standard manifests, standard tools
Signed files carry standards-compliant C2PA manifests — plus IPTC, EXIF, CAWG, PLUS, and XMP metadata where you add it — that verify in Adobe Content Credentials, c2patool, and any other conformant verifier. No Krusade software needed to check authenticity.
Public verification, always free
Anyone can verify any file against our public verify endpoint without an account. Provenance you can't check freely isn't provenance.
Trust anchors refresh independently
Browser verification loads the current C2PA signing and timestamp trust anchors from /api/trust-list. Responses use ETag and max-age caching, so browsers reuse an unchanged list and revalidate it efficiently. An out-of-band service refreshes the mounted anchors from a reviewed, commit-pinned source; the isolated claim generator never fetches trust lists from the internet.
Reference implementation under the hood
Signing and verification are built on c2pa-rs, maintained by the Content Authenticity Initiative, and exercised by an internal conformance test harness on every build.
Questions we haven’t answered?
Security review, compliance questionnaire, or architecture deep-dive — talk to us directly.
Contact us