Festplattenverschlüsselung

Wozu braucht man Festplattenverschlüsselung

• Falls das Notebook gestohlen wird, dass sensible Informationen geschützt bleiben
• Wenn die ganze Festplatte verschlüsselt ist, kann ich sie auch auf Ebay versteigern, ohne sie vorher Formatieren zu müssen.
• Die RIAA / MPAA / Polizei keine Beweise auf der Platte findet
• Man aus anderen Gründen total paranoid ist

Implementationen unter:

Linux 2.2 / 2.4 / 2.6

Unter Linux 2.4 wird die Festplattenverschlüsselung mit dem Loopback-Device realisiert. Es können alle im Kernel verwendbaren Verschlüsselungsalgorythmen verwendet werden, jedoch ist nach verschiedenen Angaben die Implementation "nicht sehr sauber" und das Design kann zu Fehlern führen. Dazu kommt, dass es offensichtlich früher (oder auch heute ?) zahlreiche Bugs in der loop.c des Linux Kernels gegeben hat.

Die Dokumentation für cryptoloop des Linux Kernels (2.6) meint dazu auch:

 WARNING: This device is not safe for journaled file systems like ext3 or Reiserfs. 

 Please use the Device Mapper crypto module instead, which can be configured to be on-disk 

 compatible with cryptoloop device.

Neu mit Linux 2.6

Die bessere Methode, um eine Verschlüsselung unter Linux 2.6 zu realisieren, ist der Device-mapper. Die Implementation ist wesentlich sauberer und unterstützt (bis jetzt) alle Dateisysteme, auch die "Journaled file systems". Es sollte allerdings eine Kernelversion von mindestens 2.6.4 verwendet werden. Empfohlen ist jedoch eine Kernelversion ab 2.6.10.

Praktischer Teil

Es sollte sich beim Linux-Kernel mindestens um die Version 2.6.10 handeln, da dort und schon früher verschiedene Bugs gefixt wurden. Die Kernel-Version findet man mit

 uname -r

heraus.

Mit Linux 2.6 einen verschlüsselten Container erstellen

Ein Container hat den Vorteil, dass wir die Partitionstabelle nicht anrühren müssen, gleîchzeitig die Grösse des Containers aber wählen können.

Hierfür sollten folgende Teile im Kernel vorhanden sein.

• loopback device
• device mapper
• crypto-targed
• twofish
• sha256

Man sollte folgende Module laden:

Modul	Funktion
aes:	Der AES Algorythmus
twofish:	Der Twofish Algorythmus
sha256:	Hashalgorhytmus
dm_mod:	Der Device Mapper
dm_crypt:	Die kryptografische Erweiterung des Device Mapper
loop:	Das loopback Modul

Wir erstellen uns ein Image-File mit 100MB (count=100)

 % dd if=/dev/urandom of=/home/user/secret bs=1M count=100 

Danach setzen wir die dateil /home/user/secret als loopback-Device

 % losetup /dev/loop/0 /home/user/secret

Hier unterscheidet sich die Device-mapper Methode von der alten cryptoloop-Methode. Diese würde nun nach dem Aufruf von losetup noch die encryption-Option -e [cypher] benötigen.

 % losetup -e aes /dev/loop/0 /home/user/secret

Da diese Methode jedoch veraltet ist, fahren wir wie folgt fort. Für den nächsten Schritt muss aber (wenigstens) das Modul dm_crypt und loop im Kernel geladen sein:

 % modprobe dm_crypt
 % modprobe loop

Wir erstellen ein virtuelles Crypto device mittels cryptsetup

 % cryptsetup -y create secret /dev/loop/0
 [ENTER YOUR PASSPHRASE]
 [ENTER YOUR PASSPHRASE]

Dies erstellt ein Device in /dev/mapper/ mit dem Namen secret. Also /dev/mapper/secret. Dieses virtuelle Device kann jetzt wie eine Partition behandelt werden.

