Zero-knowledge you can audit, not just believe

What zero-knowledge means (and does NOT mean)

Zero-knowledge means THE SERVICE cannot read your secrets: every secret is encrypted on your machine or device before it leaves it, and the server only ever sees sealed envelopes.

It does not mean nobody can read them: you (via your controller identity), your verified devices, and whoever holds your recovery code can. The promise is made against Koove — which is why it's verifiable in open source rather than an act of faith.

How each secret is encrypted

Envelope encryption with modern, audited primitives (@noble): each secret is encrypted once with a random data key (DEK) using AES-256-GCM; that DEK is sealed for each authorized recipient with their X25519 public key (ECDH + HKDF-SHA256).

The server stores the ciphertext and the sealed DEKs. Authorizing a device, revoking one, or rotating keys is always a client-side re-wrap by an authorized identity — never the server, which holds no private keys.

The primitives are open source in @koove/crypto: the tests pin the cryptographic layout against independent vectors.

Only verified devices decrypt

A mobile device becomes an eligible recipient only after passing real cryptographic attestation: Apple App Attest and Google Play Integrity — both verified end-to-end on physical devices. The server verifies the certificate chain against Apple's/Google's root and binds the proof to the device's public key.

Local decryption is additionally gated by biometrics (Face ID / fingerprint). The challenge→key binding is computed by a single implementation shared by iOS, Android and the server — it cannot diverge.

Recovery and revocation — with the honest limit

Every app has two permanent recipients: a controller identity (your tooling, never on our server) to approve devices and execute the cryptographic kill, and a recovery identity derived from a 24-word BIP39 code shown ONCE and never stored.

Revoking a device removes it from discovery immediately (no new secrets, nothing served) and the cryptographic kill strips it from every existing envelope.

The honest limit: no system can "un-deliver" a plaintext a device already decrypted and cached. For a total kill, rotate the secret's value. We say this here, in the CLI and in the docs — distrust anyone promising instant revocation.

Defense in depth on the server

The client is never trusted: attestation, biometrics and pinning raise the attacker's cost, but real control lives server-side where a compromised client cannot fake it.

Anomaly detection over the audit trail (new IPs, read velocity, repeated failed attestations), canary honeytokens (reading a decoy = confirmed breach, immediate alert), fail-closed shared rate limiting, and an exportable audit log.

Open-core: proof of the promise

Everything that runs on YOUR side is open source and auditable: the encryption primitives (@koove/crypto), the CLI writer (@koove/secrets-cli) and the mobile SDK (@koove/sdk), published on npm and GitHub.

What's closed is our control plane (attestation verification, anomaly engine, dashboard) — which by design never sees a plaintext secret.

Evidence you can verify today (don't take our word)

Code origin: our npm packages carry SLSA provenance attestations — published via OIDC from GitHub Actions, no tokens. Check it: `npm view @koove/crypto dist.attestations`.

No install scripts: our packages run no install-time scripts (`preinstall`/`postinstall`) — zero supply-chain surface, aligned with npm's new default.

iOS attestation verified on physical hardware (real App Attest, certificate chain to Apple's pinned root, no dev bypass); Android attestation also verified on physical hardware (real Play Integrity, MEETS_DEVICE_INTEGRITY verdict, no dev bypass). We also document the negative case: a non-recipient device CANNOT decrypt.

Responsible disclosure: we publish a /.well-known/security.txt and a safe-harbor VDP.

Public threat model: we document what we guarantee, how, and what we do NOT — at github.com/kooveio/koove-crypto (SECURITY-MODEL.md).

Compliance: where we are today (honest roadmap)

Honesty first: Koove does NOT hold SOC 2 or ISO 27001 certification today. What we offer today is stronger than a badge: an architecture where the provider cannot read your data, with the client code open for your team to verify.

Dated roadmap: an independent cryptographic audit of @koove/crypto (target H2 2026, we'll publish the full report) → organizational certification (ISO 27001 / SOC 2) once a contract requires it. We'll update this page at each milestone.

Payments via Stripe (PCI-DSS Level 1); Koove never sees your card. We're an EU company: a subprocessor list and DPA are available.