Zero-Knowledge-Verschlüsselung einfach erklärt

Q: Was sieht der Server in einem Zero-Knowledge-System tatsächlich?

Das ist die entscheidende Frage. Ein Server kann nie gar nichts sehen: Es braucht immer einige Metadaten, damit der Dienst funktioniert. In einem gut gebauten Zero-Knowledge-System sieht der Server:

Kurze Antwort. Zero-Knowledge-Verschlüsselung ist eine Architektur, bei der der Dienst, der Ihre Daten hostet, sie nicht entschlüsseln kann: Der Verschlüsselungsschlüssel verlässt Ihr Gerät nie im Klartext. Selbst wenn die Datenbank des Servers gestohlen, auf behördliche Anfrage herausgegeben oder von einem böswilligen Administrator durchsucht wird, enthält sie nur undurchsichtige verschlüsselte Daten. Genutzt von Signal, Tutanota, Proton, Bitwarden und der Cloud-Synchronisierung von Filarr.

Wenn ein Cloud-Dienst sagt „Ihre Daten sind verschlüsselt“, stimmt das meistens, reicht aber selten. Die Daten sind bei der Übertragung verschlüsselt (TLS) und im Ruhezustand (serverseitige Verschlüsselung mit Schlüsseln, die der Dienst hält). Aber der Dienst hat die Schlüssel weiterhin. Wenn er Ihre Daten lesen will, kann er es. Verpflichtet ihn ein Gericht dazu, wird er es tun.

Zero-Knowledge-Verschlüsselung ist die Architektur, die das konstruktionsbedingt unmöglich macht. Der Dienst kann Ihre Daten buchstäblich nicht lesen, weil die Schlüssel zum Entschlüsseln Ihr Gerät nie verlassen.

Dieser Artikel erklärt Zero-Knowledge in einfachen Worten, zeigt, wie es in der Praxis funktioniert, und räumt mit der häufigen Verwechslung mit Ende-zu-Ende-Verschlüsselung auf.

Was bedeutet Zero-Knowledge-Verschlüsselung?

„Zero-Knowledge“ ist in diesem Zusammenhang ein Marketingbegriff, der sich den Namen eines echten kryptografischen Konzepts (Zero-Knowledge-Beweise) leiht und ihn locker verwendet. Der klarere technische Begriff lautet clientseitige Verschlüsselung ohne serverseitigen Zugriff auf die Schlüssel.

Das Versprechen ist einfach:

Ihr Gerät erzeugt die Verschlüsselungsschlüssel
Ihr Gerät verschlüsselt Ihre Daten, bevor es sie an den Server schickt
Der Server speichert nur verschlüsselte Datenblöcke und hat nie die Schlüssel, um sie zu entschlüsseln
Wenn Sie sich auf einem anderen Gerät anmelden, entschlüsselt Ihr Passwort (oder ein daraus abgeleitetes Geheimnis) die Schlüssel lokal

Das Ergebnis: Der Dienst hat null Wissen über den Inhalt Ihrer Daten. Er kann Metadaten sehen (Dateigrößen, Zeitpunkte der Synchronisierung, IP-Adressen), aber der Inhalt selbst bleibt für ihn undurchsichtig.

Worin unterscheidet sich Zero-Knowledge-Verschlüsselung von gewöhnlicher Cloud-Verschlüsselung?

Fast jeder Cloud-Dienst verschlüsselt heute Daten im Ruhezustand. Dropbox, Google Drive, iCloud, OneDrive: Sie alle verschlüsseln Ihre Dateien auf ihren Servern. Die entscheidende Frage lautet: Wer hält den Schlüssel?

Verschlüsselungsmodell	Kann der Server entschlüsseln?	Beispiele
Nur TLS (bei der Übertragung)	Ja, der Server speichert Klartext	Viele kleine Dienste
Serverseitige Verschlüsselung im Ruhezustand	Ja, der Server hält den Schlüssel	Dropbox, Google Drive, iCloud (größtenteils)
Clientseitige Verschlüsselung, Server hält den Schlüssel	Ja (trotzdem!)	Manche „verschlüsselten“ Dienste, bei denen der Server eine Kopie des Hauptschlüssels hält
Zero-Knowledge / E2E	Nein, der Schlüssel liegt nur beim Client	Signal, Proton, Tutanota, Bitwarden, Cloud-Synchronisierung von Filarr

