CFS: A Cryptographic File System for UNIX

Überblick

• Autor: Matt Blaze, AT&T Bell Labs

• Es handelt sich um einen stabil funktionierenden "Research Prototype". Er wird u.a. am Lehrstuhl "Rechnernetze und verteilte Systeme" der TU Chemnitz bereits seit mehreren Jahren unter den Betriebssystemen Solaris 2.x, Linux 1.x und 2.x sowie SunOS 4.1.x praktisch und mit guten Erfahrungen eingesetzt.

• aktuelle Release: CFS 1.4.0 beta2

• Leistung: transparente Ver -und Entschlüsselung von Dateinamen und -inhalten beim Zugriff

• Für den Zugriff auf die im CFS gespeicherten Daten nutzen die Applikationen das standardisierte UNIX-Dateisystem-Interface (open(), close(), read(), write(), ...), so dass der Einsatz des CFS keinerlei Programm-Modifikationen erfordert.

• Realisierung:

  

  • Der CFS-Server cfsd läuft als mit Superuser-Privilegien ausgestatteter Dämon im Nutzeradressraum (user space). Er verhält sich aus Sicht der Applikationen wie ein NFS-Server, der die Version 2 des NFS-Protokolls über UDP beherrscht und ein eigenes virtuelles Dateisystem exportiert. Dieses Dateisystem wird vom UNIX-Kern per NFS montiert, so dass darauf wie gewohnt über die standardisierten Systemrufe des VFS (Virtual File System) zugegriffen werden kann. Das VFS ermöglicht es, verschiedenste lokale und entfernte Dateisysteme über eine einheitliche Schnittstelle anzusprechen.

  • Über die NFS-Schnittstelle des CFS-Servers werden generell Klartext-Daten ausgetauscht. Diese erscheinen allerdings niemals auf dem Netz, da der System-Kern und der cfsd ausschließlich über das Loopback-Interface (localhost) kommunizieren.

  • Die von den Applikationen geschriebenen bzw. gelesenen Daten werden durch den CFS-Server transparent ver- bzw. entschlüsselt. Die jeweiligen Chiffrate werden vom CFS-Server in einem vom Nutzer bestimmten Teilbaum des UNIX-Dateisystems abgelegt bzw. von dort gelesen. Für diese Zugriffe auf das Dateisystem nutzt der CFS-Server ebenfalls die standardisierte VFS-Schnittstelle. Diesbezüglich verhält er sich also wie eine gewöhnliche Applikation. Daher können die Chiffrate in beliebigen vom VFS unterstützten Dateisystemen liegen, entweder lokal oder auch entfernt, z.B. auf einem entfernten NFS-Server.

  • Neben der NFS-Schnittstelle verfügt der CFS-Server noch über eine auf dem ONC RPC basierende (im obigen Bild durch ADM bezeichnete) Administrations-Schnittstelle, über die das virtuelle Dateisystem des CFS administriert werden kann. Hierfür existieren die Kommandos cattach und cdetach, mit denen CFS-Teilbäume montiert bzw. wieder entfernt werden können.

  • Durch die Verwendung standardisierter Protokolle und Schnittstellen (ONC RPC, NFS, VFS) ist das CFS prinzipiell portabel.

• Die folgende Abbildung, die einem Artikel von Matt Blaze entnommen und leicht modifiziert wurde, zeigt noch einmal den Datenfluss im CFS-Prototyp:

  

• Klartext wird seitens des cfsd niemals auf einem externen Datenträger zwischengespeichert, sondern generell nur im Hauptspeicher gehalten. Dabei ist allerdings zu beachten, dass Klartext in den Swap-Bereich des UNIX-Systems gelangen kann, da dies durch CFS nicht zu beeinflussen ist.

• Es gibt einige kleinere Unterschiede zwischen dem CFS und sonstigen per NFS montierten Dateisystemen:

  • Pfadkomponenten sind auf die Hälfte und volle Pfadnamen auf ca. die Hälfte der normalen Länge begrenzt.

  • "Löcher" in Dateien werden nicht mit Nullen, sondern mit zufälligen Daten (garbage) gefüllt.

  • CFS unterstützt keine special files (Gerätedateien) und keine named pipes (FIFOs).