Zum Zeitpunkt als ich dieses Dokument geschrieben habe, hatte mich jemanden auf angebliche Unsicherheiten von AES aufmerksam gemacht (Siehe Anmerkungen). Dies ist der Grund wieso hier überall twofish verwendet wird, der natürlich genau so sicher ist wie AES. Es ist weder gegen twofish noch gegen AES eine praktische Attacke bekannt!

 % cryptsetup -y -c twofish create secret /dev/loop/0
 [ENTER YOUR PASSPHRASE]
 [ENTER YOUR PASSPHRASE]

Die Option -y von cryptsetup bewirkt, dass der Passphrase zwei Mal abgefragt wird. Wird sie weggelassen, kann die Möglichkeit bestehen, sollten wir z.B. einen Tippfehler gemacht haben, dass wir den Passphrase nur "falsch" kennen und wir nur noch Schrott im Container haben.

Um einen Watermark Angriff zu verhindern, http://de.wikipedia.org/wiki/Watermark_attack und um gleiche Daten immer anders aussehen zu lassen hängen wir noch folgende Option an, bzw. wir ändern den Verschlüsselungsalgorithmus wiefolgt.

 % cryptsetup -y -c twofish-cbc-essiv:sha256 create secret /dev/loop/0

Dann erstellen wir uns ein Dateiensystem auf dem Loopback-Device.

 % mkfs.ext3 /dev/mapper/secret

Jetzt können wir das Device ganz normal mounten, wohin wir auch immer wollen.

 % mount /dev/mapper/secret /mnt/secret

Um das Device wieder zu entfernen, z.B. zum unmounten

 % umount /mnt/secret
 % cryptsetup remove secret /dev/loop/0

Beim Mounten müssen wir jetzt jedes Mal folgenden Befehl neu eingeben, um das entschlüsselte virtuelle Device /dev/mapper/secret zu erhalten.

 % cryptsetup create -c twofish-cbc-essiv:sha256 secret /dev/loop/0
 [ENTER YOUR PASSPHRASE]

Sollten wir jedoch den Passphrase falsch eingegeben haben, wird das Device /dev/mapper/secret trotzdem erstellt. Beim Mounten hingegen wird kein Dateiensystem gefunden.

Mit Linux 2.6 einzelne Partitionen verschlüsseln

Wir haben, sagen wir mal, unsere /home Partion auf /dev/hda6 und natürlich root-Rechte.

Wir machen ein simples Backup von home und speichern wenn möglich das Backup nicht auf der home-partition.

 % tar -cvvjf home.tar.bz2 /home/

Partition unmounten...

 % umount /home/

Festplatte zufällig überschreiben...

 % wipe -qk /dev/hda6

Damit wird die Partition (/dev/hda6) aus /dev/random 4 Mal überschieben (Option -q). Die Option "-k" (keep) gibt an, dass die Datei nach Beendigung des Überschreibens nicht gelöscht wird.

Wir müssen nun den Key und den Passphrase festlegen. Es gibt mehrer Möglichkeiten dies zu tun. Die einfachste Möglichkeit, ist den Key im Partitionsheader festzulegen, und einen Passphrase um ihn freizuschalten.

 % cryptsetup create -c twofish-cbc-essiv:sha256 homepartition /dev/hda6
 [ENTER YOUR PASSPHRASE]

Jetzt müssen wir einen Passphrase eingeben. Beim Erstellen sollten man jedoch, wie oben auch erwähnt, die Option -y verwenden, welche veranlasst, dass man das Password zweimal eingeben muss.

 % cryptsetup -y create -c twofish-cbc-essiv:sha256 homepartition /dev/hda6
 [ENTER YOUR PASSPHRASE]
 [ENTER YOUR PASSPHRASE]

Dies erstellt ein virutelles Blockdevice, /dev/mapper/homepartition. Sollte man das Password allerdings zweimal falsch eingegeben haben, wird das Device auch erstellt. dann muss man das device wieder entfernen.

 % cryptsetup remove homepartition /dev/hda6

Sollten wir allerdings den Passphrase richtig eingegeben haben, können wir jetzt ein Dateiensystem auf dem virtuellen Blockdevice erstellen.

 % mkfs.ext3 /dev/mapper/homepartition

Dann können wir unsere neue home-Partition mounten.

 % mount /dev/mapper/homepartition /home/

Um unsere verschlüsselte Partition wieder zu schliessen, verwenden wir einfach folgende Befehle

 % umount /home
 % cryptsetup remove homepartition /dev/hda6