Serverseitige Verschlüsselung schützt gegen eine Bedrohung: einen Dieb, der die physischen Festplatten aus dem Rechenzentrum stiehlt. Sie schützt nicht davor, dass der Betreiber des Dienstes Ihre Daten liest, dass Hacker in den Dienst eindringen oder dass Behörden den Dienst zur Herausgabe Ihrer Daten verpflichten.

Zero-Knowledge schützt gegen alle drei.

Wie funktioniert Zero-Knowledge-Verschlüsselung tatsächlich?

Der Mechanismus ist eine Kette von Vorgängen, die vollständig auf Ihrem Gerät ablaufen. Ein typischer Zero-Knowledge-Dienst für eine Notiz-App funktioniert so:

AUF IHREM GERÄT                                 AUF DEM SERVER
───────────────                                 ──────────────

1. Sie geben Ihr Passwort ein
        │
        ▼
2. KDF (PBKDF2 / Argon2id)
   streckt das Passwort zum KEK
        │
        ▼
3. Zufälliger File Encryption Key (FEK)
   wird erzeugt (je nach Dienst pro Datei;
   bei Filarr einmal pro Konto)
        │
        ▼
4. AES-256-GCM(Datei, FEK) ────► verschlüsselter Block ──► als undurchsichtige Bytes gespeichert
        │
        ▼
5. AES-256-GCM(FEK, KEK) ──────► verschlüsselter FEK ────► neben dem Block gespeichert
        │
        ▼
6. Der KEK verlässt das Gerät nie
   (manche Dienste laden eine verschlüsselte
   Kopie des KEK hoch, die nur Ihr Passwort
   entsperren kann, siehe „Schlüsselwiederherstellung“)

Die Sicht des Servers auf die Welt: ein Strom undurchsichtiger Bytes. Selbst mit vollem Root-Zugriff auf den Server liest ein Angreifer nur verschlüsseltes Rauschen.

Damit das für Nutzer über mehrere Geräte hinweg funktioniert, wird meist auch der verschlüsselte KEK hochgeladen, aber immer nur in verschlüsselter Form. Um ihn auf einem neuen Gerät zu entsperren, müssen Sie Ihr Passwort erneut eingeben, das der Server in einem gut gebauten System nie sieht (wie Filarr die Anmeldung handhabt, steht weiter unten).

Was sieht der Server in einem Zero-Knowledge-System tatsächlich?

Das ist die entscheidende Frage. Ein Server kann nie gar nichts sehen: Es braucht immer einige Metadaten, damit der Dienst funktioniert. In einem gut gebauten Zero-Knowledge-System sieht der Server:

Einen undurchsichtigen verschlüsselten Datenblock pro Datei
Die Größe jedes Blocks (mit einer gewissen Unschärfe, manche Systeme füllen auf)
Zeitpunkte der Synchronisierung (wann Blöcke aktualisiert werden)
Ihre Kontokennung (typischerweise eine E-Mail-Adresse oder ein Benutzername)
Metadaten zur Authentifizierung (einen Passwort-Prüfwert, aber nie das Passwort selbst)

Er sieht nicht:

Dateiinhalte
Dateinamen (gut gebaute Systeme verschlüsseln auch diese)
Die Ordnerstruktur (ebenfalls verschlüsselt)
Titel von Notizen, Tags oder andere Metadaten innerhalb der App

Die Kategorien, die doch durchsickern (Größe, Zeitpunkte, E-Mail-Adresse des Kontos), bilden ein Seitenkanalrisiko: Ein ausreichend motivierter Gegner kann manchmal allein aus Größen Informationen ableiten. Ernsthafte Zero-Knowledge-Umsetzungen füllen Blöcke auf feste Größenklassen auf und versehen Zeitstempel mit Zufallsabweichungen, um das abzuschwächen.

Warum ist Zero-Knowledge für Ihre Daten wichtig?

Drei konkrete Szenarien. In einer Zero-Knowledge-Architektur gilt:

Szenario 1: Der Dienst wird gehackt. Ein Angreifer stiehlt die gesamte Datenbank. Er bekommt verschlüsselte Datenblöcke und E-Mail-Adressen, mehr nicht. Die Blöcke sind ohne die Schlüssel nutzlos, und die liegen auf den Geräten der Nutzer.

