Ein Hack des Messenger-Servers bedeutet nicht zwangsläufig, dass alle Nachrichten gelesen wurden. Das Ergebnis hängt von den gespeicherten Daten, dem Speicherort der Schlüssel und den Zugriffsrechten des Angreifers ab. Selbst wenn Chattexte korrekt Ende-zu-Ende-verschlüsselt sind, können Kontoinformationen, Zeitangaben, Gruppenmitgliedschaften und Zustellwege sensibel sein.
Fragen Sie bei der Bewertung eines Vorfalls zunächst, was der Angreifer erlangt hat: eine Datenbankkopie, Infrastrukturschlüssel, einen laufenden Server oder das System zur Softwareverteilung? Diese Szenarien haben unterschiedliche Folgen.
Eine gestohlene Datenbank ist nicht dasselbe wie ein kontrollierter Server
Ein Angreifer, der nur eine alte Datenbankkopie besitzt, ist auf die dort gespeicherten Daten beschränkt. Die Kontrolle über den laufenden Dienst kann die Erfassung neuer Daten, den Diebstahl von Sitzungen, die Veränderung von Antworten oder Versuche zum Austausch eines Kontaktschlüssels ermöglichen. Zugriff auf die Software-Lieferkette birgt ein weiteres Risiko: Schadcode auf einem Endpunkt kann Klartext vor der Verschlüsselung oder nach der Entschlüsselung sehen.
Die Aussage „Die Datenbank enthält keinen Schlüssel zum Lesen der Nachrichtentexte“ ist daher wichtig, beantwortet aber nicht alle Arten von Eindringversuchen vollständig.
Vergleich von fünf Architekturmustern
Dies sind Lehrbeispiele, keine Rangliste von fünf Produkten. Ein Dienst kann für verschiedene Funktionen mehrere Muster nutzen.
| Muster | Über die Datenbank zugängliche Daten | Wichtige Grenze |
|---|---|---|
| Nachrichten und Passwörter im Klartext | Inhalte und Zugangsdaten sind direkt lesbar | Beide Datentypen sind unzureichend geschützt |
| Gehashte Passwörter, Nachrichten im Klartext | Inhalte sind lesbar; Passwortvermutungen können möglicherweise geprüft werden | Gute Passwortspeicherung schützt keine Chattexte |
| Mit einem Serverschlüssel verschlüsselte Inhalte | Chiffretext; die Lesbarkeit hängt vom Schlüsselzugriff ab | Tatsächliche Trennung von Schlüsseln und Daten ist wichtig |
| E2EE-Chat mit für den Anbieter zugänglichem Backup | Der laufende Chat kann geschützt sein, doch die Verlaufskopie eröffnet einen eigenen Offenlegungspfad | Backup-Richtlinie und Schlüssel müssen geprüft werden |
| E2EE-Chat mit verschlüsselter Wiederherstellung und unabhängigem Schlüssel | Chiffretext und Betriebsdaten; der Inhaltsschutz hängt von Entwurf und Schlüsselschutz ab | Gerät, Wiederherstellungsphrase und Kontaktauthentifizierung bleiben wichtig |
Die Verschlüsselung von Serverdatenträgern hilft gegen den Diebstahl eines rohen Datenträgers. Verfügt der Angreifer auch über den laufenden Dienst oder den Entschlüsselungsschlüssel, darf derselbe Schutz nicht vorausgesetzt werden. E2EE soll sicherstellen, dass der vermittelnde Dienst nicht den Schlüssel zum Lesen geschützter Inhalte besitzt.
Was verraten Metadaten?
Metadaten können zeigen, welche Konten miteinander kommuniziert haben, wann sie aktiv waren, welchen Gruppen sie angehören und wie viele Daten übertragen wurden. Das sind keine Nachrichtentexte, aber wertvolle Informationen über Kommunikationsnetze und Aktivitätsmuster.
Die Sicherheitsseite von Livara beschreibt ausdrücklich die Speicherung und Verarbeitung von Betriebsdaten, darunter Routing, Mitgliedschaften, Zeitangaben, Chiffretextgrößen und Zustellstatus. Vertraulichkeit privater Inhalte darf nicht als vollständige Anonymität oder völlige Abwesenheit von Serverdaten verstanden werden.
SRP schützt Kontodaten nicht vor allen Rateangriffen
SRP ermöglicht den Nachweis, dass man ein Passwort kennt, ohne das Passwort selbst direkt zu übertragen. Der Server speichert weiterhin Prüfdaten, einen sogenannten Verifier. Der Sicherheitsabschnitt von RFC 5054 erläutert, dass ein gestohlener Verifier einen Wörterbuchangriff zum Erraten des Passworts ermöglichen kann.
„Das Passwort wird nicht über das Netzwerk übertragen“ ist also etwas anderes als „Es gibt keine passwortbezogenen Daten, die gestohlen werden können“. Ein starkes, einzigartiges Passwort, Geräteschutz und eine angemessene Reaktion auf Vorfälle bleiben erforderlich. SRP ersetzt auch weder Inhaltsverschlüsselung noch den Schutz von Anmeldesitzungen.
Welche Grenzen nennt Livara?
Livara beschreibt in seinem Sicherheitsdokument LVR1 für Direktnachrichten und LGS1 für geschützte Gruppen. Der Gruppenschutz hängt vom tatsächlichen Zustand der Gruppe ab; eine inkompatible ältere Gruppe darf nicht als E2EE gekennzeichnet werden. Öffentliche Kanäle liegen außerhalb dieser Vertraulichkeitsgrenze.
Dasselbe Dokument beschreibt die v7-Wiederherstellung als verschlüsseltes Identitätspaket, das vor dem Hochladen geschützt wird. Dieser Vorgang stellt die kryptografische Identität wieder her, nicht den Chatverlauf. Die Offenlegung der Wiederherstellungsphrase oder eines Geräts mit Schlüsseln ist ein anderes Szenario als der bloße Diebstahl der Datenbank.
Dies sind veröffentlichte Produktbeschreibungen, keine Ergebnisse einer unabhängigen Prüfung in diesem Artikel. Auch die Nennung von AES oder ML-KEM beweist allein weder eine korrekte Schlüsselverwaltung noch eine korrekte Programmimplementierung.
Welche Fragen sind bei einer Vorfallsmeldung wichtig?
- Welcher Zeitraum und welche Systeme waren betroffen? Die vage Formulierung „Nutzerdaten“ reicht nicht aus.
- Waren Klartext, Dateien, Schlüssel, Verifier, Anmeldesitzungen oder nur Chiffretext zugänglich?
- Konnte der Angreifer den Dienst oder die an Nutzer ausgelieferte Software verändern?
- Welche Schritte sind über offizielle Wege nötig: Sitzungen abmelden, Passwörter ändern, aktualisieren oder Kontaktidentitäten prüfen?
- Könnte die empfohlene Wiederherstellung den lokalen Verlauf löschen? Lesen Sie die Einschränkungen, bevor Sie die App deinstallieren.
Verwenden Sie keinen Link aus einer anonymen Nachricht zur „sofortigen Kontobestätigung“. Öffnen Sie die Meldung unabhängig über die offizielle Adresse. Livaras Bedrohungsmodell hilft beim Verständnis allgemeiner Grenzen; das Ausmaß eines tatsächlichen Vorfalls muss anhand seiner konkreten Belege bestimmt werden.
