Was ist Zero-Knowledge-Verschlüsselung? In 5 Minuten erklärt

Was ist Zero-Knowledge-Verschlüsselung? Wie sie funktioniert in 5 Minuten

Zero-Knowledge-Verschlüsselung ist eine Architektur, bei der Ver- und Entschlüsselung ausschließlich auf dem Gerät des Benutzers stattfinden. Der Server speichert nur Geheimtext und verschlüsselte Schlüssel. Selbst wenn der Anbieter kompromittiert wird, einer gerichtlichen Anordnung unterliegt oder ein böswilliger Mitarbeiter Datenbankzugriff hat, bleibt der Klartext unerreichbar.

Zero-Knowledge-Verschlüsselung kurz erklärt

Der Server besitzt niemals den Entschlüsselungsschlüssel. Er speichert nur Geheimtext und verschlüsselte Schlüssel, sodass ein Einbruch, eine gerichtliche Anordnung oder ein böswilliger Admin nichts Lesbares erhält.
Schlüssel werden ausschließlich auf dem Gerät des Benutzers generiert und verwendet, abgeleitet aus einem Masterpasswort durch PBKDF2-, RSA- und AES-256-Schichten.
Sie schützt Daten im Ruhezustand, bei der Übertragung und bei der Nutzung, aber nicht vor Phishing, unvorsichtigem Teilen oder Metadaten-Exposition.
Die Kombination mit MFA, guter Masterpasswort-Hygiene und Air-Gap-Bereitstellung schließt die Lücken, die Verschlüsselung allein nicht abdeckt.
Eine Self-Hosted-Bereitstellung hält die gesamte Kette auf der eigenen Hardware des Unternehmens, ohne ausgehende Verbindung und ohne Anbieterinfrastruktur oder -personal im Vertrauensbereich.
Überprüfen Sie die Behauptung eines Anbieters durch veröffentlichte Dokumentation, unabhängige Audits, einen ehrlichen Wiederherstellungsprozess und idealerweise überprüfbaren Quellcode.

Was Zero-Knowledge tatsächlich bedeutet

Zero-Knowledge-Architektur bedeutet, dass der Anbieter keine Möglichkeit hat, Ihre Klartextdaten zu lesen — nicht, dass er sich einfach entscheidet, nicht hinzuschauen. Der entscheidende Unterschied: Schlüssel werden vollständig auf dem Client generiert und verwendet, und der Server hält immer nur verschlüsselte Blobs, die er selbst nicht entschlüsseln kann, auch nicht unter rechtlichem Zwang.

Vergleichen Sie das mit gewöhnlichem „verschlüsseltem Speicher". Ein Anbieter mag Ihre Daten im Ruhezustand verschlüsseln, aber wenn er auch den Entschlüsselungsschlüssel besitzt, kann er diese Daten technisch jederzeit lesen. Verschlüsselung im Ruhezustand schützt vor physischem Diebstahl von Festplatten. Sie schützt nicht vor dem Anbieter selbst oder vor jedem, der die Infrastruktur des Anbieters kompromittiert.

Drei Eigenschaften unterscheiden echtes Zero-Knowledge von Marketing-Texten:

Schlüssel werden clientseitig generiert, unter Verwendung eines kryptographisch sicheren Pseudozufallszahlengenerators (CSPRNG), nicht auf einem Server.
Der private Schlüssel verlässt das Gerät niemals im Klartext und wird niemals unverschlüsselt an den Server übertragen.
Der Server speichert nur verschlüsselte Blobs, einschließlich verschlüsselter Kopien der Schlüssel selbst.

Aspekt	Standardverschlüsselung	Zero-Knowledge-Architektur
Wer die Schlüssel generiert	Anbieter (Server)	Gerät des Benutzers (Client)
Wo die Schlüssel gespeichert werden	Server, manchmal in reversibler Form	Verschlüsselt, niemals im Klartext auf dem Server
Kann der Anbieter Ihre Daten lesen	Technisch ja	Kryptographisch nein
Was ein Einbruch offenlegt	Klartext oder schwach geschützte Daten	Nur Geheimtext

