Besonderheiten von Qabel Box verglichen mit anderen Dateisystemen

von Paul Rösler

Um die in Qabel gespeicherten Dateien mit den zugehörigen Schlüsseln verschlüsselt auf dem Server abzulegen, haben wir ein eigenes intuitives Dateisystem entwickelt.

Anforderungen

  1. Die Anforderungen an dieses Dateisystem waren:
  2. Daten und Metadaten sind vertraulich, integer und authentisch auf dem Server gespeichert.
  3. Die eigenen Daten sollen mit nicht mehr als dem privaten Schlüssel der Identität zugänglich sein, sodass nur der private Schlüssel auf weitere Geräte übertragen werden muss.
  4. Die Metadaten zur Verwaltung und Strukturierung des Dateisystems sollen wenig Speicherplatz benötigen.
  5. Die Metadaten für Ordner und Dateien sollen variabel erweiterbar sein.
  6. Die Daten auf dem Server sollen weder Schluss auf die Dateistruktur noch auf Nutzerbeziehungen zulassen. Die einzige Aufgabe des Servers ist dabei, die angefragten Dateien an jeden bereitzustellen und für den jeweiligen Besitzer das Schreiben und Löschen seiner Dateien zu ermöglichen.
  7. Das Erteilen und Entziehen des Lesezugriffs soll wenige Schreibzugriffe auf den Server erfordern.
  8. Das Erteilen des Zugriffs auf ein Element (Ordner/Datei) bezieht sich auf das Element und alle Kindelemente (Unterordner und enthaltene Dateien).
  9. Das System soll mit möglichst wenig asymmetrischer Kryptographie auskommen.

Andere Dateisysteme im Vergleich

Dateisysteme, bei denen lediglich die Dateien verschlüsselt werden, können viele der genannten Anforderungen nicht erfüllen. So werden Dateien bei Seafile [1] zwar mit einem Schlüssel, abgeleitet von einem Passwort, verschlüsselt. Die Dateistruktur und die Metadaten (u.a. Dateiname) bleiben allerdings im Klartext online gespeichert.

Auch für verschlüsselten Speicher konzipierte Dateisysteme konnten nicht alle Anforderungen erfüllen. So beschreibt Tresorium [2] eine Herangehensweise, bei der alle Schlüssel eines geteilten Ordners direkt oder indirekt mit einem Gruppenschlüssel, welcher durch einen Gruppen-Diffie-Hellman berechnet wird, verschlüsselt werden. Das in Tresorit [3] verwendete Verfahren verschlüsselt einen zufälligen Gruppenschlüssel mit den öffentlichen RSA Schlüsseln aller berechtigten Nutzer. Der hauptsächliche Nachteil der beiden Systeme ist, dass das Teilen von Unterordnern eines geteilten Ordners nicht in der gleichen Datenstruktur möglich ist. Außerdem wird dem Server mitgeteilt, welcher Nutzer Zugriff auf die Daten hat. Unser System ähnelt der Architektur von Cryptree [4]. Cryptree ist ein effizientes Dateisystem, bei dem die Schlüssel von untergeordneten Elementen aus dem Schlüssel des übergeordneten Elements abgeleitet werden. Dadurch impliziert der Besitz eines Schlüssels, dass die Schlüssel aller untergeordneten Elemente berechnet werden können. Der symmetrische Schlüssel des obersten geteilten Elements wird asymmetrisch mit dem öffentlichen Schlüssels des berechtigten Nutzers verschlüsselt. Das resultierende Chiffrat wird an den berechtigten Nutzer gesendet.

Unsere Herangehensweise unterscheidet sich durch ein einfacheres und schlankeres Schlüsselmanagement. Zum einen existiert für jede Datei nur ein Schlüssel welcher bei jedem Schreibzugriff neu erzeugt wird. Es zeichnet sich außerdem dadurch aus, dass alle Metadaten der Dateien und Unterordner eines Ordners in je einer Metadatei gespeichert sind. Dazu zählen Namen, Größen, Schlüssel, weitere berechtigte Nutzer und die Pfade zu den verschlüsselten Dateien bzw. Metadateien der Unterordner.

Dadurch, dass Dateien bei jedem Upload – egal ob initial oder als Update – mit einem neuen Schlüssel verschlüsselt werden, kann sichergestellt werden, dass beim Entziehen von Berechtigungen lazy-revocation automatisch durchgeführt wird. Die Nutzung eines neuen Schlüssels ist insofern kein Overhead, dass die übergeordnete Metadatei ohnehin erneut beschrieben werden muss (Update der Größe, Änderungsdatum, …) und so der neue Schlüssel eingetragen werden kann. Die eigentliche Verschlüsselung muss auch durchgeführt werden und würde mit dem alten Schlüssel nicht schneller ablaufen.

Unser Dateisystem im Detail

Jeder Ordner wird durch eine Metadatei (Directory Metadata DM) abgebildet. Diese Metadatei enthält alle Metainformationen zu den in dem Ordner enthaltenen Unterordnern und Dateien. Die oberste Metadatei (DMindex) wird mit dem öffentlichen Schlüssel des Besitzers verschlüsselt. Der Name dieser Datei wird unter anderem aus der Hashsumme des privaten Schlüssels des Besitzers abgeleitet. So ist sichergestellt, dass der Besitzer diese Datei findet und sie mit seinem privaten Schlüssel entschlüsseln kann. Sobald der Lesezugriff auf einen Ordner erteilt wird, wird der Schlüssel der betreffenden Metadatei mit dem öffentlichen Schlüssels des Berechtigten verschlüsselt und an ihn gesendet. Sobald diese Berechtigung durch den Besitzer zurückgezogen wird, wird die entsprechende Metadatei mit einem neuen Schlüssel verschlüsselt, sodass der zuvor Berechtigte diese Datei nicht mehr lesen kann. So ist sichergestellt, dass die Berechtigung zu jeder Zeit durchgesetzt wird. Zwar sind Dateien nach dem Berechtigungsentzug noch so lange lesbar, bis sie geändert werden. Da der Zugang zuvor aber ohnehin bestand, bietet das keinen erweiterten Einblick in die Daten.

Damit die Metadateien nicht in das begrenzte Speichervolumen der Nutzer eingehen, werden sie separat von den anderen Dateien gespeichert.

Erfüllung der Anforderungen

Alle der oben aufgeführten Anforderungen können mit unserem Dateisystem erreicht werden. Allerdings könnte der Server durch dauerndes Beobachten der Schreib und Lesezugriffe die Dateistruktur und Berechtigungserteilungen erkennen. Beispielsweise wird beim Upload einer Datei immer auch die Metadatei des übergeordneten Ordners beschrieben.

Das beschriebene Dateisystem verschleiert bereits viele Metainformationen. Wir arbeiten aber weiter daran, das Maß an Metadaten-Verschleierung zu erhöhen.

Eine detailliertere Beschreibung befindet sich hier [5].

[1] https://github.com/haiwen/seafile
[2] http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6337494&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6337494
[3] https://tresorit.com/
[4] http://www.net.t-labs.tu-berlin.de/~stefan/srds06.pdf
[5] http://qabel.github.io/docs/Qabel-Protocol-Box/