Eine Festplattenkopie, die aktive Kontrolle des Servers und der Zugriff auf ein Telefon sind drei verschiedene Szenarien; eine pauschale Garantie reicht nicht für alle drei.
Wird der Server eines Messengers übernommen, hängt die genaue Antwort auf „Was wird offengelegt?“ von den gespeicherten Daten, dem Speicherort der Schlüssel und der Art des Angreiferzugriffs ab. Eine Festplattenkopie zu erlangen ist nicht dasselbe wie die aktive Kontrolle über den Dienst und den Verteilungsweg der Anwendung.
Dieser Artikel untersucht anhand der öffentlichen Dokumentation von Livara ein hypothetisches Szenario. Er behauptet weder einen Standort der Livara-Rechenzentren noch eine tatsächliche Beschlagnahme und garantiert auch keinen Dienstbetrieb bei einer Internetabschaltung. Inhaltsverschlüsselung, Netzverfügbarkeit und Infrastruktursicherheit sind getrennte Themen.
Zunächst die Art des Zugriffs bestimmen
Gespeicherte Kopie des Servers: Der Angreifer erhält Zugriff auf die in dieser Kopie enthaltenen Dateien, Datenbanken oder Sicherungen. Wenn private Inhalte auf dem Gerät korrekt verschlüsselt wurden und der Server den Entschlüsselungsschlüssel nicht besitzt, legt diese Kopie allein den Klartext des Gesprächs nicht offen.
Aktive Kontrolle über den Dienst: Neben dem Lesen vorhandener Daten kann der Angreifer bestimmte Anfragen blockieren, alte Daten zurückgeben oder das Verhalten der kontrollierten Komponenten ändern. Die Prüfung der Kontaktidentität, die Versionskontrolle und die Integrität des Clients gewinnen in diesem Szenario an Bedeutung.
Gleichzeitiger Gerätezugriff: Ein entsperrtes Telefon, Schadsoftware oder eine lesbare Kopie bei einem Gesprächsmitglied kann Inhalte auf einem völlig anderen Weg offenlegen. Auch Livaras Bedrohungsmodell garantiert keinen Schutz für entsperrte oder infizierte Geräte.
Welche Daten sind laut Livaras Dokumentation auf dem Server sichtbar?
Livaras Sicherheitsseite, gekennzeichnet mit Version 0.1.68, trennt Inhalte direkter Chats unter LVR1 und kompatibler privater Gruppen unter LGS1 von Betriebsinformationen. Dieselbe Seite erklärt, dass eine ältere, inkompatible Gruppe ausdrücklich außerhalb der E2EE bleibt; deshalb ist der Status des jeweiligen Gesprächs zu prüfen.
| Datenkategorie | Dokumentierte Grenze und mögliche Folge |
|---|---|
| Text und Anhänge eines geschützten Gesprächs | Der Server speichert eine verschlüsselte Kopie; zum Lesen ist der passende Schlüssel erforderlich |
| Kommunikationsmetadaten | Informationen wie Beteiligte, Zeitpunkt, Größe und Zustellstatus stehen dem Dienst zur Verfügung |
| Gruppenmitgliedschaft | Teil der Betriebsinformationen und der operativen Befugnisse des Servers |
| Öffentlicher Kanal | Der Inhalt ist öffentlich und für den Server lesbar |
| Paket zur Identitätswiederherstellung v7 | Wird vor dem Hochladen verschlüsselt und benötigt ein separates Wiederherstellungsgeheimnis |
| Optionale serverseitige Aufzeichnung | Durch die REC-Anzeige vom E2EE-Modus unterschieden; Ende-zu-Ende-Vertraulichkeit darf dafür nicht angenommen werden |
LSS1-Code zum Schutz von Metadaten wird in der Dokumentation erwähnt, ist aber nicht an den normalen Nachrichtenversand angeschlossen. Dass ein Protokollname in einem Projekt vorkommt, beweist nicht, dass es bei jeder Kommunikation aktiv ist.
Diese Tabelle beschreibt Produktaussagen, nicht die Ergebnisse eines tatsächlichen Beschlagnahmetests oder einer unabhängigen Prüfung sämtlicher Datenbankversionen.
Wie wichtig können Metadaten sein?
Informationen über Kontakte zwischen Personen, Zeitpunkte und Gruppenmitgliedschaften können auch ohne Nachrichtentext sensibel sein. Die Aussage „Der gesamte Kommunikationsgraph wird für immer offengelegt“ ist jedoch ohne Kenntnis der Aufbewahrungsdauer, der Protokollabdeckung und der erlangten Datenversion nicht präzise.
Eine tatsächliche Bewertung muss fragen, welche Felder erfasst wurden, wie lange sie aufbewahrt wurden und welche Sicherungskopien zugänglich sind. Inhaltsverschlüsselung allein legt keine Datenaufbewahrungsrichtlinie fest. Ebenso lässt sich aus der Architektur eines Messengers nicht ableiten, dass alle Messenger zwangsläufig dieselben Metadaten speichern.
Welche Gefahr birgt die Serverkontrolle für künftige Nachrichten?
Eine Sicherheitsprüfung sollte die Manipulation der Mitgliederliste, die Bereitstellung eines anderen Identitätsschlüssels, das Verhindern von Aktualisierungen und die Auslieferung eines bösartigen Clients getrennt testen. Die Wirkung hängt jeweils von der clientseitigen Validierung, der Anzeige von Änderungen und der Identitätsprüfung ab.
Ohne Implementierungstests kann man nicht behaupten, jeder übernommene Server könne zwangsläufig ein verborgenes Mitglied hinzufügen; ebenso wenig kann man sagen, aktive Serverkontrolle habe keine Wirkung. Bei sensiblen Gesprächen sollten unerwartete Identitäts- oder Mitgliederänderungen untersucht werden. Ein Vergleich der Schlüsselfingerabdrücke mit dem Kontakt über einen unabhängigen, vertrauenswürdigen Weg liefert mehr Informationen als das alleinige Vertrauen auf den Anzeigenamen.
Ändert ein Angreifer den auf dem Gerät ausgeführten Code, kann er möglicherweise den Klartext vor der Verschlüsselung sehen. Deshalb gehört die Sicherheit der Anwendungsverteilung und -aktualisierung zu diesem Szenario und liegt nicht außerhalb des Themas Verschlüsselung.
Was bringt die Post-Quanten-Eigenschaft zusätzlich?
Der Standard NIST FIPS 203 für ML-KEM hilft beim Aufbau eines gemeinsamen Geheimnisses. Der korrekte Einsatz in einer hybriden Konstruktion kann das Risiko bestimmter künftiger Angriffe auf den Schlüsselaustausch verringern. Das ersetzt weder Gerätesicherheit noch begrenzte Metadatenaufbewahrung oder Zugriffskontrollen auf dem Server.
Auch Proof Lab demonstriert nur bestimmte lokale P-256-, HKDF- und AES-GCM-Operationen und nimmt die vollständige LVR1/LGS1-Komposition von diesem Test aus. Ein erfolgreiches Ergebnis garantiert nicht die Widerstandsfähigkeit des gesamten Produkts gegen eine Übernahme der Infrastruktur.
Was ist bei einer tatsächlichen Bewertung oder einem Vorfall zu tun?
- Die Art des Zugriffs und bestätigte Informationen festhalten; Gerüchte über Störungen nicht mit einem bestätigten Sicherheitsvorfall gleichsetzen.
- Die Anwendungsversion und den Verschlüsselungsstatus des jeweiligen Gesprächs prüfen.
- Identitätsänderungen, Änderungen der Gruppenmitglieder und unbekannte Sitzungen über offizielle Wege untersuchen.
- Wiederherstellungsgeheimnisse, Passwörter und private Inhalte nicht für eine „Sicherheitsprüfung“ an Unbekannte geben.
- Bei ernsten Risiken oder rechtlichen Fragen geeignete Fachleute hinzuziehen und keine unumkehrbaren Maßnahmen aufgrund eines Artikels ergreifen.
Eine belastbare Schlussfolgerung muss benennen, welche Daten in welcher Version gegen welche Art des Zugriffs geschützt sind. „Auch bei einer Serverbeschlagnahme passiert nichts“ ersetzt diese Antwort nicht.
