Zero-Knowledge-Verschlüsselung – erklärt ohne Marketing
Was Zero-Knowledge in einem Passwortmanager tatsächlich bedeutet, welche Garantien es gibt und welche nicht – und wie man eine echte Aussage von einem Slogan unterscheidet.
„Zero-Knowledge“ steht auf der Startseite fast jedes Passwortmanagers, meist neben einem Vorhängeschloss. Es ist eine echte und nützliche Eigenschaft. Und sie wird regelmäßig weiter gedehnt, als sie trägt.
Hier steht, was der Begriff bedeutet, wovor er schützt, wovor nicht – und welche Fragen sich bei jedem Produkt lohnen, das damit wirbt.
Die Eigenschaft, schlicht formuliert
Ein Dienst ist Zero-Knowledge in dem Sinne, in dem die Branche das Wort verwendet, wenn der Betreiber Ihre Daten nicht lesen kann, selbst wenn er wollte.
Nicht „wird nicht“. Kann nicht. Auf diesem Unterschied beruht alles. Ein Versprechen, nicht hinzusehen, ist eine Richtlinie – sie hält genau so lange wie das Wohlverhalten des Unternehmens, seine Sicherheit und seine Eigentümerstruktur. Eine Architektur, in der der Betreiber nur Chiffrat besitzt, ist dagegen eine strukturelle Tatsache. Gerichtsbeschlüsse, Sicherheitsvorfälle und Übernahmen ändern daran nichts.
Der Mechanismus ist einfach beschrieben: Ver- und Entschlüsselung geschehen auf Ihrem Gerät, mit einem Schlüssel, der aus einem Geheimnis abgeleitet wird, das der Server nie erhält.
Wie der Schlüssel abgeleitet wird
Ihr Master-Passwort ist nicht der Schlüssel. Es ist die Eingabe für eine Schlüsselableitungsfunktion, die daraus einen macht.
Master-Passwort
│
▼
KDF (langsam, gesalzen, speicherintensiv)
│
▼
Tresorschlüssel ──► ver- und entschlüsselt den TresorDieser KDF-Schritt leistet konkrete Arbeit. Ein rohes Passwort ist kurz, entropiearm und in enormem Tempo erratbar. Eine moderne KDF – Argon2id und scrypt sind die aktuellen Empfehlungen – ist bewusst teuer in Zeit und Speicher, was den Vorteil spezialisierter Hardware abstumpft. Der Speicherbedarf ist der entscheidende Teil: GPUs und ASICs parallelisieren Rechenoperationen billig, Speicher nicht.
Das pro Tresor eindeutige Salt verhindert, dass eine vorberechnete Tabelle gegen alle Nutzenden gleichzeitig wiederverwendet wird.
Daraus folgen zwei Eigenschaften, und auf die kommt es an:
- Der Schlüssel existiert nur auf Ihrem Gerät und nur, solange der Tresor entsperrt ist.
- Der Server – sofern es einen gibt – sieht Chiffrat und sonst nichts.
Wovor Zero-Knowledge schützt
Es lohnt, die Bedrohungen konkret zu benennen, die tatsächlich wegfallen.
| Bedrohung | Hilft Zero-Knowledge? |
|---|---|
| Die Datenbank des Anbieters wird gestohlen | Ja. Die Angreifer erhalten Chiffrat. |
| Eine Mitarbeiterin durchsucht Tresore | Ja. Es gibt nichts Lesbares. |
| Eine Behörde verlangt Herausgabe der Daten | Ja. Herausgegeben werden kann nur Chiffrat. |
| Der Anbieter wird übernommen, die Richtlinie ändert sich | Ja. Richtlinien entschlüsseln nicht rückwirkend. |
| Schadsoftware auf Ihrem Gerät | Nein. |
| Ihr Master-Passwort wird erraten | Nein. |
| Eine Phishing-Seite fängt Ihr Master-Passwort ab | Nein. |
| Ein manipulierter Client-Build | Nein. |
In der unteren Tabellenhälfte passieren die meisten realen Verluste. Und sie haben eines gemeinsam: Sie greifen den Endpunkt an, nicht den Server. Zero-Knowledge verschiebt die Vertrauensgrenze auf Ihr Gerät – es beseitigt sie nicht.
Die Aussage hat eine tragende Annahme
Hier kommt der Teil, den Marketingseiten überspringen.
Bei einem webbasierten Manager wird der Code, der die Verschlüsselung ausführt, von genau dem Server ausgeliefert, der auch das Chiffrat speichert. Bei jedem Seitenaufruf erhalten Sie eine frische Kopie des Clients und führen sie sofort aus.
Dieser Server könnte im Prinzip einen Build ausliefern, der Ihren Schlüssel still weiterreicht. Sie hätten praktisch keine Möglichkeit, das zu bemerken. Die Kryptografie ist solide; der Auslieferungsweg ist die Schwachstelle.
Das macht browserbasierte Manager nicht wertlos. Es heißt aber: „Zero-Knowledge“ ist eine Aussage über die Architektur, und sie trägt nur so weit, wie Sie dem tatsächlich laufenden Client vertrauen können. Deshalb verdient das Auslieferungsmodell ebenso viel Aufmerksamkeit wie das Chiffre-Verfahren:
- Reproduzierbare Builds erlauben Dritten zu prüfen, dass ein veröffentlichtes Binary zum veröffentlichten Quelltext passt.
- Quelloffene Clients machen eine Prüfung überhaupt erst möglich.
- Langlebig installierte Clients verkleinern das Zeitfenster: Der sicherheitskritische Code wird nicht bei jeder Nutzung neu geladen.
- Rein lokale Tresore umgehen die Frage vollständig – es gibt keinen Server, der einen anderen Client ausliefern könnte.
Wie NexusPass damit umgeht
NexusPass geht den letzten dieser Wege – den langweiligsten, und für einen Einzelnutzer-Tresor den am besten begründbaren.
Der Tresor ist eine Datei auf Ihrem Gerät. Es gibt kein Konto, keinen Sync-Server und damit keinen Betreiber, der zur Herausgabe gezwungen, kompromittiert oder übernommen werden könnte. Die Frage „kann der Anbieter meinen Tresor lesen?“ braucht keine kryptografische Antwort, weil im Datenpfad kein Anbieter steht.
Schlüsselmaterial liegt im sicheren Speicher der Plattform – Android Keystore und iOS Keychain – statt im Anwendungsspeicher. Der Tresor sperrt sich nach Zeitablauf und beim Wechsel in den Hintergrund, denn das Zeitfenster, in dem Klartext im Speicher existiert, sollte so kurz sein wie das Produkt es machen kann.
Zu den Details. NexusPass ist noch in Entwicklung, und dieser Artikel nennt bewusst weder Chiffre noch KDF-Parameter oder Schlüssellängen. Das gehört in eine Dokumentation, die mit einem Release erscheint und überprüfbar ist – nicht in einen Blogbeitrag davor.
Fragen, die sich bei jedem Anbieter lohnen
Wer einen Passwortmanager bewertet, kommt mit diesen fünf Fragen weiter als mit jeder Vergleichstabelle:
- Was genau wird an Ihre Server gesendet? „Verschlüsselte Daten“ ist keine Antwort. Metadaten – Anzahl der Einträge, URLs, Zeitstempel, Ordnernamen – werden oft unverschlüsselt gespeichert und verraten mehr, als man denkt.
- Welche KDF, mit welchen Parametern? Argon2id mit dokumentierten Speicher- und Iterationskosten ist eine echte Antwort. „Verschlüsselung nach Industriestandard“ ist keine.
- Kann ich den laufenden Client verifizieren? Reproduzierbare Builds, veröffentlichte Hashes, offener Quelltext.
- Was passiert, wenn ich das Master-Passwort vergesse? Lautet die Antwort „wir können es wiederherstellen“, ist die Architektur nicht Zero-Knowledge – was auch immer auf der Startseite steht. Diese eine Frage klärt die meisten Behauptungen von selbst.
- Was ist verschlüsselt und was nur gespeichert? Anhänge und TOTP-Seeds liegen nicht immer im selben Umschlag wie die Passwörter.
Frage vier ist das schärfste Instrument der Reihe. Wiederherstellung und Zero-Knowledge schließen einander konstruktionsbedingt aus: Wenn jemand außer Ihnen den Zugang wiederherstellen kann, kann jemand außer Ihnen an Ihre Daten.
Die ehrliche Zusammenfassung
Zero-Knowledge-Verschlüsselung ist eine echte architektonische Eigenschaft mit präziser Bedeutung, und man sollte darauf bestehen. Sie beseitigt eine ganze Risikoklasse – alles, was darauf beruht, einem Betreiber über Jahre zu vertrauen.
Was sie nicht leistet: ein Gerät sicher machen, ein Master-Passwort stark oder einen Client vertrauenswürdig. Sie verschiebt die Vertrauensgrenze, statt sie aufzulösen – und genau zu wissen, wo diese Grenze nun verläuft, ist der Unterschied zwischen verstandener Sicherheit und einem aufgesagten Slogan.