Open Source im professionellen Einsatz

Sicherheitstest: Verschlüsselte Filesysteme unter Linux

Löchriger Käse

,

Ob die aktuellen Crypto-Dateisysteme unter Linux wirksam schützen, hängt von den kryptographischen Qualitäten ab und davon, ob ihre Bedienung den Admins und Anwendern schmeckt. Oftmals sorgen Programmierfehler sogar für zusätzliche Sicherheitslöcher. Dieser Test deckt Schwächen auf.

Verschlüsselnde Dateisysteme gibt es unter Linux reichlich (Tabelle 1). Doch bereits der erste Eindruck irritiert: Keiner der Testkandidaten nennt ein klares Bedrohungsszenario (vergleiche vorherigen Artikel) oder verrät wenigstens die Designprinzipien. Kaum ein System dokumentiert technische Details. Lobenswerte Ausnahmen sind nur Truecrypt und Enc-FS. Daraus folgt, dass beim Auditing tonnenweise Quellcode zu analysieren ist (per Reverse Engineering) und über die Motivation der Entwickler bestenfalls Spekulationen gelingen.

Tabelle 1:
Testfeld

 

Filesystem

Version

Implementierung

Container

Ebene

Windows-Portierung

Loop-AES

3.1d

Kernel

Datei oder Partition

Blockdevice

ja [5]

DM-Crypt

Kernel 2.6.15

Kernel

Datei oder Partition

Blockdevice

ja [9]

Cryptsetup-LUKS

1.0.3

Kernel

Datei oder Partition

Blockdevice

ja [9]

Truecrypt

4.2a

Kernel

Datei oder Partition

Blockdevice

ja

Crypto-FS

0.5.2

Userspace

Verzeichnis

Dateien

nein

Enc-FS

1.2.5

Userspace

Verzeichnis

Dateien

ja

Bei der Recherche zu diesem Artikel stellte sich heraus, dass die Quellen-Analyse weniger einem Code Audit gleicht, sondern eher einer archäologischen Ausgrabung. Relevante Funktionen verbergen sich unter mehreren Schichten von Code-Ablagerungen mit aufgegebenen Software- und Verschlüsselungsexperimenten. Die verraten immerhin, wie die Entwickler Varianten durchprobiert haben, um das Schlüsselmaterial und die chiffrierten Daten zu bearbeiten.

Die Technik der Crypto-Dateisysteme gliedert sich nach mehreren Kriterien. Einerseits nach der Implementierung im Kernel oder im Userspace, andererseits danach, ob sie eine Datei oder ein Verzeichnis als Container nutzen oder die Daten in einer eigenen Partition ablegen, sowie danach, ob sie jede Datei einzeln verschlüsseln oder ein komplettes Volume auf Blockdevice-Ebene anbieten. Tabelle 1 ordnet die Systeme nach diesen Kriterien und sagt, ob es eine Windows-Portierung gibt. Letzteres ist für viele Anwender im Mischbetrieb Linux/Windows entscheidend.

Loop-AES

Loop-AES [1] ist das älteste der hier vorgestellten Crypto-Filesysteme. Es nutzt das seit Jahren im Kernel vorhandene »loop«-Modul und verträgt sich sogar noch mit dem 2.0-Kernel. Die Funktionsweise ähnelt dem längst als unsicher entlarvten Cryptoloop-Verfahren [2]. Loop-AES arbeitet auf Blockdevice-Ebene und schreibt die verschlüsselten Daten in eine Containerdatei oder in eine eigens dafür vorbereitete Partition.

Als erste Hürde erweist sich die Installation aus dem Quellpaket. Sie benötigt die passenden Kernelsourcen inklusive der beim Kompilieren entstandenen Komponenten - in der Regel muss der Admin dazu den Kernel selber bauen. Zudem muss er das elementare Paket »util-linux« [3] patchen und neu übersetzen. Es enthält wichtige Systembefehle, beispielsweise »mount«. Immerhin erklärt die Readme-Datei [4] den Vorgang recht gut. Sie enthält weitere nützliche Hinweise, etwa zu Loop-AES in Verbindung mit Software-Suspend.

