Sicherheitstest: Verschlüsselte Filesysteme unter
Linux
Löchriger Käse
von Peter Gutmann, Christian Ney
Erschienen im Linux-Magazin
2006/10
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.
|
|
|
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.
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.
| Whitepaper |
|
Usage Landscape Enterprise Open Source Data Integration
Die Nachfrage nach Datenintegrationslösungen für Unternehmen ist zunehmend gestiegen und vor allem das Interesse an Open Source Technologien wird immer größer. Doch wie und von wem werden Open Source Datenintegrationslösungen genutzt und welches Nutzungsverhalten lässt sich daraus ableiten? Das vorliegende White Paper präsentiert die Erfahrungswerte von über 1000 Open Source Nutzern und liefert fundierte Antworten auf diese Fragen.
Download PDF (Registrierung erforderlich)
|
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
hones frof,
17.12.2010 15:09
Markus Reichelt,
20.05.2009 14:00
http://mail.nl.linux.org/linux-crypto/2006-09/msg00014.html