in english IMMD IV Hauptseite Zurück Nach oben Weiter Hilfe Rie - 14. Jan. 1997

AKBP-II 1997: Gruppe 4

Es wird empfohlen, die aktuellere englische Version zu lesen!

Das Crypt-Dateisystem

Funktionalität:

Beim Crypt-Dateisystem handelt es sich um ein Loopback-Filesystem, das es dem Benutzer erlaubt, Daten verschlüsselt abzuspeichern.

Nachdem das Crypt-Dateisystem gemountet wurde, kann mit Hilfe des User-Level-Programms cryptfs_setkey einer Shell ein Schlüssel zugeordnet werden, der von nun an zum ver- und entschlüsseln bei allen Dateizugriffen innerhalb des Crypt-Dateisystems verwendet wird. Dabei ist zu beachten, daß die Weitergabe des Schlüssels an die UNIX-Prozeßerzeugung geknüpft ist: Alle Sohnprozesse der mit cryptfs_setkey erzeugten Shell erhalten automatisch eine Kopie des Schlüssels und erhalten somit Zugiff auf die verschlüsselten Daten. Dieses Vorgehen ist besonders aus sicherheitstechnischer Sicht interessant, da selbst bei einem "Einbruch" in einen Rechner der Schlüssel nur schwer zugänglich ist.

Für den Benutzer bleibt das ver- und entschlüsseln transparent: Sobald der Schlüssel gesetzt wurde, können alle UNIX-Programme wie gewohnt benutzt werden, während das unterliegende Crypt-Dateisystem sich selbständig um das Krypten kümmert.

Implementation:

Das Crypt-Dateisystem besteht aus den drei logischen Komponenten Dateisystem-, Vnode- und Schlüsselverwaltung.

Dateisystem-/Vnode-Verwaltung

Die Dateisystemverwaltung unterscheidet sich kaum von einem "normalen" Dateisystem. Der wesentliche Unterschied besteht darin, daß neben einer Vnode-Liste eine separate Liste für die Verwaltung der Krypt-Vnodes (siehe unten) gehalten wird.

In den Funktionen für die Vnode-Verwaltung wird die eigentliche Arbeit erledigt, wobei alle Aktionen, die nicht an der Verschlüsselung beteiligt sind, einfach an das unterliegende Dateisystem weitergegeben werden. Die Ver- und Entschlüsselung selbst wird in der write- bzw. read-Funktion durchgeführt.

Da die Kryptroutinen nur auf Blöcken arbeiten (jeweils acht Bytes), werden verschlüsselte Dateien um eine Blocklänge vergrößert. Somit ist sichergestellt, daß der Krypt-Algorithmus auch die letzten Bytes einer Datei (wenn diese nicht genau einen 8-Byte-Block füllen) bearbeiten kann. Allerdings muß beim Lesen, Schreiben usw. diese veränderte Dateilänge berücksichtigt werden, um Inkonsistenzen zu vermeiden. Zudem wird beim Lesen und Schreiben innerhalb einer Datei darauf geachtet, immer vollständige Blöcke zu bearbeiten, auch wenn der Benutzerauftrag nicht genau mit einer Blockgrenze beginnt und endet, was ebenfalls eine Folge der blockorientierten Kryptroutinen ist.

Die Schlüsselverwaltung

Das Verschlüsselungsverfahren

Als Verschlüsselungsverfahren wird das symmetrische System DES verwendet, d.h. es gibt nur einen Schlüssel zum Ver- und Entschlüsseln. In der derzeitigen Version hat der Schluessel eine Laenge von 8 Byte; er wird in dem bereits erwähnten User-Level-Programm "cryptfs_setkey" vom Benutzer im Hex-Format angegeben. Die Verwaltung dieses Schlüssels im Unix-Kern, die einen prozeßabhängigen und an die Sohnprozesse vererbbaren Schlüssel erlaubt, wird im folgenden näher erläutert.

Die Schlüsselverwaltung

