Sicherheit ist die Architektur, kein nachträglicher Gedanke.
Q-Audion ist von der ersten Codezeile an Ende-zu-Ende verschlüsselt, mit einem hybriden klassischen und post-quantensicheren Schlüsselaustausch, hardwaregebundener Schlüsselspeicherung auf jeder Plattform und einem Engineering-Prozess, der sich an veröffentlichten, unabhängig verfassten Sicherheitsstandards misst.
Ein hybrider Schlüsselaustausch für die nächsten zwanzig Jahre, nicht nur für heute.
Jede Sitzung ist durch zwei unabhängige kryptografische Probleme gleichzeitig geschützt. Sie zu brechen — auch mit einem künftigen Quantencomputer — bedeutet, beide zu brechen.
Post-Quanten-Schlüsselvereinbarung
ML-KEM-1024, der vom NIST standardisierte Post-Quanten-Schlüsselkapselungsmechanismus (FIPS 203), kombiniert mit klassischem X25519 in einer Hybridkonstruktion — die Sicherheit fällt nie unter das, was X25519 allein bereits garantiert.
FIPS 203 · Kategorie 5Authentifizierte Identität
Jedes Gerät signiert sein eigenes Schlüsselmaterial mit Ed25519 (RFC 8032). Die Identität ist Ende-zu-Ende verifizierbar — auch persönlich, per Safety-Number-Vergleich und NFC-Tap-to-Verify.
Hardwaregebundene Schlüssel
Privates Schlüsselmaterial wird innerhalb von StrongBox auf Android und der Secure Enclave auf iOS erzeugt und verwendet, wo immer das Gerät dies unterstützt — das Schlüsselmaterial selbst verlässt diese Hardware-Grenze nie.
Sitzungen mit Forward Secrecy
Nachrichten- und Anrufschlüssel rücken kontinuierlich per Ratchet weiter. Ein zu einem bestimmten Zeitpunkt kompromittierter Schlüssel legt weder frühere noch spätere Gespräche offen.
Darauf ausgelegt, möglichst wenig von dir preiszugeben.
Datenschutzpannen sind fast immer Metadaten-Pannen. Unsere Serverinfrastruktur ist darauf ausgelegt, so wenig wie möglich darüber zu wissen, wer mit wem spricht.
Versiegelter Absender
Push-Benachrichtigungen tragen eine opake, gesalzene Kennung — nie einen Absendernamen, eine Inhaltsvorschau oder irgendetwas, das eine Benachrichtigungs-Pipeline außerhalb unserer Kontrolle lesen könnte.
Verschlüsselte Anhänge
Fotos, Sprachnachrichten und Dateien werden mit XChaCha20-Poly1305 versiegelt, noch bevor sie das Gerät verlassen, und danach unter einer zweiten, hardwaregebundenen AES-256-GCM-Schicht gehalten, solange sie auf der Festplatte zwischengespeichert sind.
Flüchtig nach Wahl
Timer für verschwindende Nachrichten und Anhänge werden auf jeder Plattform auf dieselbe Weise durchgesetzt, wobei die Geräte der Gegenseite synchron gehalten werden.
Telefonnummern, gehasht
Die Kontaktermittlung arbeitet mit einem gesalzenen Einweg-Hash der Telefonnummer — nie mit der Rohnummer selbst —, sodass Kontaktlisten für den Dienst, der sie abgleicht, unlesbar bleiben.
Die Teile, die man nie sieht, am selben Maßstab gemessen.
Ein Messenger ist nur so vertrauenswürdig wie die Pipeline, die ihn baut und ausliefert. Jeder Commit durchläuft dieselben automatisierten Gates, bevor er ein Gerät erreicht.
Certificate Pinning, laufend geprüft
Jeder Client pinnt das TLS-Zertifikat des Servers — und ein automatisierter täglicher Job überprüft unabhängig, ob das Live-Zertifikat noch mit dem gepinnten übereinstimmt, auf jeder Plattform, sodass Drift am selben Tag erkannt wird.
Gepinnte, verifizierte Abhängigkeiten
Jede Drittanbieter-Bibliothek ist auf eine exakte, per Prüfsumme verifizierte Version festgelegt. Ein Build kann nicht mit einer ungepinnten oder unverifizierten Abhängigkeit gemergt werden — die Pipeline lehnt es automatisch ab.
Kontinuierliches Security-Scanning
Der Quellcode jedes Clients und des Servers durchläuft fortlaufend automatisierte Sicherheitsscans, die nach den Schwachstellenklassen suchen, die für eine vernetzte, kryptografische Anwendung am wichtigsten sind.
Secrets nie im Quellcode
Produktions-Credentials existieren nur in der Laufzeitumgebung der Maschine, die sie benötigt, injiziert beim Prozessstart — nie committet, nie in eine Konfigurationsdatei im Repository geschrieben.
Wir messen uns am selben Maßstab wie ein Auditor.
Statt eine eigene Definition von „sicher" zu erklären, halten wir unseren Engineering-Prozess an Rahmenwerken fest, die von der breiteren Security-Community geschrieben und gepflegt werden — und bewerten uns neu, während sich das Produkt weiterentwickelt.
Die Branchenreferenz dafür, was eine sicherheitsbewusste mobile App richtig machen sollte — von lokaler Datenspeicherung über Plattforminteraktion bis zur Kryptografie.
Angewendet auf unsere Backend-Dienste: Authentifizierung, Session-Handling, Zugriffskontrolle und API-Design, geprüft anhand derselben Checkliste, die unabhängige Auditoren verwenden.
Leitet, wie wir als Engineering-Organisation steuern, identifizieren, schützen, erkennen, reagieren und wiederherstellen — nicht nur, wie ein einzelnes Feature codiert wird.
So ist das zu lesen: Dies sind interne Selbstbewertungen, durchgeführt anhand öffentlich veröffentlichter Rahmenwerke und aktualisiert, während sich die Codebasis ändert — kein von einem Dritten ausgestelltes Zertifikat. Wo für eine unserer Aussagen ein formales, unabhängig geprüftes Siegel existiert, nennen wir den Auditor und verlinken den Nachweis direkt.
Kontakt
Wird hier zusammen mit dem Public-Key-Block vor dem öffentlichen 1.0 Release veröffentlicht.
Eine Draft Security Advisory im Security-Tab des relevanten Q-Audion-Repositorys öffnen (GitHub Private Vulnerability Reporting).
Unsere Verpflichtungen
- Bestätigung innerhalb 48 Geschäftsstunden nach Erhalt
- Triage und Schweregradklassifikation innerhalb 5 Werktagen
- 90-Tage Coordinated-Disclosure-Fenster Standard, nur mit Reporter-Zustimmung verlängert wenn ein komplexer Fix erforderlich
- Öffentliche Anerkennung in Release Notes sofern keine Anonymität gewünscht
Bug Bounty
Ein gemanagtes Bug-Bounty-Programm wird vor dem öffentlichen 1.0 Release live gehen. Bis dahin bieten wir gutgläubige Belohnungen fallweise für High-Impact-Findings.
Scope
- +Gesamter Q-Audion Server-Code (Identität, Key-Management, Transport, Gruppen, Prekeys, File Storage)
- +Alle veröffentlichten Q-Audion Clients auf Android, iOS und Desktop (Windows / macOS / Linux wenn ausgeliefert)
- +Kryptografisches Protokolldesign (PQ-Handshake, Post-Quanten-Double-Ratchet, Schutz der Absender-Metadaten, Sigsum Key Transparency)
- +Wire-Spec-Drift, die plattformübergreifendes unsicheres Verhalten verursacht
- −Probleme, die physischen Zugriff auf entsperrtes Gerät erfordern
- −Selbst zugefügte XSS ohne Überschreitung einer Trust-Boundary
- −Veraltete Browser-/OS-Versionen außerhalb der Hersteller-Support-Fenster
- −Volumetrische DDoS ohne Logic Flaw
- −Social Engineering von Q-Audion-Personal
- −Reports basierend auf automatisiertem Scanner-Output ohne funktionierendes Proof-of-Concept
Offene Wire Specification
Der plattformübergreifende Protokollvertrag ist byte-identisch über alle Q-Audion Clients. Die Spec ist über die Client-Repositorys und das Server-Repository als Gating Commit für jede Wire-Änderung gespiegelt. Unabhängige Prüfer können sie vor dem Öffnen einer Session lesen — und Library-Implementierungen (liboqs, BouncyCastle, @noble/post-quantum) werden gegen geteilte KAT-Vektoren kreuzvalidiert.
Reproduzierbare Builds (1.0-Ziel)
Alle 1.0 Release-Artefakte (APK, IPA, Desktop-Installer) werden Sigstore-signiert. Unabhängige Reproduzierbarkeit aus dem Quellcode ist ein Release-Go-Kriterium: jeder kann verifizieren, dass das ausgelieferte Binary mit dem öffentlichen Quellcode übereinstimmt.