Szenario 2: Der Dienst erhält eine behördliche Anfrage. Eine Behörde verlangt Nutzerdaten. Der Dienst kommt der Anfrage nach, mit dem, was er hat: verschlüsselten Datenblöcken. Die Behörde kann sie ebenfalls nicht entschlüsseln.

Szenario 3: Ein böswilliger oder nachlässiger Mitarbeiter. Ein Administrator mit Datenbankzugriff versucht, Dateien von Nutzern zu lesen. Er sieht verschlüsselte Bytes. Ohne das Passwort des Nutzers, das das System nie gespeichert hat, kann er nichts entschlüsseln.

Der Dienst kann Sie buchstäblich nicht verraten, selbst wenn er wollte oder gezwungen würde. Das ist der Wert von Zero-Knowledge: Die Notwendigkeit, zu vertrauen, wird durch Mathematik beseitigt, nicht durch Versprechen.

Was kostet Zero-Knowledge-Verschlüsselung?

Zero-Knowledge bringt echte technische Abwägungen mit sich.

1. Verlorene Passwörter bedeuten verlorene Daten. Wenn der Dienst Ihre Daten nicht entschlüsseln kann, kann er auch Ihr Passwort nicht zurücksetzen. Die meisten Zero-Knowledge-Dienste bieten Wiederherstellungscodes oder Wiederherstellungsphrasen, aber wenn Sie Ihr Passwort und Ihr Wiederherstellungsgeheimnis verlieren, sind Ihre Daten dauerhaft unzugänglich. Das ist der Preis echter Privatsphäre.

2. Serverseitige Funktionen sind begrenzt. Der Dienst kann Ihre Daten nicht durchsuchen, keine Vorschauen auf dem Server erzeugen und keine KI-Zusammenfassungen Ihrer Notizen erstellen, weil er nichts sehen kann. Alle solchen Funktionen müssen auf Ihrem Gerät laufen.

3. Die Synchronisierung über mehrere Geräte ist schwieriger. Schlüssel zwischen Ihren Geräten zu teilen, verlangt ein sorgfältiges Kopplungsprotokoll (typischerweise ECDH mit Ableitung per HKDF). Das richtig zu entwerfen, ist nicht trivial.

4. Echtzeitzusammenarbeit ist schwieriger. Wenn zwei Nutzer dasselbe verschlüsselte Dokument bearbeiten, muss die Zusammenführung auf dem Client oder über kryptografische Protokolle erfolgen (CRDTs über verschlüsselten Daten sind ein aktives Forschungsfeld).

Diese Kosten werden in Kauf genommen. Die Garantie der Privatsphäre ist zu wertvoll, um sie für geringfügige Funktionsgewinne aufzugeben.

Worin unterscheidet sich Zero-Knowledge von Ende-zu-Ende-Verschlüsselung?

Die Begriffe werden oft gleichbedeutend verwendet. Sie überschneiden sich, sind aber nicht identisch.

Ende-zu-Ende-Verschlüsselung (E2E) beschreibt eine Eigenschaft: Nur die Endpunkte einer Kommunikation können den Inhalt lesen. Kein Zwischenglied (Server, Internetanbieter) kann es. Das Lehrbuchbeispiel ist Signal: Eine Nachricht wird auf Ihrem Telefon verschlüsselt, über die Server von Signal geschickt und erst auf dem Telefon des Empfängers entschlüsselt.

Zero-Knowledge ist ein Betriebsmodell für Speicherdienste: Der Server speichert Ihre Daten verschlüsselt mit Schlüsseln, die er nicht hat. Man kann es als E2E sehen, angewandt auf eine „Kommunikation“ zwischen Ihrem früheren Ich (beim Hochladen) und Ihrem künftigen Ich (beim Herunterladen auf einem anderen Gerät).

Die meisten Zero-Knowledge-Dienste setzen auch E2E für das Teilen um (wenn Sie eine Datei mit einem anderen Nutzer teilen, werden die Schlüssel von Client zu Client ausgetauscht, ohne dass der Server sie sieht). Aber Sie können Zero-Knowledge ohne Teilen haben (ein persönlicher Tresor) oder E2E ohne Speicherung (eine Chat-App, die keinen Verlauf aufbewahrt).

Einen ausführlicheren Vergleich finden Sie in Ende-zu-Ende oder Zero-Knowledge: Was ist der Unterschied?.

