Warum Hardware-Isolation statt nur besserer Software?

Wenn das Betriebssystem das Mikrofon lesen kann, kann jede Spyware mit Root-Rechten dies ebenfalls. Hardware-Isolation bindet den Mikrofon-Bus beim Booten an die Secure World — die Normal World kann ihn schlicht nicht rekonfigurieren.

Was ist der DMA Air-Gap?

DMA Air-Gap ist unser patentangemeldetes Muster (UIBM 2026, Patent #1) zur Bindung von Peripherie-DMA-Deskriptoren an die Secure World beim ersten Boot. Die Peripherie erscheint der Normal World nicht als Gerät. Es ist das architektonische Rückgrat der Abhörsicherheits-Garantie von Q-AUDION.

Warum ML-KEM-1024 und nicht nur AES?

AES ist eine symmetrische Chiffre — beide Parteien benötigen denselben Schlüssel. ML-KEM-1024 ist der Schlüsselkapselungsmechanismus, mit dem sich zwei Parteien auf diesen AES-Schlüssel einigen, ohne dass ein Angreifer (selbst ein zukünftiger Quantencomputer) ihn wiederherstellen kann. Beide werden gemeinsam verwendet.

Ist die Wire-Spezifikation über Android, iOS und Desktop identisch?

Ja — byte-identisch. Wir erzwingen dies in CI über Known-Answer-Test-Vektoren, die alle drei Plattformen vor jedem Release bestehen müssen.

Technologie · Key Management

Souverän by design. Ihre Schlüssel, nicht unsere.

Name: Q-AUDION
Brand: Q-AUDION

Unser Key Management System verwahrt opake Container — niemals deren Inhalte. Der Master-Schlüssel liegt in Ihren Händen, hardware-gebunden, von Ihnen verifiziert, für immer außerhalb unseres Operator-Perimeters.

Souveränes Schlüsselmanagement

Der Tresor, der nicht in sich selbst hineinschauen kann.

Kunde

Master Key

Tresor mit opaken Behältern

KMS Vault

Hardware-gebunden · Tür öffnet nur nach außen

Ciphertext-Ausgang

Opak · Unlesbar

Der Kunde hält den Master Key. Immer.

Der Server verwahrt opake Behälter. Niemals deren Inhalt.

Zero-Knowledge by Design. Hardware-gebunden. BYOK auf der Roadmap.

Die Tresortür öffnet sich nur zum Kunden hin. Selbst ein vollständig kompromittierter Server-Betreiber kann keinen Plaintext ableiten — der Unwrapping-Key existiert ausschließlich in den Händen des Kunden und innerhalb hardware-gebundener Grenzen.

Hardware-gebundene Identität

Hardware-verankertes Vertrauen statt Betreiberversprechen

Jeder Geräte-Identitätsschlüssel ist an Hardware gebunden — Android StrongBox oder Apples Secure Enclave — und wird per Trust-On-First-Use gekoppelt, demselben Erstkontakt-Modell, das Signal und WhatsApp verwenden. Vollständige HSM-Attestierungszeremonien pro Operation, unabhängig vom Kunden verifizierbar, stehen auf unserer Roadmap in Richtung FIPS 140-3 Level 2.

Hardware-gestützte Identitätsschlüssel (StrongBox / Secure Enclave) — bereits heute im Einsatz
Signierte Attestierungen pro Operation — Roadmap
Quorum-basierte administrative Zeremonien — Roadmap

BYOK · Key Wrapping (Roadmap)

Bring Your Own Key — kommt auf den Sovereign Server

Für die Sovereign-Server-Bereitstellung werden Kunden ihren eigenen Master-Schlüssel erzeugen und damit unsere Datenverschlüsselungsschlüssel wrappen, sodass kein BCrypto-Operator ohne einen aktiven kundenseitigen Unwrap Plaintext erzeugen kann. Dies ist ein aktives Roadmap-Vorhaben, noch nicht verfügbar.

PKCS#11 / KMIP-kompatible Wrapping-Protokolle — geplant
Hybrides Post-Quanten-Wrapping (ML-KEM + AES-256-GCM) — geplant
Kunden-Widerruf, ausgelegt auf sofortige, serverseitige Wirkung

Zero-Knowledge-Verwahrung

Die Tresortür öffnet sich nach außen, niemals nach innen

Verschlüsselte Container betreten das KMS. Verschlüsselte Container verlassen das KMS. Nichts innerhalb des Servers kann deren Plaintext ableiten. Unsere Control Plane autorisiert Container-Bewegungen und Zugriffs-Policies; die Data Plane sieht Schlüssel niemals im Klartext. Session-Schlüssel sind ephemer und hardware-gebunden.

Zero-Knowledge-Architektur: Server-Kompromittierung ≠ Daten-Kompromittierung
Forward-secret Session-Protokoll mit ephemerem DH-Austausch
Keine Backdoors, kein Master-Recovery, keine Escrow-Angriffsfläche

Sigsum Key Transparency (Roadmap)

Identitätsschlüssel, auf dem Weg in ein verifizierbares öffentliches Log

Wir arbeiten auf ein Sigsum-Transparenz-Log hin — nach dem Vorbild der Certificate Transparency des Web —, sodass jeder Client das Log auditieren und einen Server erkennen könnte, der versucht, einen bösartigen Schlüssel in eine Konversation zu injizieren. Heute beruht das Identitätsvertrauen auf Trust-On-First-Use-Kopplung und Out-of-band-Fingerprint-Verifizierung; das öffentliche Transparenz-Log steht auf unserer Roadmap, ist noch nicht live.

Verifizierbares Append-only-Log der Identitäts-Public-Keys — Roadmap
Clients würden Schlüsselaustausch unabhängig vom Server erkennen — Roadmap
Trust-On-First-Use-Identitätskopplung — bereits heute verfügbar

Trust-Modell

TOFU heute. Stufen INTRODUCED & VERIFIED auf der Roadmap.

Kontaktvertrauen ist nicht binär. Heute verwendet Q-Audion Trust-On-First-Use (TOFU) — dasselbe Erstkontakt-Modell wie Signal und WhatsApp —, in der UI für jeden Anruf angezeigt. Zwei zusätzliche Vertrauensstufen stehen auf unserer Roadmap: INTRODUCED (verbürgt durch einen bereits vertrauten Kontakt) und VERIFIED (Out-of-band-Fingerprint-Abgleich), konzipiert, damit das Protokoll selbst bei partieller Kompromittierung kontrolliert degradiert.

TOFU — beobachteter Schlüssel, in der UI als unverifiziert angezeigt — bereits heute im Einsatz
INTRODUCED — verbürgt durch einen vertrauten Kontakt — Roadmap
VERIFIED — Out-of-band-Fingerprint-Abgleich — Roadmap

Sehen Sie das Threat Model. Auditieren Sie die Grenze.

Engineering-Teams und Beschaffungsprüfer können das vollständige technische KMS-Briefing anfordern, einschließlich unseres aktuellen hardware-gebundenen Identitätsmodells und der BYOK/Sigsum-Roadmap.

Technisches KMS-Briefing anfordern