Zero-Knowledge-Architektur erklärt

"Wir können Ihre Daten nicht sehen." Es ist eine Aussage, die auf jeder datenschutzorientierten Produktseite auftaucht — und zugleich die, die am häufigsten falsch ist. In den meisten Fällen bedeutet sie tatsächlich "wir versprechen, nicht hinzuschauen" — eine Richtlinie, keine Garantie.

Zero-Knowledge-Architektur ist das, was diese Aussage faktisch macht. Sie ist ein spezifisches technisches Design, bei dem der Dienstbetreiber keine kryptographische Möglichkeit hat, Nutzerdaten zu lesen — selbst wenn er wollte, selbst wenn seine Server beschlagnahmt würden, selbst wenn sein Personal kompromittiert wäre. In diesem Artikel erklären wir genau, was das bedeutet, wie es in der Praxis funktioniert und wie Schweizerform es für Formular-Einreichungen umsetzt.

Was "Zero-Knowledge" wirklich bedeutet

In der Kryptographie hat "Zero-Knowledge" eine präzise akademische Definition, die mit Zero-Knowledge-Proofs zusammenhängt. In der Welt der Sicherheitsprodukte wird der Begriff weiter gefasst und beschreibt ein System, in dem:

• Alle Ver- und Entschlüsselungen auf dem Gerät des Nutzers stattfinden, nie auf dem Server
• Die zur Entschlüsselung nötigen Schlüssel den Server niemals in verwertbarer Form erreichen
• Der Server nur Chiffretext speichert und den Klartext nicht ableiten, erraten oder wiederherstellen kann
• Vertrauen in den Betreiber nicht erforderlich ist — die Architektur ist beweisbar, nicht versprochen

Das Gegenteil von Zero-Knowledge ist ein vertrauensbasiertes System, bei dem der Server die Schlüssel hält und verspricht, verantwortungsvoll zu handeln. Die meisten gängigen SaaS-Produkte sind so aufgebaut. Das ist nicht schlechtes Engineering — es ist nur ein anderes Vertrauensmodell. Zero-Knowledge ist das Modell, das man wählt, wenn die Daten zu sensibel sind, als dass ein Versprechen genügen könnte.

Das schwierige Problem, das Zero-Knowledge lösen muss

Die naheliegende Frage: Wenn der Server keine Schlüssel hält, wie melden sich Nutzer an, teilen Formulare, entschlüsseln Einreichungen geräteübergreifend und erholen sich von vergessenen Passwörtern? Das ist die eigentliche Designherausforderung. Jeder kann ein System bauen, das sicher, aber unbenutzbar ist — die Kunst ist, eines zu bauen, das sicher UND benutzbar ist.

Jedes Zero-Knowledge-System konvergiert auf eine Handvoll kryptographischer Grundprimitive, um dies zu lösen:

Wie Schweizerform das zusammenfügt

Schweizerform ist eine Formular-Plattform, also lautet die spezifische Designfrage: Wie ermöglichen wir es jemandem, ein Formular zu erstellen, einen öffentlichen Link zu teilen, verschlüsselte Einreichungen von beliebigen Internetnutzern zu akzeptieren und nur dem Formularbesitzer das Lesen zu gestatten — ohne dass der Server jemals eine entschlüsselbare Kopie besitzt?

Die Antwort umfasst drei Schlüsselebenen: einen aus Ihrem Zugangscode abgeleiteten Hauptschlüssel, ein Formular-RSA-Schlüsselpaar und einen einmaligen AES-Schlüssel pro Einreichung. Gehen wir sie durch.

Ebene 1 — Ihr Hauptschlüssel

Wenn Sie sich bei Schweizerform registrieren, erstellen Sie einen Zugangscode. Das ist kein normales Passwort. Er wird nie an unsere Server gesendet und kann bei Verlust nicht wiederhergestellt werden — denn die Sicherheitsgarantien hängen genau von dieser Eigenschaft ab. In Ihrem Browser wird der Zugangscode in eine Schlüsselableitungsfunktion (PBKDF2 mit hoher Iterationszahl und benutzerspezifischem Salt) eingespeist, um einen AES-256-Hauptschlüssel zu erzeugen.

Der Hauptschlüssel existiert nur im Speicher des Browsers. Er berührt nie die Festplatte im Klartext. Er verlässt nie das Gerät. Er ist das, was alles andere entpackt.

Ebene 2 — Ihr Formular-Schlüsselpaar

Wenn Sie ein Formular erstellen, generiert der Browser ein RSA-OAEP-Schlüsselpaar. Der öffentliche Schlüssel wird auf unsere Server hochgeladen und beim Rendern des öffentlichen Formulars mitgeliefert — so verschlüsseln Befragte Daten für Sie. Der private Schlüssel wird sofort mit Ihrem Hauptschlüssel verschlüsselt und auf unseren Servern als Chiffretext gespeichert. Wir speichern den verschlüsselten privaten Schlüssel, können ihn aber nicht entschlüsseln.

Da der öffentliche Schlüssel eben öffentlich ist, kann jeder, der das Formular öffnet, ihn zum Verschlüsseln einer Einreichung verwenden. Aber nur jemand mit Ihrem Zugangscode kann den Hauptschlüssel ableiten, den privaten Schlüssel entpacken und die Einreichung lesen. Der Server ist kryptographisch ausgeschlossen.

Ebene 3 — Ein einzigartiger Schlüssel pro Einreichung

RSA ist mächtig, aber langsam, und seine Chiffretextlänge ist durch die Schlüsselgrösse begrenzt. Deshalb verschlüsseln wir die Formularantworten nicht direkt mit RSA. Stattdessen, wenn ein Befragter einreicht:

