Martins key.matique-Blog

>> Zurück zum Artikelverzeichnis >>


Zero-knowledge+:
Der "Cautiously Knowing Service"

Geschrieben: 14.12.2020
Letzte Überarbeitung: 21.12.2020

In "Zero Knowledge (Client Encryption)" habe ich mich mit mit Begriff und Technologie des "Zero-Knowledge-Servers" auseinandergesetzt. Inzwischen arbeiten wir an der Umsetzung, stoßen dabei aber an Grenzen, die erfordern, das Konzept weiterzuentwickeln.

Wo liegen die Grenzen des üblichen Zero-Knowledge-Konzepts?

Zunächst einmal weckt der Begriff falsche Erwartungen: "Zero-Knowledge" lässt einen denken, dass der Server gar keine Nutzerdaten kennt. Manche Serverbetreiber behaupten sogar leichtsinnig*, sie selbst könnten gar nicht an die Nutzerdaten kommen, selbst wenn sie es wollten.

Beides ist aber falsch. In der Regel kennen die Serverbetreiber durchaus eine Reihe von Nutzerdaten, nämlich E-Mail-Adresse, IP-Adresse, Zahlungsdaten. Daten sind vor dem Zugriff des Serverbetreibers nur außerhalb einer Benutzersitzung auch gegen dessen Willen geschützt, über die mit dem Hauptpasswort verschlüsselte Speicherung. Das ist aber auch bei Online-Passwortmanagern der Fall, die mit Server-Encryption arbeiten. Ein Serverbetreiber könnte immer böswilligerweise seine Software ändern und damit Benutzergeheimnise ausspähen. Er würde damit allerdings sein Geschäftsmodell untergraben.**

Man sollte sich also ehrlich machen und nicht Dinge behaupten, die man nicht liefern kann. Schon deshalb sollte man den Begriff "Zero-Knowledge" meiden und diejenigen, die als erste das Konzept für Online-Passwortmanager einführten, nennen es inzwischen selber lieber "Client-Encryption".

Aber auch inhaltlich ist das Konzept, alle Geheimnisse nur noch mit der Client-Encryption zu schützen, nicht haltbar: In der Teamarbeit spielt das Teilen von Geheimnissen mit anderen eine große Rolle. Doch damit ergibt sich das Problem, dass ein Teammitglied einem anderen auch virusbehaftete Dateien unterschieben kann, fahrlässig oder absichtlich. In jedem Fall sollte es dem Empfänger möglich sein, eine solche Datei einem Malwarescan zu unterziehen.

Dies über JavaScript zu erledigen, ist angesichts der Menge an Signaturen schier unmöglich. Dem Benutzer zuzumuten, solche Dateien herunterzuladen und auf seinem PC zu überprüfen, ist unrealistisch. Es würde vermutlich viel zu selten gemacht werden. Also sollte der Service anbieten, dass die Datei auf dem Server überprüft wird, aber der Inhalt auch sofort wieder vergessen wird. Dabei sollten natürlich alle serverseitigen Vorsichtsmaßnahmen, die wir ja schon von den Zeiten vor der Client-Encryption kannten, zum Zuge kommen.

Neben dem Malwarescan ist auch die Suchfunktion schwierig auf dem Client (also via JavaScript) implementierbar. Dort wo man sie braucht, also in großen Boxen, würde die Suche dann unverhältnismäßig lange dauern. Wenn aber Bedienbarkeit mit Sicherheit in Konflikt kommt, verliert in der Regel die Sicherheit. Daher ist es sinnvoll, dem Benutzer anzubieten, die Suche auf dem Server durchzuführen. Die nötigen Schlüssel würden vom Client zum Server übertragen und vom Server nach Abschluss der Suche umgehend wieder vergessen. Also wiederum eine bewusste Ausnahme von der "Zero-Knowledge"-Regel.

Schließlich ist in der Regel eine Total-Verschlüsselung aller Benutzerdaten mit dem Hauptkennwort gar nicht sinnvoll: In diesem Fall würde ein Verlust des Hauptkennworts auch nicht nur der Kerngeheimnisse, sondern auch der Begleitdaten bedeuten, so dass es nahezu unmöglich wäre, die vielen Internetkonten, die man hat, aufzufinden, um ein neues Kennwort zu setzen.