Wie die Verschlüsselungskette funktioniert: Ein praktisches Beispiel

Zero-Knowledge-Verschlüsselung basiert auf einer Kette von Schlüsselableitungs- und Verschlüsselungsschritten, wobei jeder den nächsten entsperrt. In Passworks Kryptographiemodell wird ein Masterpasswort durch PBKDF2 zu einem Masterschlüssel. Dieser Masterschlüssel entschlüsselt einen privaten RSA-Schlüssel, der Tresorschlüssel entschlüsselt, die wiederum die Datensatzschlüssel entschlüsseln, welche die eigentlichen Passwörter und Geheimnisse schützen.

Hier ist die clientseitige Kette Schritt für Schritt:

Masterpasswort → Masterschlüssel. Der Benutzer gibt sein Masterpasswort ein. PBKDF2 (HMAC-SHA-256, 300.000 Iterationen) leitet einen 512-Bit-Masterschlüssel ab, und die serverseitige Ableitung läuft mit 600.000 Iterationen für eine zusätzliche Schicht. Die hohe Iterationszahl existiert aus einem Grund: Sie macht das Brute-Forcing des Passworts rechenintensiv.
Masterschlüssel → privater RSA-Schlüssel. Der Masterschlüssel entschlüsselt den privaten RSA-2048-Schlüssel des Benutzers (RSA-OAEP, SHA-256) mit AES-256. Dieser private Schlüssel liegt verschlüsselt auf dem Server. Ohne das Masterpasswort sind es nur inerte Daten.
Privater Schlüssel → Tresorschlüssel. Der private RSA-Schlüssel entschlüsselt einen symmetrischen Tresorschlüssel (256-Bit, etwa 596 Bit Entropie). Ein Tresor enthält eine Sammlung von Datensätzen, die von Teammitgliedern geteilt werden, und jeder Tresor trägt seinen eigenen eindeutigen Schlüssel.
Tresorschlüssel → Datensatzschlüssel → Datensatzdaten. Der Tresorschlüssel entschlüsselt einzelne Datensatzschlüssel, die wiederum die eigentlichen Passwörter, Geheimnisse und angehängten Dateien entschlüsseln — alles durch AES-256.
Eine zweite, unabhängige Schicht. Getrennt von der clientseitigen Kette verschlüsselt ein Serverschlüssel (256-Bit, OpenSSL-generiert) die Datenbank mit AES-256. Zwei unabhängige Schlüssel, zwei unabhängige Schichten. Die Kompromittierung eines davon kompromittiert nicht den anderen.

Was der Server tatsächlich speichert. Nicht das Masterpasswort. Nicht den Klartext von irgendetwas. Er speichert: den verschlüsselten Masterschlüssel-Hash zur Identitätsverifizierung, den verschlüsselten privaten Schlüssel, verschlüsselte Tresor- und Datensatzschlüssel, verschlüsselte Datensatzdaten und einen Verifizierungs-Hash, der verwendet wird, um einen Anmeldeversuch zu bestätigen, ohne jemals das Passwort selbst zu sehen.

Da der Server niemals den clientseitigen Entschlüsselungsschlüssel besitzt, liefert ein Datenbankeinbruch nur Geheimtext. Das ist der Nutzen der gesamten Kette: Wer die Datenbank, Backups oder den serverseitigen Schlüssel stiehlt, erhält nichts Verwertbares.

Dieser Schutz hat jedoch eine Grenze. Er verteidigt gegen Infrastrukturkompromittierung, nicht gegen einen Angreifer, der ein gültiges Masterpasswort erlangt und sich als Benutzer anmeldet. Der Cost of a Data Breach Report 2025 von IBM stellt fest, dass Angreifer zunehmend auf gestohlene Anmeldedaten setzen, anstatt die Infrastruktur direkt auszunutzen — ein Weg, den Zero-Knowledge-Architektur nicht abdeckt. Das ist ein Grund, die Architektur mit MFA zu kombinieren.

Was Zero-Knowledge schützt — und was nicht

