Die verschlüsselte Festplatte im Server bleibt wirkungslos, wenn die wertvollen Daten auf CDs oder DVDs doch in die Hände von Spionen tröpfeln. Wegen der besonderen CD- und DVD-Dateisysteme ist es kniffelig, diese Medien mit einem wasserdichten und transparenten Crypto-Filesystem auszustatten.

Zu ihrem eigenen Schutz liegen sensible Daten in verschlüsselten Filesystemen auf der Festplatte – spätestens nach der Lektüre dieser Ausgabe des Linux-Magazins sollte diese Aussage häufiger zutreffen. Wer seine Daten mitnehmen will, brennt eine Momentaufnahme auf CD oder kopiert die Files auf seinen USB-Stick. Diese Medien dürfen aber das Sicherheitskonzept nicht unterlaufen.

Da sich USB-Speicher wie externe Festplatten verhalten, ist dieses Problem leicht zu lösen. Schwierig wird es dagegen bei CDs und DVDs, aber auch hierfür gibt es Wege. Der einfachste Ansatz wäre, die Dateien einzeln per GPG oder mit ähnlichen Tools zu verschlüsseln und das Resultat auf CD zu brennen. Das genügt für manche Zwecke bereits und ist hinreichend sicher.

Auf den zweiten Blick birgt er jedoch ein Risiko: Um den Inhalt zu lesen, entschlüsselt der Anwender das File und speichert den Klartext temporär auf einem beschreibbaren Medium. Letzteres müsste daher ein verschlüsseltes Filesystem besitzen, um die Geheimhaltungskette nicht zu unterbrechen. Neben dem mehrfachen Ver- und Entschlüsseln verschwendet dieser Ansatz außerdem Speicherplatz.

Als weitere simple Methode drängt sich auf, das verschlüsselte Blockdevice unverändert auf die Scheibe zu bannen. Doch sind DVD-taugliche Datenpartitionen unter 8 GByte heute nur noch selten anzutreffen. Die Partition wäre daher auf mehrere Medien zu verteilen. Um dieses Image zu lesen, muss der Anwender die Teile wieder zusammenführen. Das Vorgehen verschwendet ebenfalls Festplattenplatz, allerdings darf er unverschlüsselt sein. Damit entfällt wenigstens das mehrfache Ver- und Entschlüsseln im Vergleich zur ersten Methode.

Doch es geht viel besser. Die beiden im Folgenden vorgestellten Lösungen verschlüsseln die Daten erst beim Brennen und sorgen für transparentes Entschlüsseln beim Lesen. Das klappt fast wie von der Festplatte mit Crypto-Filesystem gewohnt, nur dass eine CD keine nachträglichen Änderungen zulässt.

Wie im Fluge

Die erste Methode chiffriert die Daten direkt während des Brennens mit dem Programm »cdrecord«. Dazu hat Maximilian Decker ein Patch [1] für Jörg Schillings Cdrecord-Software geschrieben. Der Auszug in Listing 1a zeigt, wie man das Patch auf den Quellcode anwendet. Beim resultierenden Gespann gibt der Anwender für den aktuellen Brennvorgang einen Schlüssel an. Die Verschlüsselung erfolgt per AES mit 256 Bit im CBC-Modus (siehe Kasten “Begriffe”).

01 wget 'ftp://ftp.berlios.de/pub/cdrecord/cdrtools-2.01.tar.bz2'
02 wget 'http://burbon04.gmxhome.de/linux/files/cdrtools-2.01-encrypt-1.0rc2.diff.gz'
03 tar xjvf cdrtools-2.01.tar.bz2
04 cd cdrtools-2.01
05 zcat ../cdrtools-2.01-encrypt-1.0rc2.diff.gz | patch -p1

In der GPL-Version brennt Cdrecord zwar CDs, scheitert aber an DVDs. Um auch mit diesen Medium umgehen zu können, kommen zwei andere Patches zum Einsatz, sie sind bereits für das neuere Cdrecord 2.01.01a05 angepasst (aus dem Alpha-Zweig der Cdrtools). Erst ergänzt der OSS-DVD-Support [2] die Funktionen für das Brennen von DVDs, danach fügt das auf dem gleichen Server liegende angepasste Encryption-Patch die Fähigkeit zum Verschlüsseln hinzu (Listing 1b).

01 wget 'ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a05.tar.bz2'
02 wget 'http://www.crashrecovery.org/oss-dvd/cdrtools-2.01.01a05-ossdvd.patch.bz2'
03 wget 'http://crashrecovery.org/oss-dvd/cdrtools-2.01.01a01-encrypt-1.0rc1.diff.gz'
04 tar xjvf cdrtools-2.01.01a05.tar.bz2
05 cd cdrtools-2.01.01
06 bzcat ../cdrtools-2.01.01a05-ossdvd.patch.bz2 | patch -p1
07 zcat ../cdrtools-2.01.01a01-encrypt-1.0rc1.diff.gz | patch -p1

Das zusätzliche Patchen ist der Nachteil an dieser Methode, sollte aber für erfahrene Anwender kein Problem darstellen. Gentoo-Benutzer sind übrigens fein raus, dort reicht es, das USE-Flag »on-the-fly-crypt« beim Emergen von »app-cdr/cdrtools« zu setzen.

Kryptisch brennen

Das Encryption-Patch erweitert in beiden Fällen die »write_track_data()«-Funktion (Abbildung 1). Sie brennt den internen Buffer auf CD/DVD. Das Patch nutzt beim Verschlüsseln die GPL-lizenzierte AES-Implementierung von B. R. Gladman [3]. Die Nutzdaten unterteilt das Patch in jeweils 256 Bit große Pakete (32 Byte) und verschlüsselt sie mit dem ebenfalls 256 Bit langen Key. 16 dieser Pakete fasst es per CBC zu einem 512 Byte großen Block zusammen und wiederum vier dieser Blöcke zu einem 2048-Byte-Block. Den schreibt Cdrecord dann direkt auf CD.

Abbildung 1: Abhängig vom Parameter »-encrypt« schickt das gepatchte Cdrecord die Daten durch einen zusätzlichen Verschlüsselungsschritt, bevor es sie auf CD brennt.

Die Aufteilung in 512-Byte-Einheiten schränkt das Verfahren auf den CD-Modus 1 ein, der genau 2048 Byte große Blöcke speichert. Bei Modus 2 wären die Blöcke 2352 Byte groß und damit nicht durch 512 teilbar. Das gepatchte Cdrecord versteht etliche neue Parameter. Um die Verschlüsselung zu aktivieren, muss der Anwender »-encrypt« einsetzen. Das zugehörige Passwort stellt er auf eine von drei Arten bereit:

• Klartext: »-encpass=Passwort«
• Hexwert: »-encpasshex=70617373776F7264«
• Datei: »-encpassfile=/home/Name/secret.key« (nur
  die ersten 32 Byte sind relevant)

Die dritte Methode ist am ehesten zu empfehlen. Bei den ersten beiden taucht der Schlüssel in der Shell-History und in der Prozessliste auf, wo ihn möglicherweise Dritte entdecken.

Ist der angegebenen Schlüssel zu kurz, füllt ihn das Patch mit Null-Werten auf 32 Byte Länge auf (Null-Padding). Einen eventuell vorhandenen Zeilenumbruch vor der 32-Byte-Grenze interpretiert der Code als Teil des Schlüssels. Dies führt zu Problemen, wenn der User beim Entschlüsseln den Key manuell angibt.

Schlüsselfrage

Beim Schlüssel unterscheidet das Verfahren zwei Stile. Die so genannte »old«-Variante verwendet den (möglicherweise per Padding aufgefüllten) Schlüssel direkt, der »new«-Stil wendet zunächst einen SHA-256-Algorithmus an (Secure Hash). Der Unterschied zwischen den beiden Varianten zeigt sich beim Entschlüsseln.

Daten, die der Produzent der CD mit der alten Variante gebrannt hat, sind mit Hilfe des Crypto-Loop-Device zu mounten. Die neue Variante erzeugt dagegen eine CD für DM-Crypt, das Crypt-Target des Device-Mapper.

Der alte Stil empfiehlt sich nur, wenn das Zielsystem mit einem älteren Kernel läuft. Die neue DM-Crypt-Variante setzt nämlich beim Mounten mindestens Kernel 2.6.5 voraus, funktioniert dann aber ohne Patches. Für das Mounten von Crypto-Loop-Devices (alter Stil), die per 256-Bit-AES entstanden, sind einige Losetup-Patches nötig, die nicht jede Distribution direkt zur Verfügung stellt (siehe Tabelle 1). Dazu kommt, dass neuere Versionen der entsprechenden Pakete Patches enthalten, die nicht mit der alten Variante kompatibel sind.

Besser neu

Wer einen DM-Crypt-fähigen Kernel verwendet, greift daher besser zur neuen Variante. Der komplette Vorgang vom Brennen bis zum Mounten ist für das Verfahren »old« in Listing 2a und für das Verfahren »new« in Listing 2b zusammengefasst. Die erste Zeile legt in beiden Listings ein ISO-Filesystem an und übergibt es an Cdrecord. In der alten Variante dient »-encstyle=old« als Parameter (Listing 2a), bei der neuen lautet der Parameter »-encstyle=new«. In beiden Fällen aktiviert »-encrypt« die Verschlüsselung und »-encpass=Passwort« übergibt das Passwort im Klartext.

01 # mkisofs -J -R ~/daten/ | cdrecord dev=/dev/hda -encrypt -encstyle=old -encpass=Passwort -
02 [...]
03 NOTE: this version of cdrecord is an inofficial (modified) release of
04       cdrecord and thus may have bugs that are not present in the
05       original version. Please send bug reports and support requests to
06       <burbon04 at gmx.de>. For more information please see
07       http://burbon04.gmxhome.de/linux/CDREncryption.html. The original
08       author should not be bothered with problems of this version.
09 [...]
10 Starting to write CD/DVD at speed 48 in real TAO mode for single session. Last chance to quit, starting real write    0 seconds. Operation starts.
11 Turning BURN-Free off
12 Using aes-256-cbc encryption with plain password, plain IV. (e.g. cryptoloop >2.4.22, 2.6).
13 [...]
14 Track 01: Total bytes read/written: 42958848/42958848 (20976 sectors).
15 # mount -t iso9660 /dev/cdrom /media/crypt -o encryption=aes256
16 # ls /media/crypt
17 cat.mpeg              funny_cats.wmv
18 newsreportfromIraq.wmv
19 Der_Karatekaefer.avi  German_Engineering_Arab_Technology.wmv
20 sexy_nussknacker.mpg
21 felina_im_schnee.mpg  keinostdeutsch.mpg
22 Sprachproblem.mpg

01 # mkisofs -J -R /daten/small/Witzig/Videos/ | cdrecord dev=/dev/hda -encrypt -encstyle=new -encpass=Passwort -
02 [...]
03 NOTE: this version of cdrecord is an inofficial (modified) release of
04       cdrecord and thus may have bugs that are not present in the
05       original version. Please send bug reports and support requests to
06       <burbon04 at gmx.de>. For more information please see
07       http://burbon04.gmxhome.de/linux/CDREncryption.html. The original
08       author should not be bothered with problems of this version.
09 [...]
10 Starting to write CD/DVD at speed 48 in real TAO mode for single session. Last chance to quit, starting real write    0 seconds. Operation starts.
11 Turning BURN-Free off
12 Using aes-256-cbc encryption with sha-256 hashed key, plain IV. (e.g. dm-crypt)
13 [...]
14 Track 01: Total bytes read/written: 42958848/42958848 (20976 sectors).
15 # cryptsetup -r -c aes -s 256 -h sha256 create ecdrom /dev/cdrom
16 # mount -t iso9660 /dev/mapper/ecdrom /media/crypt
17 # ls /media/crypt
18 cat.mpeg              funny_cats.wmv
19 newsreportfromIraq.wmv
20 Der_Karatekaefer.avi  German_Engineering_Arab_Technology.wmv
21 sexy_nussknacker.mpg
22 felina_im_schnee.mpg  keinostdeutsch.mpg
23 Sprachproblem.mpg
24 #

Die Unterschiede zeigen sich beim Mounten der gebrannten CD. In Listing 2a genügt ein erweiterter Mount-Befehl (Zeile 15), während bei der neuen Variante in Listing 2b ein Cryptsetup-Aufruf (Zeile 15) das Mounten über den Device-Mapper (Zeile 16) vorbereitet. Dabei ist jedoch zu beachten, dass der Parameter »-r« (Read-only) in der aktuellen Version 0.1 von Cryptsetup noch fehlt. Ohne diese Option verweigert Cryptsetup das Erstellen des Mappers auf schreibgeschützten Medien.

Wer den Weg über die selbst kompilierte CVS-Version scheut, muss die CD vorher per »losetup« auf ein Loop-Device abbilden und darauf mit Cryptsetup arbeiten. Wie das im Detail funktioniert, zeigt Listing 2c ab Zeile 9.

01 # mkisofs -J -R /daten/small/Witzig/Videos/ | cdrecord dev=/dev/hda -encrypt -encstyle=new -encpass=Passwort -
02 [...]
03 Starting to write CD/DVD at speed 48 in real TAO mode for single session.
04 Last chance to quit, starting real write    0 seconds. Operation starts.
05 Turning BURN-Free off
06 Using aes-256-cbc encryption with sha-256 hashed key, plain IV. (e.g. dm-crypt)
07 [...]
08 Track 01: Total bytes read/written: 42958848/42958848 (20976 sectors).
09 # losetup /dev/loop0 /dev/cdrom
10 # cryptsetup -c aes -s 256 -h sha256 create ecdrom /dev/loop0
11 # mount -t iso9660 /dev/mapper/ecdrom /media/crypt
12 # ls /media/crypt
13 cat.mpeg              funny_cats.wmv
14 newsreportfromIraq.wmv
15 Der_Karatekaefer.avi  German_Engineering_Arab_Technology.wmv
16 sexy_nussknacker.mpg
17 felina_im_schnee.mpg  keinostdeutsch.mpg
18 Sprachproblem.mpg

Vorsicht, Falle

Eine mögliche Stolperstelle in der DM-Crypt-Methode offenbart sich, wenn der User an »cryptsetup« den Schlüssel per Datei übergibt. Dann ignoriert Cryptsetup den Parameter »-h« (Hash-Algorithmus) und verwendet den Key im Klartext ohne weiteres Hashing. Cdrecord interpretiert dagegen den Wert als Schlüssel-Basis, die es einem Hash unterzieht. So kommt keine Entschlüsselung zustande. Um dieses Problem zu umgehen, empfiehlt es sich, in beiden Fällen den Hashwert in der Datei abzulegen und für Cdrecord »-encstyle=old« beziehungsweise »-encstyle=aes256-cbc-plain« zu verwenden. Dann nutzt Cryptsetup auch den Key aus der Datei korrekt.

Da sie während des Brennens verschlüsselt, lässt sich diese Methode hervorragend in Programme einbauen, die »cdrecord« als Brennprogramm nutzen. Abbildung 2 zeigt, wie das bei der KDE-Software K3B funktioniert. Es genügt, bei den benutzerdefinierten Parametern die Kommandozeilen-Argumente für »cdrecord« zu ergänzen.

Abbildung 2: Mit den Einstellungen von K3B lässt sich das Cdrecord-Patch leicht integrieren, ohne dass eine Modifikation von K3B selbst nötig wäre. Es genügt, die zusätzlichen Parameter einzutragen.

Wer Cdrecord nicht verändern kann, kommt mit einer zweiten Methode und dem AES-Pipe-Programm [4] zum Ziel. Eine beliebige Brennsoftware schreibt das von AES-Pipe verschlüsselte Image auf CD oder DVD.

Verschlüsselte Pipe

AES-Pipe verschlüsselt einen beliebigen Datenstrom von Stdin und gibt das Resultat auf Stdout weiter. Als mögliche Eingabe eignet sich die Ausgabe von »mkisofs« (Abbildung 3). Dabei verwendet das Programm den CBC-Modus und verknüpft 16 einzelne 32-Byte-Pakete zu 512 Byte großen Blöcken. Wie auch das gepatchte Cdrecord eignet sich die Methode nur für den CD-Modus 1.

Abbildung 3: Die AES-Pipe verschlüsselt einen Datenstrom von der Standardein- zur Standardausgabe, egal von welchem Programm er kommt. Damit eignet es sich für die Programmkette beim Brennen einer CD.

Zur Auswahl stehen eine Schlüsselstärke von 128, 192 und 256 Bit sowie mehrere Hash-Funktionen. Ohne explizite Wahl per Aufrufparameter nutzt AES-Pipe den AES-Algorithmus mit 128-Bit-Schlüssel und SHA 256 als Hash-Algorithmus für den Key. Die einfachste Variante zeigt Zeile 1 von Listing 3 mit einer simplen Passworteingabe (Zeile 2). Das Passwort muss mindestens 20 Zeichen lang sein. Zeile 8 bestätigt, dass sich das Resultat problemlos mounten lässt.

Zudem bietet AES-Pipe die Möglichkeit, über den Parameter »-K« den Schlüssel als GPG-chiffrierte Datei anzugeben (Listing 4a). Mit dieser Methode lässt sich der Schlüssel separat und sicher transportieren und etwa auf einem USB-Stick aufbewahren. Dadurch genügen einem Datendieb nicht mehr nur die verschlüsselte CD und ein Passwort, er braucht zusätzlich den USB-Stick und das Passwort für den Key (auch Passphrase oder Mantra genannt).

01 # mkisofs -J -R . | aespipe | cdrecord dev=/dev/hdd -
02 Password:
03 cdrecord: Asuming -tao mode.
04 cdrecord: Future versions of cdrecord may have different drive dependent defaults.
05 Cdrecord-Clone 2.01.01a06 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2006 Jörg Schilling
06 [...]
07 Track 01: Total bytes read/written: 475136/614400 (300 sectors).
08 # mount -t iso9660 /dev/hdd /mnt/crypted -o loop,encryption=AES128
09 Passwort:
10 # ll /mnt/crypted/
11 insgesamt 22
12 drwxr-xr-- 2 maz network  2048  1. Apr 20:21 Bilder
13 -rw-r--r-- 1 maz network 18064 25. Jul 12:35 Crypto-CD.txt
14 -rw-r--r-- 1 maz network   349  8. Jan 2006  distris.txt
15 -rw-r--r-- 1 maz network   649 30. Mär 20:23 patch.txt

01 # mkisofs -J -R . | aespipe -K ~/test.gpg | cdrecord dev=/dev/hdd -
02 Password:
03 cdrecord: Asuming -tao mode.
04 cdrecord: Future versions of cdrecord may have different drive dependent defaults.
05 Cdrecord-Clone 2.01.01a06 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2006 Jörg Schilling
06 [...]
07 Track 01: Total bytes read/written: 475136/614400 (300 sectors).
08 # mount -t iso9660 /dev/hdd /mnt/crypted -o loop,encryption=AES128
09 Passwort:
10 # ll /mnt/crypted/
11 insgesamt 22
12 drwxr-xr-- 2 maz network  2048  1. Apr 20:21 Bilder
13 -rw-r--r-- 1 maz network 18064 25. Jul 12:35 Crypto-CD.txt
14 -rw-r--r-- 1 maz network   349  8. Jan 2006  distris.txt
15 -rw-r--r-- 1 maz network   649 30. Mär 20:23 patch.txt

Zudem ermöglicht es die GPG-Variante, verschiedene Passwörter für die gleiche CD zu vergeben. Dazu packt der Admin den Hauptschlüssel in mehrere GPG-Archive, die er mit unterschiedlichen Passwörtern schützt. So kann er bei Bedarf sogar einen neuen Schlüssel herausgeben, wenn ein User sein altes Passwort vergessen hat, ohne eine neue CD zu brennen. Diese Methode erlaubt zudem den sicheren Versand von Datenträgern ähnlich einer verschlüsselten E-Mail, wenn die GPG-Datei per Public-Key-Verfahren verschlüsselt ist.

Als Weiterführung dieser Idee schreibt ein gewiefter Admin die GPG-Datei an den Anfang der CD (Listing 4b). Dann befindet sich der Schlüssel für die Entschlüsselung der Daten direkt auf der CD, ist aber durch ein (hoffentlich sicheres) Passwort geschützt. Erforderlich ist dafür eine Datei fester Länge (Zeile 1), die am Anfang die GPG-Datei enthält (Zeile 2). Das eigentliche verschlüsselte Image hängt er an (Zeile 3) und brennt das Resultat auf CD/DVD (Zeile 4).

01 # yes "" | dd of=image.iso bs=512 count=16
02 # head -c 2925 /dev/urandom | uuencode -m - | head -n 66 | tail -n 1 | gpg --symmetric -a | dd of=image.iso conv=notrunc
03 # mkisofs -iso-level 3 -l -r /daten/ | aespipe -e aes256 -w 5 -K image.iso -O 16 >> image.iso
04 # growisofs -dvd-compat -Z /dev/dvdrw=image.iso
05 [...]
06 # mount -t iso9660 /dev/hdd /mnt/crypted -o loop,gpgkey=/dev/hdd,encryption=AES256,offset=8192
07 Passwort:
08 # ll /mnt/crypted/
09 insgesamt 22
10 drwxr-xr-- 2 maz network  2048  1. Apr 20:21 Bilder
11 -rw-r--r-- 1 maz network 18064 25. Jul 12:35 Crypto-CD.txt
12 -rw-r--r-- 1 maz network   349  8. Jan 2006  distris.txt
13 -rw-r--r-- 1 maz network   649 30. Mär 20:23 patch.txt

Beim Mounten der CD gibt der User dann als Quelle und auch als Schlüssel das Device des CD-Laufwerks an (Zeile 6). Über den Offset-Wert 8192 (16 mal 512, vergleiche Zeile 1) findet der Mount-Befehl den tatsächlichen Anfang der verschlüsselten Daten. Unter [5] stellt der Autor ein einfaches Bash-Skript zur Verfügung, das die wichtigsten Schritte vereint. Allerdings hat dieses Verfahren den Nachteil einer weiteren Abhängigkeit in Ergänzung zu Tabelle 1 (GPG), die Tools »losetup« und »mount« brauchen zudem Patches. Die meisten Distributionen sind jedoch bereits passend vorbereitet.

Nicht nur Scheiben

AES-Pipe chiffriert auf Wunsch jeden Datenstrom. So sind verschlüsselte Tar-Archive vorstellbar:

tar cj /daten | aespipe > daten.tar.bz2.enc
aespipe -d < daten.tar.bz2.enc | tar xj

Ein weiteres lohnendes Ziel sind verschlüsselte Backups, zum Beispiel direkt per Tar auf ein Bandlaufwerk:

tar cj /daten| aespipe| dd of=/dev/st0 bs=56
dd if=/dev/st0 bs=56 | aespipe -d | tar tj

AES-Pipe beherrscht auch Bzip-2-Kompression. Sie ist aber nur vor der Verschlüsselung sinnvoll, chiffrierte Daten lassen sich nicht eindampfen. Zudem vermeidet diese Variante Tar-Warnungen über ignorierten Datenmüll: Die Hinweise »bzip2: (stdin): trailing garbage after EOF ignored« entstehen, weil AES-Pipe mit einer festen Blockgröße von 16 Byte arbeitet und fehlende Bytes mit Null-Werten auffüllt. Das verwirrt Tar und dessen Bzip-2-Funktion.

Die Kompression führt bei ISO-Images nicht zum Erfolg, weil die CDs und DVDs sich dann nicht mehr mittels »losetup« mounten lassen. Wer die Daten packen will, sollte das im Filesystem erledigen.

Paranoia

AES-Pipe bietet noch einige Einstellungen, um potenziellen Angreifern das Leben zu erschweren. So ist es möglich, gleich 64 Schlüssel auf einmal für die Verschlüsselung zu nutzen. In diesem Multi-Key-Modus verschlüsselt das Programm den ersten Sektor mit dem ersten Schlüssel, den zweiten Sektor mit dem zweiten und so fort. Dazu nutzt es statt eines normalen Initialisierungsvektors (IV, siehe Kasten “Begriffe”) jeweils einen MD5-Hash-IV.

Allerdings funktioniert dieser Modus nur im Zusammenhang mit einer GPG-verschlüsselten Datei. Der Multi-Key-Modus kommt automatisch zum Zuge, sobald in der GPG-Datei mindestens 64 Schlüssel zu je 20 Zeichen durch Zeilenumbruch getrennt stehen.

Eine weitere Methode, um Brute-Force-Attacken zu erschweren, bearbeitet den Schlüssel mehrere tausend Mal mittels AES. Der Parameter »-C Faktor« gibt den Tausender-Faktor an. Dieses Verfahren erhöht die CPU-Auslastung einmalig vor der eigentlichen Verschlüsselung, der Angreifer hat jedoch ebenfalls diesen Mehraufwand bei jedem Schlüssel, den er probiert. Das Programm verwendet auf Wunsch auch einen Seed, anzugeben per Parameters »-S«. Die letzten beiden Methoden funktionieren aber nicht im Muli-Key-Mode.

Fazit

Sowohl das modifizierte Cdrecord als auch die Kombination eines unveränderten Brennprogramms mit AES-Pipe eignen sich, um verschlüsselte Datenträger zu erstellen und wieder transparent ins Dateisystem zu hängen. AES-Pipe bietet durch seinen allgemeinen Charakter mehr Spielraum. Dafür ist das Cdrecord-Patch in seiner Benutzerfreundlichkeit kaum zu überbieten, insbesondere die einfache Integration in vorhandene Brenn-GUIs wie K3B dürfte vielen Anwendern gefallen. Sie sollten bei der Methode aber auf die »-encstyle=new«-Variante setzen, um Inkompatibilitäten aus dem Wege zu gehen. (fjl)