Eine solche Situation würde das Risiko eines Identitätsdiebstahls extrem erhöhen, da diese Konten-"Leichen" einen bequemer Ansatzpunkt für Online-Kriminelle darstellen. Diese finden die Konten, die Sie nicht mehr finden. Irgendwann werden Ihre Kennwörter dort zu schwach und sie wissen gar nicht, dass Sie sie ändern sollten.

Natürlich können Sie dieser Situation auch vorbeugen, Ihr Hauptkennwort hinterlegen, oder sich auf Ihrem Rechner regelmäßig eine Exportdatei ihrer Box sichern. Aber wenn Sie hier einen Fehler machen oder es die Hinterlegungsstelle nicht mehr gibt, wäre doch der Notnagel, zumindest die Begleitdaten wieder erhalten zu können schon sinnvoll. (Auch ist die regelmäßige Abspeicherung von Exportdateien nicht risikofrei. Sie müssten sie vor fremden Zugriff schützen und dürfen sie nicht verlieren.)

Daher sollte dem Normalbenutzer die Möglichkeit, Geheimnisse in Kerngeheimnisse und Begleitdaten zu trennen, als Voreinstellung angeboten werden. (Der versierte Internetnutzer wird dagegen schnell herausfinden, wie er, wenn es wirklich will, auch die Begleitdaten wie Kerngeheimnisse schützen kann.)

"Zero-knowledge+"

Wir kommen also nicht umhin einen neuen Begriff zu entwickeln. Wir müssen das Dogma von "Zero" auf festgelegte Weise dort aufweichen, wo dies für ein Plus an Sicherheit erforderlich ist, aber auch nur dort. Dieses Ziel ist griffig mit "Zero-knowledge+" umschrieben.

Als Marketing-Begriff mag "Zero-knowledge+" taugen, da er den Bezug zum herkömmlichen Begriff "Zero-knowledge server" deutlich macht: Es wird nicht weniger, sondern mehr geleistet. All die Dienste die derzeit von Zero-Knowledge-Servern geleistet werden, leistet auch ein Zero-knowledge-+-Server mit gleichem "Nullwissen" über Hauptkennwort, Schlüssel und Kerngeheimnisse des Benutzers.

Als Fachbegriff hätte "Zero-knowledge+" aber dann doch seine Schwächen. Es würde zu einigen Gedankenverknotungen führen, systematisch von einem Minus an Zero für ein Plus an Sicherheit zu sprechen. Besser ist es, begrifflich neu anzufangen, statt dogmatisch mit "Nullwissen", sondern mit "zurückhaltendem" Umgang mit Wissen (das soweit wie möglich und sinnvoll Nullwissen bedeutet, aber kluge Ausnahmen zulässt) und letztlich dem Benutzer die Entscheidung überlässt.

Der Fachbegriff hinter dem "Zero-knowledge server" gilt die "Client-Encryption" die auch bei "Zero-knowledge+" eine große Rolle spielt, aber das Plus eben nicht abzudecken vermag: Es geht hier auch um die Gesamtbetrachtung der drei Ebenen Benutzer, Client und Server, um die Rollenverteilung und die Kompetenzen. Dieses Gesamtbetrachtung ist erforderlich, damit die Ent-Dogmatisierung nicht in Beliebigkeit endet: Wenn Ausnahmen von der Regel "Nullwissen des Servers" definiert werden, muss klar sein, wer bestimmt, welche Ausnahmen zulässig sind. Wie wird sichergestellt, dass diese Entscheidungen fundiert getroffen werden? Aber auch: Wie wird der Client vor Angriffen geschützt?

Das Ergebnis dieser Überlegungen ist, neben (einem wohl unverzichtbaren Marketing-Begriff) "Zero-knowlege+" den Begriff "Cautiously Knowing Service" einzuführen, der durch eine klare Definition bestimmt wird und eine saubere tiefergehende Beschäftigung mit der Problematik erlaubt.

"Cautiously Knowing Service" als Fachbegriff

Der neue Begriff weicht gleich in zwei Punkten von dem des "Zero-Knowledge-Server" ab: "Cautiously", also "vorsichtig oder "behutsam" ist eine starke Forderung, aber vermeidet Absolutheit. Vorsicht braucht keinen Superlativ und kein Dogma, ihr ist das Streben dem Optimum bereits inhärent. Ein überängstlicher Hase würde verhungern, ein übermütiger selbst gefressen werden. "Cautious" heißt auch "umsichtig", bedeutet also, mehr als einen Aspekt zu beachten.