Zero-Knowledge ist leistungsstark, aber keine Magie. Es verteidigt die Speicherschicht, nicht den Endpunkt, und das Verständnis dieser Grenze unterscheidet einen informierten Käufer von jemandem, der die Slogans eines Anbieters wiederholt.

Schützt vor:

Server-Einbrüche. Ein Angreifer, der die Datenbank exportiert, erhält verschlüsselte Blobs, nichts weiter.
Insider-Zugriff. Datenbankadministratoren, Backup-Operatoren und Support-Mitarbeiter können keinen Klartext lesen, weil keiner von ihnen die clientseitigen Schlüssel besitzt. Dies erzwingt die Trennung von Aufgaben: Die Person, die den Server wartet, erhält nicht automatisch Zugriff auf die darin gespeicherten Passwörter.
Vorladungen und gerichtliche Anordnungen. Wer auch immer die Infrastruktur betreibt, hat nichts Lesbares zu übergeben, da die Entschlüsselungsschlüssel niemals den Client verlassen.
Datenbanklecks oder gestohlene Backups. Exponierte Datensätze sind Geheimtext, ohne die clientseitigen Schlüssel nutzlos.

Schützt nicht vor:

Phishing. Wenn Sie Ihr Masterpasswort einem Angreifer übergeben, kann die Architektur ihn nicht aufhalten.
Öffentlichem Teilen entschlüsselter Daten. Sobald Sie etwas entschlüsselt und irgendwo unsicher eingefügt haben, ist Verschlüsselung nicht mehr die relevante Kontrolle.
Metadaten-Lecks. Der Server weiß typischerweise, wann Sie auf einen Tresor zugegriffen haben, auch wenn er nicht weiß, worauf Sie zugegriffen haben.

Datensicherheit wird üblicherweise über drei Zustände beschrieben: im Ruhezustand, bei der Übertragung und bei der Nutzung. Zero-Knowledge-Architektur bezieht sich grundlegend auf den Ruhezustand: Der Server speichert Geheimtext, den er nicht entschlüsseln kann, unabhängig davon, wie darauf zugegriffen wird.

Bei der Übertragung kommt der Schutz von TLS, einer separaten Kontrolle. Was Zero-Knowledge hier hinzufügt, ist ein Nebeneffekt, kein Ersatz: Daten verlassen den Client bereits verschlüsselt, sodass selbst ein TLS-Fehler keinen Klartext offenlegen würde.

Bei der Nutzung, wenn der Tresor entsperrt und ein Datensatz entschlüsselt wird, geschieht diese Entschlüsselung nur innerhalb des authentifizierten Clients des Benutzers selbst, für diesen einen Benutzer. Der Server empfängt oder beobachtet den Klartext zu keinem Zeitpunkt in diesem Prozess.

Was Zero-Knowledge in einer Self-Hosted-Umgebung bedeutet

Self-Hosting und Zero-Knowledge sind unabhängige Eigenschaften. Self-Hosting kontrolliert, wo die Infrastruktur sich befindet. Zero-Knowledge kontrolliert, ob derjenige, der diese Infrastruktur betreibt, die Daten lesen kann.

In einer Self-Hosted-Bereitstellung befindet sich die gesamte Kette — Server, Datenbank und verschlüsselte Schlüssel — auf der eigenen Hardware des Unternehmens, ohne ausgehende Verbindung. Was sich ändert, wenn dieses Setup mit Zero-Knowledge kombiniert wird:

Keine externe Partei im Spiel. Es gibt keine Anbieterinfrastruktur, kein Anbieterpersonal und keinen ausgehenden Datenverkehr, der Daten oder Schlüssel aus dem Unternehmen trägt. Alles, was die Verschlüsselungskette berührt, bleibt innerhalb des Unternehmensnetzwerks.
Datenresidenz und Verschlüsselung werden zu separaten Antworten. Self-Hosting klärt, wo die Daten physisch liegen. Zero-Knowledge klärt, wer sie selbst dort lesen kann. Zusammen verengen sie die Vertrauensgrenze auf das Client-Gerät, innerhalb einer Infrastruktur, die das Unternehmen bereits Ende-zu-Ende kontrolliert.
Die Kosten verschieben sich, sie verschwinden nicht. Patching, Backups und Verfügbarkeit wandern vom Anbieter zur internen IT. Das ist ein betrieblicher Kompromiss, kein sicherheitstechnischer, und gehört in die TCO-Betrachtung.

