Clientseitige Verschlüsselung und Ende-zu-Ende-Verschlüsselung

Clientseitige Verschlüsselung bedeutet, dass die Verschlüsselung auf Ihrem eigenen Gerät stattfindet, bevor Daten irgendwo anders ankommen. Ihr Browser führt die kryptografischen Operationen aus, und das Schlüsselmaterial bleibt in Ihrer Hand. Ende-zu-Ende-Verschlüsselung stellt eine engere Frage: Wer kann auf dem Weg vom Absender zum Empfänger den Klartext lesen?

Oft treffen beide Eigenschaften zusammen. Ein Nachrichtendienst, der auf Ihrem Gerät verschlüsselt und beim Empfänger entschlüsselt, ist gleichzeitig clientseitig und Ende-zu-Ende. Ein Werkzeug im Browser, das eine Datei lokal verschlüsselt und nur den Geheimtext hochlädt, ist clientseitig, aber nicht Ende-zu-Ende, weil es keinen zweiten Endpunkt gibt. Der eine Begriff beschreibt den Ort. Der andere beschreibt den lesbaren Weg.

Im clientseitigen Modell bleibt der Schlüssel auf Ihrem Gerät und wird nie übertragen. Sie können ihn mit PBKDF2 aus einer Passphrase ableiten, wie in RFC 8018 beschrieben, oder einen zufälligen 256-Bit-Schlüssel über die W3C Web Crypto API erzeugen. Verschlüsselt wird dann mit AES-256-GCM, genormt in FIPS 197 und NIST SP 800-38D. Wer diesen Schlüssel besitzt, kann den Geheimtext entschlüsseln.

Im Ende-zu-Ende-Modell hält jeder Endpunkt eigenes Schlüsselmaterial, und die Vermittlungsstelle speichert oder leitet Geheimtext weiter, den sie nicht lesen kann. Der Schlüsselaustausch folgt Protokollen wie TLS 1.3 (RFC 8446) oder einem Double Ratchet, und Forward Secrecy begrenzt, wie viel ein gestohlener Schlüssel offenlegt. Ein praktischer Unterschied: Ein clientseitiges Werkzeug hat meist gar kein Schlüsselverzeichnis, während ein Ende-zu-Ende-System eines für die Auffindung der Schlüssel braucht.

Ende-zu-Ende-Verschlüsselung richtet sich gegen Mithören und gegen eine ehrliche, aber neugierige Vermittlungsstelle. Wer den Datenverkehr aufzeichnet oder die Datenbank des Betreibers liest, erhält nur Geheimtext. Clientseitige Verschlüsselung nimmt eine zweite Stelle ins Visier: die Speicherschicht. Wenn ein Anbieter Ihren verschlüsselten Datenblock aufbewahrt, liefert ein Einbruch oder eine behördliche Anordnung Daten, die ohne Ihren Schlüssel nutzlos sind. Ein Zero-Knowledge-Entwurf kann deshalb zu Recht sagen, dass er Ihre Dateien nicht lesen kann.

Keines der beiden Modelle schützt die Endpunkte selbst. Läuft Schadsoftware auf dem Gerät, auf dem Sie die Passphrase eingeben, oder wurde die geladene Seite verändert, sieht der Angreifer Klartext und Schlüssel zugleich. Diesen Teil lassen viele Vergleiche aus, und genau dort ereignen sich reale Zwischenfälle.

Ein Browser ist eine gemeinsame Laufzeitumgebung. Jedes Skript auf demselben Ursprung kann dieselbe Web Crypto API aufrufen, Ihre Eingabefelder lesen und das Ergebnis anderswohin senden. Eine Cross-Site-Scripting-Lücke oder eine Erweiterung mit weitreichenden Rechten wiegt deshalb schwerer als die Chiffre selbst. Sie können es selbst prüfen: Öffnen Sie die Entwicklerwerkzeuge und führen Sie crypto.subtle.generateKey({ name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]) aus. Das true im zweiten Argument macht den Schlüssel exportierbar. Mit false kann kein Skript diesen Schlüssel mehr exportieren.

Erweiterungen stehen außerhalb der Kontrolle der Seite. Ein Passwort-Manager, ein Werkzeug für Bildschirmfotos oder ein Leser der Zwischenablage kann erfassen, was Sie vor der Verschlüsselung eingetippt haben. Gemeinsam genutzte und entsperrte Geräte bringen ein anderes Problem mit: Verschlüsselung schützt Daten im Ruhezustand und auf dem Transportweg, aber nicht eine Sitzung, die bereits jemand anderes geöffnet hat und weiter benutzt. Die OWASP-Hinweise zur Speicherung im Browser sagen dasselbe, denn ein Browser ist keine vertrauenswürdige Ausführungsumgebung.

Einmalige Aufgaben sind das Feld der clientseitigen Verschlüsselung: eine Datei vor dem Hochladen verschlüsseln, einen Textabschnitt schützen, den Sie später in eine E-Mail einfügen, oder offline ohne Konto arbeiten. Als Sicherungsstrategie versagt sie, denn Geheimtext ohne Schlüssel ist verloren, und für einen bereits kompromittierten Endpunkt tut sie nichts. Ende-zu-Ende-Verschlüsselung passt zu laufenden Gesprächen zwischen bekannten Parteien, bei denen Schlüssel gefunden, geprüft und regelmäßig gewechselt werden müssen.

Zwei Fragen sortieren die meisten Fälle. Muss die Datei später für jemand anderen lesbar bleiben? Wenn nicht, ist clientseitige Verschlüsselung mit einem Schlüssel in Ihrer Hand einfacher und nimmt den Anbieter aus Ihrer Vertrauensgrenze. Wandern die Daten zwischen zwei Parteien, die beide mitlesen müssen? Dann brauchen Sie einen Ende-zu-Ende-Entwurf mit Schlüsselprüfung, und die Metadaten rings um eine Nachricht bleiben dabei meist sichtbar.