Bei Web-Apps, die kritische Benutzerdaten verwalten, darf die Achtsamkeit sich nicht nur gegen den Bruch von Geheimnissen richten. Es muss auch darauf geachtet werden, dass die Daten nicht verloren gehen, z. B. durch die Möglichkeit, das Hauptkennwort zu hinterlegen. Und durch die Möglichkeit, Kerngeheimnisse von Begleitdaten zu trennen und diese Möglichkeit auch als Vorbelegung vorzusehen. Es muss auch auf die Bedienbarkeit geachtet werden, und eben auch auf solche Dinge wie den Malwarescan von Dateien und eine leistungsfähige Suchfunktion.

Wir reden damit bereits vom "Service" und nicht nur vom "Server". Der Service beinhaltet auch Skripte, die im Browser laufen, also den Client. Und ein Service hat naturgemäß immer auch den Kunden, den Nutzer im Blick.

Die Sicherheit von Web-Apps hängt entscheidend von allen drei Ebenen ab: Nutzer, Client und Server. Während der Service Client und Server programmieren kann und damit deren Sicherheit bestimmt, sollte er den Nutzer führen und sich gleichzeitig ihm unterordnen. Das heißt: Der Service muss dem Nutzer gegenüber transparent darlegen, was mit dessen Daten geschieht, er sollte ihn über kritische Aktionen aufklären, ihm kluge Empfehlungen geben aber letztendlich ihm, dem Kunden die Entscheidungen überlassen.

Konkret: Der Server sollte sich prinzipiell als "Zero-Knowledge-Server" verhalten, also die Verschlüsselung dem Client überlassen, und weder Klartexte noch Schlüssel kennen, aber mit Ausnahmen, wo es sinnvoll ist, und wenn es ihm der Nutzer nach entsprechender Aufklärung explizit erlaubt.

Auch beim Client sind höchste Sicherheitsanforderungen zu beachten: Es muss darauf geachtet werden, dass Geheimnisse soweit wie möglich gar nicht erst in den Cache des Browsers gelangen und ansonsten dieser nach Beendigung der Sitzung gelöscht wird (durch Anleitung des Kunden, entsprechende Einstellungen zu wählen). Ferner sind Sitzungsdaten des Clients stark zu verschlüsseln und der Schlüssel muss nach Ende der Sitzung (auch bei Abbruch) weggeworfen sein.

Sowiel Wissen wie nötig, sowenig wie möglich

Es ist klar, dass Server und Client sich beim Erwerb von Wissen über Nutzerdaten zurückhalten sollten. Aber wie steht es damit beim Kunden?

Dieser sollte ebenfalls sein Wissen im Wesentlichen auf den Zugang zum Dienst beschränken. Denn dafür ist ja der Dienst da, um den Nutzer und seine Merkfähigkeit zu entlasten. Allerdings sind in der Box alles Daten natürlich seine Daten. Er hat jederzeit das gute Recht, diese nach Belieben abzurufen. Wenn er entscheidet, dass das nötig ist, ist es nötig.

Gute Wissensverteilung

Für die Sicherheit ist essenziell, dass das Wissen gut verteilt ist: Während der Server nur stark verschlüsselte Daten verwaltet und sich um Backups kümmert, sollte der Client nur für Benutzersitzungen ins Spiel kommen. Ein- und Ausgabe von Geheimnissen finden ohnehin über den Browser statt, d. h. der Client weiß zu diesem Zeitpunkt nicht mehr, wenn er auch die Verschlüsselung übernimmt. Der Server braucht die Schlüssel und das Hauptkennwort dann aber nicht auch noch zu kennen.

Der Nutzer braucht dagegen nur das Hauptkennwort auswendig zu wissen und (für den zweiten Faktor bei der Authentisierung) sein Gerät zu besitzen. Gelegentlich wird er ein neues Gerät in den Kreis der berechtigten Geräte einreihen wollen und kann dies bei key.matique über einen Authentisierungs-Schlüssel tun, den er sich vielleicht beizeiten ausdruckt. Ansonsten muss er sich nur in seiner Box zurecht finden, mehr nicht.

Wann sollte der neue Begriff gebraucht werden?