• Bei CFS 1.4 stehen folgende symmetrische Verschlüsselungsverfahren zur Verfügung:

  Verfahren	Bemerkung
  DES	Hierbei handelt es sich um den weltweit genutzten Data Encryption Standard der US-Regierung mit einem 56-Bit-Schlüssel, der heutzutage allerdings als zu kurz einzuschätzen ist, weswegen die Anwendung dieses Verfahrens nur noch im Rahmen von 3DES (Triple DES) empfohlen wird.
  3DES	Triple DES, also dreifache Hintereinanderausführung von DES-Operationen. 2 Varianten werden unterstützt: mit 2 bzw. 3 unterschiedlichen Schlüsseln, woraus Schlüssellängen von 112 (2×56) bzw. 168 Bit (3×56) resultieren.
  Blowfish	Von Bruce Schneier entwickeltes, sehr effizientes und mittlerweile recht verbreitetes Verfahren mit variabler Schlüssellänge. CFS verwendet 128 Bit lange Blowfish-Schlüssel.
  SAFER-SK128	Dies ist eine verbesserte Version des von James L. Massey entwickelten Verfahrens SAFER und verwendet 128 Bit lange Schlüssel.
  MacGuffin	Experimentelles, von Matt Blaze und Bruce Schneier entwickeltes Verfahren. Laut der 2. Auflage von Schneiers bekanntem Buch "Applied Cryptography" wurde dieses Verfahren noch auf derselben Konferenz, auf der es 1995 offiziell vorgestellt worden war, gebrochen!!
  ...	CFS ist bzgl. der Verschlüsselungsverfahren relativ leicht erweiterbar. Allerdings erfordern derartige Erweiterungen Quelltext-Modifikationen.

• Die Arbeit mit CFS geschieht in Nutzerregie:

  • Jeder Nutzer erzeugt nach Bedarf ihm gehörende CFS-Teilbäume (Kommando cmkdir), typischerweise unterhalb seines Home-Verzeichnisses. Für jeden mittels cmkdir erstellten Teilbaum legt der Anwender eine Passphrase fest, die zur Verschlüsselung des Teilbaums verwendet wird.

  • CFS-Teilbäume und "normale" UNIX-Teilbäume koexistieren problemlos.

  • Der Nutzer montiert seine Teilbäume selbständig im virtuellen CFS-Dateisystem (Kommando cattach) und entfernt sie auch wieder (Kommando cdetach). Zum Montieren benötigt der Nutzer die gültige Passphrase.

  • Jeder CFS-Teilbaum wird separat unter Verwendung einer vom Nutzer gewählten, nur ihm bekannten Passphrase verschlüsselt. Ab CFS 1.3 ist diese Passphrase jederzeit änderbar (Kommando cpasswd), da zur Verschlüsselung der Nutzerdaten ein von CFS zufällig generierter und im CFS-Teilbaum chiffriert gespeicherter Schlüssel verwendet wird. Lediglich dieser Schlüssel wird unter Nutzung der Passphrase chiffriert. Somit ist ein Wechsel der Passphrase möglich, weil dadurch der für die Verschlüsselung der Nutzerdaten verwendete Schlüssel selbst nicht verändert, sondern nur neu chiffriert wird.

  • In älteren CFS-Versionen ist pro Teilbaum nur genau eine Passphrase möglich. Ab CFS 1.4 können auch mehrere Passphrasen pro Teilbaum genutzt werden. Hierfür existiert das Werkzeug cmkkey, das ein neues Verzeichnis erstellt und dort einen Verweis (symbolischen Link) auf den Original-Teilbaum sowie eine Kopie des zur Chiffrierung dieses Original-Teilbaums genutzten Schlüssels ablegt. In diesem neuen Verzeichnis kann dann unabhängig vom Original-Teilbaum bzw. anderen durch cmkkey erstellten Kopien die zum Schutz des Schlüssels eingesetzte Passphrase getauscht werden. Die bei cattach anzugebende Passphrase hängt jetzt davon ab, welches Verzeichnis (Original oder Kopie) als Wurzel des zu montierenden Teilbaums verwendet wird.

