Technology · Key Management
Sovereign by design. Your keys, not ours.
Our Key Management System custodies opaque containers — never their contents. The master key lives in your hands, attested by hardware, verified by you, forever outside our operator perimeter.
Gestione sovrana delle chiavi
Il caveau che non può guardare al suo interno.
Cliente
Master Key · BYOK
Caveau a contenitori opachi
KMS Vault
HSM-attested · apertura solo verso l'esterno
Ciphertext in uscita
Opaco · Illeggibile
Il cliente detiene la chiave master. Sempre.
Il server custodisce contenitori opachi. Mai il contenuto.
Zero-knowledge by design. HSM-attested. BYOK disponibile.
La porta del caveau si apre solo verso il cliente. Anche un operatore del server completamente compromesso non può derivare il plaintext — la chiave di unwrapping esiste solo nelle mani del cliente e all'interno dei confini HSM attestati.
HSM Attestation
Hardware-Rooted Trust, Not Operator Promises
Every key operation is attested by a hardware security module. Each unwrap or signing event produces a cryptographic statement bound to the HSM firmware version, the operator identity, and the policy that authorized the action. Customers verify these attestations independently — trust is not granted to us, it is measured.
- FIPS 140-3 Level 2 target with tamper-evident hardware boundaries
- Per-operation signed attestations, exportable for audit
- Quorum-based administrative ceremonies, no single-operator override
BYOK · Key Wrapping
Bring Your Own Key. Wrap Ours With Yours.
Customers generate the master key on their own HSM or air-gapped ceremony, then wrap our data-encryption keys with it. The wrapping key never leaves the customer perimeter. Even with full administrative access to our infrastructure, no operator can produce plaintext without an active customer-side unwrap call.
- PKCS#11 / KMIP-compatible wrapping protocols
- Hybrid post-quantum wrapping (ML-KEM + AES-256-GCM)
- Customer revocation = immediate, irreversible, server-side
Zero-Knowledge Custody
The Vault Door Opens Outward, Never Inward
Encrypted containers enter the KMS. Encrypted containers leave the KMS. Nothing inside the server can derive their plaintext. Our control plane authorizes container movement and access policy; the data plane never sees keys in the clear. Forward-secret session keys are ephemeral and HSM-bound.
- Zero-knowledge architecture: server compromise ≠ data compromise
- Forward-secret session protocol with ephemeral DH exchange
- No backdoors, no master-recovery, no escrow surface
Sigsum Key Transparency
Identity Keys in a Verifiable Public Log
Every identity public key Q-Audion mints is appended to a Sigsum transparency log — modeled on Certificate Transparency for the web. Any client can audit the log and detect a server attempting to inject a malicious key into a conversation. Trust is observable, not promised: a malicious server cannot silently swap an identity key without leaving a public, append-only record.
- Verifiable append-only log of identity public keys
- Clients detect key swaps independently of the server
- Sealed Sender envelope hides sender identity from the server itself
3-Factor Trust Model
TOFU + INTRODUCED + VERIFIED
Contact trust is not binary. Q-Audion assigns one of three levels: TOFU (Trust On First Use — observed but unverified), INTRODUCED (vouched for by an already-trusted contact), VERIFIED (out-of-band fingerprint match). UI surfaces the level for every call; the protocol degrades gracefully when any single factor is undermined. Combined with hardware-rooted key custody and Sigsum transparency, an attacker needs to compromise all three independent dimensions to escalate impersonation.
- TOFU — observed key, surfaced in UI as unverified
- INTRODUCED — vouched by a contact already at VERIFIED
- VERIFIED — out-of-band fingerprint match, highest tier
See the threat model. Audit the boundary.
Engineering teams and procurement reviewers can request the full KMS technical brief, including HSM attestation flows and BYOK ceremony scripts.
Request the KMS technical brief