Um die Vererbung zu ermöglichen, muß der Schlüssel in einer prozeßabhängigen Datenstruktur abgelegt werden, die nach den Systemaufrufen "fork()" und "exec()" bestehen bleibt. Hier bieten sich die Filedeskriptoren an, da die Einträge der file descriptor table beim Erzeugen eines Sohnprozesses dupliziert werden bzw. beim Ausführen eines Kommandos mit "exec()" erhalten bleiben. Konkret wurde ein bestimmter Filedeskriptor (Nummer 63) ausgewählt, der, wenn ein Prozeß auf verschlüsselte Daten zugreifen können soll, auf eine spezielle v-node verweisen muß, in deren private-data-Bereich der Schlüssel vermerkt ist. Beim Aufruf der Operationen "read()" und "write()" des Crypt Filesystems wird zunächst geprüft, ob der 63. Eintrag in der file descriptor table des aufrufenden Prozesses auf eine vnode des passenden Typs (also auf eine "key-vnode") verweist. Ist dies nicht der Fall, wird der Aufruf mit dem Rückgabewert für "Access denied" (EACCES) abgebrochen. Wird die passende key-vnode vorgefunden, kann der Schlüssel ausgelesen und zum ver-/entschlüsseln benutzt werden. Hierbei kann nicht getestet werden, ob es sich um den "passenden" Schlüssel handelt, d.h. bei Vorliegen eines falschen Schlüssels liefert die Lese-Routine unbrauchbare Ausgaben.

Das Setzen des Schlüssels

Um den Codeaufwand, der im Cryptfilesystem-Modul für die Erzeugung der key-vnodes anfällt, möglichst gering zu halten, wird ein key-vnode von der "lookup()"-Funktion des Cryptfilesystems erzeugt, wenn ein Aufruf mit dem Namen ".keytab" durchgeführt wird. In "cryptfs_setkey" wird deshalb ein "open()" auf dieses File aufgerufen, daß einen Filedeskriptor zurückgibt, der auf eine key-vnode verweist. Diese ist zunächst nicht mit einem Schlüssel initialisiert. Mit Hilfe von "dup2()" sorgt "crypt_setkey" nun dafür, daß gemäß Konvention Filedeskriptor 63 auf den neuen key-vnode zeigt; Der zunächst erhaltene Filedeskriptor wird freigegeben. Die Initialisierung des key-vnode erfolgt durch einen Aufruf von "write()" mit dem vom Benutzer angegebenen Schlüssel als dem zu "schreibenden" Puffer. Dieser Schlüssel wird in den "private data"-Bereich des key-vnodes eingetragen, aus dem er bei nachfolgenden Lese- und Schreiboperationen über den Zugriff auf Filedeskriptor 63 gelesen werden kann. Ist der vom Benutzer an "crypt_setkey" übergebene Schlüssel falsch oder wird versucht, auf eine Datei des Cryptfilesystems zuzugreifen, die - z.B. von einem anderen Benutzer - mit einem anderen Schlüssel verschlüsselt worden ist, kann dies in der derzeitigen Version noch nicht erkannt werden. Der entsprechende Aufruf von "read()" wird deshalb zwar scheinbar erfolgreich zurückkehren, aber die gelesenen Daten sind freilich unbrauchbar.

Erweiterungsmöglichkeiten:

Hier noch ein kleiner Ausblick auf "Features", die evtl. noch zu implementieren wären:
  • Vergeben von file-handles (NFS)
  • Mountoption zum Festlegen der Verschlüsselungsrichtung: Bisher wird beim Lesen ent- und beim Schreiben verschlüsselt. Will man aber z.B. Dateien, die im Klartext auf der Platte liegen, verschlüsselt übers Netz schicken, so könnte dies durch eine Umkehrung der Verschlüsselungsrichtung erreicht werden.
  • Anbieten verschiedener Verschlüsselungsverfahren
  • Erkennen falscher Schlüssel
  • Minimierung der Anzahl globaler Symbole
  • Fehlertoleranz von ``setkey''
  • ...
    • Unser Server | Brief an Webmaster | Navigationshinweise | Suche