Auditbefunde

TalX wird laufend intern geprüft: Quellcode-Review des Krypto-Kerns, vollständige Test- und Lint-Läufe, ein Release-Build mit Laufzeitprüfung und ein fortlaufender Feldtest auf zwei realen Geräten. Diese Seite führt die Befunde auf – die behobenen und die offenen.

Stand des letzten Kryptografie-Audits

12behoben
1hoch, offen
0niedrig, offen
6akzeptiert oder informativ

Befundübersicht

ID	Titel	Schwere	Status
F-01	Kein X3DH – statischer initialer Ratchet-Wurzelschlüssel	Mittel	behoben
F-02	WebRTC-Verbindungsdaten über rohen statischen Schlüssel	Niedrig	behoben
F-03	Backup-Schlüsselableitung nicht speicherhart	Niedrig	behoben
F-04	Gruppen: Sender-Keys rotierten nicht periodisch	Niedrig	behoben
F-05	Keystore-Schlüssel nicht an Nutzer-Authentifizierung gebunden	Niedrig	akzeptiert
F-06	Relay sieht Metadaten (wer mit wem, wann)	Information	akzeptiert
F-07	Kein unabhängiges externes Krypto-Audit	Hoch	offen
F-08	Exportierbarer privater Identitätsschlüssel bei Geräteverknüpfung	Information	gemindert
F-09	ML-KEM liefert bei manipulierter Kapsel still ein anderes Geheimnis	Information	akzeptiert
F-10	Zustell-Stillstand nach einseitigem Sitzungs-Reset	Mittel	behoben
F-11	Message-Key-Verbrauch durch Wiederholungen → Überlauf	Mittel	behoben
F-12	Anwesenheit im lokalen Netz per mDNS sichtbar	Information	akzeptiert
F-13	Anruf- und Verbindungssignale ohne Frischenachweis	Information	akzeptiert
F-14	Server-Zugangsdaten unverschlüsselt in den App-Einstellungen	Niedrig	aufgelöst
F-15	Post-Quanten-Austausch lief über den Ratchet (Henne-Ei-Sperre)	Mittel	behoben
F-16	Datenverbindung aktivierte das Mikrofon; Audiositzung blieb offen	Mittel	behoben
F-17	Geisteranruf durch veraltete Annehmen-Intents	Mittel	behoben
F-18	Duplizierte Neustart-Anfragen entwerteten das Post-Quanten-Geheimnis	Niedrig	behoben
F-19	Kontaktlöschung ließ Gruppen-Schlüsselmaterial zurück	Niedrig	behoben

Die offenen und akzeptierten Punkte im Klartext

F-07 · Kein unabhängiges externes Krypto-Audit Hoch

Der Krypto-Kern ist nur intern und werkzeuggestützt geprüft. Für ein Sicherheitsprodukt ist das keine hinreichende Grundlage für belastbare Aussagen gegenüber Nutzern: Betriebsblindheit und subtile Protokollfehler lassen sich intern nur begrenzt ausschließen.

Empfehlung, so wie sie im Auditbericht steht: Vor jeder 1.0- oder Produktivaussage ein unabhängiges Audit durch ein spezialisiertes Labor beauftragen – Schwerpunkte Ratchet-Bootstrap, PAKE-Choreografie, Post-Quanten-Integration, Anruf- und Medien-Signalisierung, Relay-Protokoll.

Das ist der Grund, warum diese Website an keiner Stelle behauptet, TalX sei sicherheitsgeprüft. Auf der Roadmap steht es an erster Stelle.

F-05 · Keystore-Schlüssel nicht an Nutzer-Authentifizierung gebunden

Der Wickel-Schlüssel entschlüsselt Datenbank, Identität und Anhänge – und ist bewusst ohne Bindung an eine Nutzer-Entsperrung angelegt, damit der Hintergrunddienst auch bei gesperrtem Gerät empfangen kann.