1. Der Browser generiert einen frischen AES-256-GCM-Schlüssel — einzigartig für diese Einreichung
2. Alle Antworten (und Dateianhänge) werden mit diesem AES-Schlüssel clientseitig verschlüsselt
3. Der AES-Schlüssel selbst wird dann mit dem öffentlichen RSA-Schlüssel des Formulars verschlüsselt
4. Sowohl die verschlüsselten Antworten als auch der verschlüsselte AES-Schlüssel werden an den Server gesendet

Dieses Muster — ein symmetrischer Schlüssel, der durch einen asymmetrischen Schlüssel geschützt ist — ist das standardmässige hybride Verschlüsselungsmodell und wird von TLS, PGP und praktisch jedem ernsthaften System verwendet. Es kombiniert die Geschwindigkeit von AES mit den Schlüsselaustausch-Eigenschaften von RSA.

Die Rolle der authentifizierten zusätzlichen Daten (AAD)

AES-GCM ist nicht nur Verschlüsselung — es ist authentifizierte Verschlüsselung. Es erzeugt einen Tag, den der Entschlüsseler prüft, um zu bestätigen, dass der Chiffretext nicht verändert wurde. GCM unterstützt auch Additional Authenticated Data: zusätzlicher Kontext, der nicht verschlüsselt, aber an den Chiffretext gebunden ist. Ändert sich dieser Kontext, schlägt die Entschlüsselung fehl.

Schweizerform verwendet AAD, um jede Einreichung an ihr spezifisches Formular und ihre Einreichungs-ID zu binden. Das AAD-Format ist:

submission_payload:{formId}:{submissionId}

Das schliesst eine subtile Angriffsklasse aus: Selbst wenn ein Angreifer irgendwie einen verschlüsselten Einreichungs-Blob erhielte, könnte er ihn nicht auf einem anderen Formular abspielen oder Einreichungsdatensätze in der Datenbank austauschen, ohne dass die Entschlüsselung beim Besitzer fehlschlägt. Der Chiffretext ist mit seinem Kontext verschweisst.

Der vollständige Zyklus, von Anfang bis Ende

An jedem Schritt, an dem Klartext existiert, existiert er in einem Browser. An jedem Schritt, an dem der Server die Daten berührt, sind die Daten Chiffretext. Das ist die gesamte Definition von Zero-Knowledge für diesen Anwendungsfall.

Wogegen das schützt — konkret

Ehrlich sein darüber, was Zero-Knowledge nicht löst

Zero-Knowledge ist eine mächtige Schicht — aber keine Wunderwaffe. Eine gut informierte Leserschaft verdient eine ehrliche Darstellung ihrer Grenzen:

• Es schützt nicht das Gerät des Befragten — ist der Browser kompromittiert, ist der Klartext an der Quelle exponiert
• Es schützt nicht vor einem böswilligen clientseitigen Code-Push — weshalb Code-Integrität, CSP und Subresource Integrity zählen
• Es verschlüsselt keine Metadaten wie Zeitstempel, Einreichungszahlen oder Fragenstruktur — diese sind für die Funktion der App notwendig
• Es überlebt nicht den Verlust Ihres Zugangscodes — Wiederherstellung erfordert einen geteilten Wiederherstellungsschlüssel bei einer vertrauenswürdigen Drittpartei, den wir unterstützen, den Sie aber im Voraus einrichten müssen
• Es ersetzt weder starke Transportsicherheit noch korrekte Authentifizierung oder sichere Server-Operationen — es ergänzt sie

Zero-Knowledge ist kein Ersatz für gutes Security-Engineering — es ist das, was gutes Security-Engineering hervorbringt, wenn das Bedrohungsmodell den Betreiber selbst einschliesst.

Wie Sie Zero-Knowledge-Behauptungen selbst überprüfen

Sie müssen uns nicht einfach vertrauen. Öffnen Sie die Entwicklertools Ihres Browsers auf einer Schweizerform-Einreichungsseite. Beobachten Sie den Netzwerk-Tab, während Sie einreichen. Sehen Sie sich die Nutzdaten an, die Ihr Gerät verlassen. Sie werden sehen:

• Einen hexadezimal codierten verschlüsselten Blob für die Antwort-Nutzdaten — keine lesbaren Feldwerte
• Einen umhüllten AES-Schlüssel — kürzer, ebenfalls Chiffretext
• Einen IV und eine AAD-Bindung — zur Entschlüsselung nötige Metadaten, aber nicht die Daten selbst

Sie werden die Antworten nirgends im Request im Klartext sehen. Das ist der Test. Ein System, das diesen Test nicht besteht, ist nicht Zero-Knowledge — unabhängig von seinen Marketing-Behauptungen.

Das Fazit

Zero-Knowledge ist kein Feature-Bulletpoint — es ist ein Designprinzip, das schwierige Engineering-Entscheidungen erzwingt. Alles, was sich in klassischem SaaS "einfach" anfühlt (Admin-Datenzugriff, Passwort-Wiederherstellung mit Datenwiederherstellung, serverseitige Volltextsuche über Nutzerinhalte), muss neu gedacht oder auf anderer Grundlage neu gebaut werden.

Aber für sensible Formulardaten — Krankengeschichten, juristische Aufnahmen, Whistleblower-Meldungen, Finanzoffenlegungen — ist dieser Aufwand der ganze Sinn. Das Ziel ist nicht, mit den Daten betraut zu werden; das Ziel ist, die Frage des Vertrauens irrelevant zu machen. Wenn der Server physisch nicht lesen kann, was er speichert, verschwindet die gesamte Klasse betreiberseitiger Bedrohungen.