„Zero Knowledge“ ist eine Frage der Architektur, nicht der Richtlinie

„Zero Knowledge“ gehört zu den meistbenutzten und am wenigsten hinterfragten Begriffen in der Cloud-Speicher-Branche. Er steht auf Preisseiten neben „Verschlüsselung nach Militärstandard“ und „Sicherheit auf Bankniveau“. Meist steckt dahinter etwas Wahres, aber Bescheidenes. Der Anbieter hat sich zur Regel gemacht, Kundendaten nicht anzusehen. Zugriffskontrollen und ein Audit-Log sichern diese Regel ab, und die Mitarbeitenden sind geschult, sich daran zu halten.

Das ist eine Richtlinie, also ein Versprechen über Verhalten. Ein Insider kann es brechen, ein Gericht kann es per Anordnung aushebeln, ein Angreifer mit den richtigen Zugangsdaten kann es umgehen. Oder der Anbieter ändert es stillschweigend in einer späteren Fassung der Nutzungsbedingungen. Für nichts davon muss die Kryptografie versagen. In einem System, das auf einer Richtlinie beruht, war es nie die Kryptografie, die den Anbieter von den Daten fernhielt.

Bei einer Architektur ist das anders. Hier kann der Anbieter die Daten nicht lesen, weil er nie etwas besitzt, womit das ginge. Es gibt keinen Schlüssel, den jemand missbrauchen könnte. Es gibt keine Hintertür, die der Anbieter auf Anordnung öffnen müsste. Und es gibt kein privilegiertes Konto, dessen Übernahme Klartext preisgibt. Das Versprechen lautet nicht „Wir tun es nicht“, sondern „Wir können es nicht, und zwar aus diesem Grund“.

Dieser Artikel zeigt, wie Sie beides auseinanderhalten. Als Beispiel dient Sapherbox, einschließlich der Stellen, an denen selbst eine Architektur ihre Grenzen offen benennen muss.

Der Test: Woher kommt der Schlüssel?

Die nützlichste Frage an jeden verschlüsselten Dienst lautet: Wo entstehen die Schlüssel, und wer bekommt sie überhaupt je in die Hand?

In Sapherbox entsteht jeder Schlüssel in Ihrem Browser. Ihr Account Master Key besteht aus 256 Zufallsbits, die Ihr Gerät bei der Registrierung erzeugt. Dort entstehen auch Ihre Identitätsschlüsselpaare, die klassischen ebenso wie die Post-Quanten-Paare. Die privaten Schlüssel werden mit dem Account Master Key verschlüsselt, bevor irgendetwas gespeichert wird. Den Account Master Key selbst verschlüsselt Ihr Gerät mit einem Schlüssel, den es aus Ihrem Passwort ableitet. Das Passwort verlässt Ihr Gerät nie. Beim Server kommen nur verschlossene Behälter an. Er kann sie speichern, sichern und Ihnen zurückgeben. Öffnen kann er keinen davon.

Zum Vergleich die verbreitete Alternative. Der Anbieter erzeugt für jeden Kunden einen Schlüssel, legt ihn in einem Schlüsselverwaltungsdienst ab und verschlüsselt damit die Daten auf dem Server. Die Daten sind dann im Ruhezustand verschlüsselt. Das hilft, wenn eine Festplatte gestohlen wird. Den Schlüssel hat aber der Anbieter. „Zero Knowledge“ beschreibt hier, was der Anbieter will, nicht was er kann. Auf die Frage, wo der Schlüssel liegt, lautet die Antwort: „Bei uns, geschützt durch eine Richtlinie.“

Fünf Stellen, an denen sich die Architektur zeigt

Auf der Startseite sehen Richtlinie und Architektur gleich aus. Der Unterschied zeigt sich in den Sonderfällen, also überall dort, wo eine bequeme Funktion nur mit Klartext beim Anbieter funktionieren würde. Genau dort lohnt sich der Blick.

Passwort zurücksetzen. Kann ein Anbieter Ihr Passwort zurücksetzen und Ihnen danach wieder Zugriff auf Ihre Dateien geben, dann hat er einen Schlüssel zu diesen Dateien. Ist der Schutz dagegen in die Architektur eingebaut, muss das Zurücksetzen über etwas laufen, das nur Sie besitzen. Sapherbox nutzt dafür einen Wiederherstellungscode, den Sie bei der Registrierung einmal angezeigt bekommen. Optional kommt ein Escrow-Schlüssel hinzu, den Ihre eigene Organisation erzeugt und verwahrt. Einen Wiederherstellungsschlüssel des Anbieters gibt es nicht. Warum das so ist, haben wir in einem eigenen Artikel beschrieben.

Suche. Eine Volltextsuche über Klartext auf dem Server bedeutet, dass der Server Ihre Dokumente liest. Wer die Daten nicht lesen kann, muss suchen, ohne die Wörter zu kennen. Die Suche in Sapherbox arbeitet mit verblindeten Tokens. Ihr Gerät berechnet sie mit einem Schlüssel, an den der Server nicht herankommt. Der Server gleicht die Tokens ab, ohne zu erfahren, wofür sie stehen. Der Preis dafür ist dokumentiert. Der Server erfährt, welche Dateien gemeinsame Tokens haben, aber nicht, welche Wörter.