Bei physischem Zugriff auf ein entsperrbares Gerät sinkt dadurch die Hürde. Gemindert durch die separate App-Sperre. Ein getrennter, auth-gebundener Schlüssel für besonders sensible Teile steht als optionale Maßnahme im Bericht.

F-06 · Relay sieht Metadaten

Der Relay bekommt ausschließlich Ciphertext und Kennungen und kann Inhalte nicht lesen. Er sieht jedoch, welche Kennungen wann miteinander kommunizieren. Das ist für serverbasierte Zustellung inhärent. Minderung: den Relay selbst betreiben oder TalX rein offline über die Nahfunk-Wege nutzen.

F-09 · Stille Fehlkapsel bei ML-KEM

ML-KEM liefert bei einer manipulierten, aber längenkorrekten Kapsel keinen Fehler, sondern ein abweichendes Geheimnis – das ist Absicht im FIPS-203-Entwurf. Eine untergeschobene Kapsel führt daher nur zu auseinanderlaufenden Ableitungen, nicht zu einer verwertbaren Kompromittierung. Unkritisch, weil die Kapsel authentifiziert transportiert wird.

F-12 · Anwesenheit im lokalen Netz

Der LAN-Transport kündigt sich per mDNS an; Dienstname und Begrüßung tragen die eigene Kennung. Jeder im selben Netz sieht damit, welche TalX-Identitäten anwesend sind – Inhalte bleiben verschlüsselt. Das entspricht dem Metadaten-Niveau des Relays, nur lokal statt serverseitig. Akzeptiert für das Heimnetz-Szenario; ephemere, pro Sitzung rotierende Dienstkennungen sind als spätere Härtung vorgesehen.

F-13 · Signalisierung ohne Frischenachweis

Anrufsignale und Verbindungsdaten sind authentifiziert verschlüsselt, tragen aber keinen Frischenachweis. Ein Netzbeobachter kann aufgezeichnete Blöcke erneut zustellen; schlimmstenfalls stört das ein laufendes Gespräch. Der Annehmen-Pfad ist zusätzlich gegen wiederholte Intents abgesichert.

F-08 · Der exportierte Identitätsschlüssel

Für die Geräteverknüpfung wird der private Identitätsschlüssel exportiert und übertragen – das Kronjuwel. Es geschieht ausschließlich nach erfolgreichem J-PAKE und verschlüsselt mit dem dabei ausgehandelten Schlüssel. Restrisiko: Ein aktiver Angreifer, der die Vermittlung kontrolliert und den Code beobachtet hat, bekommt genau einen Online-Rateversuch. Der Nutzerhinweis „Code nur dem eigenen Gerät nennen“ bleibt deshalb bestehen.

Was die internen Prüfungen seither noch gefunden haben

Die Prüfungen laufen weiter, und sie fördern weiter Dinge zutage. Das spricht für die Prüftiefe – und zugleich dafür, dass eine junge Codebasis solche Funde eben noch produziert. Eine Auswahl der gewichtigsten seit dem letzten Kryptografie-Audit:

Was gefunden wurde	Warum es zählte
Anhänge kamen gar nicht an. Der Empfangspuffer verwarf unter Last lautlos Stücke; im Sendepfad verschluckte eine kurzgeschlossene Bedingung den Rest der Übertragung.	Datenverlust ohne jede Fehlermeldung – die schlimmste Sorte.
Gruppennachrichten gingen nach einer Kettenlücke still verloren. Der Absender wiederholte 30-mal denselben Block, den die Gegenseite nachweislich nie öffnen konnte.	Zehn Minuten Funkverkehr für ein garantiert unmögliches Ergebnis, danach war die Nachricht weg.
Gruppen-Entschlüsselfehler waren komplett stumm – keine einzige Protokollzeile.	Ohne Faden zum Ziehen kostete die Fehlersuche Stunden. Heute wird der Fehlschlag protokolliert, mit Metadaten, nie mit Schlüsseln oder Inhalten.
Ein garantierter Deadlock-Zyklus im Krypto-Kern. Zwei Wege führten durch dieselben zwei Sperren in entgegengesetzter Reihenfolge.	Nie beobachtet, weil die heutige Startreihenfolge zufällig daran vorbeiläuft – aber eine umsortierte Zeile hätte gereicht. Ein Deadlock beim Start ist ein nicht reproduzierbarer Absturz.
Nach einem Neu-Pairing kam minutenlang nichts an, weil ein veralteter Prekey den Schlüsselwechsel überlebte.	Der Fehler sah aus wie ein Netzproblem und war keins.
Halbstände bei Geräteverknüpfung und Wiederherstellung. Ein Abbruch mittendrin hinterließ einen Teilbestand.	Beides ist heute alles-oder-nichts.
Zip-Slip beim Modell-Download und ein ungeprüftes Modellarchiv.	Behoben, plus fest eingebaute Prüfwerte.
Aufbewahrte Message-Keys verfielen nie.	Sie verfallen jetzt nach sieben Tagen.
Ein aufbewahrter Schlüssel wurde verworfen, BEVOR die Prüfung lief. Der Ratchet-Kopf liegt im Klartext auf der Leitung – wer einen Ciphertext mitschneidet und ein einziges Byte des Rumpfes ändert, adressiert denselben aufbewahrten Schlüssel und lässt die Prüfung scheitern.	Der Schlüssel war danach weg und die echte Nachricht dauerhaft unlesbar. Im Anhang-Pfad reichte dafür sogar eine volle Festplatte. Heute wird erst entschlüsselt und danach verworfen.
Eine wiederholte Erstnachricht drehte die laufende Sitzung zurück. Der Bootstrap-Fallback konnte die allererste Nachricht einer längst laufenden Sitzung nicht von einem echten Neuaufbau unterscheiden.	Für den Betreiber der Vermittlung wäre das ein Abschaltknopf pro Chat gewesen – ganz ohne Schlüsselmaterial, nur durch erneutes Ausliefern einer gespeicherten Nachricht. Die Sitzung merkt sich jetzt, aus welchem Schlüssel der Gegenseite sie entstanden ist.

Jeder dieser Punkte hat einen Regressionstest bekommen, der gegen den alten Code nachweislich fehlschlägt.

Testabdeckung

Stand 0.85.3: 160 Testfälle in 27 Klassen auf der JVM und 131 Testfälle in 40 Klassen auf echter Android-Laufzeit.

Unit-Tests auf der JVM, je Debug- und Release-Variante: J-PAKE, ML-KEM, Kompression, Protokoll- und Wire-Kompatibilität, LAN-Framing samt Grenzen, Gruppen-Forward-Secrecy, Chatlisten-Vorschau und -Sortierung, Modell-Integrität, Übertragungsgrenzen.
Instrumentierte Tests auf echter Android-Laufzeit: AES-GCM mit Zusatzdaten, Anhangsformate, Einmal-Subkeys, Double Ratchet inklusive Prekey-Bootstrap, Post-Quanten-Übergang, periodische Gruppenrotation, Backup mit beiden Ableitungsverfahren, Sicherheitsnummer, kompletter J-PAKE-Handshake, Ratchet-Selbstheilung, Abwehr von Geisteranrufen, Aufräumen bei Kontaktlöschung, Sperrreihenfolge im Keystore, Datenbank-Migrationen.
Zwei-Geräte-Feldtest auf realer Hardware: Zustellung mit Bestätigung in beide Richtungen, Direktverbindung im lokalen Netz, Sprach- und Videoanruf im reinen WLAN, Analyse der Audiositzungen vor, während und nach einem Anruf.
Android-Lint ohne Fehler im Krypto-Kern.
Release-Build mit Verschleierung: baut, installiert und lädt die Krypto-Klassen zur Laufzeit korrekt.

Krypto- und Datenbanktests laufen bewusst nicht als reine JVM-Tests: Sie brauchen den echten Android-Keystore und die native Datenbankbibliothek.