Linux 2.6 und swap verschlüsseln

Nachdem man die o.g. Module in die /etc/modules eingetragen hat, sind nur noch 2 Schritte notwendig:

1. In unserem Beispiel liegt die swap auf /dev/hda3 (dies muss man gegebenenfalls anpassen). Um herauszufinden, wo die swap liegt, genügt ein

 % cat /etc/fstab | grep swap

Anschliessend öffnet man die /etc/crypttab und fügt folgende Zeile ein:

 swap /dev/hda3 /dev/urandom swap,cipher=twofish-cbc-essiv:sha256

2. Jetzt muss man nur noch in der /etc/fstab die Zeile

 /dev/hda3       none            swap    sw              0       0

in folgende Version abwandeln:

 /dev/mapper/swap none           swap    sw              0       0

Linux 2.6 und cryptsetup-luks

Die bisher vorgestellten Methoden zur Verschlüsselung der Festplatte mittels cryptsetup sind jedoch ziemlich unbequem und verwirrend.
Zum Ersten wird das target device auf /dev/mapper/whatever auch erstellt, wenn der passphrase falsch eingegeben wurde. Weiter ist es in den Befehlen nicht klar, ob man jetzt ein device neu erstellt oder nur öffnet.

Abhilfe in diesen und anderen Fällen schafft das sogenannte LUKS Linux Unified Key Setup. Mit Luks kann man Informationen im Header der Partition unterbringen und muss sie somit nicht immer auf der command-line mitgeben. Zudem kann man mehrere Passphrases für eine Partition festlege.

Die LUKS Erweiterung ist z.B. in Debian etch im cryptsetup enthalten. Sollte die LUKS Erweiterung nicht in der Distribution enthalten sein, kann man sie sich hier herunterladen.

todo: Andere Distributionen

Wir haben wieder unsere home Partition auf /dev/hda6.

cryptsetup luksFormat -y -c twofish-cbc-essiv:sha256 /dev/hda6

Es ist hier kein Name für das device nötig. Man kann auch ein Key-file angeben.

cryptsetup luksFormat -y -c twofish-cbc-essiv:sha256 /dev/hda6 <key-file>

Somit wollen wir jetzt unsere Partition öffnen.

cryptsetup luksOpen /dev/hda6 <name> <--key-file> <--read-only>

<name> ist hier jetzt der Name für das Mapping vom Device mapper, <--key-file> ist die Datei welche den Schlüssel darstellt und <--read-only> um die Partition nur lesbar zu entschlüsseln.

Das Hinzufügen eines zusätzlichen Keys wird wiefolgt erledigt.

cryptsetup luksAddKey /dev/hda6
>Enter any LUKS passphrase:
>Verify passphrase:
>Key slot 0 unlocked
>Enter new passphrase for key slot:
>verify passphrase:
>Command successful.

Um einen neuen passphrase hinzuzufügen, benötigt man irgend einen vorhanden passphrase. Der nächste passphrase wird dann in dem nächsten freien Slot gespeichert

Um einen Key zu löschen, geht man analog vor.

cryptsetup luksDelKey /dev/hda6 <key slot number>

Achtung: hier wird nicht nach einem passphrase gefragt. Die <key slot number> bekommt man, indem man eine Abfrage des Headers der Partition macht.

cryptsetup luksDump /dev/hda6

Weitere Informationen siehe: man cryptsetup

Debian Etch

Um die ganze Sache jetzt noch zu perfektionieren, gibt es unter Debian etch die Datei /dev/crypttab. In dieser Datei kann man die Partitionen und Optionen angeben mit denen diese beim Start automatisch gemounted werden sollen.

#<target device> <source device> <key file> <options>
home  /dev/hda6 none checkargs=ext3,tries=3,luks
#für swap
cswap /dev/hda3 /dev/random swap

Das erste Keyword ist der Mappername, dann Quellpartition dann ein mögliches key-file, oder auch keines (none), dann Optionen. Hier checkargs um dem check-script zusätzliche Hilfe zu geben, um zu überprüfen, ob die Partition richtig entschlüsselt wurde, tries um die Anzahl der Versuche anzugeben, um die Partition zu entschlüsseln und dann noch luks um die LUKS Erweiterung zu verwenden.