Der Begriff "Cautiously Knowing Service" sollte gebraucht werden, um einen SaaS (Software as a Service) zu beschreiben, der folgende Forderungen erfüllt:

  • Der Service muss auf allen drei Ebenen Nutzer, Client und Server nach dem Prinzip verfahren: Soviel Wissen wie nötig, sowenig Wissen wie möglich. Das Wissen ist so zu verteilen, dass es möglichst wenig angreifbar ist, aber auch nicht verloren geht.
  • Der Service muss, soweit nicht für bestimmte Funktionen notwendig und vom Nutzer nach entsprechender Aufklärung explizit Ausnahmen erlaubt werden, geheime Nutzerdaten verschlüsseln und die Verschlüsselung nur auf dem Client durchführen und dem Server keine Kenntnis von Klartexten, Schlüsseln und dem Hauptkennwort geben.
  • Der Service muss sicherstellen, dass nach Beendigung oder Abbruch einer Sitzung sämliche Clientdaten durch Löschung oder Verschlüsselung für Dritte unzugänglich geworden sind.
  • Der Service muss dem Benutzer gegenüber deutlich machen, welche Daten als "streng geheim" eingestuft werden.
  • Der Benutzer muss die Möglichkeit haben, alle Daten, die nicht
    • die Kontaktaufnahme des Services zum Benutzer,
    • den Zahlungsverkehr oder
    • Einstellungen für den Dienst betreffen, oder
    • bei denen es sich um reine Bezeichner (Objektnamen) handelt, oder
    • die sonst nur zur Verwaltung der eigentlichen Nutzerdaten dienen und deren Kenntnis der Server dafür braucht
    als "streng geheim" einzustufen.
  • Streng geheime Nutzerdaten im Klartext, die der Service ausnahmsweise verarbeiten darf, dürfen nur solange wie nötig gemerkt und auch nur im RAM gehalten werden. Es ist sicherzustellen, dass kein Speicherabzug auf der Platte entstehen kann.
  • Nutzerdaten, die nicht als "streng geheim" eingestuft sind, sind vom Service dennoch sorgfältig zu behandeln und auf dem Server nur im RAM, auf RAM-Disks oder auf verschlüsselten Platten zu halten (deren Schlüssel beim Hochfahren des Systems von außen her eingegeben werden muss).

Wofür sollte der neue Begriff NICHT gebraucht werden?

Er sollte nicht gebraucht werden, um Dienste, die obige Bedingungen noch nicht erfüllen, zu disqualifizieren. Wir wollen keineswegs behaupten, dass obige Definition als einzige für Achtsamkeit im Bereich von Software as Services steht. (Wir hielten auch uns selbst durchaus schon für achtsam und vorsichtig im Umgang mit Kundengeheimnissen, bevor wir anfingen, uns mit der Client-Encryption zu beschäftigen.)

Um die Eigenschaften von Web-Diensten vergleichen zu können, muss man sie griffig beschreiben könnnen. Und dafür braucht es eben Begriffe. Nur dafür ist dieser Begriff gedacht.

Sind die Forderungen an einen "Cautiously Knowing Service" in Stein gemeißelt?

Natürlich nicht. Geben wir einfach den oben genannten Forderungen die Versionsnummer "0.1" und halten uns damit offen, sie den Anforderungen der Zeit bei Bedarf anzupassen.

Für den Übergang

Wenn ein Service die Eigenschaft "Cautiously Knowing" erwerben will, dauert diese Umstellung sicherlich eine Weile. Ich schlage vor, dass dieser Übergang sauber dokumentiert wird: D. h. welche Punkte der oben genannten Definition bereits erfüllt, welche noch in Arbeit sind etc.

Für key.matique ist dieses Dokument im Handbuch-Teil Wie es funktioniert unter Datenschutz > Cautiously knowing Service abgelegt.

 

*) Das wollen wir jedenfalls zu deren Gunsten annehmen. Es ist aber zur Beurteilung von Schutzmaßnahmen unabdingbar, sich in die Rolle eines Angreifers hineinzudenken.

**) Dieser Umstand stellt den eigentlichen Schutz des Benutzers dar. Daneben bleibt dem Benutzer aber auch immer die Möglichkeit, das Komplementskonzept. anzuwenden. In diesem Fall käme auch ein böswilliger Serverbetreiber nur an unvollständige Geheimnisse heran.


>> Zurück zum Artikelverzeichnis >>