AKBP-II 1999: Gruppe 0

Crypt-Filesystem

Aufgabenstellung:

Aufgabe war es, ein Loopback-Filesystem zu erstellen, wobei die Dateien in dem gemounteten Verzeichnis verschlüsselt abgelegt werden. Dabei soll für den Anwender das Ver- und Entschlüsseln transparent sein, d.h. nachdem das Verzeichnis gemounted worden ist, kann darauf wie auf ein gewöhnliches Filesystem zugegriffen werden.

Das Vorhaben läßt sich prinzipiell in drei Teilprobleme gliedern: das Loopback-Filesytem, die Verschlüsselungsalgorithmen sowie das Management der Schlüssel.

Implementierung:

Unser Filesystem geht von dem Lofs-Filesystem aus. Anfangs standen wir vor dem Problem, uns einen Überblick über die vielfältigen Strukturen des Solaris-Kernels zu verschaffen, mit denen wir uns die nächsten zwei Wochen beschäftigen würden. Im Mittelpunkt steht natürlich die vnode-Struktur, die unter Solaris eine Filesystem-unabhängige Repräsentation eines Files darstellt. Außerdem ist u.a. auch die vfsp-Struktur von Bedeutung, die eine gemountete Instanz eines Filesystems darstellt.

Wir begannen mit der Erstellung eines einfachen Loopback-Filesystems, welches die grundsätzlichen Funktionen zur Verfügung stellt, die für ein Filesystem benötigt werden. Dabei werden in den meisten Fällen die Aufrufe einfach an das darunterliegende Filesystem weitergereicht. Nachdem wir dieses "Gerüst" mounten und umounten konnten, fingen wir damit an, die für unserer Crypt-Filesystem wichtigen Funktionen zu schreiben.

Diese Funktionen sind die read- und write-Funktionen, sowie die getattr-Funktion. Die read- und die write-Funktion sind der Kern des Crypt-Filesystems. Die write-Funktion übernimmt die Daten, die geschrieben werden sollen, und schreibt diese in einen Zwischenpuffer. Wichtig dabei ist zu beachten, ob die zu schreibende Datei schon existiert und möglicherweise unverschlüsselt ist. In diesem Fall soll natürlich weiterhin (z.B. beim Anhängen an die Datei) unverschlüsselt geschrieben werden. Ist die Datei schon gecrypted, so müssen der übergebene Offset und die Länge der Schreibanforderung richtig umgesetzt werden. Hierzu müssen unter Umständen Teile der schon existierenden Datei nochmals eingelesen und entschlüsselt werden, um den Puffer auf eine durch 8 teilbare Länge aufzufüllen. Dies ist deswegen notwendig, weil das verwendete symmetrische Verschlüsselungsverfahren DES auf 8 Byte Blöcken arbeitet. Nachdem die Daten in den Puffer übertragen wurden und eventuell - falls die Datei schon existiert - Teile noch nachgeladen wurden, um den Puffer aufzufüllen, wird der Puffer mit DES verschlüsselt. Danach wird die write-Funktion des darunterliegenden Filesystem aufgerufen, die den Puffer dann auf Platte schreibt.

Die read-Funktion arbeitet vom her Konzept ähnlich, nur selbstverständlich in der anderen Richtung. Sie muss immer ein Vielfaches von 8 Bytes von dem darunterliegenden Filesystem anfordern, die Daten entschlüsseln und dann nur das nach oben weitergeben, was wirklich angefordert wurde.

Wie oben schon angesprochen, sollen auch unverschlüsselte Dateien möglich sein, die dann natürlich nicht verschlüsselt weitergeschrieben werden sollen. Dazu ist es notwendig, eine verschlüsselte Datei zu erkennen. Zu diesem Zweck benutzen wir einen Header, der einige Verwaltungsinformationen beinhaltet. Unter anderem enthält er eine magic number, mit dem wir eine von uns verschlüsselt geschriebene Datei erkennen. Ausserdem können wir noch einen Namen für den verwendeten Schlüssel abspeichern, das verwendete Verfahren (DES, Triple-DES, simples ROT13, usw.) sowie die richtige Dateilänge ohne Header.