siehe: man crypttab

Danach muss man die Partition nur noch in die fstab eintragen. Die Reihenfolge bei normalen Partitionen wird automatisch richtig gemacht.

/dev/mapper/home     /home  ext3   defaults     0      0

Ein weiteres Dokument für Debian Etch: http://www.debian-administration.org/articles/428/print

Der Debian installer ab Beta3 unterstütz neu auch das aufsetzten verschlüsselter Partitionen.

Linux 2.6 und rootfs verschlüsseln

http://www.debian-administration.org/articles/428/print

Anmerkungen

Journaling Dateiensysteme (ext3, Reiserfs, usw)

Man sollte z.B. das Keyfile nicht auf einer ext3 oder einem anderen Journaling Filesystem haben. 1. Nicht im Klartext (logisch) und 2. ist das Löschen einer Datei auf einem Journaling Dateiensystem mit Problemen verbunden. Auch mittels wipe kann die Möglichkeit bestehen, dass die Datei nach dem Löschen aus dem Journaling wieder hergestellt werden kann, da ja das Dateiensystem "Buch führt" über die Veränderungen des Dateiensystems. Dies ist ja eines der Features von Journaling Dateiensystemen.

Arbeitsspeicher

2008 hat die Princeton Universität eine neue Art Angriff gezeigt. Diese Art von Angriff funktioniert gegen jegliche gängige Festplatten-Verschlüsselungstechnik (Truecrypt/dm-crypt/Bitlocker u.a.). Der Arbeitsspeicher wird von extern einfach ausgelesen. Dies funktioniert aber nur ein par Mintuen nach dem Abschalten. (ca. 2 Minuten bei Raumtemperatur und ca. 10 Minuten und länger beim Schockfrieren des Arbeitspeichers.

Den ganzen Artikel gibts hier: Cold boot attac on encryption keys

AES

2002 haben zwei polnische Mathematiker eine theoretischen Angriff auf AES gezeigt. Seit dem ist aber nicht viel passiert. Es wird somit angenommen dass AES bisweilen immer noch sehr sicher ist. Im übrigen ist die Attacke sehr generell gehalten und man kann praktisch auf jeden block cipher angewandt werden von dem twofish warscheinlich auch betroffen wäre.

Hierzu ein Artikel von Bruce Schneier: AES News

Des weiteren gibt es hier einen Link der sich mit der sicherheit von AES fortlaufend beschäftigt

Geschwindigkeit

Unter Debian Etch (Kernel 2.6.15-1-486) ergaben sich bei einem AMD Athlon 3200+ (64-Bit) mit bonnie++ folgende Werte (IDE Festplatte):

		Sequential Output						Sequential Input				Random Seeks			Sequential Create						Random Create
	Size:Chunk Size	Per Char		Block		Rewrite		Per Char		Block				Num Files	Create		Read		Delete		Create		Read		Delete
		K/sec	% CPU	K/sec	% CPU	K/sec	% CPU	K/sec	% CPU	K/sec	% CPU	/ sec	% CPU		/ sec	% CPU	/ sec	% CPU	/ sec	% CPU	/ sec	% CPU	/ sec	% CPU	/ sec	% CPU
ext3	1768M	31844	65	35108	10	11928	2	21644	42	27919	2	184.5	0	16	2638	98	+++++	+++	+++++	+++	2476	98	+++++	+++	11564	99
twofish	1768M	23344	48	36643	25	10531	3	14086	28	19548	1	191.2	0	16	1750	98	+++++	+++	+++++	+++	2198	97	+++++	+++	10963	98
aes256	1768M	17359	35	24464	6	9774	1	12623	25	16728	1	210.6	0	16	1035	98	+++++	+++	+++++	+++	979	98	+++++	+++	10167	99

Man beachte, dass Twofish deutlich besser abschnitt als AES. Dies liegt höchstwahrscheinlich an der 64-Bit CPU (s.o.). Weitere Ergebnisse sind unter http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio zu finden.

Ein interessantes Dokument ist auch das von Bruce Schneier. http://www.schneier.com/paper-aes-comparison.pdf