Welche Apps nutzen Zero-Knowledge-Verschlüsselung?

Bekannte Dienste, die Zero-Knowledge korrekt umsetzen:

Signal: Ende-zu-Ende-verschlüsselte Nachrichten
Bitwarden: Passwortmanager (auch für die Tresorspeicherung Zero-Knowledge)
1Password: Passwortmanager
Proton (Mail, Drive, Calendar): Schweizer Anbieter, vollständig Zero-Knowledge
Tutanota: verschlüsselte E-Mail, Kalender, Kontakte
Standard Notes: verschlüsselte Notizen
Cryptomator: lokale Verschlüsselung für Cloud-Speicher
Filarr: Local-first-Arbeitsbereich mit optionaler Zero-Knowledge-Cloud-Synchronisierung

Dienste, die oft für Zero-Knowledge gehalten werden, es aber nicht sind: iCloud (Apple hält für die meisten Daten die Schlüssel, außer bei Elementen hinter dem Erweiterten Datenschutz), Dropbox, Google Drive, OneDrive.

Wie setzt Filarr Zero-Knowledge um?

Filarr ist ein Local-first-Arbeitsbereich, dessen Cloud-Synchronisierung Zero-Knowledge ist. Die Architektur:

Die Dateien liegen zuerst verschlüsselt auf Ihrer Festplatte. Die lokale App braucht keine Cloud, um zu funktionieren: Das ist der Local-first-Teil.
Wenn Sie die Cloud-Synchronisierung einschalten, verschlüsselt Ihr Gerät jede Datei mit AES-256-GCM unter dem FEK Ihres Kontos, mit einem neuen Zufallswert pro Datei. Die Schlüsselhierarchie erklärt KEK und FEK erklärt.
Der Server speichert nur verschlüsselte Datenblöcke. Die Daten liegen auf Cloudflare R2. Ohne Ihr Passwort sind die Blöcke Rauschen.
Die Kopplung mehrerer Geräte nutzt ECDH (Diffie-Hellman auf elliptischen Kurven) mit per HKDF abgeleiteten Sitzungsschlüsseln, um Ihren Hauptschlüssel zwischen Ihren Geräten zu teilen, ohne ihn je dem Server preiszugeben.
Ihre Kontoanmeldung wurde am 16. Oktober 2026 auf einen abgeleiteten Schlüssel umgestellt: Ein neues Konto oder eines, das sich seitdem angemeldet hat, sendet statt des Passworts einen auf Ihrem Gerät abgeleiteten Schlüssel. Während einer Übergangszeit von etwa zwei Monaten sendet ein Konto, das sich noch nicht erneut angemeldet hat, oder eine ältere Version einer App das Passwort weiterhin über HTTPS; dort wird es mit einem bcrypt-Hash abgeglichen und nie gespeichert.

Das Ergebnis: Würde unsere Datenbank morgen gestohlen, bekämen die Angreifer verschlüsseltes Rauschen, E-Mail-Adressen und umhüllte Schlüssel, die sie ohne Ihr Passwort oder Ihre Wiederherstellungsphrase nicht öffnen können. Sie könnten keine einzige Datei lesen. Die bekannte Grenze war die Anmeldung selbst, und sie schließt sich: Seit dem 16. Oktober 2026 sendet die Anmeldung einen auf Ihrem Gerät abgeleiteten Schlüssel. Nur ein Konto, das sich noch nicht erneut angemeldet hat, oder eine ältere App-Version sendet während der Übergangszeit noch das Passwort, und ein in diesem Moment kompromittierter Server könnte es abfangen und damit Ihren Schlüssel entpacken. Bei einer behördlichen Anfrage hätten wir nur das, was wir speichern, verschlüsselte Datenblöcke, und die können wir nicht entschlüsseln.

Die vollständige Sicherheitsarchitektur von Filarr lesen, mit den genauen Parametern und dem Bedrohungsmodell.

Weiterlesen

„Cryptographic Right Answers“, Latacora: pragmatische Entscheidungen in der Kryptografie
Was ist AES-256-GCM und warum ist es wichtig?
Ende-zu-Ende- oder Zero-Knowledge-Verschlüsselung: Was ist der Unterschied?
KEK und FEK erklärt: die Schlüsselhierarchie von Filarr
Die Sicherheitsarchitektur von Filarr
Was ist Local-first-Software?