• Da alle Verschlüsselungs-Operationen ausschließlich im lokalen CFS-Server erfolgen, werden auch dann, wenn die Chiffrate auf einem entfernten Server (z.B. auf einem zentralen NFS-Server) gespeichert werden, keine Klartexte über das Netz übertragen. Dies ist sehr vorteilhaft, falls das Netz oder der entfernte Datei-Server nur eingeschränkt vertrauenswürdig sind. CFS bietet allerdings generell nur Vertraulichkeit, jedoch keinen Schutz der Integrität und/oder Authentizität der Daten. An den Chiffraten vorgenommene Manipulationen werden also durch das CFS nicht bemerkt.

• Ein Backup der CFS-Teilbäume ist ohne besondere Vorkehrungen möglich. Die CFS-Schlüssel müssen dazu nicht bekannt sein.

• Hauptanwendungsfall von CFS ist der Schutz sensitiver Daten auf lokal administrierten Rechnern, z.B. dem privaten Linux-PC oder dem NFS-Server im als vertrauenswürdig eingestuften LAN.

• CFS wurde in der Programmiersprache C (K&R, kein ANSI-C) implementiert und ist kostenfrei verfügbar (Copyright AT&T). Früher waren die Exportbeschränkungen der USA für starke kryptographische Verfahren zu beachten.

  Es kann mittlerweile von SourceForge.net bezogen werden:

  http://sourceforge.net/projects/cfsnfs/

  Außerdem findet man es auf verschiedenen FTP-Servern, z.B.

  ftp://ftp.hacktic.nl/pub/crypto/disk/cfs

• Die aktuelle Implementierung ist nicht generell für den Multiuser-Betrieb geeignet, da sie single-threaded arbeitet und einen relativ hohen Speicherbedarf aufweist (ca. 0,5 MB pro montiertem Teilbaum).

• CFS 1.4 sollte u.a. auf folgenden Plattformen ohne Probleme einsetzbar sein: SunOS 4.x, HP/UX, Irix, Linux, AIX, Ultrix 4.2, Solaris 2.3 und höher, BSD (4.4/BSD386, BSDI 2.0 und höher, freeBSD, NetBSD i386 1.0) sowie vermutlich auch NeXT.

  Hinweis: In Abhängigkeit von der konkreten Umgebung (Betriebssystem, C-Bibliothek, Entwicklungswerkzeuge) können allerdings kleinere Quelltextanpassungen notwendig sein.

  Der Autor der vorliegenden Seite verwendet CFS schon mehrere Jahre nicht mehr, setzte aber früher auf seinen Systemen eine leicht modifizierte Version von cfs.1.4.0.beta2.tar.gz ein:

  mycfs-1.4.0.beta2.tar.gz

  Hier wurden einige Fehler behoben, die speziell auf neueren Linux-Systemen auftraten. So wurde vor allem ein Problem in der Datei truerand.c beseitigt, das dazu führte, dass das Kommando cmkdir nicht mehr funktionierte. Außerdem wird durch das Skript correct_rpcgen_out die Ausgabe des bei der CFS-Generierung benötigten RPC-Protokoll-Compilers rpcgen korrigiert, sofern diese Generierung unter Linux 2.2 erfolgt, da dort Probleme mit dem rpcgen festgestellt wurden.

Beispiel-Dateibaum

Die folgende Abbildung zeigt ein Beispiel eines Dateibaums, der ein virtuelles CFS-Dateisystem enthält, dessen Wurzel unter /crypt zu finden ist. Unterhalb dieser Wurzel kann jeder Nutzer seine Teilbäume montieren.

