Verschlüsselter Speicher trennt Dateidaten von der Entschlüsselungsbefugnis, doch Empfänger, Metadaten und lokale Kopien bleiben Teil des Bedrohungsmodells.
Ein Ende-zu-Ende-verschlüsselter Anhang kann auf einem Server gespeichert werden, ohne diesem die unverschlüsselte Datei zugänglich zu machen. Ein verbreitetes Konzept verschlüsselt die Datei auf dem Absendergerät mit einem neuen Inhaltsschlüssel, lädt den Chiffretext hoch und sendet den Schlüssel innerhalb einer authentifizierten, verschlüsselten Nachricht an die vorgesehenen Empfänger.
Diese Trennung ist nützlich, aber „Zero-Knowledge-Speicherung“ ist keine vollständige Spezifikation. Es bleibt zu klären, wie Schlüssel, Dateiverweise, Dateinamen, Zugriffskontrollen und heruntergeladene Kopien behandelt werden.
Der Lebenszyklus eines Anhangs
- Datei vorbereiten. Der Absender wählt ein Foto, Video oder Dokument aus. Das Entfernen von Metadaten oder eine Transkodierung sind gesonderte Schritte; Verschlüsselung allein entfernt weder EXIF-Daten noch Dokumenteigenschaften.
- Verschlüsselungsmaterial erzeugen. Eine sichere Implementierung erzeugt die benötigten Schlüssel und Nonces gemäß dem gewählten Verfahren.
- Vor dem Upload verschlüsseln. Der Speicherdienst erhält verschlüsselte Bytes statt des ursprünglichen Inhalts.
- Einen authentifizierten Verweis zustellen. Die verschlüsselte Chatnachricht enthält die Informationen, die Empfänger benötigen, etwa Speicherort, Entschlüsselungsschlüssel und relevante Integritätsmetadaten.
- Abrufen und prüfen. Der empfangende Client lädt das Datenobjekt herunter und prüft die Authentifizierung, bevor er das Ergebnis als gültigen Inhalt behandelt.
- Lokale Kopien verwalten. Anzeigen, Exportieren, Bearbeiten oder Speichern in einer Galerie kann Kopien außerhalb der ursprünglichen verschlüsselten Speichergrenze erzeugen.
Der Schlüssel kann in einer verschlüsselten Hülle durch die Infrastruktur desselben Anbieters übertragen werden. Das als „Out-of-Band“ zu bezeichnen, kann irreführen: Er ist logisch vom Objektspeicher getrennt, wird aber nicht zwingend über einen unabhängigen Kommunikationskanal zugestellt.
Was authentifizierte Verschlüsselung hinzufügt
Ein authentifiziertes Verschlüsselungsverfahren schützt Vertraulichkeit und erkennt unbefugte Änderungen innerhalb seines authentifizierten Umfangs. NISTs GCM-Spezifikation definiert eine solche Konstruktion und ihre Anforderungen. Korrekte Schlüssel- und Nonce-Verwaltung sowie das Prüfen des Authentifizierungsergebnisses sind entscheidend; ein bekannter Algorithmusname macht nicht jede Implementierung sicher.
Die Anwendung muss die Datei außerdem an die richtige Nachricht und das richtige Gespräch binden. Ein gültiges verschlüsseltes Datenobjekt beweist für sich allein nicht, dass es in diesen bestimmten Chat gehört. Dateikennungen, erwartete Größe, Reihenfolge der Teilstücke und Anhangsmetadaten benötigen ein geeignetes authentifiziertes Design.
Was der Speicherdienst weiterhin erfahren kann
| Information | Verbirgt Inhaltsverschlüsselung allein sie? |
|---|---|
| Ursprüngliche Dateibytes | Dafür ist sie gegenüber Parteien ohne Schlüssel ausgelegt |
| Ungefähre verschlüsselte Größe | Normalerweise nicht |
| Zeitpunkt von Upload und Download | Normalerweise nicht |
| Welches Konto eine Datei anfordert | Hängt von Routing und Zugriffskontrolle ab |
| Dateiname und Bildunterschrift | Nur wenn das Protokoll auch diese schützt |
| Eine vom Empfänger gespeicherte Kopie | Nein; der Empfänger hat bereits Klartextzugriff |
Zugriffskontrollen bleiben wichtig, selbst wenn Datenobjekte verschlüsselt sind. Sie können unerwünschte Downloads, Missbrauch und die Offenlegung von Kennungen begrenzen. Verschlüsselung ersetzt weder Autorisierung noch Aufbewahrungsregeln oder Verfügbarkeit.
Große Dateien brauchen mehr als ein Schlagwort
Ein Konzept für große Dateien kann Daten streamen oder in authentifizierte Teilstücke aufteilen. Das kann den Speicherbedarf senken, doch Nummerierung, endgültige Länge, Wiederholungsversuche und der Umgang mit Abschneiden müssen definiert sein. Erfinden Sie keine Leistungszahlen und behaupten Sie nicht, dass eine Datei in einer Nachricht zwangsläufig den „Ratchet-Zustand aufbläht“; solche Folgen hängen von der Implementierung ab.
Ein hilfreicher Test umfasst eine gültige Datei, ein geändertes Byte, einen abgeschnittenen Download, ein umgeordnetes Teilstück und einen unbefugten Abrufversuch. Führen Sie solche Tests nur in einer autorisierten Testumgebung mit nicht sensiblen Dateien durch. Halten Sie fest, ob der Client ungültige Daten vor dem Öffnen zurückweist.
Was Livara dokumentiert
Livaras Sicherheitsseite beschreibt Verschlüsselung vor dem Upload, einen zufälligen Schlüssel pro Datei innerhalb der geschützten Sitzung sowie Schutz für Dateinamen und Bildunterschriften in Gesprächen mit aktiver E2EE, einschließlich kompatibler privater Gruppen. Ältere inkompatible Gruppen sind ausdrücklich ausgenommen. Sie unterscheidet geschützte Gespräche von öffentlichen Sendekanälen. Das sind dokumentierte Produktaussagen, kein neues Implementierungsaudit in diesem Artikel.
Das Bedrohungsmodell erkennt außerdem an, dass ein Empfänger oder ein kompromittiertes Gerät lesbare Inhalte offenlegen kann. Verschlüsselter Speicher kann daher nicht versprechen, dass ein Bild von jedem Gerät verschwindet, wenn seine Chatnachricht gelöscht wird.
Fragen vor dem Teilen sensibler Dateien
Prüfen Sie, ob der Gesprächstyp E2EE unterstützt, ob alle vorgesehenen Empfänger vertrauenswürdig sind und ob die Datei selbst identifizierende Metadaten enthält. Prüfen Sie automatisches Speichern in der Galerie und Cloud-Fotosicherungen gesondert. Überlegen Sie bei Dokumenten, ob Kommentare, Versionsverlauf oder eingebettete Eigenschaften vor dem Versand entfernt werden sollten.
Verstehen Sie schließlich Löschung und Wiederherstellung. Das Entfernen eines Datenobjekts vom Server kann künftige Downloads verhindern, aber keine bereits vorhandene Empfängerkopie zurückholen. Der Verlust des erforderlichen Schlüssels kann eine verbleibende verschlüsselte Datei unlesbar machen. Ein gutes Anhangsdesign erklärt beide Folgen klar.
