Was bedeutet Zero-Knowledge-Verschlüsselung?

Stellen Sie sich einen Tresor in einem Hotelzimmer vor, dessen Schlüssel ausschließlich Sie besitzen. Nicht das Hotel, nicht der Hersteller des Tresors, niemand sonst kann ihn öffnen – auch nicht, wenn jemand danach verlangt, und auch nicht, wenn man das Hotel dazu zwingen wollte. Das Hotel verwahrt den verschlossenen Kasten, weiß aber nicht, was darin liegt, und hat keine Möglichkeit, es herauszufinden. Genau dieses Versprechen steht hinter dem Begriff Zero-Knowledge-Verschlüsselung: Der Anbieter, der Ihre Daten speichert oder überträgt, hat keinerlei Kenntnis von ihrem Inhalt. Dieser Beitrag erklärt, was der Begriff genau bedeutet, wie die Technik dahinter funktioniert, worin er sich von verwandten Konzepten unterscheidet – und woran sich ein echtes Zero-Knowledge-Verfahren von einem bloßen Etikett unterscheiden lässt.

• Der Anbieter, der nichts weiß
• Wo der Schlüssel entsteht
• Ein Beispiel von Anfang bis Ende
• Ein Begriff, zwei Bedeutungen
  • Zero-Knowledge oder Ende-zu-Ende?
• Vier Schutzmodelle im Vergleich
• Was Zero-Knowledge schützt – und was nicht
  • Was passiert, wenn ich mein Passwort verliere?
• Woran man echtes Zero-Knowledge erkennt
• Fazit

#Der Anbieter, der nichts weiß

Der Kern des Begriffs steckt im Wort „Zero-Knowledge", also „null Wissen": Gemeint ist, dass der Diensteanbieter null Wissen über die Inhalte hat, die er für Sie speichert oder weiterleitet. Er sieht nur verschlüsselte Daten – eine unverständliche Zeichenfolge – und besitzt nicht die Mittel, sie zu entschlüsseln. Das unterscheidet Zero-Knowledge grundlegend von den meisten gängigen Cloud- und Sharing-Diensten, bei denen der Anbieter die Daten zwar verschlüsselt speichert, den passenden Schlüssel aber selbst verwaltet und damit jederzeit Zugriff auf den Klartext hat.

Diese Unterscheidung hat handfeste Folgen. Wenn der Anbieter den Schlüssel besitzt, kann er die Daten lesen – ob aus eigenem Antrieb, aufgrund einer Sicherheitslücke, durch einen kompromittierten Mitarbeiterzugang oder weil eine Behörde ihn dazu verpflichtet. Bei einem echten Zero-Knowledge-Verfahren entfällt diese Möglichkeit nicht aus Versprechen oder guter Absicht, sondern aus technischer Notwendigkeit: Der Anbieter kann nicht herausgeben, was er nicht hat. Die Vertraulichkeit hängt damit nicht mehr vom Vertrauen in den Anbieter ab, sondern von der Architektur des Systems.

Das verändert das Bedrohungsmodell grundlegend. Bei herkömmlichen Diensten muss man darauf vertrauen, dass der Anbieter sorgfältig arbeitet, seine Mitarbeiter integer sind, seine Systeme nicht kompromittiert werden und er Anfragen Dritter angemessen prüft. Jeder dieser Punkte ist eine mögliche Bruchstelle. Zero-Knowledge entfernt sie nicht einzeln, sondern macht sie gegenstandslos: Wo der Anbieter den Klartext technisch nicht erreichen kann, spielt es keine Rolle mehr, ob ein Mitarbeiter neugierig, ein Angreifer erfolgreich oder eine behördliche Anordnung wirksam ist. Das Vertrauen wandert vom Verhalten des Anbieters zur Mathematik der Verschlüsselung.

#Wo der Schlüssel entsteht

Damit der Anbieter nichts weiß, muss eine einfache Regel eingehalten werden: Die Verschlüsselung geschieht beim Nutzer, bevor die Daten das Gerät verlassen, und der Schlüssel verlässt das Gerät niemals im Klartext. Technisch spricht man von clientseitiger Verschlüsselung – „Client" meint das Gerät oder die Anwendung des Nutzers, im Gegensatz zum Server des Anbieters.

Der Ablauf lässt sich in wenigen Schritten beschreiben. Aus einem Geheimnis, das nur der Nutzer kennt – typischerweise ein Passwort –, wird auf dem Gerät ein kryptografischer Schlüssel abgeleitet. Mit diesem Schlüssel werden die Daten lokal verschlüsselt, etwa im Browser oder in der App, noch bevor irgendetwas übertragen wird. Erst die so entstandene, unlesbare Fassung wird zum Anbieter hochgeladen. Beim Abruf läuft der Vorgang rückwärts: Der Anbieter liefert die verschlüsselten Daten zurück, und erst auf dem Gerät des Nutzers werden sie mit dem dort abgeleiteten Schlüssel wieder lesbar gemacht.