Im konkreten Fall ist genau ein solcher Teilbaum montiert, der unterhalb von /crypt/hot zu erreichen ist. Die dort sichtbaren Dateien befinden sich lediglich in verschlüsselter Form auf dem externen Datenträger, und zwar unterhalb des Verzeichnisses /home/hot/secret.

Der Abbildung ist zu entnehmen, dass auch die Datei- und Verzeichnisnamen verschlüsselt gespeichert werden. So steht z.B. edbcb7a9192f3cf5 für die Datei abc und ac12298c80b64663 für das Verzeichnis 123.

Der etwas eigenartig anmutende, da offenbar ins Leere zeigende symbolische Link .pvect_edbcb7a9192f3cf5 enthält einen sog. Perturbations-Vektor (perturbation vector) für die Datei edbcb7a9192f3cf5, deren Klartextname abc lautet. Dieser Vektor fließt als ein zusätzlicher Operand in die bei der Ver- bzw. Entschlüsselung von Dateiinhalten ausgeführten XOR-Operationen ein und soll verhindern, dass identische Teile des Inhalts unterschiedlicher Dateien auf dasselbe Chiffrat abgebildet werden. Damit hat der Perturbations-Vektor eine dem bei Blockchiffren genutzten Initialisierungs-Vektor (IV) entsprechende Funktion.

Als Perturbations-Vektor wird das Bitmuster verwendet, das sich hinter der stets 8 Byte langen Zeichenkette verbirgt, die den Inhalt des Links darstellt. Als Elemente dieser Zeichenkette werden nur die 16 ASCII-Zeichen 0 ... 9 und a ... f verwendet.

Der im Beispiel angegebene Link-Inhalt 1a8af884 repräsentiert demnach das folgende Bitmuster:

Die Erzeugung bzw. Berücksichtigung des Links mit dem Perturbations-Vektor kann bei Bedarf durch die Option -l (lower security mode) bei cattach unterdrückt werden. In diesem Fall wird der Null-Vektor, d.h. ein aus lauter 0-Bits bestehender Vektor verwendet, der bei XOR wirkungslos bleibt.

Administrations-Dateien und Schlüssel bei CFS 1.4

Details dazu finden sich in einem separaten Dokument.

Erstmalige Installation (Beispielablauf)

• Anpassen des Makefiles an die lokale Umgebung

• Maschinen-Programme generieren:

    make cfs
  

• Installation der Programme als Superuser (root):

    make install_cfs
  

  oder Kopieren von Hand

• CFS-Bootstrap-Mount-Punkt anlegen:

    mkdir /null
    chmod 0 /null
  

• CFS-Mount-Punkt exportieren:

  Beispiel Linux: Zuerst die Zeile

    /null   127.0.0.1(rw)
  

  in /etc/exports eintragen und danach diese Datei durch den Mount-Dämon einlesen lassen (Server entweder neu starten oder ihm das Signal SIGHUP senden).

• realen CFS-Mount-Punkt anlegen:

    mkdir /crypt
  

• Ergänzen der /etc-Dateien, um den cfsd künftig bei jedem Reboot automatisch zu starten:

  Beispiel Linux: Eintrag von

    if [[ -x /usr/local/sbin/cfsd ]]
    then
      /usr/local/sbin/cfsd &&
      /bin/mount -o port=3049,intr,bg localhost:/null /crypt
    fi
  

  in /sbin/init.d/nfsserver (Mount-Dämon muss bereits zuvor gestartet worden sein).

Alternativen zu CFS

Neben dem schon recht betagten CFS gibt es eine Reihe anderer und modernerer Ansätze zur Realisierung kryptographischer File-Systeme. Hier eine Auswahl für Linux:

http://www.debianadmin.com/filesystem-encryption-tools-for-linux.html

Speziell EncFS dürfte sich auf Grund seiner zentralen Konzepte als logischer Nachfolger sowie performantere Alternative zu CFS empfehlen:

• http://arg0.net/encfs
• http://arg0.net/wiki/encfs/intro2

Holger Trapp

letzte Modifikation: 2.6.2007