Martins key.matiq-Blog
>> Zurück zum Artikelverzeichnis >>
Zero-Knowledge+ (1):
Der "Cautiously Knowing Service"
Geschrieben: 14.12.2020
Letzte Überarbeitung: 24.05.2022
Stichwörter: Sicherheit, Sicherheit mit Bedienbarkeit
In "Zero Knowledge (Clientseitige Verschlüsselung)" 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 Nutzer*innendaten kennt. Manche Serverbetreiber*innen behaupten sogar leichtsinnig1, sie selbst könnten gar nicht an die Nutzer*innendaten kommen, selbst wenn sie es wollten.
Beides ist aber falsch. In der Regel kennen die Serverbetreiber durchaus eine Reihe von Daten der Nutzer*innen, nämlich E-Mail-Adresse, IP-Adresse, Zahlungsdaten. Daten sind vor dem Zugriff des Serverbetreibers nur außerhalb einer Sitzung der Benutzer*in auch gegen deren Willen geschützt, über die mit dem Hauptpasswort verschlüsselte Speicherung. Das ist aber auch bei Online-Passwortmanagern der Fall, die mit serverseitiger Verschlüsselung arbeiten. Umgekehrt könnte aber eine Serverbetreiber*in immer böswilligerweise ihre Software ändern, um Geheimnise von Nutzer*innen auszuspähen. Sie würde damit allerdings ihr Geschäftsmodell untergraben.2
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-side encryption".
Aber auch inhaltlich ist das Konzept, alle Geheimnisse nur noch mit der clientseitigen Verschlüsselung 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 der Empfänger*in möglich sein, eine solche Datei einem Malwarescan zu unterziehen.
Dies über JavaScript zu erledigen, ist angesichts der Menge an Signaturen schier unmöglich. Der Benutzer*in zuzumuten, solche Dateien herunterzuladen und auf ihrem PC zu überprüfen, ist unrealistisch. Es würde vermutlich viel zu selten gemacht werden. Also sollte der Dienst 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 clientseitigen Verschlüsselung 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, der Benutzer*in 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 Nutzer*innendaten 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 der Normalnutzer*in die Möglichkeit, Geheimnisse in Kerngeheimnisse und Begleitdaten zu trennen, als Voreinstellung angeboten werden. (Die versierte Internetnutzer*in wird dagegen schnell herausfinden, wie sie, wenn sie 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 der Benutzer*in.
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 der Benutzer*in die Entscheidung überlässt.
Als Fachbegriff hinter dem "Zero-Knowledge-Server" gilt die "client-side encryption" (clientseitige Verschlüsselung), 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*in, Client und Server, um die Rollenverteilung und die Kompetenzen. Diese Gesamtbetrachtung ist erforderlich, damit die Entdogmatisierung 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 nach 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 Nutzer*innendaten 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 die Kund*in, die Nutzer*in im Blick.
Die Sicherheit von Web-Apps hängt entscheidend von allen drei Ebenen ab: Nutzer*in, Client und Server. Während der Service Client und Server programmieren kann und damit deren Sicherheit bestimmt, sollte er die Nutzer*in führen und sich gleichzeitig ihr unterordnen. Das heißt: Der Service muss der Nutzer*in gegenüber transparent darlegen, was mit deren Daten geschieht, er sollte sie über kritische Aktionen aufklären, ihr kluge Empfehlungen geben, aber letztendlich ihr, der Kund*in 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 die Nutzer*in nach entsprechender Aufklärung ausdrücklich erlaubt.
Wenn dann der Server geheime Daten erhält, muss er natürlich damit äußerst sorgsam umgehen. Er darf diese nur kurzzeitig im flüchtigen Programmspeicher halten und sie keinesfalls (auch nicht kurzzeitig) unverschlüsselt auf eine physikalische Platte schreiben. Er muss Vorkehrungen treffen, dass auch bei Programmabbrüchen keine Speicherabzüge auf die Platte geschrieben werden. Und der flüchtige Hauptspeicher muss auch ansonsten so gut wie irgend möglich vor unbefugtem und unnötigen Datenabgriff geschützt sein.
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 Kund*innen, entsprechende Einstellungen zu wählen). Ferner sind Sitzungsdaten des Clients stark zu verschlüsseln und der Schlüssel muss am Ende der Sitzung (auch bei Abbruch) unwiderbringlich vernichtet werden.
Sowiel Wissen wie nötig, sowenig wie möglich
Es ist klar, dass Server und Client sich beim Erwerb von Wissen über Nutzer*innendaten zurückhalten sollten. Aber wie steht es damit bei der Benutzer*in selbst?
Diese sollte ebenfalls ihr Wissen im Wesentlichen auf den Zugang zum Dienst beschränken. Denn dafür ist ja der Dienst da, um die Nutzer*in und ihre Merkfähigkeit zu entlasten. Allerdings sind in der Box alle Daten natürlich ihre Daten. Sie hat jederzeit das gute Recht, diese nach Belieben abzurufen. Wenn sie 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 Nutzer*innensitzungen 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.
Die Nutzer*in braucht dagegen nur das Hauptkennwort auswendig zu wissen und (für den zweiten Faktor bei der Authentisierung) ihr Gerät zu besitzen. Gelegentlich wird sie ein neues Gerät in den Kreis der berechtigten Geräte einreihen wollen und kann dies bei key.matiq über einen Authentisierungs-Schlüssel tun, den sie sich vielleicht beizeiten ausdruckt. Ansonsten muss sie sich nur in ihrer Box zurecht finden, mehr nicht.
Wann sollte der neue Begriff gebraucht werden?
Der Begriff "Cautiously Knowing Service" sollte gebraucht werden, um eine Webanwendung zu beschreiben, die folgende Forderungen erfüllt:
- Der Service muss auf allen drei Ebenen Nutzer*in, 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 von der Nutzer*in nach entsprechender Aufklärung ausdrücklich Ausnahmen erlaubt werden, geheime Nutzer*innendaten 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 bestmöglich Erkundungsangriffe abwehren, die zum Ziel haben, zu erfahren für welche Benutzer*innennamen, -nummern oder E-Mail-Adressen angreifbare Konten existieren oder nicht.3
- 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 der Benutzer*in gegenüber deutlich machen, welche Daten als "streng geheim"4 eingestuft werden.
-
Die Benutzer*in muss die Möglichkeit haben, alle Daten, die nicht
- die Kontaktaufnahme des Services zur Benutzer*in,
- 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 Nutzer*innendaten dienen und deren Kenntnis der Server dafür braucht
- Streng geheime Nutzer*innendaten 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.
- Nutzer*innendaten, 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 mindestens ebenso sicher zu behandeln ist und daher 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 Kund*innengeheimnissen, bevor wir anfingen, uns mit der clientseitigen Verschlüsselung näher 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. Die oben genannten Forderungen sind inzwischen schon einige Male überarbeitet worden und haben inzwischen die Versionsnummer "0.4". Wir halten uns weiterhin offen, sie bei Bedarf den Anforderungen der Zeit anzupassen.
Schutzniveaus
Oben habe ich zwischen "streng-geheim" und weniger geheim unterschieden. Diese Differenzierung reicht jedoch in der Praxis nicht aus, will man (wie es nötig ist) der Benutzer*in die Möglichkeit geben, genau zu wissen, wie ihre Daten geschützt werden. Praktikabel ist es, zwischen verschiedenen Schutzniveaus zu unterscheiden. Im Artikel "Zero Knowledge+ (4): Schutzniveaus" entwickle ich eine Klassifizierung dafür.
Vertretbare Ausnahmen
Nach der 80-zu-20-Regel5 ist Perfektionismus teuer: Es gibt meist einige Probleme, deren Lösung unverhältnismäßigen Aufwand im Verhältnis zum Nutzen bedeutet. Daher sollte es möglich sein, einen Dienst als "Cautiously Knowing" zu bezeichnen, wenn einige nicht besonders wesentliche Abweichungen von den oben genannten Prinzipien bestehen. Wichtig ist aber, dass diese Ausnahmen dokumentiert sind und diese Dokumentation für die Nutzer*innen des Dienstes leicht auffindbar ist. Die Einschränkungen dürfen also keinesfalls verheimlicht werden. Und sie dürfen für die Datensicherheit keine große Rolle spielen.
Diese Art von Ausnahmen sind zu unterscheiden von Ausnahmen, die die Nutzer*in genehmigt, um Funktionen oder eine Performance zu erreichen, die sonst nicht möglich wäre, oder die die Nutzer*in im Rahmen des Übergangs zum Cautiously Knowing genehmigt.
Die vertretbaren Ausnahmen bestehen auch im vollständig implementierten Cautiously Knowing Service und auch ohne lästige Abfrage einer Genehmigung der Nutzer*in im Einzelfall.6 Dafür müssen sie jedoch wirklich notwendig, gut begründet und dokumentiert sein.
Der geregelte Umgang mit solchen Ausnahmen bietet aber auch die Chance, einen Dienst mit optimaler Sicherheit bei gleichzeitig voller Transparenz darüber zu entwickeln.7
Geltungsbereich
Um die Sache komplett zu machen, ist es nötig, zu bestimmen, für welche Arten von Diensten der Begriff "Cautiously Knowing Service" (CKS) gelten soll. Auch für uns gilt: "Schuster bleib bei deinem Leisten!" Wir von der matiq UG haben unsere Kompetenz vor allem bei browserbasierten Webanwendungen. Also sollten wir uns zunächst auf diese beziehen. Vermutlich ist es möglich, die Prinzipien des CKS auch auf viele nicht-browserbasierte Web-Apps zu übertragen. Ob dies allgemein der Fall ist, können wir nicht entscheiden. Noch schwieriger ist die Frage, ob sich das CKS-Konzept allgemein auch auf Software as Services ausweiten lässt. Besser ist es wohl, diese Frage vorerst offen zu lassen.
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.
An derselben Stelle können auch die Schutzniveaus und die "vertretbaren Ausnahmen" dokumentiert werden.
Für key.matiq ist dieses Dokument im Handbuch-Teil Wie es funktioniert unter Datenschutz > Cautiously knowing Service abgelegt.
Schutz des Begriffs "Cautiously Knowing Service"
In die Entwicklung des Konzepts, diesen Artikels und auch der Begriffsfindung haben wir schon einige Arbeit und viele Diskussionen investiert. Deshalb verdient der Begriff schon einen gewissen Schutz vor missbräuchlicher Verwendung.
Wir begrüßen durchaus, sollten andere das Konzept als nützlich für sich ansehen und natürlich dürfen sie dann auch den Begriff für ihr eigenes Produkt verwenden. Aber dann sollte auch die Spezifikation eingehalten werden, das dokumentiert werden, die Versionsnummer benannt werden und es sollte auch einen Verweis auf die Spezifikation geben, einschließlich der Benennung der Urheberin.
Am Einfachsten ist es, diesen Schutz schon einmal vorläufig herzustellen, indem wir dafür das Marken- und das Urheberrecht in Anspruch nehmen. Deshalb reklamieren wir neben der Urheberschaft an diesem Artikel auch die Markenrechte an dem Begriff "Cautiously Knowing Service". Sollten sich Interessierte finden, können wir auch gerne an die Übertragung der Rechte z. B. an einen Verein oder eine Stiftung reden, um hierfür eine unabhängige Instanz zu schaffen.
Nächster Artikel zum Thema "Zero Knowledge+"
"Zero Knowledge+ (2): Schlüsselstreckung"
1) Das wollen wir jedenfalls zu deren Gunsten annehmen. Es ist aber zur Beurteilung von Schutzmaßnahmen unabdingbar, sich in die Rolle einer Angreifer*in hineinzudenken.
2) Dieser Umstand stellt den eigentlichen Schutz der Benutzer*in dar. Daneben bleibt der Nutzer*in aber auch immer die Möglichkeit, das Komplementskonzept. anzuwenden. In diesem Fall käme auch eine böswilliger Serverbetreiber*in nur an unvollständige Geheimnisse heran.
3) Dieses Thema wird im Artikel "Zero Knowledge+ (3): Erkundungsangriffe" behandelt.
4) Der Begriff "streng geheim" ist für eine erste Näherung zwar in Ordnung, aber in der Praxis unzureichend. Unter "Schutzniveaus" führen wir daher differenziertere Begriffe ein.
5) Siehe Wikipedia "Paretoprinzip".
6) Die Benutzer*in sollte nicht um Genehmigungen für jede Kleinigkeit gebeten werden. Eine Fragenflut würde die Aufmerksamkeit für wichtigere Fragen vermindern. Daher gilt auch hier: Weniger ist manchmal mehr.
7) Ich habe mich natürlich gefragt, ob solche Ausnahmen nicht eine Aufweichung der Definition des "Cautiously Knowing Service" bedeuten würden, also eine Ausnahmeninflation eintreten könnte. Doch die Dokumentationpflicht schiebt dem einen Riegel vor: Wer immer Ausnahmen leichtfüßig definieren würde, würde sich auch schnell der Kritik aussetzen, da der gesamte Mitbewerb das ja mitlesen könnte. Umgekehrt würde aber auch das (bewußte oder fahrlässige) Verschweigen von Ausnahmen auf den Dienstbetreiber zurückfallen und seine Seriösität infrage stellen.