Der entscheidende Punkt ist, was dabei nie passiert: Der abgeleitete Schlüssel und das zugrunde liegende Passwort werden nicht an den Anbieter übermittelt. Der Server sieht zu keinem Zeitpunkt den Klartext und nie den Schlüssel. Damit ist die Vertraulichkeit nicht eine Eigenschaft, die der Anbieter gewährt, sondern eine, die er gar nicht aufheben kann. Wie sich dieses Prinzip auf den konkreten Versand vertraulicher Inhalte anwenden lässt, zeigt der Beitrag Vertrauliche Dokumente sicher versenden – Schritt für Schritt.

#Ein Beispiel von Anfang bis Ende

An einem einfachen Vorgang lässt sich das Zusammenspiel nachvollziehen. Angenommen, Sie möchten ein vertrauliches Dokument über einen zero-knowledge-basierten Dienst teilen. Sobald Sie die Datei auswählen, erzeugt die Anwendung auf Ihrem Gerät einen zufälligen Schlüssel und verschlüsselt das Dokument damit lokal. Was anschließend zum Anbieter hochgeladen wird, ist nur noch die verschlüsselte Fassung – für den Server eine bedeutungslose Zeichenfolge.

Damit der Empfänger das Dokument lesen kann, braucht er den Schlüssel. Hier zeigt sich eine Eigenheit zero-knowledge-basierter Dienste: Der Schlüssel darf nicht über den Anbieter laufen, sonst hätte dieser ihn ja. Stattdessen wird er häufig im Link selbst transportiert – genauer in dem Teil hinter dem Rautezeichen, der technisch nicht an den Server übermittelt wird – oder über einen getrennten Kanal an den Empfänger gegeben. Öffnet der Empfänger den Link, lädt seine Anwendung die verschlüsselte Datei herunter und entschlüsselt sie erst auf seinem Gerät mit dem mitgelieferten Schlüssel.

Über den gesamten Weg sieht der Anbieter zu keinem Zeitpunkt den Klartext und nie den Schlüssel. Genau das ist der praktische Sinn von Zero-Knowledge: Der Dienst vermittelt die Übertragung, ohne am Inhalt teilzuhaben. Zugleich macht das Beispiel eine Verantwortung sichtbar – wird der Schlüssel über denselben unsicheren Kanal wie der Link geteilt, entsteht eine Lücke, die nicht in der Architektur liegt, sondern in der Handhabung.

#Ein Begriff, zwei Bedeutungen

An dieser Stelle ist eine Klarstellung nötig, die in der Praxis oft fehlt und die ein fachkundiges Publikum zu Recht erwartet. „Zero-Knowledge" bezeichnet zwei verschiedene Dinge, die leicht verwechselt werden.

Das erste ist die hier beschriebene Zero-Knowledge-Verschlüsselung beziehungsweise Zero-Knowledge-Architektur: eine Bauweise von Speicher- und Sharing-Diensten, bei der der Anbieter keinen Zugriff auf Schlüssel und Klartext hat. „Zero-Knowledge" ist hier eine beschreibende Aussage über den Anbieter – er hat null Wissen über Ihre Inhalte.

Das zweite ist der Zero-Knowledge-Beweis (englisch zero-knowledge proof), ein eigenständiges kryptografisches Protokoll. Dabei beweist eine Partei einer anderen, dass eine Aussage wahr ist, ohne dabei irgendeine weitere Information preiszugeben als die Tatsache, dass die Aussage zutrifft. Das klassische Beispiel ist der Nachweis, ein Passwort zu kennen, ohne es zu übertragen. Zero-Knowledge-Beweise sind ein Werkzeug der Kryptografie und kommen unter anderem bei Authentifizierungsverfahren und in der Blockchain-Welt zum Einsatz.

Beide Begriffe teilen die Grundidee, etwas zu belegen oder zu verarbeiten, ohne das Eigentliche offenzulegen – aber sie sind nicht dasselbe. Eine Zero-Knowledge-Verschlüsselung setzt nicht zwingend einen Zero-Knowledge-Beweis voraus. Manche Dienste kombinieren beides, indem sie etwa die Anmeldung über ein Verfahren absichern, bei dem der Server das Passwort prüfen kann, ohne es je zu erfahren. Notwendig für die Vertraulichkeit der gespeicherten Daten ist das jedoch nicht; dafür genügt die clientseitige Verschlüsselung. Wer die Begriffe sauber trennt, erkennt schneller, was ein Dienst tatsächlich verspricht.

#Zero-Knowledge oder Ende-zu-Ende?

