Why hardware isolation instead of just better software?

If the operating system can read the microphone, any spyware that gets root on the OS can read the microphone too. Hardware isolation binds the microphone bus to the Secure World at boot — the Normal World OS literally cannot reconfigure it.

What is the DMA Air-Gap?

DMA Air-Gap is our patent-pending pattern (UIBM 2026, Patent #1) for binding peripheral DMA descriptors to the Secure World at first boot. The peripheral does not appear as a device to the Normal World. It is the architectural backbone of Q-AUDION's anti-interception guarantee.

Why ML-KEM-1024 and not just AES?

AES is a symmetric cipher — both parties need the same key. ML-KEM-1024 is the key-encapsulation mechanism that lets two parties agree on that AES key without an attacker (even a future quantum one) being able to recover it. Both are used together.

Is the wire identical across Android, iOS, and Desktop?

Yes — byte-identical. We enforce this in CI via Known-Answer-Test vectors that all three platforms must pass before any release.

Technology · Key Management

Sovereign by design. Your keys, not ours.

Name: Q-AUDION
Brand: Q-AUDION

Our Key Management System custodies opaque containers — never their contents. The master key lives in your hands, bound to hardware, verified by you, forever outside our operator perimeter.

Sovereign Key Management

The vault that cannot look inside itself.

Customer

Master Key

Opaque container vault

KMS Vault

Hardware-bound · door opens outward only

Ciphertext out

Opaque · Unreadable

Customer holds the master key. Always.

Server custodies opaque containers. Never the contents.

Zero-knowledge by design. Hardware-bound. BYOK on the roadmap.

The vault door opens only toward the customer. Even a fully compromised server operator cannot derive plaintext — the unwrapping key exists only in the customer's hands and inside hardware-bound boundaries.

Hardware-Bound Identity

Hardware-Rooted Trust, Not Operator Promises

Every device identity key is bound to hardware — Android StrongBox or Apple's Secure Enclave — and paired using Trust-On-First-Use, the same first-contact model used by Signal and WhatsApp. Full per-operation HSM attestation ceremonies, independently verifiable by the customer, are on our roadmap toward FIPS 140-3 Level 2.

Hardware-backed identity keys (StrongBox / Secure Enclave) — live today
Per-operation signed attestations — roadmap
Quorum-based administrative ceremonies — roadmap

BYOK · Key Wrapping (Roadmap)

Bring Your Own Key — Coming to the Sovereign Server

For the Sovereign Server deployment, customers will generate their own master key and wrap our data-encryption keys with it, so no BCrypto operator can produce plaintext without an active customer-side unwrap. This is an active roadmap item, not yet available.

PKCS#11 / KMIP-compatible wrapping protocols — planned
Hybrid post-quantum wrapping (ML-KEM + AES-256-GCM) — planned
Customer revocation designed to be immediate and 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. Session keys are ephemeral and hardware-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 (Roadmap)

Identity Keys, Headed for a Verifiable Public Log

We're building toward a Sigsum transparency log — modeled on Certificate Transparency for the web — so any client could audit the log and detect a server attempting to inject a malicious key into a conversation. Today, identity trust relies on Trust-On-First-Use pairing and out-of-band fingerprint verification; the public transparency log is on our roadmap, not yet live.

Verifiable append-only log of identity public keys — roadmap
Clients would detect key swaps independently of the server — roadmap
Trust-On-First-Use identity pairing — available today

Trust Model

TOFU Today. Introduced & Verified Tiers on the Roadmap.

Contact trust isn't binary. Today, Q-Audion uses Trust-On-First-Use (TOFU) — the same first-contact model used by Signal and WhatsApp — surfaced in the UI for every call. Two additional trust tiers are on our roadmap: INTRODUCED (vouched for by an already-trusted contact) and VERIFIED (out-of-band fingerprint match), designed to let the protocol degrade gracefully even under partial compromise.

TOFU — observed key, surfaced in UI as unverified — live today
INTRODUCED — vouched by a trusted contact — roadmap
VERIFIED — out-of-band fingerprint match — roadmap

See the threat model. Audit the boundary.

Engineering teams and procurement reviewers can request the full KMS technical brief, including our current hardware-bound identity model and the BYOK/Sigsum roadmap.

Request the KMS technical brief