In der derzeitigen Version ist nur Verschlüsselung mittels DES vorgesehen, aber weitere Verfahren sind natürlich leicht einzubauen. Der Name für den Schlüssel bietet die Möglichkeit, zu erkennen, ob die Datei mit dem Schlüssel, mit dem das Filesystem gemounted wurde, auch gecrypted wurde. Es besteht bei DES natürlich keine Möglichkeit, zu erkennen, ob die gewünschte Datei mit dem angegeben Key verschlüsselt wurde. Möglicherweise wird mit einem falschen Key eben fehlerhaft entschlüsselt. Um dies zu verhindern, kann man einen Schüssel mit einem Namen assoziieren. Allerdings fordert dies Sorgfalt vom Anwender, da er nun bei Angabe des richtigen Schlüssels gepaart mit einem jedoch falschen Namen auch keinen Zugriff auf die Datei erhalten würde. Deshalb ist diese Funktionalität derzeit nicht eingebaut.

Schlüsselverwaltung:

Eine Schlüsselverwaltung im herkömmlichen Sinne bietet unsere derzeitige Version nicht. Wir haben uns dafür entschieden, den Schlüssel beim mounten zu übergeben. Dies beschränkt die Anwendung, da ein Filesystem nur von Root gemounted werden kann und dann alle Anwender, die die entsprechenden Rechte haben, auch Zugriff auf die Dateien bekommen. Jedoch ist dies eine Funktionaltität, die optimal für eine Anwendung auf einem Heimrechner bzw. Einbenutzerrechner paßt. Hier kann der Benutzer (der daheim auch Root werden kann) wichtige Dateien verschlüsselt ablegen. Ein Diebstahl der Hardware gefährdet die enthaltenen Daten nicht. Eine Erweiterung in Richtung Mehrbenutzerverwaltung mit Schlüsseln, die beispielsweise mit einer Prozess-ID assoziiert werden, ist denkbar. Bei der derzeitigen Implementierung ist es jedoch möglich, für jeden Benutzer, der Verschlüsselung benötigt, ein eigenes Verzeichnis mit eigenem Schlüssel zu mounten.

Eine kurze Bemerkung zur Technik: Der Schlüssel bzw. der DESContext liegt im Kernelspace "unterhalb" der vfsp-Struktur, wo er natürlich gegen Angriffe aus dem Userlevel sicher ist. Auch ein Root hat darauf keinen Zugriff, ausser mittels einem Kerneldebugger, indem er den Speicher ausliest.

Verschlüsselungstechnik:

Wie oben schon erwähnt, verwenden wir derzeit DES, ein symmetrisches Verfahren mit 56 Bit Schlüssellänge. Es sollte erwähnt werden, daß DES mittlerweile mit einigem technischen Aufwand innerhalb vertretbarer Zeit gebrochen werden kann (siehe z.B. den Wettbewerb von RSA, bei dem in weniger als 24 Stunden mit viel Hardwareaufwand der Schlüssel gefunden werden konnte). Eine Erweiterung auf sicherere Verfahren wie Triple-DES oder IDEA sind jedoch nicht allzuschwer zu implementieren. Ferner sollte auch DES für Normalanwender mit nicht sehr wichtigen Daten noch ausreichend sicher sein.

Geschwindigkeit:

Auf einer Sun Ultra1 creator haben wir ein paar "Praxistests" durchgeführt. Das Verschlüsseln von Daten zeigt keine grösseren Verzögerungen. Noch interessanter ist das Lesen: das Abspielen eines gecrypteten Mpeg3-Songs oder eines Quicktime-Filmes funktionieren weiterhin in Echtzeit.

Bedienung:

Für das Crypt-Filesystem wurde ein spezifischer mount-Befehl implementiert, der in /usr/lib/fs/akbpfs abgelegt wird und so von dem 'generischen' mount-Befehl mit der Option -F akbpfs aufgerufen werden kann.

Der mount-Befehl fragt anschließend nach einem acht Byte langen Schlüssel, der in dem gemounteten Crypt-Filesystem zu verwenden ist. Zusätzlich muß ein bis zu acht Zeichen langer Schlüsselname angegeben werden. Der Schlüssel wird normalerweise alphanumerisch eingegeben. Das Filesytstem-spezifische mount-Kommando versteht jedoch auch die Option -n, mit der der Schlüssel als eine Folge von acht Dezimalwerten zwischen 0 und 255 eingegeben werden kann. Diese Option wird beim generischen mount-Befehl als -o n spezifiziert.