Eng verwandt, aber nicht deckungsgleich ist die Ende-zu-Ende-Verschlüsselung. Sie beschreibt, dass Inhalte durchgängig vom Absender bis zum vorgesehenen Empfänger verschlüsselt bleiben, sodass Zwischenstationen – auch der vermittelnde Anbieter – sie nicht lesen können. Zero-Knowledge ist im Kern dieselbe Idee, betont aber die Perspektive des speichernden Anbieters: Er hat null Wissen, weil Schlüssel und Entschlüsselung ausschließlich beim Nutzer liegen.

In der Sache überschneiden sich die Begriffe stark. Ein zero-knowledge-basierter Speicherdienst ist clientseitig verschlüsselt; ein Ende-zu-Ende-verschlüsselter Dienst hält den Anbieter ebenfalls außen vor. Der Unterschied ist meist einer der Betonung und des Anwendungsfalls – „Ende-zu-Ende" denkt von der Kommunikation zwischen zwei Parteien her, „Zero-Knowledge" von der Speicherung beim Anbieter. Wo genau die Grenze zwischen durchgehender und reiner Transportverschlüsselung verläuft, vertieft der geplante Beitrag Ende-zu-Ende- vs. Transportverschlüsselung.

#Vier Schutzmodelle im Vergleich

Der Wert von Zero-Knowledge wird am deutlichsten, wenn man es neben die übrigen gängigen Schutzmodelle stellt. Die folgende Übersicht ordnet sie danach, wer den Schlüssel hält und wovor das Modell tatsächlich schützt:

Die ersten beiden Zeilen beschreiben Modelle, bei denen der Anbieter den Klartext sehen kann – serverseitige Verschlüsselung schützt vor allem gegen den Diebstahl von Festplatten, Transportverschlüsselung gegen das Mitlesen unterwegs. Warum gerade die gewöhnliche E-Mail diese Schwächen bündelt, behandelt der Beitrag Warum E-Mail keine sichere Datenübertragung ist. Erst die unteren beiden Zeilen schließen den Anbieter aus – und Zero-Knowledge ist die konsequenteste Ausprägung dieses Gedankens.

Wichtig ist dabei, dass diese Modelle sich nicht ausschließen, sondern aufeinander aufbauen. Ein zero-knowledge-basierter Dienst nutzt im Hintergrund weiterhin Transportverschlüsselung für die Übertragung und verschlüsselt die Daten oft auch im Ruhezustand auf dem Server – die clientseitige Verschlüsselung legt sich als zusätzliche, entscheidende Schicht darüber. Der Unterschied liegt nicht darin, dass weniger geschützt wird, sondern darin, wer den Schlüssel zur obersten Schicht hält. Genau diese Schicht entzieht dem Anbieter den Zugriff auf den Klartext.

#Was Zero-Knowledge schützt – und was nicht

So stark das Modell ist, es ist kein Allheilmittel, und ein seriöser Umgang mit dem Begriff benennt auch seine Grenzen. Zero-Knowledge schützt die Vertraulichkeit der Inhalte gegenüber dem Anbieter und gegenüber jedem, der sich Zugang zu dessen Systemen verschafft. Es macht die Daten nicht „unknackbar", und es schützt nicht gegen alles.

Eine erste Grenze liegt in der Stärke des Passworts. Da der Schlüssel aus dem Geheimnis des Nutzers abgeleitet wird, ist das gesamte Verfahren nur so stark wie dieses Geheimnis. Ein schwaches, erratbares Passwort untergräbt den Schutz, ganz gleich wie solide die Verschlüsselung selbst ist. Eine zweite Grenze liegt im Endgerät: Ist der Rechner des Nutzers mit Schadsoftware infiziert, kann der Inhalt dort abgegriffen werden, bevor er verschlüsselt wird oder nachdem er entschlüsselt wurde. Zero-Knowledge schützt die Daten beim Anbieter, nicht den kompromittierten Endpunkt.

Eine dritte, subtilere Grenze betrifft das Vertrauen in den Client. Die Verschlüsselung findet in der Software des Nutzers statt – doch diese Software stammt häufig vom Anbieter selbst, etwa als Web-Anwendung, die bei jedem Aufruf neu geladen wird. Man vertraut also darauf, dass der ausgelieferte Client tatsächlich das tut, was er verspricht, und den Schlüssel nicht heimlich abführt. Quelloffener, unabhängig prüfbarer Code und nachvollziehbare Veröffentlichungsprozesse verringern dieses Restvertrauen, heben es aber nicht vollständig auf. Schließlich bleiben oft Metadaten sichtbar – etwa Dateigrößen oder Zeitpunkte –, die der Inhaltsverschlüsselung entgehen.