Für regulierte Branchen lässt sich diese Unterscheidung direkt auf Compliance-Fragen zur Datenresidenz abbilden.

Zero-Knowledge in der Praxis verstärken

Zero-Knowledge-Verschlüsselung schützt Daten, deckt aber keine Authentifizierungsgewohnheiten oder Netzwerkexposition ab. Die Kombination mit MFA, Masterpasswort-Hygiene, organisatorischen Kontrollen und Air-Gap-Bereitstellung schließt die verbleibenden Lücken.

Sicherheitsgrundlage:

Multi-Faktor-Authentifizierung (MFA). Ein Angreifer, der das Masterpasswort phisht, benötigt immer noch den zweiten Faktor, um den Tresor zu entsperren.
Masterpasswort-Hygiene. Die Iterationszahl von PBKDF2 verlangsamt Brute-Forcing, kann aber ein schwaches oder wiederverwendetes Passwort nicht reparieren. Länge und Einzigartigkeit zählen immer noch mehr als die KDF, die sie umgibt.
Organisatorische Kontrollen. Rollenbasierter Zugriff, mit AD/LDAP synchronisierte Gruppenberechtigungen und ein vollständiges Audit-Log begrenzen, wie viel Schaden ein kompromittiertes Konto anrichten kann.

Air-Gap-Bereitstellung: Ein Self-Hosted-Passwortmanager ohne ausgehende Verbindung eliminiert Remote-Exploitation, Cloud-Supply-Chain-Kompromittierung und Netzwerk-Interception als Angriffsvektoren vollständig.

Wie man eine Zero-Knowledge-Behauptung überprüft

Die Überprüfung einer Zero-Knowledge-Behauptung ohne Quellcode-Lektüre läuft auf fünf Punkte hinaus, die ein seriöser Anbieter bereitwillig dokumentieren wird: ein technisches Whitepaper, Nachweis clientseitiger Schlüsselgenerierung, unabhängige Audits, ein ehrlicher Wiederherstellungsprozess und offene Kryptographie. Vage Marketing-Seiten, die diese Details überspringen, sind ein Signal, kein Beweis, für ein Problem.

Zero-Knowledge-Verifizierungs-Checkliste (5 Punkte):

Bestätigen Sie clientseitige Verschlüsselung. Prüfen Sie, ob die Verschlüsselung erfolgt, bevor Daten den Browser oder die App verlassen. Wenn Schlüssel auf dem Server generiert werden, ist es kein Zero-Knowledge, unabhängig davon, was das Marketing sagt.
Suchen Sie nach unabhängiger Validierung. Penetrationstests durch Dritte und Zertifizierungen wie ISO/IEC 27001 oder SOC 2 Type II liefern externe Nachweise, keine selbstberichteten Behauptungen.
Untersuchen Sie den Wiederherstellungsprozess. Echtes Zero-Knowledge bedeutet kein „Passwort zurücksetzen" im traditionellen Sinne. Wenn der Support Ihren Zugang zurücksetzen kann, hält er irgendwo einen Schlüssel. Legitime Wiederherstellung basiert auf einem vorgenerierten Wiederherstellungsschlüssel, den nur der Benutzer aufbewahrt.
Bevorzugen Sie überprüfbare Kryptographie. Sie müssen nicht jede Zeile lesen, aber öffentlich dokumentierte Algorithmen und Parameter sind ein bedeutsames Vertrauenssignal.

Die Dokumentation von Passwork ist ein funktionierendes Beispiel dafür, was diese Checkliste zutage fördern sollte: eine ISO/IEC 27001-Zertifizierung, ein HackerOne-Programm für unabhängige Sicherheitstests und eine öffentlich dokumentierte kryptographische Spezifikation, die jeden verwendeten Algorithmus und Parameter auflistet, sowie überprüfbaren Quellcode, den Kunden direkt einsehen können, um zu verifizieren, dass die Implementierung der Dokumentation entspricht.