Teilen. Kann der Server einem neuen Empfänger einen Dateischlüssel aushändigen, dann kann er ihn jedem aushändigen, auch sich selbst. In Sapherbox versiegelt die teilende Person den Schlüssel auf ihrem eigenen Gerät für den öffentlichen Schlüssel des Empfängers und signiert die Freigabe. Ein kompromittierter Server kann sich deshalb weder selbst als Empfänger eintragen noch eine Freigabe umleiten. Außerdem wird die Identität des Empfängers beim ersten Kontakt gepinnt. Tauscht jemand den Schlüssel später aus, fällt das auf.

Entzug. Ein System auf Richtlinienbasis löscht eine Zeile aus einer Berechtigungstabelle. Eine Architektur muss die alten Schlüssel unbrauchbar machen, denn die entfernte Person hat sie womöglich noch. Sapherbox rotiert die Schlüssel für alles, was diese Person öffnen konnte.

Scannen und Analysieren. Malware-Scans, Datenklassifizierung, Auswertungen und KI-Funktionen brauchen Klartext. Ein Anbieter, der sie auf dem Server ausführt, hat also Klartext. Sapherbox führt Inhaltsbereinigung, Klassifizierung, SQL-Auswertungen und die KI-Funktionen auf dem Gerät in Ihrem Browser aus. Das geschieht bei Ihnen, vor der Verschlüsselung oder nach der Entschlüsselung. Der Server sieht nur die Ergebnisse, die Sie speichern möchten, und die sind wie alles andere verschlüsselt.

An jeder dieser Stellen bräuchte die bequeme Lösung einen Server, der Ihre Daten liest. Wirbt ein Anbieter mit „Zero Knowledge“ und bietet zugleich Suche und Scans auf dem Server sowie das Zurücksetzen des Passworts per Support-Ticket an, dann beschreibt er eine Richtlinie.

Was auch eine Architektur nicht verbergen kann

Eine ehrliche Architektur sagt auch, was der Server sieht, denn keine Architektur verbirgt alles. Genau deshalb verwenden wir den Begriff „Zero Knowledge“ für Sapherbox nicht. Der Server kennt die Größe Ihrer Dateien und weiß, wann sie angelegt und geändert wurden. Er kennt den Aufbau Ihrer Ordner und weiß, wer worauf mit welcher Rolle Zugriff hat. Er weiß, wer sich angemeldet hat und was diese Person getan hat. Und er weiß, welche verblindeten Suchtokens in welchen Dateien vorkommen. Er sieht die Labels, die die Klassifizierung vergibt. Inhalte, Namen, Notizen, Suchbegriffe, Passwörter und Schlüssel sieht er nicht.

Diese Liste steht in unserer Sicherheitsübersicht. Das Whitepaper für Sicherheitsteams nennt daneben die bekannten Grenzen. Ein kompromittiertes Gerät sieht alles, was die Person sieht, die es benutzt. Die Netzwerkverbindung nutzt klassisches TLS und überträgt Metadaten. Ein Entzug kann bereits heruntergeladene Kopien nicht zurückholen. Eine Architektur, die ihre Grenzen verschweigt, verlangt, dass Sie ihr den Rest einfach glauben. Damit sind Sie wieder bei einer Richtlinie.

Warum der Unterschied heute wichtiger ist als früher

Zwei Dinge haben sich geändert. Erstens fragen Aufsichtsbehörden zunehmend nicht mehr, ob Daten verschlüsselt sind, sondern wer die Schlüssel hat. Diese Frage taucht bei Bewertungen nach Art. 32 DSGVO auf, bei Lieferkettenprüfungen nach NIS2 und in jedem ernsthaften Lieferantenfragebogen. Zweitens ist das Bedrohungsmodell gewachsen. Hält ein Anbieter die Schlüssel, ist er die eine Stelle, an der ein Einbruch, ein Insider, eine gerichtliche Herausgabeanordnung oder ein künftiger Quantencomputer die Daten aller Kunden auf einen Schlag offenlegt. Eine Architektur verlagert dieses Risiko dorthin zurück, wo die Daten hingehören: zu jedem einzelnen Kunden und auf jedes einzelne Gerät.

Was Sie tatsächlich kaufen, verrät nicht der Begriff auf der Webseite. Das verraten die Antworten auf ein paar konkrete Fragen. Wo entstehen die Schlüssel? Wie funktioniert das Zurücksetzen des Passworts? Wie funktioniert die Suche? Was passiert, wenn jemand entfernt wird? Und was sieht der Server? Eine Architektur beantwortet alle fünf mit je einem Satz und legt die Liste dessen vor, was sie nicht verbergen kann. Eine Richtlinie antwortet mit einem Zertifikat und einem Versprechen.

Fragen?

Wenn Sie uns diese fünf Fragen direkt stellen möchten oder Ihr Sicherheitsteam die vollständige technische Beschreibung hinter den Antworten braucht, schreiben Sie uns an hello@sapherbox.com.