Eine vierte Grenze zeigt sich beim Teilen. Solange Daten nur für Sie selbst verschlüsselt sind, bleibt der Kreis der Wissenden auf eine Person beschränkt. Sobald Sie Inhalte mit anderen teilen, geben Sie den Schlüssel notwendigerweise weiter – und erweitern damit den Kreis derer, die entschlüsseln können. Zero-Knowledge sorgt dafür, dass der Anbieter außen vor bleibt, nicht dafür, dass der Empfänger vertrauenswürdig ist oder den Schlüssel sicher verwahrt. Die Vertraulichkeit ist immer nur so gut wie das schwächste Glied unter denen, die den Schlüssel halten. Wer teilt, sollte daher genauso sorgfältig wählen, mit wem und über welchen Weg er den Zugang gibt, wie er den Dienst selbst auswählt.

#Was passiert, wenn ich mein Passwort verliere?

Diese Frage führt zur unvermeidlichen Kehrseite des Modells. Weil der Anbieter den Schlüssel nicht besitzt, kann er ihn auch nicht zurücksetzen. Es gibt keinen „Passwort vergessen"-Knopf, der den Zugang wiederherstellt, denn dazu müsste der Anbieter die Daten entschlüsseln können – und genau das schließt Zero-Knowledge aus. Verlieren Sie das Passwort und einen etwaigen Wiederherstellungsschlüssel, sind die Daten unwiederbringlich verloren.

Das ist keine Schwäche der Umsetzung, sondern die logische Konsequenz des Versprechens: Die vollständige Kontrolle über den Schlüssel bedeutet auch die vollständige Verantwortung für ihn. Viele Dienste mildern dies durch einen einmalig erzeugten Wiederherstellungscode, den der Nutzer sicher verwahrt. Dieser verlagert die Verantwortung, hebt sie aber nicht auf. Wer Zero-Knowledge nutzt, sollte diese Kehrseite kennen und das Passwort sowie den Wiederherstellungsschlüssel entsprechend sorgfältig behandeln.

#Woran man echtes Zero-Knowledge erkennt

Da der Begriff werblich attraktiv ist, lohnt ein prüfender Blick, ob ein Dienst hält, was das Etikett verspricht. Die folgenden Fragen helfen bei der Einordnung:

• Findet die Verschlüsselung nachweislich auf dem Gerät des Nutzers statt, bevor Daten übertragen werden?
• Wird ausdrücklich erklärt, dass der Anbieter weder Schlüssel noch Passwort erhält und keinen Zugriff auf den Klartext hat?
• Gibt es folgerichtig keinen anbieterseitigen Passwort-Reset, der den Zugang ohne Wiederherstellungsschlüssel wiederherstellt?
• Ist der Client quelloffen oder unabhängig auditiert, sodass die Behauptungen überprüfbar sind?
• Macht der Anbieter klare, nachvollziehbare Aussagen zur Schlüsselhoheit, statt nur das Schlagwort zu verwenden?

Je mehr dieser Fragen sich mit Ja beantworten lassen, desto eher steht hinter dem Begriff eine echte Architektur und nicht nur ein Marketingversprechen. Ein Widerspruch ist besonders aufschlussreich: Wer einen vollständigen Passwort-Reset anbietet und zugleich „Zero-Knowledge" verspricht, kann beides kaum zugleich einhalten. Crymbl ordnet seine zero-knowledge-basierten Konzepte genau in dieses Verständnis ein – Vertraulichkeit als Eigenschaft der Architektur, nicht als Vertrauensbekundung.

#Fazit

Zero-Knowledge-Verschlüsselung bedeutet, dass ein Anbieter Ihre Daten speichern oder übermitteln kann, ohne sie jemals lesen zu können. Erreicht wird das durch clientseitige Verschlüsselung: Der Schlüssel entsteht beim Nutzer und verlässt dessen Gerät nie im Klartext, sodass der Anbieter nur unverständliche Daten sieht. Damit verlagert sich die Vertraulichkeit vom Vertrauen in den Anbieter hin zu einer Eigenschaft des Systems.

Zwei Dinge gehören zum ehrlichen Verständnis dazu. Erstens ist die Zero-Knowledge-Verschlüsselung nicht mit dem gleichnamigen Zero-Knowledge-Beweis zu verwechseln – verwandte Idee, verschiedenes Konzept. Zweitens hat das Modell einen Preis: Es macht Daten nicht unknackbar, verlangt ein starkes Passwort und ein vertrauenswürdiges Endgerät, und es kennt keinen Rettungsanker bei Passwortverlust. Wer diese Grenzen kennt, kann den Begriff einordnen, statt ihm zu vertrauen – und genau diese Urteilsfähigkeit ist es, die ein gutes Verständnis von Zero-Knowledge stiften sollte.