Das Fazit

Zero-Knowledge-Verschlüsselung läuft auf eine Designentscheidung hinaus: Der Server speichert nur das, was er strukturell nicht lesen kann. Alles andere — die PBKDF2-Iterationen, der RSA-Schlüsselaustausch, die zweistufige Verschlüsselung — existiert, um diese eine Garantie in jedem Schritt der Kette durchzusetzen.

Für ein Unternehmensteam geht es darum, den Explosionsradius eines Einbruchs zu verkleinern. Eine gestohlene Datenbank, ein kompromittiertes Backup, ein Support-Mitarbeiter mit zu viel Zugriff: Nichts davon ist relevant, wenn das, was geleakt wird, Geheimtext ist, den niemand verwenden kann.

FAQ

Was ist der Unterschied zwischen Zero-Knowledge und Ende-zu-Ende-Verschlüsselung?

Ende-zu-Ende-Verschlüsselung (E2EE) schützt die Kommunikation zwischen zwei spezifischen Parteien: Nur Sender und Empfänger besitzen die Schlüssel, kein Vermittler. Zero-Knowledge beschreibt die Speicherarchitektur eines Servers: Der Anbieter kann strukturell nicht entschlüsseln, was er speichert, unabhängig vom Kontext. Die beiden Konzepte überschneiden sich oft, anstatt entgegengesetzt zu sein. Ein Passwortmanager kann Zero-Knowledge sein, ohne dass „zwei Parteien" überhaupt Nachrichten austauschen.

Was ist der Unterschied zwischen Zero Trust und Zero-Knowledge?

Zero Trust ist ein Netzwerksicherheitsmodell: Kein Benutzer oder Gerät wird standardmäßig vertraut, jede Anfrage wird unabhängig von der Herkunft verifiziert. Zero-Knowledge ist eine kryptographische Eigenschaft: Der Server kann strukturell keine gespeicherten Daten lesen. Zero Trust regelt Zugriffsentscheidungen; Zero-Knowledge regelt, was ein Angreifer erhält, selbst nachdem Zugriff gewährt wurde. Die beiden funktionieren gut zusammen, lösen aber unterschiedliche Probleme.

Kann ich meine Daten wiederherstellen, wenn ich mein Masterpasswort vergesse?

In einem echten Zero-Knowledge-System: Nein. Nicht einmal ein Systemadministrator kann Ihr Passwort zurücksetzen, weil der Entschlüsselungsschlüssel niemals zum Zurücksetzen verfügbar war. Einige Produkte bieten eine Wiederherstellung durch einen vorgenerierten Wiederherstellungsschlüssel an, der separat vom Benutzer aufbewahrt wird. Verlieren Sie sowohl das Masterpasswort als auch den Wiederherstellungsschlüssel, sind die Daten kryptographisch unerreichbar.

Wie kann ich eine Zero-Knowledge-Behauptung überprüfen, ohne den Quellcode zu lesen?

Fordern Sie das technische Whitepaper an und prüfen Sie, ob es die KDF, Iterationszahlen und Schlüsselhierarchie spezifiziert. Bestätigen Sie, dass die Verschlüsselung clientseitig vor der Übertragung erfolgt. Suchen Sie nach unabhängigen Audits oder Zertifizierungen wie ISO 27001. Ein Anbieter, der keines davon bereitstellen möchte, ist das eigentliche Warnsignal — nicht das Fehlen von Open-Source-Code.

Funktioniert Zero-Knowledge-Verschlüsselung mit SSO oder SAML-Anmeldung?

SSO bestätigt, wer Sie sind; es ersetzt nicht das Masterpasswort, das zur Ableitung clientseitiger Verschlüsselungsschlüssel verwendet wird. Ein Zero-Knowledge-System in Kombination mit SAML SSO erfordert immer noch dieses separate Geheimnis, weil dem Identity Provider niemals die Entschlüsselungsschlüssel gegeben wurden.