Wegen der tiefen Eingriffe ins System ist gut beraten, wer sich möglichst an die distributionsspezifischen Pakete hält. Ubuntu macht es hier relativ einfach, wie Listing 1 zeigt. Der Aptitude-Aufruf in Zeile 1 installiert die benötigten Pakete. Danach bewährt sich der »module-assistant« in den Zeilen 2 bis 4, um ein passendes Loop-AES-Paket aus den Quellen zu erstellen.

Listing 1: Loop-AES auf
Ubuntu

01 sudo aptitude install loop-aes-utils loop-aes-source
02 sudo module-assistant update
03 sudo module-assistant prepare
04 sudo module-assistant build loop-aes
05 sudo dpkg -i loop-aes-2.6.15-26-686_3.1b-8+2.6.15-26.45_i386.deb
06 
07 losetup -e AES256 /dev/loop0 /dev/hda6
08 mkfs.xfs /dev/loop0
09 mount /dev/loop0 /home/chris/loopaes

Es tritt zwar ein kleiner Bug auf, ist aber auch schnell behoben: Beim »build«-Aufruf meckert das System, dass »debian/rules« die nötigen Rechte fehlen. Lösung des Problems: Ein weiteres Terminalfenster öffnen, die Rechte per »chmod +x /usr/src/modules/loop-aes/debian/rules« händisch setzen und danach den Build-Vorgang fortsetzen. Zeile 5 installiert das resultierende Paket.

Durch die gute Integration ins System mit eigens angepassten Werkzeugen ist Loop-AES recht einfach benutzbar. Zeile 7 in Listing 1 zeigt den Losetup-Aufruf, der eine logische Verbindung zwischen dem Loopdevice »loop0« und der Partition »/dev/hda6« herstellt. Als Blockdevice dürfte hier auch eine normale Datei stehen, die dann als Container das Crypto-Blockdevice aufnimmt.

Nach der Angabe des mindestens 20-stelligen Passworts schreibt Losetup die von Loop-AES benötigten Header auf die Partition. Mit dem Anlegen eines XFS-Dateisystems in Zeile 8 ist das Loopdevice bereit und lässt sich per »mount« ins System einbinden. Nach einem »umount« ist noch ein »losetup -d /dev/loop0« nötig, um auch die logische Zuordnung zum physikalischen Device zu trennen. Wer das Mounten automatisieren will, ergänzt Folgendes in »/etc/fstab«:

/dev/hda6 /home/chris/loopaes xfs defaults,loop=/dev/loop0,encryption=AES256 0 0


Obwohl Loop-AES recht tiefe Eingriffe ins System verlangt und seine Technik bereits Staub ansetzt, ist es in der Praxis recht einfach und gut nutzbar. Mit Crosscrypt [5] sind Loop-AES-Container auch unter Windows zu lesen.

Sicherheit von Loop-AES

Eine verwirrende Vielzahl von Optionen beim Kompilieren und Verwenden des Filesystems behindert die Sicherheitsanalyse. Die Verschlüsselungsfunktionen verhalten sich je nach gewählter Option radikal unterschiedlich. Der unübersichtliche Code behindert das Audit ebenfalls: Es ist schwer herauszufinden, was im Inneren von Loop-AES vorgeht und ob der Code wirklich tut, was er tun soll.

Loop-AES verzichtet beim Hashen des Passworts auf einen Salt, der verhindern würde, dass gleiche Passwörter zu identischen Keys führen. Zudem berechnet Loop-AES den Verschlüsselungskey mit nur einer Hashing-Iteration (etwa SHA-256 oder SHA-512). Das ist anfällig für vorausberechnete Wörterbuchangriffe: Der Cracker erzeugt vorab mit Hilfe von Wörterbüchern und zusätzlichen Regeln eine Liste möglicher Passwörter und berechnet zu jedem die Hashfunktion. Er muss dann nur noch diese Hashes als Keys probieren, nicht mehr alle möglichen Zahlenkombinationen (das wäre ein Brute-Force-Angriff).

Das Readme für Loop-AES [4] behauptet dagegen, dass Loop-AES sowohl ein Salting als auch mehrfache Iterationen vorsieht. Die dazu passenden Beispiele für Konfigurationsdateien, die Google aufspürt, lassen jeden Salt vermissen und setzen den Iterationen-Wert auf 100 (das entspricht 100000 Iterationen). Per Default sieht Loop-AES weder Salting noch Passwort-Hash-Iterationen vor.

Diesen Artikel als PDF kaufen

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook