Sicherheitsanalyse von TrueCrypt 7.0a mit einem Angriff auf das Schlüssel-Datei-Verfahren

Transkript

1 Sicherheitsanalyse von TrueCrypt 7.0a mit einem Angriff auf das Schlüssel-Datei-Verfahren Ubuntu Privacy Remix Team 14. August 2011 Inhaltsverzeichnis Vorbemerkungen Daten des Programms Bemerkungen zu den Binärpaketen von TrueCrypt 7.0a Übersetzen von TrueCrypt 7.0a aus den Quelltexten...3 Compilieren von TrueCrypt 7.0a unter Linux...3 Compilieren von TrueCrypt 7.0a unter Windows Methode der Überprüfung Das Programm tcanalyzer Ergebnisse der Analyse im Einzelnen...7 Die TrueCrypt Lizenz...7 Webseite und Dokumentation von TrueCrypt...8 Kryptographische Algorithmen von TrueCrypt...8 Modus der Verschlüsselung in TrueCrypt...10 TrueCrypt-Container und versteckte Volumen...11 Der Zufallsgenerator von TrueCrypt...12 Das Format der TrueCrypt-Container Ein Angriff auf TrueCrypt Schlüssel-Dateien...15 Der TrueCrypt Schlüssel-Datei-Algorithmus...15 Die Manipulation von TrueCrypt Schlüssel-Dateien...15 Reaktion der TrueCrypt-Entwickler auf den Angriff Schlussfolgerungen...19 Vorbemerkungen Wir haben früher schon die Versionen 4.2a, 6.1a und 6.3a von TrueCrypt im Quelltext analysiert ohne unsere Resultate zu veröffentlichen. Nun jedoch, für unsere Analyse der Version 7.0a haben wir uns entschieden, sie zu veröffentlichen. Wir hoffen, dass dies anderen helfen wird, sich eine 1

2 eigene fundierte Meinung über die Sicherheit von TrueCrypt zu bilden. Darüber hinaus werben wir um Hilfe bei der Berichtigung jedweder Fehler, die uns unterlaufen sind. Deshalb möchten wir die Leser dieser Analyse ermutigen, uns Kritiken oder Vorschläge für eine weitere Analyse von True- Crypt zu zusenden. In der Vorbereitung unserer Analyse für die Veröffentlichung haben wir unsere früheren Resultate neu durchdacht und bewertet. Dabei haben wir schwerwiegende Schwächen in dem Verfahren entdeckt, mit dem TrueCrypt seine sogenannten Schlüssel-Dateien (auf englisch Keyfiles ) verarbeitet. Diese Entdeckung konnte sogar für einen erfolgreichen Angriff auf TrueCrypt Schlüssel-Dateien ausgenutzt werden. Wir legen diesen Angriff im Abschnitt 7 dar. Wir möchten aber betonen, dass die Sicherheit von TrueCrypt Containern, die Schlüssel-Dateien nicht benutzen, in keiner Weise von diesen Schwächen oder dem Angriff betroffen ist. TrueCrypt ist ein Programm für mehrere Plattformen. Bis jetzt gibt es Versionen für Windows, Linux und Mac OS X. Unsere Analyse konzentriert sich hauptsächlich auf die Linux-Version. Die Windows-Version ist in geringerem Umfang in die Analyse mit einbezogen worden, die Version für Max OS X gar nicht. In weiten Teilen ist die Code-Basis von TrueCrypt für alle Betriebssysteme dieselbe. Andererseits gibt es in TrueCrypt auch speziellen Code für jedes der unterstützen Betriebssysteme. Dies schlägt sich sogar in stellenweise leicht abweichendem Verhalten des Programms auf den verschiedenen Betriebssystemen nieder. Im Quellcode von TrueCrypt 7.0a gibt es weiterhin Verzeichnisse für die Betriebssysteme FreeBSD und Solaris. Offensichtlich ist der Quellcode in diesen Verzeichnissen jedoch noch nicht so weit gediehen, dass ein Programm daraus gebaut und vertrieben werden kann. Aus diesem Grund haben wir diesen Code vollständig vernachlässigt. Der vorliegende Bericht gliedert sich wie folgt: Abschnitt 1 enthält eine Auflistung der Daten des Programms. In Abschnitt 2 machen wir einige Bemerkungen zu den Binärpaketen. Abschnitt 3 behandelt die Übersetzung aus den Quelltexten. Abschnitt 4 legt die Methode der Überprüfung dar. In Abschnitt 5 beschreiben wir unser Programm tcanalyzer, welches für die Analyse geschrieben wurde. Abschnitt 6 enthält die Ergebnisse der Überprüfung im Einzelnen mit Ausnahme des Angriffs auf TrueCrypt Schlüssel-Dateien, welchem Abschnitt 7 gewidmet ist. Schließlich legt Abschnitt 8 unser Fazit der Überprüfung dar. Die Begründung zu den Schlussfolgerungen in Abschnitt 8 finden sich hauptsächlich in Abschnitt 6. In den Abschnitten 6 und 7 sind einige tiefer gehende technische und mathematische Details in Fußnoten dokumentiert worden. Leser, die diese Details nicht benötigen oder denen Kenntnisse zu ihrem Verständnis fehlen, können sie unbeschadet überlesen. 1. Daten des Programms Webseite: Überprüfte Version: TrueCrypt 7.0a Untersuchter Quellcode (Unix): TrueCrypt 7.0a Source.tar.gz MD5-Fingerabdruck: 0a61616bc5c5ad90e876b4014c004ac9 SHA1-Fingerabdruck: 42be0f333e6791e7a122b3e1183e014cd Alternativer Quellcode (Windows): MD5-Fingerabdruck: SHA1-Fingerabdruck: TrueCrypt 7.0a Source.zip c674bc18d6bcf55d056560f0a7 8f9bf2ae13461fb3bfb4d1f7acb76c7c1c7ed29d 2

3 2. Bemerkungen zu den Binärpaketen von TrueCrypt 7.0a Auch für Linux werden die Binärpakete von TrueCrypt 7.0a als ausführbare Installationsprogramme bzw. Skripte verteilt, die allerdings ihrerseits noch einmal in ein.tar.gz-archiv verpackt sind. Nach dem Auspacken dieser Installationsprogramme bietet ihre Ausführung die Möglichkeit der direkten Installation oder der Extraktion eines.tar.gz-archivs welches dann im Verzeichnis /tmp landet. Abgesehen davon, dass unter Linux ausführbare Installationsprogramme sowieso unüblich sind, ist mit der Version 7.0 ein weiterer Schritt von der unter Linux üblichen Softwareverwaltung weg gemacht wurden. Bis zur Version 6.3a hatte TrueCrypt noch.deb- oder.rpm-pakete mit dem Installationsprogramm extrahiert oder installiert. Ab der Version 7.0 ist dies nicht mehr der Fall. TrueCrypt installiert sich jetzt über ein weiteres.tar.gz-archiv, welches das Installationsprogramm extrahiert. Zum Ausgleich enthält die installierte Software von TrueCrypt 7.0a jetzt das Skript /usr/bin/truecrypt uninstall.sh, mit welchem sie wieder deinstalliert werden kann. 3. Übersetzen von TrueCrypt 7.0a aus den Quelltexten Compilieren von TrueCrypt 7.0a unter Linux Wir haben die Übersetzung von TrueCrypt 7.0a unter Linux auf einem Rechner mit Ubuntu LTS getestet. Zusätzlich zu den bei der Installation des Rechners mit diesem Betriebssystem schon vorhandenen Paketen müssen für diesen Zweck die Pakete g++ nasm libwxgtk2.8 dev libfuse dev und alle Pakete, von denen diese Pakete abhängig sind installiert werden. Weiter haben wir wie in der Datei Readme.txt in den Quellen angegeben von ftp://ftp.rsasecurity.com/pub/pkcs/pkcs- 11/v2-20 die drei Header-Dateien pkcs11.h pkcs11f.h pkcs11t.h herunter geladen und nach /usr/include kopiert. Will man sie nicht in ein Standard-Include-Verzeichnis legen, so muss man vor dem Compilieren die Umgebungsvariable PKCS11_INC anlegen mit dem Inhalt des vollständigen Pfads des Verzeichnisses, in welches diese Dateien gelegt wurden. Danach haben wir einfach die Befehle tar xvzf "TrueCrypt 7.0a Source.tar.gz" cd truecrypt 7.0a source make eingegeben. Das Compilieren lief damit ohne jede Fehler und Warnmeldungen durch. Im Unterverzeichnis Main lag anschließend das ausführbare Programm truecrypt. Auf diese Weise entsteht ein Programm, welches sowohl die Kommandozeile unterstützt, wie auch eine graphische Oberfläche bietet. 3

4 Möchte man ein Debian-Paket aus dem selbst übersetzten TrueCrypt 7.0a bauen, so installiert man sich noch das Paket fakeroot und kann dann wie folgt fortfahren: mkdir p truecrypt_7.0a/debian mkdir p truecrypt_7.0a/usr/share/applications mkdir p truecrypt_7.0a/usr/share/pixmaps mkdir p truecrypt_7.0a/usr/share/truecrypt/doc mkdir p truecrypt_7.0a/usr/bin echo "Package: truecrypt" > truecrypt_7.0a/debian/control echo "Version: 7.0a" >> truecrypt_7.0a/debian/control echo "Section: utils" >> truecrypt_7.0a/debian/control echo "Priority: optional" >> truecrypt_7.0a/debian/control echo "Architecture: i386" >> truecrypt_7.0a/debian/control echo 'Maintainer: Vorname Name < >' >> \ truecrypt_7.0a/debian/control echo "Depends: libwxgtk2.8 0, libfuse2" >> \ truecrypt_7.0a/debian/control echo "Description: Software for on the fly encrypted volumes" >> \ truecrypt_7.0a/debian/control cp Main/truecrypt truecrypt_7.0a/usr/bin echo "[Desktop Entry]" > \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop echo "Encoding=UTF 8" >> \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop echo "Name=TrueCrypt" >> \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop echo "Exec=/usr/bin/truecrypt" >> \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop echo "Icon=truecrypt" >> \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop echo "Terminal=false" >> \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop echo "Type=Application" >> \ truecrypt_7.0a/usr/share/applications/truecrypt.desktop cp "Release/Setup Files/TrueCrypt User Guide.pdf" \ truecrypt_7.0a/usr/share/truecrypt/doc cp License.txt truecrypt_7.0a/usr/share/truecrypt/doc cp Resources/Icons/TrueCrypt 48x48.xpm \ truecrypt_7.0a/usr/share/pixmaps/truecrypt.xpm fakeroot dpkg deb build truecrypt_7.0a Dann hat man ein Paket truecrypt_7.0a.deb im aktuellen Verzeichnis erzeugt. Die Architektur muss amd64 statt i386 sein, wenn man auf einem 64-Bit-System baut. Der Maintainer ist auch entsprechend anzupassen. Compilieren von TrueCrypt 7.0a unter Windows Wir haben TrueCrypt 7.0a auch auf einem Rechner mit Windows XP Professional übersetzt. Nach den Anweisungen in der Datei Readme.txt haben wir dazu Visual Studio 2008 Professional Edition in der Standard-Konfiguration installiert. Eine 90 Tage verwendbare Trial Version kann von Microsoft herunter geladen werden. Das von uns zuerst ausprobierte Visual Studio 2008 Express Edition mit SP1 eignet sich zum Übersetzen von TrueCrypt nicht, weil in ihm das benötigte Verzeichnis atlmfc mit Bibliotheken und Header-Dateien fehlt. Darauf haben wir dann alle Updates eingespielt. 4

5 Als nächstes haben wir das Microsoft Windows SDK 7.0 for Windows 7 and.net Framework 3.5 SP1 installiert. Es war wichtig, dies nach der Installation von Visual Studio zu installieren, weil sonst in Visual Studio die Variable WindowsSdkDir auf dem Wert C:\Programme\Microsoft SDKs\Windows\v6.0A stehen bleibt und so das falsche SDK verwendet wird. Weiterhin haben wir Microsoft Visual C c installiert und die Umgebungsvariable MSVC16_ROOT auf den Wert C:\MSVC gesetzt, in welches Verzeichnis sich dies installiert hatte. Schließlich haben wir Microsoft Windows Driver Kit in der Standard-Konfiguration und den NASM 2.08 für Windows installiert. Den Pfad zu dem Programm nasm.exe haben wir zu der Variablen PATH hinzugefügt. Die drei oben genannten PKCS-11 Header-Dateien haben wir in ein eigenes dafür angelegtes Verzeichnis kopiert und die Umgebungsvariable PKCS11_INC mit diesem Wert des Pfades zu diesem Verzeichnis angelegt. TrueCrypt weigert sich zu Compilieren, wenn die Projekt-Datei in einem Verzeichnis liegt, dessen Pfad Leerzeichen enthält. Darum haben wir den TrueCrypt-Quellcode aus dem ZIP-Archiv TrueCrypt 7.0a Source.zip in ein neues Verzeichnis hinein entpackt, welches keine Leerzeichen enthält. Nach diesen Vorbereitungen kann man endlich die Datei TrueCrypt.sln in dem zuletzt genannten Verzeichnis in Microsoft Visual Studio 2008 als Projekt laden, All als zu bauende Unterprojekte auswählen und mit F7 das Bauen von TrueCrypt starten. Nachdem das durchgelaufen ist, findet man im Unterordner Release\Setup Files des Projekt-Ordners die ausführbare Datei TrueCrypt Setup.exe. Dies ist jedoch noch nicht das gewünschte Installationspaket für True- Crypt 7.0a. Eine solches Installationspaket muss man erst noch mit dem Aufruf TrueCrypt Setup.exe /p in dem Verzeichnis erstellen. Damit wird TrueCrypt Setup 7.0a.exe erzeugt, welches das gewünschte Installationspaket ist. 4. Methode der Überprüfung Wir haben den Quellcode des Unix-Quellcode-Archivs sorgfältig gelesen. Die Teile die allen Betriebssystemen gemeinsam sind und der Teil für Linux wurden vollständig untersucht. Es hat auch geholfen, Differenzen zu der Version 6.3a, die wir bereits in 2010 geprüft hatten, mit dem Programm diff zu berechnen und durchzusehen. Dadurch konnten wir die Aufmerksamkeit auf die Teile des Codes konzentrieren, die sich substantiell geändert haben. Für den XTS-Modus der in TrueCrypt 5, 6 und 7 verwendet wird haben wir, genauso wie zuvor bei der früheren Untersuchung der Version 4.2a für den LRW-Modus, die mathematische Theorie in den einschlägigen Veröffentlichungen studiert. Das XTS-Verfahren ist auf dem aktuellen Stand der Forschung und ersetzt das LRW-Verfahren in dieser Hinsicht. Wir haben dann das Programm tcanalyzer geschrieben, welches die Header von TrueCrypt Containern analysiert. Es benutzt Bibliotheken der vollkommen unabhängig von TrueCrypt entwickelten Software ScramDisk for Linux (siehe die TrueCrypt-Container öffnen und erzeugen kann. Zu dem Zweck haben wir die letzte Version von ScramDisk for Linux ( herunter geladen und unser Programm mit den daraus gebauten Bibliotheken verlinkt. Unser Programm tcanalyzer wird zusammen mit dieser Analyse veröffentlicht und steht unter der GNU General Public License in der Version 3. Wir haben Test-Container sowohl mit den selbst compilierten Paketen von TrueCrypt 7.0a wie auch mit den binären Paketen von der TrueCrypt Webseite unter Linux wie unter Windows erzeugt. Alle Verschlüsselungs- und alle Hash-Algorithmen wurden dabei mindestens einmal ausgewählt. Verborgene Volumen in einem äußeren TrueCrypt-Container waren auch unter den Test-Containern. 5

6 Sie wurden sowohl einmal direkt in einem Zug mit dem äußeren Container erzeugt wie auch einmal nachträglich in einem zuvor erzeugten TrueCrypt-Container. Wir haben die Header aller dieser Container mit tcanalyzer analysiert. Am Ende waren wir überzeugt, dass keine sicherheitsrelevanten Fehler oder Hintertüren in der Verschlüsselung oder im Header-Format verborgen sind. Auf Windows können die Versionen 5, 6 und 7 von TrueCrypt das ganze Betriebssystem verschlüsseln. Wir haben nur einmal eine solche Systemverschlüsselung mit TrueCrypt 7.0a erzeugt und ein Festplatten-Image der verschlüsselten Festplatte mit tcanalyzer untersucht. In diesem Fall konnten wir uns ebenfalls überzeugen, dass das vom üblichen TrueCrypt-Format abweichende Format dieser Systemverschlüsselung fehlerfrei ist. Den TrueCrypt-Boot-Code, der die Festplatte beim hochfahren des Rechners entschlüsselt, haben wir jedoch nicht untersucht und noch nicht einmal gelesen. 5. Das Programm tcanalyzer Das Programm tcanalyzer analysiert einen der bis zu vier Header eines TrueCrypt-Containers und zeigt die Information in diesem Header an. Es macht Gebrauch von dem Code von ScramDisk for Linux (siehe den es als Bibliotheken nutzt. Welcher Header analysiert wird, wird durch Parameter kontrolliert, die dem Programm auf der Kommandozeile übergeben werden. tcanalyzer kann das Format der TrueCrypt-Versionen 4.1 bis 7.0 analysieren. Das Programm darf nur auf Test-Container angewendet werden. Andernfalls kann die Sicherheit der im Container enthaltenen Daten durch die Anzeige des Schlüssels des Containers kompromittiert werden. Das Programm tcanalyzer hat die folgenden Optionen, die als Parameter auf der Kommandozeile übergeben werden können: -?, --help : eine Hilfe ausgeben und das Programm beenden. -b, --backup: analysiere den Backup Header. -h, --hidden: analysiere das verborgene Volumen. -s, --sysdisk: nehme an, dass es sich um eine Systemverschlüsselung handelt. -f, --full: gebe den kompletten Header aus (64 Kilobytes für Versionen > 5), ohne diese Option werden nur 512 Bytes ausgegeben. -o, --out Datei: schreibe die Ausgabe in die angegebene Datei, ohne diese Option erfolgt die Ausgabe auf das Terminal. -p, --passphrase Passwort: benutze das angegebene Passwort für die Analyse, ohne diese Option wird nach dem Passwort gefragt. -c, --container container: analysiere den angegebenen Container. Eine typische Ausgabe von tcanalyzer, die nur in englischer Sprache erfolgt, sieht dann etwa wie folgt aus: Enter passphrase: :> **** Analysis of normal header for TrueCrypt container /tmp/test 70a aes.tc ================================================================================ TrueCrypt version : 7 Encryption mode : XTS Digest : ripemd160 Cipher : aes Key size : 32 bytes 6

7 ================================================================================ 0: cc c3 d2 be ba 09 b3 09 cf d9 b1 a1 c4 d8 salt 16: 41 fa 47 aa e ad ac 7c 72 salt 32: 5e f4 00 de 5b 6f 0f af 82 e4 f4 3c salt 48: b c d2 c7 b salt 64: ce e4 b4 c : 'TRUE', 68: header version 5, 70: program version 7.0, 72: CRC32(bytes ) 80: : hidden volume size 0 96: c : volume size , 108: master encryption offset : c : master encryption size , 124: flags 0 128: : sector size : : : : : : : b3 5b ea : CRC32(bytes ) 256: 59 e5 89 3a fd 4e 41 ca f 5f 74 ee master key 272: 96 d4 e9 22 9d b0 da d8 41 7a 52 2d fd 9f master key 288: 8a d9 1a a e a c d7 a4 XTS key 304: 12 be 55 e9 89 ca ed ec 0c 7f ac 62 cc af XTS key 320: : : : : : : : : : : : Nach der Information über die TrueCrypt-Version, die den Container erzeugt hat, den Modus der Verschlüsselung, Hash- und Verschlüsselungsalgorithmus sowie die Länge des Schlüssels werden die entschlüsselten Bytes des Headers mit 16 Bytes pro Zeile ausgegeben. Jede Zeile wird von einem Zeichen gefolgt, welches einige Erklärungen zur Bedeutung der Daten in der Zeile von ihr abtrennt. 6. Ergebnisse der Analyse im Einzelnen Die TrueCrypt Lizenz TrueCrypt verwendet kryptographischen Code aus fünf verschiedenen Quellen: von der TrueCrypt- Foundation selbst, von Paul Le Roux, Brian Gladman, Mark Adler und Eric Young. Daher enthält die TrueCrypt-Lizenz in ihrer aktuellen Version 3.0 neben den eigenen Bestimmungen der True- Crypt-Foundation drei weitere Abschnitte mit Bestimmungen von Paul Le Roux, Brian Gladman und Mark Adler (von Eric Young wird keine eigener Lizenzteil beigefügt aber erwähnt). Soweit ist das wohl historisch bedingt, da TrueCrypt zum Teil als Weiterentwicklung von Encryption for the 7

8 Masses (E4M) von Paul Le Roux entstanden ist. Aber auch die eigenen Lizenz-Bestimmungen der TrueCrypt-Foundation sind inkompatibel mit der GNU General Public License (GPL). Das verkompliziert den rechtlichen Status von TrueCrypt. Falls andere einmal die Entwicklung von True- Crypt fortführen wollen, etwa weil die TrueCrypt-Foundation die Pflege des Programms eingestellt hat, so wäre das zumindest rechtlich sehr problematisch. Auch die großen Linux-Distributoren Debian, Ubuntu, Fedora, opensuse und Gentoo betrachten TrueCrypt nicht als Open-Source-Produkt (siehe und weigern sich konsequenter Weise auch Pakete dafür bereit zu stellen. Webseite und Dokumentation von TrueCrypt Die Präsentation von TrueCrypt macht für ein Open-Source-Projekt einen etwas verschlossenen Eindruck. So kann man von der Webseite nur die letzte Version (derzeit 7.0a) und wenige ältere Versionen (für Linux gegenwärtig zusätzlich nur noch die Version 6.3a) herunter laden. Bug-Reports, die im Diskussionsforum nicht erwünscht sind und über ein eigenes Formular eingegeben werden sollen, werden nicht veröffentlicht. Auch die Teile des Forums, die sich mit Problemen befassen, kann man nur als angemeldeter Benutzer lesen. Auf Vorschläge und Hinweise unsererseits, sowohl per an die auf der TrueCrypt Webseite veröffentlichten -Adressen wie auch als Beiträge im TrueCrypt-Forum, haben die Entwickler bisher überhaupt nie reagiert. Dies änderte sich jedoch, als wir Ihnen den hier vorgestellten Angriff auf TrueCrypt Schlüssel-Dateien schickten. Wir bekamen umgehend eine Antwort darauf, die wir gemeinsam mit der Darlegung des Angriffs im Abschnitt 7 diskutieren. Die Dokumentation auf der Webseite dagegen ist gut. Sie enthält nicht nur eine ausführliche Beschreibung der Features und eine Anleitung zur Bedienung des Programms sondern z.b. auch Angaben zum Format der Container und zu den auswählbaren kryptographischen Algorithmen. Der technische Teil der Dokumentation ist so detailliert, dass er unsere Analyse gut unterstützen konnte. Man vermisst hier allerdings eine Changelog Datei, die die Änderungen am Code kurz darlegt und gegebenenfalls begründet. Das erschwert die Codeanalyse jeder neuen Version. Kryptographische Algorithmen von TrueCrypt TrueCrypt 7.0a bietet drei verschiedene Hash- und acht verschiedene Verschlüsselungsalgorithmen zur Auswahl an. Die Hash-Algorithmen dienen dazu, aus dem Passwort des Benutzers den Schlüssel abzuleiten, mit dem der Header des Containers verschlüsselt ist. Dafür stehen zur Auswahl: Ripemd-160, SHA-512 und Whirlpool. Die Verschlüsselungsalgorithmen setzen sich aus drei verschiedenen Chiffren zusammen, die nicht nur einzeln als Verschlüsselungsalgorithmus zur Verfügung stehen, sondern auch mit anderen in Form einer Hintereinanderausführung kombiniert werden können. Diese Speicherverwaltungsalgorithmen sind 1 : AES, 1 Alle drei Chiffren sind Kandidaten der Finalrunde des weltweiten Wettbewerbs, mit dem im Oktober 2000 Rijndael als neuer Verschlüsselungsstandard AES von der NIST (National Institute of Standards and Technology) der USA gekürt wurde (siehe Sie wurden allesamt von Teams renommierter Kryptographen entwickelt und im Prozess des Wettbewerbs einer intensiven öffentlichen Analyse unterzogen. Bei den Kombinationen wird die Reihenfolge von TrueCrypt gegenüber der Reihenfolge, wie sie bei der Initialisierung und der Verschlüsselung benutzt wird, umgekehrt angegeben. Die hier genannte Reihenfolge ist die von TrueCrypt angegebene, die auch der Reihenfolge bei der Entschlüsselung entspricht. 8

9 Serpent, Twofish, AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES und Twofish-Serpent. Weitere Algorithmen, die in früheren Versionen benutzt wurden, sind noch vorhanden, werden aber nur noch beim Öffnen älterer Container, die mit früheren Versionen und einer der früheren Algorithmen erstellt wurden, benutzt. Eine Hintereinanderausführung von mehreren Chiffren erhöht die Sicherheit, weil eine mögliche Schwäche, die in einer der Chiffren entdeckt werden sollte, dann unter dem Schutz der anderen Chiffren ohne Auswirkung bleibt. Sie verlangsamt aber auch die Ver- und Entschlüsselung. Das kann besonders auf Rechnern mit einem älteren Prozessor zu einer starken Belastung des Systems führen. Wir empfehlen daher, auf neueren Rechner eine Kombination wie Serpent-AES. Auf älteren Rechnern empfehlen wir den sehr schnellen und, auch in Folge seiner Wahl zum internationalen Standard, besonders intensiv auf seine Sicherheit hin untersuchten Algorithmus AES alleine auszuwählen. Die Wahl des Hash-Algorithmus ist vom Sicherheitsstandpunkt aus nicht so erheblich. Wir empfehlen hier die Wahl von SHA-512, welches ebenfalls ein internationaler Standard ist und mit 64 Byte (512 Bit) eine deutlich größere Länge des Hash-Wertes hat als Ripemd-160 mit 20 Byte (160 Bit). Die Länge des Hash-Wertes von Whirlpool beträgt ebenfalls 64 Byte (512 Bit). TrueCrypt begrenzt die Passwortlänge auf maximal 64 Zeichen. Das ist jedoch kein Problem, weil längere Passwörter kaum einen Sinn machen, weil die Länge der Schlüssel dann eine weitere Verstärkung begrenzt. Mit Methoden, die sinnvolle Wörter im Passwort 2 vermeiden, erhält man schon bei 30 oder eventuell sogar 20 Zeichen eine ausreichende Qualität, um selbst große Geheimdienste daran zu hindern, sie zu knacken. Mit einem Zeichensatz von z.b. 62 Zeichen (Groß- und Kleinbuchstaben und Ziffern) und 20 völlig zufällig daraus ausgewählten Zeichen erhält man eine Entropie 3 von 119 Bit. Mit der Diceware-Methode 4 erhält man mit neun ausgewürfelten Diceware-Wörtern auch schon 116 Bit Entropie die bei der englischen Diceware-Liste zusammen im Schnitt 38,1 Zeichen lang wären. Um der Schwäche der Wahl eines zu kurzen Passwortes etwas entgegen zu wirken, wiederholt TrueCrypt die Anwendung des Hash-Algorithmus 5 bei der Ableitung des Schlüssels 1000 bzw Mal. Das wirkt sich auf mögliche Angriffe so aus, als hätte das Passwrot 10 oder 11 Bit mehr Entropie und ist eine der Stärken von TrueCrypt. Bei den heute üblichen Prozessor-Geschwindigkeiten könnte man hier auch durchaus einen höheren Wert zum Beispiel verwenden. Das würde zwar die Aufwärtskompatibilität von TrueCrypt brechen, aber die brechen die Entwickler ja sowieso schon mit jeder neuen Hauptversion. 2 Um die Notwendigkeit zu betonen, sinnvolle Wörter im Passwort zu vermeiden oder wenigstens mehrere Wörter im Passwort zu haben, verwenden PGP und GnuPG in diesem Zusammenhang den Begriff Passphrase anstelle von Passwort. Wir halten uns in diesem Dokument jedoch an die TrueCrypt-Terminologie. 3 Die Entropie in Bits ist in diesem Zusammenhang ein Maß für die Stärke eines Passwortes. Die Anzahl der verschiedenen Passwörter, die ein Angreifer durchprobieren muss, um mit Sicherheit das richtige zu finden, beträgt dann 2 Entropie und jedes Bit mehr verdoppelt den Aufwand für den Angreifer. 4 Die Diceware Homepage erklärt die Diceware-Methode im Detail. Dort können auch Wortlisten dafür herunter geladen werden. 5 Genau genommen wird der Hash-Algorithmus auch nicht in der einfachen Form unmittelbar auf das Passwort angewandt. Vielmehr wird hier das auf dem Hash-Algorithmus aufbauende HMAC-Verfahren benutzt, welches das Passwort mit dem am Anfang des Containers gespeicherten Salt -Wert zusammen verrechnet. Diese Berechnung wird für Ripemd mal und für SHA-512 und Whirlpool 1000 mal iteriert. Für eine Systemverschlüsselung wird sie auch für Ripemd-160 nur 1000 mal iteriert. 9

10 Modus der Verschlüsselung in TrueCrypt Die Verschlüsselungsalgorithmen operieren auf Blöcken von 16 Bytes (128 Bit). Ältere Versionen von TrueCrypt enthielten auch Algorithmen, die auf 8 Byte (64 Bit) großen Blöcken operierten. Diese werden von TrueCrypt 7.0a nur noch benutzt, wenn ein, mit einer älteren Version erzeugter, Container geöffnet werden muss. Damit nicht identische Blöcke mit gleichem Resultat verschlüsselt werden, wird die Verschlüsselung noch von Block zu Block etwas modifiziert. Das nennt man in der Kryptographie den Modus der Operation. Bis einschließlich zur Version 4.0 hat TrueCrypt hierfür das so genannte Cipher Block Chaining (CBC) eingesetzt. Dieser Modus hat im Kontext einer Volumenverschlüsselung jedoch erhebliche Schwächen. Diese erlauben es einem aktiven Angreifer, der in der Lage ist, jemanden zum Speichern bestimmter Daten zu veranlassen, später bestimmte, wenn auch sehr begrenzte, Rückschlüsse auf andere in dem verschlüsselten Container gespeicherte Daten zu ziehen. Um diese Sicherheitslücke zu schließen, hat TrueCrypt mit der Version 4.1 den LRW-Modus eingeführt. Der CBC-Modus wird weiterhin unterstützt, neue Container wurden seit dem aber nur noch mit dem LRW-Modus erzeugt. Der LRW-Modus ist nach seinen Erfindern Liskov, Rivest und Wagner benannt 6. Dabei wird ein zweiter Schlüssel von der Größe der Blocklänge mit einem Block- Zähler in einem Galois-Feld multipliziert und das Ergebnis dieser mathematischen Operation sowohl zu dem betreffenden Klartext-Block wie zu dem Resultat der Verschlüsselung hinzu addiert. Wir haben sowohl die mathematische Korrektheit der von TrueCrypt benutzten Darstellungen 7 der beiden Galois-Felder für die Blocklängen von (in der Version noch) 64 und 128 Bit wie auch die Programmierung sorgfältig untersucht. Auch die Kompatibilität mit unabhängigen Implementierungen hiervon im Linux-Kernel und in ScramDisk for Linux bestätigt die Korrektheit. Mit der Version 5.0 hat TrueCrypt als Ersatz für den LRW-Modus den XTS-Modus eingeführt, der den LRW-Modus leicht abwandelt 8, um eine nur theoretische kleine Schwäche des LRW-Modus auszugleichen. Eines der verwendeten Galois-Felder bleibt das gleiche, das andere wird nicht mehr verwendet. Es werden dabei zusätzlich zu den 16 Byte großen Blöcken 512 Byte große Verschlüsselungseinheiten eingeführt und in jeder dieser Einheiten die Galois-Operationen für die Blöcke neu mit einer Verschlüsselung der Nummer der Einheit initialisiert. Bis zur Version 6.3a waren diese Verschlüsselungseinheiten identisch mit den Sektoren. Ab der Version 7.0 können die Sektoren auch größer als 512 Bytes sein. Die Sektorgröße wird darum dann auch im Dateikopf gespeichert. Auch diesen Modus haben wir einer eingehenden Überprüfung auf die mathematische Korrektheit und die Korrektheit der Umsetzung in den Programmcode unterzogen. Dies ist alles richtig umgesetzt. Mit dem XTS-Modus hat TrueCrypt ein modernes und mathematisch beweisbar sicheres Verschlüsselungsverfahren eingeführt, sofern die zugrunde liegenden Verschlüsselungsalgorithmen sicher sind. Wegen der Schwächen des CBC-Modus und des LRW-Modus empfehlen wir keine Container weiter zu benutzen, die mit einer TrueCrypt-Version vor 5.0 erstellt wurden. TrueCrypt 7.0a überlässt auf Linux für Container, die mit dem XTS-Modus formatiert sind, nachdem es den Dateikopf eines Containers gelesen und entschlüsselt hat, die Entschlüsselung des Volumens ganz dem Linux-Kernel. Dasselbe macht TrueCrypt auch für ältere Container, die mit dem LRW-Modus formatiert sind, wenn sie nur eine Chiffre benutzen und diese eine Blocklänge von 16 Byte (128 Bit) hat. Das betrifft also alle Container, die mit den Versionen 5, 6 und 7 von TrueCrypt erzeugt wurden, und einen Teil der Container, die mit einer der Versionen 4.1 bis 4.3a 6 Siehe Moses Liskov, Ronald L. Rivest und David Wagner: Tweakable Block Ciphers, CRYPTO Diese Darstellungen basieren auf den Polynomen x 64 x 4 x 3 x 1 und x 128 x 7 x 2 x 1 für die Galois-Felder GF 2 64 bzw. GF die tatsächlich primitiv über GF 2 sind, was die notwendige und hinreichende Bedingung für die mathematisch korrekte Darstellung ist. Das erste Polynom ist nur für die älteren Algorithmen zuständig, die mit 64-Bit Blöcken operieren. Im XTS-Modus wird es nicht mehr verwendet, weil dieses nur mit den neuen Algorithmen arbeitet. 8 Beim XTS-Modus wird etwas vereinfacht dargestellt die Galois-Multiplikation für 16-Byte-Blöcke, wie sie auch im LRW-Modus verwendet wird, in jeder 512 Byte großen Verschlüsslungseinheit des Containers durch eine Verschlüsselung der Nummer der Einheit mit dem XTS-Schlüssel neu initialisiert. 10

11 erzeugt wurden. Dazu übergibt TrueCrypt dem Linux-Kernel mit dem Kommando dmsetup das Verschlüsselungsverfahren, den Modus, den Offset des verschlüsselten Bereichs in der Containerdatei sowie den hexadezimal kodierten Master-Schlüssel und den Schlüssel für den Modus. Einerseits haben wir damit eine weitere Kontrolle für die Richtigkeit der Volumenverschlüsselung, weil die unabhängige Implementierung im offiziellen Linux-Kernel sie durch die erfolgreiche Entschlüsselung bestätigt. An dem Linux-Kernel ist auch eine sehr viel größere Zahl von Entwicklern beteiligt als an TrueCrypt. Damit kann man davon ausgehen, dass auch einige dieser Entwickler den kryptographischen Code des Kernels einmal bearbeitet oder wenigstens geprüft haben. Andererseits eröffnet sich durch dieses Vorgehen für einen Angreifer die Möglichkeit, einfach mit dem Kommando sudo dmsetup table showkeys nicht nur das Verschlüsselungsverfahren sondern auch den Master-Schlüssel auslesen zu können, mit dem der Container geöffnet werden kann. Das sehen wir jedoch nicht als Einwand gegen dieses Vorgehen von TrueCrypt 7.0a, da dieses Kommando root-rechte benötigt und ein Angreifer mit den Rechten des Administrators auf einem System mit geöffnetem TrueCrypt-Container sowieso die Sicherheit vollständig kompromittiert. Das zeigt jedoch erneut, wie wichtig es ist, True- Crypt nur in einer sicheren Umgebung zu verwenden. Ubuntu privacy remix wurde genau zu dem Zweck entwickelt, solch eine sichere Umgebung zur Verfügung zu stellen. TrueCrypt-Container und versteckte Volumen TrueCrypt kann einen Container sowohl als Datei, wie auch direkt ohne Umweg auf einer Partition oder einem Datenträger als ganzes anlegen. Die letztere Option hat den Vorteil, dass sie den Speicherplatz auf dem Datenträger besser ausnutzt, weil keine Verwaltungsinformationen eines Dateisystems außerhalb des Containers Platz beanspruchen. Die erste Option hat dagegen den Vorteil, dass ein Backup durch einfaches Kopieren der Container-Datei angefertigt werden kann, ohne dass der Container dazu geöffnet werden muss. Unter Ubuntu privacy remix basiert die halbautomatische Backup-Funktion auf dem Namen backup.tc, der naturgemäß auch nur bei einer Container-Datei vergeben werden kann. Als eine weitere Option bietet TrueCrypt an, ein TrueCrypt-Volumen verborgen innerhalb eines größeren TrueCrypt-Containers zu erzeugen. Das geht sowohl für Container-Dateien wie auch für Container, die auf einer ganzen Partition oder einem Datenträger als ganzes angelegt wurden. Ob man ein solches hidden TrueCrypt Volume erzeugen möchte, wird als Auswahl im zweiten Fenster nach dem Klick auf Create Volume abgefragt. Ab Version 6.0 wird ein zweiter 64 Kilobyte großer Header für das verborgene Volumen direkt hinter dem ersten Header abgelegt. Wenn kein verborgenes Volumen in einem Container angelegt wurde, so wird dieser zweite Header stattdessen mit Zufallswerten gefüllt. Der Header des versteckten Volumens enthält unter anderem die Angabe des Beginns und der Größe des versteckten Volumens. Davor befinden sich dann noch Dateien, die in dem äußeren Container gespeichert wurden. Welcher Container, der äußere oder der innere, von TrueCrypt geöffnet wird, hängt dann immer davon ab, welche der beiden verschiedenen Passwörter eingegeben wurde. Wir haben auch den Code für versteckte Volumen überprüft. Die Sicherheit der Verschlüsselung ist dafür identisch mit der für normale TrueCrypt-Container. Darüber hinaus lässt sich, soweit diese Verschlüsselung nicht gebrochen werden kann, auch nicht unterscheiden, ob sich innerhalb des äußeren Containers noch ein verstecktes Volumen verbirgt. Das gilt selbst dann, wenn das Passwort des äußeren Containers bekannt ist und dieser damit entschlüsselt werden kann. Als Zweck solcher versteckter Volumen nennt die Dokumentation von TrueCrypt, dass man in den äußeren Container einige weniger oder nur scheinbar geheime Dateien kopieren könne und jemandem, der mit Gewalt die Herausgabe des Passworts erpresst, nur die zu dem äußeren Container geben könne. Ob dies in solchen Situationen funktioniert, ist fraglich. Sinn macht dieses Feature jedoch unter rechtlichen Situationen wie in Großbritannien, wo es eine mit Strafe bewährte 11

12 Pflicht zur Übergabe von Schlüsseln und Passwörtern auf gerichtliche Anordnung hin gibt. Wie die Gerichte dort entscheiden werden, wenn staatliche Stellen die Vermutung vortragen, dass ein verborgener Container innerhalb des Containers wahrscheinlich existieren würde, bleibt abzuwarten. Der Zufallsgenerator von TrueCrypt Wie jedes gute Programm zur Verschlüsselung von Daten, benötigt auch TrueCrypt Zufallszahlen. Konkret sind dies zunächst 64 Byte für eine salt (zu deutsch Salz ) genannte zufällige Initialisierung des Verfahrens, dann zwischen 32 Byte und 96 Byte für den oder, bei mehreren hinter einander ausgeführten Chiffren, die Schlüssel des Verschlüsselungsalgorithmus und schließlich noch einmal zwischen 32 Byte und 96 Byte für den zweiten XTS-Schlüssel. Darüber hinaus füllt True- Crypt auch den Container selbst bei der Erzeugung noch mit zufälligen Werten, damit bei geöffnetem äußeren Container nicht unterschieden werden kann, ob dieser noch einen versteckten Container in seinem Inneren enthält. Diese zufälligen Werte zu erzeugen, ist die Aufgabe des in True- Crypt eingebauten Zufallsgenerators. Der Zufallsgenerator von TrueCrypt basiert auf einer Arbeit von Peter Gutmann von Er nutzt die Positionen der Maus bei Maus-Bewegungen und die genauen Zeiten von Ergeinissen wie Maus-Klicks und Benutzereingaben zur Gewinnung von Zufallswerten aus. Dies ist praktisch nicht vorhersagbar. Auf einem Linux-System werden auch immer wieder Zufallswerte hinzu gemischt, die aus den Linux eigenen Pseudo-Zufallsgeräten /dev/random und /dev/urandom gelesen werden. Bis heute sind keine funktionierenden Angriffe gegen diesen Zufallsgenerator bekannt. Allerdings zeigt eine Arbeit von Kelsey, Schneier, Wagner und Hall 10, in der ähnliche aber einfachere Designs von Zufallsgeneratoren analysiert werden, das ein solcher Angriff auch nicht undenkbar ist, wenn ein Angreifer auf dem System selbst aktiv eingreifen kann. Eine Schlussfolgerung aus dieser Analyse war die Entwicklung von Yarrow, welches eindeutig der bessere Pseudo- Zufallsgenerator ist 11. Ein aktiver Angreifer könnte auch z.b. mit den Kommandos sudo rm /dev/random /dev/urandom sudo mknod /dev/random c 1 5 sudo mknod /dev/urandom c 1 5 den Zufall aus den Linux Gerätedateien ausschalten 12. Da ein aktiver Angreifer mit diesen Rechten aber sowieso alle Möglichkeiten hat den Anwender auszuspähen, ist dies kein Einwand gegen TrueCrypt, sondern bedeutet nur, dass jegliche solche Aktivitäten eines potenziellen Angreifers durch andere Maßnahmen unterbunden werden müssen. Das erinnert uns wiederum daran, dass TrueCrypt nur in einer sicheren Umgebung sicher betrieben werden kann. Die Implementierung des Zufallsgenerators in TrueCrypt hat den Nachteil, dass sie keine Abschätzung vornimmt, wie viel echter Zufall in den verwendeten Ereignissen enthalten ist. Dadurch blockiert er nicht solange, bis etwa die Maus wieder hinreichend viel bewegt wurde, sondern rechnet einfach weiter neue scheinbar zufällige Werte aus. Auf Linux entspricht dies dem Verhalten der Gerätedatei /dev/urandom im Gegensatz zu /dev/random. Dem Anwender erspart das die Mühe langwierig fortgesetzter Maus-Bewegungen, ist aber unsicherer. Um diese Schwäche auszugleichen, empfehlen wir, dass beim Erzeugen von TrueCrypt-Containern vor dem Klick auf den Format -Button, in dem Fenster welches auch Zufallswerte anzeigt, mindestens eine Minute lang heftig die Maus bewegt werden muss. Zuvor empfehlen wir auch das Häkchen vor Show herauszunehmen. Sonst werden die ersten jeweils 13 Bytes des aktuellen Random-Pools und nach der 9 Siehe Peter Gutmann, Software Generation of Practically Strong Random Numbers, Usenix Security Symposium John Kelsey, Bruce Schneier, David Wagner und Chris Hall, Cryptanalytic Attacks on Pseudorandom Number Generators, Siehe John Kelsey, Bruce Schneier und Niels Ferguson, Yarrow-160: Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator, SAC'99, Diese Kommandos ersetzen die Gerätedateien durch eine Kopie von /dev/zero. 12

13 Erzeugung auch von Header-Schlüssel und Master-Schlüssel angezeigt. Diese Werte können als Teilinformationen für einen Angriff auf den erzeugten Container benutzt werden, wenn sie z.b. durch die Aufzeichnung der Monitorabstrahlung von einem Angreifer mit gelesen werden konnten. Das Format der TrueCrypt-Container TrueCrypt verwendet in Containern genauso wie auf komplett verschlüsselten Partitionen oder Datenträgern einen 64 Kilobyte großen Dateikopf welcher mit dem englischen Fachbegriff als Header bezeichnet wird. Im Falle versteckter Volumen innerhalb eines Containers wird ein zweiter, völlig gleich aufgebauter Header von ebenfalls 64 Kilobyte im Anschluss an den ersten gespeichert, der sonst mit Zufallswerten gefüllt wird. Ab der Version 6.0 hat TrueCrypt zudem zwei ebenfalls je 64 Kilobyte große Header mit gleichem Aufbau am Ende des Containers, die als Sicherungskopie dienen, falls einer der beiden Header am Anfang beschädigt sein sollte. Im Falle einer Systemverschlüsselung wird auf den Header für den versteckten Container und die beiden Header am Ende des Containers verzichtet. In diesem Fall hat der Header auch wie bei früheren True- Crypt-Versionen vor 6.0 nur eine Größe von 512 Byte. Die ersten 64 Bytes eines TrueCrypt-Headers sind ein zufällig gewählter so genannter Salt-Wert, der unverschlüsselt gespeichert wird. Er geht in die Ableitung des ersten Schlüssels aus dem Passwort ein und initialisiert das Verschlüsselungsverfahren. Der Rest des Headers ist mit diesem ersten Schlüssel verschlüsselt. Dadurch lassen sich ein TrueCrypt-Header, wie auch das sich an ihn anschließende Volumen, nicht von Zufallswerten unterscheiden. Die folgende Tabelle gibt die in dem Header gespeicherten Informationen wieder. Das Format und auch die Größe dieser Header wurden dreimal nach der früher von uns untersuchten Version 4.2a geändert, einmal mit Version 5.0 und dann wieder mit den Versionen 6.0 und 7.0. Die folgende Tabelle spezifiziert das Format des TrueCrypt-Headers in den Versionen 7.0 und 7.0a. Blockstart Blocklänge Bedeutung der Information 0 64 Salt (unverschlüsselt) 64 4 Konstanter Prüfwert aus den ASCII-Zeichen TRUE (verschlüsselt) 68 2 Versionsnummer (derzeit 5) des Header-Formats (verschlüsselt) 70 2 Mindestens erforderliche Versionsnummern des Programms (derzeit 7.0), das den Container öffnen kann (verschlüsselt) 72 4 CRC-32-Prüfsumme der entschlüsselten Bytes 256 bis 511 im Dateikopf (verschlüsselt) Ungenutzt, 0-Bytes (verschlüsselt) 92 8 Größe des verborgenen Volumens oder Null für nicht verborgene Volumen (verschlüsselt) Größe des Volumens (verschlüsselt) Beginn des mit dem Master-Schlüssel verschlüsselten Bereichs (verschlüsselt) Größe des mit dem Master-Schlüssel verschlüsselten Bereichs (verschlüsselt) Markierung, ob es sich um eine Systemverschlüsselung handelt (Bit 0), 13

14 Blockstart Blocklänge Bedeutung der Information und ob eine stellenweise nicht Systemverschlüsselung vorliegt (Bit 1), die weiteren Bits 2 bis 31 sind bisher ungenutzt (verschlüsselt) Sektorgröße in Bytes (verschlüsselt) Ungenutzt, 0-Bytes (verschlüsselt) CRC-32-Prüfsumme der entschlüsselten Bytes 64 bis 251 im Dateikopf (verschlüsselt) 256 Variabel 64, 128 oder 192 Master-Schlüssel und zweiter Schlüssel für den XTS-Modus hintereinander aufgefüllt mit 0-Bytes bis zu Byte 511 (verschlüsselt) Ungenutzt, bei einer Systemverschlüsselung wird dieser Teil ausgelassen. Die Linux-Version schreibt hier 0-Bytes während die Windows-Version diesen Bereich mit Zufallswerten füllt. (verschlüsselt) Wie in der Tabelle vermerkt, füllt die Windows-Version von TrueCrypt 7.0a abweichend von der Linux-Version den Byte großen Bereich ab Byte 512 in jedem der vier Header mit Zufallswerten. Das ist ein Problem für die Überprüfung, weil es keine Möglichkeit gibt zu unterscheiden, ob es sich hier wirklich um Zufallswerte handelt oder ob darin ein Zweitschlüssel zum Container als Hintertür (z.b. für einen Geheimdienst) abgelegt wurde. Der veröffentlichte Quellcode der Windows-Version schreibt hier tatsächlich Zufallswerte hinein und legt somit keine Hintertür an. Vom Standpunkt der Wartbarkeit aber auch der Lesbarkeit des Quellcodes ist diese Duplikation eines Teils des Codes mit kleinen Abweichungen ein großes Ärgernis. Denkbar ist, dass die veröffentlichte ausführbare TrueCrypt-Exe-Datei aus einem von dem in TrueCrypt 7.0a Source.zip veröffentlichten Quellcode abweichenden Code erzeugt wurde und diesen Bereich des Headers als Hintertür benutzt. Die Linux-Version hat dieses Problem an dieser Stelle nicht, weil die Entschlüsselung zu 0-Bytes beweist, dass hier kein Zweitschlüssel verborgen ist. Prinzipiell könnte ein Zweitschlüssel auch im Salt-Wert verborgen werden, was auch die Linux-Version beträfe. Die 64 Bytes des Salt-Wertes würden reichen, um den Master-Schlüssel und den XTS-Schlüssel bei Verschlüsselung mit einer einfachen Chiffre, mit einem zweiten dem Hersteller der ausführbaren Programme bekanntem Passwort verschlüsselt abzuspeichern. Bei einer Kombination von zwei oder drei Chiffren reichen sie für die Schlüssel der zweiten und dritten Chiffre nicht mehr, dann können aber die Salt-Bytes des Backup-Headers hinzugenommen werden. Vor einer solchen möglichen Hintertür schützt man sich aber am besten dadurch, dass man den überprüften Quellcode selbst compiliert und nur die so erstellten Programme dann auch verwendet. Wir haben die SHA1- und MD5-Fingerabdrücke des von uns untersuchten Quellcodes aus diesem Grund in Abschnitt 1 angegeben. Damit kann dann überprüft werden, dass der von herunter geladene Quellcode mit dem von uns analysierten Quellcode identisch ist. Diese Überprüfung kann auf einem Linux-System durch Anwendung von md5sum oder sha1sum auf die Archive und Vergleich mit den von uns angegebenen Fingerabdrücken geschehen. Im Falle einer Systemverschlüsselung gibt es nur einen 512 Byte großen Header, der nicht in der Systempartition selbst sondern im letzten Sektor vor der ersten Partition gespeichert wird (das ist meistens Sektor 62 der Festplatte in einer bei 0 beginnenden Zählung der Sektoren). In diesem Fall werden nur die ersten 512 Bytes der obigen Tabelle in diesen Sektor geschrieben. Die anderen drei Header fehlen im Falle einer einfachen Systemverschlüsselung auch. 14

15 7. Ein Angriff auf TrueCrypt Schlüssel-Dateien Der TrueCrypt Schlüssel-Datei-Algorithmus Die so genannten Keyfiles oder zu deutsch Schlüssel-Dateien von TrueCrypt sind als Ergänzung oder, wenn man ein leeres Passwort angibt, Ersatz des Passwortes gedacht. TrueCrypt wendet einen hausgemachten Algorithmus 13 auf den Inhalt der ausgewählten Datei oder auch mehrerer Dateien an um damit das eingegebene Passwort zu modifizieren. Ein Einwand gegen die Verwendung von Schlüssel-Dateien ist der folgende: Eine solche Datei muss irgendwo gespeichert sein. Ein Angreifer, der Zugriff auf den verschlüsselten Container erlangt kann in der Regel auf die gleiche Art auch auf andere gespeicherte Dateien der selben Person zugreifen. Eine Ausnahme von diesem Einwand mag die Speicherung der Schlüssel-Datei auf einer PKCS-11 konformen Chipkarte sein, die durch eine PIN gesichert ist. Alle möglichen Dateien als Schlüssel-Dateien durch zu probieren, ist für moderne Computer kein Problem auch wenn es Millionen sind. Wenn der Betroffene dann in dem falschen Bewusstsein, mit der Schlüssel-Datei ein weiteres Geheimnis zu haben, sein Passwort entsprechend schwächer gewählt hat oder gar ein leeres angegeben hat, ist der Schlüssel zu seinem Container schnell geknackt. Nach unserer Kenntnis ist der Algorithmus der TrueCrypt Schlüssel-Dateien bisher noch nie kryptographisch analysiert worden. In dem Algorithmus werden die Zwischenzustände der Verarbeitung einer Schlüssel-Datei Byte für Byte mit einem CRC-32-Algorithmus 14 zu aufeinander folgenden Bytes eines Pools modulo 2 8 =256 addiert. Immer wenn dabei das letzte Byte des Pools erreicht wurde, wird der Vorgang weiter am Anfang des Pools fortgesetzt. Am Ende der Verarbeitung einer Schlüssel-Datei wird schließlich der Pool mittels ein exklusiven Oder-Operation (XOR) mit dem Passwort verknüpft wird. Aufgrund dieser Tatsache können wir schließen, dass die durch das Passwort selbst gegebene Sicherheit durch zusätzliche Schlüssel-Dateien nicht geschwächt wird, denn die Änderung eines beliebigen Bits des Passwortes ändert auch das Ergebnis. Auf der anderen Seite wird die Sicherheit damit aber auch nicht in jedem Fall verstärkt, wie unser unten dargelegter Angriff beweisen wird. Es ist allgemein bekannt, dass der CRC-32-Algorithmus keinen kryptographischen Ansprüchen genügt, wie sie an einen Hash-Algoithmus gestellt werden. Darum kann auch von diesem Schlüssel-Datei-Algorithmus keine kryptographische Sicherheit erwartet werden. Tatsächlich haben wir einen Angriff entdeckt, mit dem beliebige Dateien so manipuliert werden können, dass sie keinerlei Effekt haben, wenn sie als Schlüssel-Datei verwendet werden. Dazu müssen wir lediglich zwischen 1524 und 2804 Bytes am Ende der Datei anfügen. Es gibt viele Anwendungsprogramme, die sich an den zusätzlichen Bytes am Ende nicht stören und den Inhalt der Datei genau so anzeigen, wie er ohne diese Bytes war. Das gilt insbesondere für Bildbetrachter und Bilddateien (z.b..jpg und.png Dateien) und für PDF-Leseprogramme (wie etwa der Adobe Acrobat Reader oder Evince) und PDF-Dokumente. Die Manipulation von TrueCrypt Schlüssel-Dateien In unserem Angriff wird eine beliebige Datei so manipuliert, dass sie keinerlei Effekt mehr hat, wenn sie beim Erzeugen eines neuen TrueCrypt-Containers als Schlüssel-Datei hinzugefügt wird. Der Container kann anschließend genauso ohne wie mit dieser Schlüssel-Datei geöffnet werden, in beiden Fällen mit dem gleichen Passwort. Umgekehrt kann ein Container, der ohne Schlüssel- Dateien erzeugt wurde, auch mit dieser Datei als Schlüssel-Datei geöffnet werden. Wenn mehrere verschiedene solche manipulierten Schlüssel-Dateien beim Erzeugen eines Containers hinzugefügt wurden, so können einige davon oder auch alle diese Schlüssel-Dateien beim Öffnen wegge- 13 Siehe für eine detaillierte Beschreibung des Algorithmus. Die Dokumentation ist jedoch in einer Hinsicht falsch. Sie spricht von der Anwendung eines Hash-Algorithmus, wo im Code jedoch nur ein zyklischer Redundanz Code (CRC-32) angewendet wird. 14 Der hier benutzte CRC-32-Algorithmus ist der des Standards IEEE802.3 welcher auch bei Ethernet-Transmissionen benutzt wird. 15

16 lassen werden. Ein Angreifer mit üblen Absichten könnte viele solche manipulierten Dateien an Stellen ablegen, von wo er hofft, dass sein Opfer seine Schlüssel-Dateien auswählt. Eine alternative Angriffslinie wäre die Verbreitung eines Trojanischen Pferdes, welches insgeheim alle Dateien, die der Angegriffene damit bearbeitet, entsprechend manipuliert. Als Demonstration unseres Angriffs haben wir die PDF-Datei dieses Dokuments dem Angriff entsprechend modifiziert. Ebenso haben wir auch die englische Version dieses Dokuments verändert. Mit einem Programm zur Anzeige von PDF-Dokumenten geöffnet wird der Inhalt dieser Dokumente so dargestellt, wie wir ihn geschrieben haben. Zur Verifikation des Angriffs kann man jedoch eines oder auch beide Versionen dieses Dokuments als Schlüssel-Dateien zu einem neuen Container hinzufügen. Er lässt sich dann anschließend auch ohne diese Schlüssel-Dateien öffnen. Der erste Schritt in unserem Angriff besteht darin, die CRC-32-Prüfsumme der zu manipulierenden Datei am Ende an diese Datei anzuhängen. Es ist eine spezielle Eigenheit des CRC-32-Algorithmus, dass die CRC-32-Prüfsumme dieser Verkettung Null ist. Diese Eigenheit ist allgemein bekannt und wird üblicherweise in der Überprüfung von CRC-32-Prüfsummen ausgenutzt. Für den Schlüssel-Datei-Algorithmus von TrueCrypt bedeutet dies, dass der Zwischenzustand des CRC- 32-Algorithmus nach der Verarbeitung der ursprünglichen Datei und der vier angehängten Bytes Null wird. Für unseren Angriff hat das den Vorteil, dass er danach mit einer immer gleichen und einfachen Ausgangslage starten kann. In der Entwicklung unseres Angriffs haben wir zuerst die 256 Folgen von je fünf Bytes berechnet, die einen CRC-32-Zustand von Null nach dem fünften Byte liefern, wenn der Zustand vor der Verarbeitung der Folge Null war 15. Eine beliebige Folge von fünf Bytes würde 20 Bytes des Pools verändern, dank der speziellen Eigenart dieser Folgen verändern sie jedoch nur 10 Bytes des Pools mit nur vier verschiedenen Additionen, wenn der CRC-32-Zustand vorher Null war. Da die Addition zum ersten Byte nach der augenblicklichen Position im Pool für diese 256 Folgen alle möglichen Werte annimmt, kann dieses Byte zu Null gemacht werden, indem diejenige Folge an die Datei angehängt wird, die das Komplement des Pool-Bytes modulo 256 als Summand hat. Nach dieser Operation hat sich die Position im Pool 20 Bytes vorwärts verschoben. Eventuell, wenn dabei zwischenzeitlich das Ende des Pools erreicht wurde, wurde die Verschiebung am Anfang des Pools fortgesetzt. Somit kann die Operation jetzt für das Byte an der neuen Position im Pool wiederholt werden. Dank der speziellen Eigenart der Folgen, die nur 10 statt 20 Bytes im Pool verändern, wird das zuvor veränderte Byte nie wieder durch solche Operationen geändert die an anderen Positionen im Pool vorgenommen werden. Nach 16 solcher Operationen ist man wieder zur ursprünglichen Position im Pool zurückgekehrt und hat 16 der 64 Bytes des Pools zu Null gemacht. Dafür wurden weitere 80 Bytes an die Datei angehängt. Um weitere Bytes des Pools zu Null machen zu können, ohne die Bytes wieder zu verändern, die inzwischen Null sind, haben wir als nächstes Paare der fünf Byte langen Folgen gebildet, die zusammen Null zum ersten Byte des Pools nach der augenblicklichen Position addieren. Diese Paare haben wir nach dem Wert sortiert, den die Folgen zusammen zum zweiten Byte nach der augenblicklichen Position addieren. Nachdem wir noch Paare entfernt hatte, die nur ein Duplikat dieses Wertes eines anderen Paares lieferten, blieben 44 Paare über. Wenn ein Byte im Pool das Komplement eines dieser 44 Werte ist kann es zu Null gemacht werden, indem zuerst die erste Folge des Paares an die Datei angehängt wird und nach 15 anderen solchen Operationen, wenn man wieder zurück an der selben Position im Pool ist, die zweite Folge des Paares. Wenn ein Byte im Pool kein Komplement eines dieser 44 Werte ist können wir es zu Null machen, indem wir zwei oder in seltenen Fällen auch drei dieser Werte auf diese Weise zu dem Byte addieren. In der Praxis mussten wir so in diesem Schritt zwischen 320 und 480 Bytes an die Datei anhängen. Damit wurde erreicht, dass nach diesem Schritt 32 der 64 Pool-Bytes Null sind. Im nächsten Schritt haben wir Tripel unserer fünf Byte langen Folgen berechnet, die in der Summe Null sowohl zum ersten wie zum zweiten Byte nach der augenblicklichen Position im Pool addie- 15 Als binäre Polynome betrachtet wie es im CRC-32-Algorithmus vorgesehen ist sind diese Folgen genau die binären Polynome mit einem Grad kleiner als 40, die ein Vielfaches des CRC-32-Polynoms x 32 x 26 x 23 x 22 x 16 x 12 x 11 x 10 x 8 x 7 x 5 x 4 x 2 x 1 sind. 16

17 ren. Diese haben wir nach dem Wert, den sie zum dritten Byte im Pool addieren sortiert und wiederum Tripel, die nur Duplikate in diesem Wert beisteuern, aussortiert. Es blieben 19 solche Tripel über. In diesem Schritt benötigten wir zwei bis vier solche Tripel um eines der noch verbleibenden von Null verschiedenen Bytes des Pools zu Null zu machen. So sind in diesem Schritt zwischen 480 und 960 Bytes an die Datei anzuhängen. Danach sind dann 48 der 64 Pool-Bytes Null. Um schließlich die letzten 16 Pool-Bytes zu Null zu machen haben wir Quadrupel der fünf Byte langen Folgen berechnet, die in der Summe Null zum ersten, zweiten und dritten Byte des Pools nach der augenblicklichen Position addieren. Nachdem sie nach dem Wert sortiert wurden, den sie in der Summe zum vierten Byte des Pools addieren und wiederum Duplikate aussortiert wurden, blieben abermals 19 Quadrupel über. Wir benötigten dann wieder zwischen zwei und vier Quadrupel um ein weiteres Byte des Pools zu Null zu machen. So sind im letzten Schritt noch einmal zwischen 640 und 1280 Bytes an die Datei anzuhängen. Danach ist dann der gesamte Pool Null. Da ein Pool, der nur aus Nullen besteht, in der exklusiven Oder-Verknüpfung (XOR) mit dem Passwort das Passwort nicht verändert, haben wir unser Ziel erreicht. Zusammenfassend ist festzustellen, dass zwischen 1524 und 2804 an eine Datei angehängte Bytes ausreichen, um ihren Effekt als Schlüssel-Datei zu annullieren. Es waren drei hauptsächliche Schwächen des Schlüssel-Datei-Algorithmus von TrueCrypt, die unseren Angriff ermöglicht haben. Die erste Schwäche besteht in der Verwendung des kryptographisch unsicheren CRC-32-Algorithmus. Seine Eingaben können leicht so zurecht gebastelt werden, dass jede beliebige gewünschte Ausgabe erzeugt wird. Die zweite Schwäche ist die Linearität der Operationen, nämlich die Additionen, durch die die Bytes des Pools geändert werden. Das machte den Angriff zu einer einfachen Anwendung linearer Algebra. Die dritte Schwäche ist die lokale Natur der Änderungen am Pool. Jedes Byte der Schlüssel-Datei ändert nur vier Bytes des Pools. Das ermöglichte es die Bytes des Pools eins nach dem anderen zu Null zu machen. Wenn die Entwickler der TrueCrypt-Foundation Schlüssel-Dateien nicht ganz aufgeben wollen, würden wir das HMAC-Verfahren basierend auf SHA-512 oder Whirlpool mit dem Passwort als Schlüssel und der gesamten Schlüssel-Datei als Nachricht für den Schlüssel-Datei-Algorithmus empfehlen. Wenn mehrere Schlüssel-Dateien ausgewählt werden können die Resultate dieser Operationen mit der exklusiven Oder-Operation (XOR) miteinander verknüpft werden. Das endgültige Resultat kann dann wie bisher in den Algorithmus zur Ableitung des Schlüssels aus dem Passwort eingegeben werden. Eine weitere Bemerkung ist hier angebracht. Man darf sich nicht sicher fühlen, wenn die ausgewählte Schlüssel-Datei tatsächlich einen Effekt hat, also wenn der Container nicht ohne sie geöffnet werden kann. Unser Angriff könnte leicht auch so modifiziert werden, dass er eine ganz bestimmte Änderung am Passwort verursacht, die dem Angreifer aber nicht dem Opfer bekannt ist. Wir veröffentlichen das für diesen Angriff erstellte Programm bzw. seinen Quellcode nicht, weil wir solche realen Angriffe nicht unterstützen wollen. Reaktion der TrueCrypt-Entwickler auf den Angriff Wir haben einen Fehlerbericht bezüglich des Angriffs über das Formular auf der TrueCrypt Webseite an die TrueCrypt Entwickler geschickt. Am selben Tag noch erhielten wir die folgende Antwort: Hallo, zuerst danke für die Überprüfung unserer Software wir schätzen und begrüßen unabhängige Überprüfungen sehr. Es ist zu bemerken, dass wir uns, als wir den Schlüssel- Datei-Algorithmus entworfen haben, der in dem Dokument erwähnten Eigenschaften des CRC-32-Algorithmus wohl bewusst waren. Es folgt unsere Antwort auf den Angriff, den Ihr uns berichtet habt: Unabhängig davon welcher Schlüssel-Datei-Algorithmus verwendet wird kann ein Angreifer, wenn er die Schlüssel-Datei modifizieren kann, die bei der Erzeugung des 17

18 Containers verwendet wird, die Entropie/Stärke der Schlüssel-Datei reduzieren. Genauso wie man einem Angreifer nicht erlauben kann, das eigene Passwort zu bearbeiten oder zu modifizieren, kann man ihm auch nicht erlauben die Schlüssel-Datei zu bearbeiten oder zu modifizieren bevor man den Container damit erzeugt. Andernfalls kann man vernünftigerweise nicht erwarten irgendeine Sicherheit zu haben. Es ist eine grundlegende Anforderung an kryptographische Schlüssel (ob Passworte, Schlüssel-Dateien oder Master-Schlüssel), dass sie geheim und dem Angreifer unbekannt sind. Euer Angriff verletzt diese Anforderung und ist deshalb ungültig/schwindel. Das gilt gleichermaßen ob man einen CRC-32-Algorithmus oder HMAC-SHA-512, ob man den TrueCrypt Schlüssel-Datei-Algorithmus oder etwas anderes verwendet. Danke abermals, dass Ihr Euch die Zeit genommen habt, unsere Software zu überprüfen. Wir hoffen, dass die Fehler berichtigt werden bevor die Überprüfung veröffentlicht wird (die Veröffentlichung eines ungültigen Angriffs wäre irreführend). Hochachtungsvoll David PS Sogar wenn der Angriff gültig wäre (er ist es nicht) und ein kryptographisch sicherer Hash (wie z.b. HMAC-SHA-512) anstatt des CRC-32-Algorithmus (Euer Vorschlag) benutzt würde, wäre der Angreifer immer noch in der Lage die Schlüssel-Datei zu knacken durch einen vergleichsweise kurzen Angriff mit roher Gewalt (dies wäre nur unwesentlich langsamer weil der Angreifer nur die richtige Schlüssel-Datei unter den Tausenden oder Millionen Schlüssel-Dateien finden müsste, die er gebastelt hat). (eigene Übersetzung) Diese Antwort ist ein Irrtum. Darin wird nicht unterschieden zwischen der unbedingt notwendigen Geheimhaltung des Passwortes und der Schlüssel-Datei und der Unmöglichkeit, dass ein Angreifer Passwort oder Schlüssel-Datei verändern kann. Die Geheimhaltung von Passwort und Schlüssel- Datei ist in der Tat eine grundlegende Voraussetzung für die Sicherheit eines TrueCrypt-Containers wie sie es in jeder anderen kryptographischen Anwendung auch ist. Es ist jedoch gut möglich, dass ein Angreifer eine Schlüssel-Datei in einem gewissen Grade modifizieren kann während gleichzeitig diese Schlüssel-Datei vollständig geheim und ihm unbekannt bleibt. Der Punkt, der hier in Betrachtung kommt, ist, dass die Kryptographie sehr wohl Mittel hat, auch in einer solchen sonderbaren Situation Sicherheit zu bieten. Als ein Beispiel einer solchen Situation kann man sich einen Angreifer vorstellen, der eine Bildbearbeitungssoftware vertreibt. Er könnte unseren Algorithmus für den Angriff in seine Software einbauen, so dass sie jedes Bild, welches sie bearbeitet, so manipuliert, dass es als TrueCrypt Schlüssel-Datei keinen Effekt hat. Unser Algorithmus ist sogar klein genug, dass er in kleineren Geräten wie beispielsweise einer digitalen Kamera laufen kann. So könnte auch eine digitale Kamera alle Bilder die sie schießt entsprechend bearbeiten und manipulierte Bilddateien ausgeben. Die Bilder würden trotzdem zeigen was der Anwender wollte und blieben dem Hersteller der Kamera oder der Bildbearbeitungssoftware unbekannt. Sie können also geheim gehalten werden obwohl sie von einem Angreifer modifiziert wurden. In dieser Situation würde ein Schlüssel-Datei-Algorithmus, der auf HMAC-SHA-512 basiert, perfekte Sicherheit bieten während der TrueCrypt Schlüssel-Datei-Algorithmus komplett versagt. Ein Angriff mit roher Gewalt 16 ist hier unmöglich, weil der Angreifer nicht nur zwischen Millionen Schlüssel-Dateien, die er gebastelt hat, den richtigen finden muss, sondern die Auswahl zwischen einer praktisch unendlichen Zahl möglicher Bilder zu treffen ist, die mit der Kamera aufgenommen worden oder mit der Bildbearbeitungssoftware bearbeitet sein können. Ein anderes Szenario, wo die Argumentation der TrueCrypt Entwickler nicht anwendbar ist, ist ein Offline-Sicherheitssystem wie Ubuntu privacy remix. Es wurde speziell entworfen um die Geheimhaltung von Dateien, die damit bearbeitet werden, zu schützen. Das heißt, dass es für einen 16 Der englische Fachausdruck dafür ist brute force attack. 18

19 Angreifer schwierig ist, Zugriff auf Dateien zu erlangen, die innerhalb des Systems bearbeitet wurden. Es ist jedoch nicht so schwierig, den Nutzer zu veranlassen, Dateien in das System einzubringen. Darum sollte ein Verschlüsselungsprogramm innerhalb des Systems sich besonders gegen Manipulationen wie den obigen Angriff schützen. 8. Schlussfolgerungen TrueCrypt in der Version 7.0a ist ein sehr sicheres Programm zur Verschlüsselung von Containern auf dem aktuellen Stand der wissenschaftlichen Forschung. In dem veröffentlichten Quellcode waren keine sicherheitsrelevanten Fehler oder Hintertüren zu entdecken mit Ausnahme unseres Angriffs auf die Schlüssel-Dateien. Wenn man dieses Programm in einer sicheren Umgebung wie Ubuntu privacy remix einsetzt, kann man mit hoher Sicherheit davon ausgehen, dass niemand an die damit verschlüsselten Daten in den Containern herankommt, sofern die Container geschlossen sind, das verwendete Passwort nicht zu schwach ist und der Angreifer nicht sehr fortgeschrittene Methoden unterhalb der Ebene des Betriebssystems wie BIOS-Rootkits, Hardware-Keylogger oder Video-Überwachung anwendet. Ein grundsätzliches Problem besteht bezüglich der Überprüfung der auf der TrueCrypt-Webseite veröffentlichten Binärpakete. Ohne ein extrem aufwendiges sogenanntes reverse engineering kann nicht festgestellt werden, ob diese Binärpakete tatsächlich aus dem veröffentlichten Quellcode erzeugt wurden oder in Teilen etwas anderes machen. So kann nicht ausgeschlossen werden, dass diese Binärpakete eine Hintertür enthalten, die im veröffentlichten Quellcode nicht vorhanden ist. Eine solche Hintertür könnte darin bestehen, dass die im Dateikopf eines TrueCrypt- Containers notwendigerweise vorhandenen Zufallswerte durch eine Zweitverschlüsselung des Master-Schlüssels zum Container ersetzt werden. Das lässt sich auch mit unserem Analyseprogramm tcanalyzer anhand des erzeugten Containers nicht mehr feststellen. Aus diesem Grunde empfehlen wir, TrueCrypt selbst aus dem Quellcode zu erzeugen, um kein blindes Vertrauen in die TrueCrypt-Foundation setzen zu müssen. Im Abschnitt 3 haben wir detailliert beschrieben wie das bewerkstelligt werden kann. Aus der Untersuchung in den Abschnitten 6 und 7 können die folgenden Schlussfolgerungen für die Arbeit mit TrueCrypt gezogen werden. Die Begründung hierzu findet sich ebenfalls in den genannten Abschnitten. Alle Hash- und Verschlüsselungsverfahren von TrueCrypt sind gut. Wenn die Schnelligkeit des Rechners das zulässt, kann eine Kombination wie Serpent-AES die Sicherheit erhöhen, erweist sich ein Rechner dafür zu langsam, so kann z.b. AES alleine verwendet werden; für das Hash-Verfahren ist SHA-512 eine gute Wahl, jede andere Wahl des Hash-Verfahrens ist aber auch in Ordnung. Alte TrueCrypt-Container, die mit einer Version vor 5.0 erzeugt wurden, sollten durch neue mit TrueCrypt 7.0a erzeugte Container ersetzt und die alten Container nach der Sicherung ihres Inhalts in die neuen Container gelöscht werden. Die sogenannten Keyfiles, zu deutsch Schlüssel-Dateien, sind unsicher. Sie schwächen zwar nicht die Sicherheit des zusammen mit ihnen verwendeten Passwortes, wenn dieses jedoch schwach oder gar leer gewählt wurde, sind die Daten im Container nicht mehr sicher. Versteckte Volumen sind sicher. Ein Angreifer hat keine Möglichkeit zu entscheiden, ob sich in einem TrueCrypt-Container noch ein verstecktes Volumen verbirgt. Dies gilt selbst dann, wenn ihm das Passwort des äußeren Containers enthüllt wird. Wir empfehlen, dass beim Erzeugen eines Containers im letzten Fenster vor dem Klick auf den Format -Button das Häkchen vor Show herausgenommen wird und mindestens eine Minute lang heftig die Maus bewegt wird. 19