EINSTUFUNG WURDE AUFGEHOBEN 'J& 'J& NYR FÜR DEN DIENSiTSEBRJI,UCiol NUR FÜR DEN DIENSTSEBRAYSI-I Historie Untersuchung TrueCrypt Arbeitspaket 5 Prüfungen Seite 1 von 114 1 12010 Seite 2 von 114 I 12010

VS vs NIJR FYR 9EN 91ENS:C:CE8RAIJCH Inhaltsverzeichnis 1 Algorithmische Implementierungen {AP5.1) ...............................................................6 1.1 Methodik und Vorgehensweise ...........................................................................6 1.2 Voraussetzungen und Annahmen .......................................................................? 1.3 Analyse AES .......................................................................................................7 1.3.1 C-lmplementierung ....... ;.............................................. - .............................. 8 1.3.2 x86 CPU Assemblerimplementierung ........................................................11 1.3.3 x64 CPU Assemblerimplementierung ................... :...............................,... ,ll 1.3.4 AES-NI Assemblerimplementierung ....................; ..................... :............... 12 1.3.5 Unterschiede bei Bootloader-lmplementierung ......................................... 12 1.3.6 C sinalllmplementierung ...........................................................................13 1.3.7 x86 Assemblersmall Assemblerimplementierung .....................................13 1.4 Übersetzung des AES-Codes ...... :.........................................................; .......... 14 1.5 Bewertung AES .................................................................................................14 1.5.1 Standardkonformität. .......................................... :.......... ·........• :.................. 14 1.5.2 Geschwindigkeit. ....................., ..................................................................15 1.5.3 Vertrauenswürdigkeit.. ......... ...,:.................... ............................................. 15 1.5.4 Sicherheitsaspekte .....................................................................................15 1.5.5 Empfehlung .................................................................-........ ....................... 15 1.6 Analyse XTS Encryption Mode .................................... ,.... ,............................... 15 1.6.1 Standardkonformität. ........... :..................................................................... 16 1.6.2 Korrektheit der lmplementierung ....... ~ ......................................................,17 1.6.3 Sicherheltsaspekte ...................................................................................... 17 1.6.4 Geschwindigkeit~ ........................................................................................18 1.7 Analyse Hashfunktionen ...................................................................................-19 . L7.1 SHA-512 ...................................................................................-.......... ~ ...... 19 1.7.2 RIP!::MD-160..............................................................................................21 1.7.3 SHA-512 für Full Disk Encryption ...................,....... ~ ... ;..............................22 1.8 Tests der Algorithmen ...... .-.............................................................·.................... 22 1.8.1 Test AES ........ :... :... .- ........................................................................,.......... 22 1.8.2 Test XTS ....................................................................................................23 1.8.3 Test SHA-512 ............................................................................................23 1.8.4 Test RIPEMD-160 ......................................................................................23 2 Schutz von Schlüsselmaterial {AP5.2) ..............................................................:...... 24 2.1 Methodik und Vorgehensweise .........................................................................24 ·2.2 Voraussetzungen und Annahmen .........................................................;........... 24 2.3 Analysiertes Schlüsselmaterial .........................................................................25 2.4 Analyse der Verarbeitung von Schlüsselmaterial .................................. :.......... 25 2.5 Analyse Schlüsselv~rarbeitung Linux ......................... :...................................... 26 2.5.1 Zusammenfassung und Gesamtbewertung Linux .....................................43 2.6 Analyse Schlüsselverarbeitung Windows .........................................................44 2.6.1 Zusammenfassung und Gesamtbewertung Windows .....................:.........73 2.7 Analyse der Speicherung von Schlüsselmaterial im RAM ................................73 2.7.1 Datenhaltung während des Programmablaufs ..........................................73 2.7.2 Datenhaltung während Suspend-To-RAM und Suspend-To-Disk ....... : ....74 2.8 Analyse der veränderungssicheren Schlüsselspeicherung ..............................74 S1111le 3 von 114 1 12010 NIJR FYR 9EN 91ENS:C:CE8RAIJCH 3 Quellen für Schlüsselmateriai/Zufallszahlengenerator {AP5.3) ............................... 76 3.1 Methodik und Vorgehensweise .... : ......................................,.............................76 3.2 Voraussetzungen und Annahmen ............................................................~ ........76 3.3 Analyse .....................................................................................................:........ 76 3.3.1 Nutzung vOn Zufallsmaterial ......................................................................76 3.3.2 Unterscheidung Benutzer- und Serverbetrieb ...........................................78 3.4 Analyse des Zufallszahlengenerator Linux...............................................:....... 78 3.4.1 Start und Stop des Entropiepool.. ..............................................................78 3.4.2 Hinzufügen von Entropie ........................................................................... 78 3.4.3 Mischfunktion .... :....................................................................................... ;. 79 3.4.4 Entropiequelle Betriebssystem ..................................................................BO 3.4.5 Entropiequelle Benutzer ....................................................................; ....... 81 3.4.6 Zufallsdaten aus dem Pool extrahieren .....................................................81 3.4.7 Hineinschauen in den Pool .................................................:...................... 83 3.4.8 Test der Daten aus dem Zufallsdatengenerator ........................................ 83 3.5 Analyse des Zufallszahlengenerator Windows .................................................83 3.5.1 Start und Stopp des Entropiepooi ..............................................................B3 3.5.2 Mischfunktion ..............................................................................................83. 3.5.3 Hinzufügen von Entropie ....................................................... .-................... 84 3.5.4 Entropiequellen ..........................................................................................84 3.5.5 Zufallsdaten aus dem Pool extrahieren .....................................................86 3.5.6 Hineinschauen in den Pool ...................................... ,.................................86 3.5.7 Test der Daten aus dem Zufallsdatengenerator ........................................ 86 3.6 Hinzufügen zusätzlicher Entropiequellen ...........................:..............................86 4 Algorithmische Darstellung verwendeter Algorithmen ............................................. 87 4.1 Definitionen .......................................................................................................87 4.1.1 Definitionen aus Standards ...................-.....................................................87 4.1.2 Weitere Definitionen ..................................................................................87 4.1.3 Funktion lenQ .............................................................................................88 4.1.4 Funktion readfileQ ......................................................................................88 4.1.5 Funktion filesizeQ .......................................................................................88 4.1.6 Funktion invQ ............................................. ,............................................... 88 4.1.7 Funktion HMAC_RMD160Q ......................................................................:88 4.1.8 Funktion HMAC_SHA512Q ..................... ;............ .-... .-.................................89 4.2 Zutallszahlengenerator..........................................................................:........... 89 4.2.1 Start des RNG ............................................................................................89 4.2.2 Mischen des Entropiepools ........................................................................90 4.2.3 HinzufOgen von Daten zum EntropiepooL ................................................91 4.2.4 Hinzufügen von Entropie ...........................................................................91 4.2.5 Extrahieren von Zufallsdaten aus dem Entropiepool.. ........................... ,...91 4.3 Header-Verarbeitung .........................................................................................92 4.3.1 Erzeugung eines Header-Passworts .........................................................92 4.3.2 Anwenden eines Keyfiles ...........................................................................92 4.3.3 Generierung eines neuen Headers ...........................................................93 4.3.4 Generierung eines Headers .. ; ....................................................................93 4.3.5 Öffnen eines Headers ................................................................................94 4.3.6 Erstellen eines Backup-Headers ...............................................................94 Selta 4 von lU I I 2.010

IJ.S NYR FYR 9!;N 91ENSTG!;BRAYCiol VS 4.4 Verschlüsseln und Entschlüsseln von Daten ....................................................95 4.4.1 Verschlüsseln von Daten ...........................................................................95 4.4.2 Entschlüsseln von Daten ...........................................................................95 4.5 Pseudozufallszahlengenerator ........ :.: ............................................:..................95 5 Makroexpansion .......................................................................................................97 6 Schlüsselverarbeitende·Funktionen Linux ...............................................................99 7 Ergebnisse Zufallszahlentest. ................................................................................ 103 7.1 Linux.................................................................................................................103 7.2 Windows ..............;...........................................................................................106 NYR FYR 9EN 91ENSTGEBRAYCiol 1 Algorithmische Implementierungen (AP5.1) TrueCrypt unterstützt in Kryptografiekomponenten: der vorliegenden Version 7.0a die folgenden Symmetrische Chiffren - AES mit 256 Bit Schlüsseln - Blowfish mit 448 Bit Schlüsseln - CAST-256 mit 128 Bit Schlüsseln - 3DESfTDEA mit 168 Bit Schlüsseln - TWOFISH mit 256 Bit Schlüsseln - SERPENT mit 256 Bit Schlüsseln Betriebsmodi - XTS - LRW - CBC Hash Funktionen - RIPEMD mit 160 Bit Digest Länge - SHA1 mit 160 Bit Digest Länge - SHA2 mit 512 Bit Digest Länge - Whirlpool mit 512 Blt Digest Länge Der Schwerpunkt der Prüfung .liegt bei AES-256, XTS und SHA-512. Zusätzlich wird RIPEMD-160 untersucht, . da diese Hashfunktion derzeit noch für die Fuii-Disk- Encryption unter Windows benötigt wird. Andere Algorithmen .werden nicht nicht behandelt. .1.1 Methodik und Vorgehensweise Bei der Analyse wird zunächst die ErfOIIurig der Standards analysiert. Hierfür werden zuerst die fOr die jeweiHgen Algorithm.en notwendigen Standards und Dokumente identifiziert. Anschließend wird durch Analyse gemäß der im Folgenden aufgezeigten Punkte kontrolliert, ob der Quelltext die spezifizierten Algorithmen umsetzt Hierbei wurden die Quelltexte zeilenweise analysiert und die Funktionalität jeder Zeile auf den Algorithmus im Standard bzw. einer alternativen Darstellung (s. [1 ], Absch. 7) abgebildet. Insbesondere wurden die funktionalen Blöcke der (AES: SubBytesQ, ShiftRowsQ, MixColumnsQ, Algorithmen identifiziert AddRoundKeyQ und die Key Expansion; XTS: Aufteilung in Sektoren und AES- Biöcke, Tweakerzeugung, Multiplikation in GF(2128}, Verschlüsselung; SHA-512 und RIPEMD-160: lnitialislerung, Vorverarbeitung, Padding, Hashberechnung). Bei Seite 5 von 114 1 12010 Seile e von 114 1 2010

VS VS NYR FÜR 9EN 91ENSTCEBRAYGH kombinierter Darstellungsweise eines oder mehrerer Schritte wurde außerdem die Korrektheit der Kombination verifiziert Danach wurde kontrolliert, dass der Quelltext die Operationen korrekt implementiert. Zusätzlich wurde der vom Compiler nach Makroexpansion verarbeitete Quelltext untersucht sowie die vom Compiler erzeugte Objektdatei · disassembliert und analysiert. Hierdurch wurde verifiziert, dass im Übersetzungs-Prozeß der Objektcode korrekt erstellt wird. Insbesondere wird bestätigt, dass keine zusätzlichen Makros im Übersetzungs-Prozeß definiert werden, durch die die Übersetzung des Quelltextes beeinflusst wird. Wenn in den Spezifikationen optionale Funktionalitäf enthalten ist, wird beschrieben, ob TrueCrypt diese unterstutzt Wenn TrueCrypt zusätzliche Funktionalität umsetzt, . wird diese dokumentiert Abschließend wird die Korrektheit der Implementierung durch Tests mit Testvektoren bestätigt. Im nächsten Schritt wird überprüft, ob Programmierfehler vorliegen. Hierbei wird überprüft, ob die Basisoperationen der Algorithmen .fehlerfrei sind. Insbesondere wurden hier die Operationen für Multiplikation und Potenzierung in GF(2") untersucht. Außerdem findet eine Überprüfung der Größe von Datentypen, Größe von Speicherarrays, Verwendung von Zeigern und Zugriffe auf Speicherarrays statt. Als letzte Komponente der ·Analyse Wird der Quelltext auf mögliche inhärente Angriffspunkte untersucht. R~levant sind hier z.B. Timing-Angriffe, die positions- und • zeitabhängige Speicherzugriffslatenzen oder datenabhängige Ausführungszeiten von Opcodes ausnutzen können. 1.2 Voraussetzungen und Annahmen Es wird davon ausgegangen, dass TrueCrypt ausschließlich mit AES im Betriebsmodus XTS-AES-256 verwendet wird, sowie als Hashfunktion nur RIPEMD- 160 und SHA-2 mit 512 Bit Digest-Länge (SHA-512) zum Einsatz kommen. Es wird davon ausgegangen, dass der Compiler den Quelltext gemäß den aktuellen Standards C99 (2] bzw. C++98 [3] Obersetzt Diese spezifizieren die Semantik und Syntax des Quelltextes, aber nicht die genaue Ausführungsumgebung. Da diese aber insbesondere ftir Seitenkanalangriffe relevant ist, sollte diese in die Analyse eingeschlossen werden. Daher wird hier auß.erdem die Ausführung auf x86 und AMD64 Systemen und die relevanten Compiler (GCC, MSVC) mit entsprechenden Compiler-Optionen eingeschlossen. Als Referenz für das Programmcode-Verhalten werden die Handb!lcher von Intel herangezogen [4]. Diese stellen ebenfalls die Referenz für die Assemblerimplementierungen dar. Es wird davon ausgegangen, dass der Programmcode nicht von externen Komponenten, die auf dem gleichen System ausgeführt werden, anders als Ober die vorgesehenen Schnittstellen ·angesprochen und/oder manipuliert wird. Eine genauere Analyse dieser AnfOrderung ist in AP3, insbesondere in Abs. 5.5 .Angriffsbaum System ry./5)" dargestellt. · 1.3 Analyse AES · Die AES-Chiffre wird in TrueCrypt im Modus XTS-AES-256 genutzt (s. Abs. 4.4 ). S&lle 7 von 114 1 2010 NYR FÜR 9EN 91ENSTCEBRAYGH Für die Prüfung der AES Implementierung wird der AES-Standard [5] als Referenz herangezogen. ln allen Implementierungen wird ·ausschließlich eine Schlüssellänge von 256 Bit unterstützt. TrueCrypt nutzt verschiedene Implementierungen der AES Chiffre. Es wird eine generische, auf Geschwindigkeit optimierte, Implementierung in C bereitgestellt, sowie zusätzlich auf Geschwindigkeit optimierte Assemblerimplementationen für x86 und AMD64, sowohl mit als auch ohne Unterstützung für die AES Befehle in neuen Intel Prozessoren. Für Geschwindigkeitssteigerungen werden insbesondere Tabellen mit vorher berechneten Ergebnissen von Teilen der Algorithmen, gleichzeitige Verarbeitung großer Blöcke und Loop unrolling genutzt. Außerdem steht eine ·speicheroptimierte c- und x86-Assembler-lmplementierung bereit, die nur sparsam Tabellen und Loop Unrolling verwendet. Die API der Funktionen ist unabhängig von der Implementierung (Ausnahme: AES-NIImplementierung). 1.3.1 C-lmplementlerung TrueCrypt. nutzt eine leicht modifizierte Version der AES-Implementierung von Dr. Brian Gladinan (http'llgladmao,plushost co uk/oldsjte(AES/jndex,php). Dieser Code ist vielen Leuten bekannt und hat bereits entsprechend viel Analyse erfahren. Er findet sich in den Dateien Aescrypt. c, Aeskey. c, Aesopt. h, Aes. h Lind Aestab. h. Modifikationen für TrueCrypt beschränken sich funktional auf die Möglichkeit, die im folgenden angeführten Tests zu deaktivieren. Zunächst ist anzumerken, ·dass TrueCrypt ausschließlich AES-256 Verschlüsselung anbietet. AES Varianten mit einer Schlüssellänge von 128 und 192 Bit werden nicht· unterswtzt (s. Aes. h). Es existieren Angriffe auf AES-256 und AES-192 [6]. Als Blockgröße wird 128 Bit unterstützt, was dem AES Standard entspricht. Es werden beide. Verarbeitungsrichtungen . unterstützt (Ver- und Entschlüsselung). Um die Verwendung der Algorithmen während der Laufzeit zu kontrollieren, wird getestet, ob der VerschiOSselungskontext eine gültige Anzahl Rundenschillssei enthält. Eine mögliche Fehlfunktion der Implementierung wird nicht erkannt. Um diese zu gewährleisten, mosste regelmäßig die korrekte Verarbeitung von Testvektoren Oberprüft werden (diese Funktionalität ist derzeit nicht in TrueCrypt enthalten), was einen hohen zusätzlichen Aufwand und damit Verlangsamung der Verarbeitungsgeschwindigkeit darstellt. Einführen solcher Test ist nicht sinnvoll, da: 1. Die Sicherheit wird für den Fall erhöht, dass ein Fehler in der Ausführung des Programms auf dem Prozessor die Chiffre schwächt, ohne das Programm anderweitig zu stören. Ein solcher Fehler ist sehr unwahrscheinlich. 2. Der zusätzliche Aufwand bremst die Ausführung des Programmes deutlich. · Bewertung: Die Einführung solcher Tests ist nicht sinnvoll. TrueCrypt in der vorliegenden Version sollte nicht dahingehend geändert werden. Die C-lmplementierung der Chiffre verwendet ausgiebig Textersetzung von Makros durch den C-Präprozessor. So kann durch Setzen von . Makro-Optionen die Implementierungsart ausgewählt werden. Relevante Optionen betreffen insbesondere die Anzahl und Größe von LookuJr-Tabellen und Loop Unrolling. Die Makroexpansion ist zum Teil sehr tief verschachtelt, was die Analyse des Quelltextes Seite 8 von 114 2010

\<& '.«& NUR FYR 9EN 91ENS+GEBRAUCM NUR FYR 9EN ·QIENS:W:GEBRAUCM dies notwendig, somit könnte der zusätzliche Speicherplatz für die umgekehrte Speicherung der Schlüssel gespart werden. Außerdem ist die Verwendung von Schlüsseln in umgekehrter Reihenfolge für EntschlüsseJung in der Aes_x64. asm Assembler-Implementierung langsamer (s. Kommentar in Aes_x64 . asm, z. 133f). Über den Einfluss dieser Speicherweise auf die. Geschwindigkeit in anderen Implementierungen wird keine Aussage getroffen. erschwert (siehe Beispiel in Abschnitt 5). Um Gewissheit über der Korrektheit des übersetzten Codes zu erlangen, wurde zusätzlich zu ·den Implementierungsdateien der Quelltext analysiert, der nach dem Präprozessordurchlauf vom Compiler · übersetzt wird. Durch diese Verwendung von Makros könnte undefiniertes Verhalten erzeugt werden: Einer Variable wird mehrfach ein · Wert zugewiesen, ohne dass die Zuweisungen durch Sequenzpunkte getrennt sind (Aeskey. c, z . 524-527, reduzierte Darstellung in Text 1.1, Zuweisungen zu ss [ 4 ]). Da die Zuweisung hier immer der gleiche Wert ist, wird der Quelltext von gängigen Compilern wie erwartet übersetzt. Ob diese Nutzung tatsächlich undefiniert ist, ist Frage der Interpretation des Standards. Die einzige datenabhängige Operation. die in der Key Schedule durchgeführt wird, ist das Nachschlagen einer vorher berechneten Rotations-Operation mit Substitution aus zwei 4096-Byte-Tabelle und das Nachschlagen der Rundenkonstante aus einer 40-Byte Tabelle (entsprechend SubWord(RotWord(temp)) und Rcon[i/Nk] aus (5], Figure 11). Empfehlung: Da der Code von gängigen Compilern korrekt übersetzt wird, ist eine Problem: Die temporäre Variable s s [] enthält Schlüsselmaterial und Wir vor Änderung nicht notwendig. Beenden der Funktionen aes_encrypt_key256() und aes_decrypt_key256() nicht sicher überschrieben. · ~ ~ -~ >ks[52] ----- =( t_im[0][(ss[4] = alblcld)]>> 0 \ A t_im[1][(ss[4] = alblcld)]» 8 \ A t_im[2][(ss[4] = alblcld)]»16 \ A t_im[3][(ss[4] = I· Behebung: Sicheres Überschreiben der Variable ss [] hinzufügen. Aufwand: 1 Personentag. Endianess alblcld)]>>24 ); Text 1.1: Evtl. undefiniertes Verhalten nach M8kroexpansion Die C-lmplementierung hat vor allem 32 Bit Maschinen als Zielplattform. So nutzt die Polynommultiplikation gf_mulx eine Schreibweise, bei der 4 Bytes des AES- zustandes · in einer 32 Bit Variable gespeichert und jeweils im GF(2") (mod x"+X"+x"+x+1 = m(x) aus [5]) multipliziertwerden (Aesopt. h, Z. 584). Die C-lmplementierung alloziert an keiner Stelle Speicher. Der Speicher für Klartext, Chiffretext und Schlüsselkontext inkl. aller Rundenschlüssel muss von den aufrutenden Codestellen bereitgestellt werden. Diese Aufrufe wurden in Abs. 2 untersucht. Endianess wird in Common/Endian. h abstrahiert. Hierdurch wird sicher gestellt, dass Volumes von Big-Endian-Systemen auch auf Little-Endian-Systemen geöffnet werden können. Relevant ist die Endianess beim Zugriff auf Datenblöcke, die größer sind als ein Byte. Im betrachteten Quelltext sind die Größen 2, 4 und 8 Byte relevant. Die TrueCrypt AES Implementierung kann auf allen Systemen sowohl Big- als auch Little-Endian nutzen, ist jedoch bei Nutzung der nativen Endianess schneller. Daher wird in den betrachteten Kryptographie-Implementierungen von TrueCrypt immer PLATFORM_BYTE_ORDER genutzt (s. Aesopt. h, Z. 40). Außerdem ist die native Byte-Ordnung für die Assembler-Implementierungen des Algorithmus notwendig. Im AES Standard .ist Endianess nicht spezifiziert. um portable Container zu erstellen muss die Endianess der Maschine somit an anderer Stelle berücksichtigt werden. Sie erfolgt in der Implementierung des Betriebsmodus (s. Abs. 1.6). Key Schedule AES-256 nutzt 15 Rundenschlüssel, die jeweils aus l.6 Byte bestehen und somit einen gesamten Speicherbedarf von 15*16 Byte = 240 Byte aufweisen. Diese Schlüssel · werden gemäß der AES Key-Schedule zu den Rundenschlüsseln expandier.t und linear hintereinander im Arbeitsspeicher abgelegt. Es werden Tabellen für die Beschleunigung der Substitution eingesetzt, sowie Loop ·Unrolling .zur weiteren Erhöhung der Ausfflhrungsgeschwindigkeit. Für die EntschlüsseJung werden die Rundenschlüssel in umgekehrter Reihenfolge gespeichert, d.h. die ·16 Bytes des letzten. Rundenschlüssels werden an erster Position gespeichert, die 16 Bytes des vorletzten Rundenschlüssels an zweiter Position etc. Dies ist die Reihenfolge, in der sie bei der EntschlüsseJung benötigt werden. Diese Form der Speicherung ist notwendig fflr Verwendung von AES~ Hardware in VIA Chips. Bei keiner in TrueCrypt verwendeten Implementierung ist Seite 8 von 114 1 12010 Schnelle Implementierungen Es gibt verschiedene ~semblerimplementierungen des AES sowie Kombinationen von C- und Assembler-Code . Um die Geschwindigkeit des Codes zu steigern wird im Aescrypt. c Code volles Loop-Unrolling der AES-Runden durchgefflhrt. Als Nachteil ist hier der größere Speicherbedarf des Codes sowohl in der Objektdatei als auch zur Laufzeit zu beachten. Ebenso werden 16 Tabellen (4 für die normale Verschlüsselungsrunden, 4 für die letzte Verschlüsselungsrunde, ebenso fflr EntschiOsselung) mit je 256*4 Bytes fflr Ver- und EntschlüsseJung sowie 4 Tabellen mit 256*4 Bytes fflr die Seite 10 yon 1141 _12010

V& N'=IR FOR 9EN 91ENS1'GE8R.li.'=IC:I-I VS N'=IR FÜR 9EN 9IENS1'GE8R.t.'=IC:I-I Entschlüsselungs-Key-Schedule genutzt, um die Geschwindigkeit zu erhöhen. Die Tabellen kombinieren die SubBytes( ) , ShiftRows() und MixColumns(} Operationen und werden wie in [1] dargestellt generiert und genutzt. Alternativ hierzu wäre eine Umsetzung mit nur einer oder ganz ohne Beschleunigungstabelle möglich. Nachteil von großen Tabelle ist der erhöhte Speicherbedarf, Die Tabellen werden statisch im Data-Segment bereitgestellt Tabellen für Ver~ und EntschlüsseJung (normale Runde, letzte Runde, vorwärts und rückwärts}. Die Tabellen haben Einträge der Größe 8 Byte und sind so gefüllt, dass die Shift-Operation der Operation ShiftRows() durch einen Adressoffset beim Speicherzugriff erreicht wird. Außerdem ist zu erwarten, dass eine Implementierung mit großen Tabellen anfälliger ist für einen Seitenkanalangriff mittels Zeitmessungen (Timing}[7]. Eine Implementierung des AES mit AES-NI Instruktionen [4][11] findet sich in Aes_hw_cpu. { asm I h) für CPUs mit x86- und AMD64-Befehlssätzen, die diese neuen Instruktionen unterstützen. Es wird die dem Betriebsystem entsprechende Calling Convimtion genutzt (cdec/, AMD64, MS x86, s.o.). ln der TrueCrypt- lmplementierung werden vier der neuen Befehle genutzt (s. Tabelle 1.1). Es werde ausschließlich 256-Bit-Schlüssel unterstutzt Das Interface zu der Ver- und EntschlüsseJungstunktion unterscheidet sich von dem bisher verwendeten: Es werden nur zwei Parameter genutzt, wobei die unverschlüsselten Daten mit den verschlüsselten Daten Oberschrieben werden. zusätzlich wird eine Funktion aes_hw_cpu_( en 1de )crypt_32_blocks () angeboten, die 32 aufeinander folgende 128 Bit-Blöcke mit gleichem Schlüssel mittels AES verschlüsselt. Zugriffe auf diese unterschiedlichen FUnktionen werden in Common/Crypto. c und Volume/Cipher. cpp abstrahiert. 1.3.2 x86 CPU Assemblerimplementierung ln der Datei Aes_x86. asm befindet sich eine Assemblerimplementierung der .Aescrypt. c Funktionen für CPUs mit Intel x86-Befehlsunterstützung. Es wird für Windows und Linux die C Calling Convention (cdec/, siehe [8)) genutzt, d.h. Funktionsparameter werden auf ·dem Stack übergeben. Es wird tatsächlich der identische Algorithmus wie in der C-lmplementierung durchgeführt (gleiche Tabellen zur Beschleunigung, Reverse Decipher Key Schedule). Für die Key Schedule wird der C Code aus Aeskey .'c genutzt Somit werden auch hier die Schlüssel im Speicher in der Reihenfolge abgelegt, wie sie von der Entschlüsselungsoperation benötigt werden. Eine Speicherung in umgekehrter Reihenfolge, d.h. in Reihenfolge der Verarbeitung bei Verschlüsselung, wäre allerdings schneller (.Aes_x86. asm", Z. 108). Empfehlung: Durch Ändern der Key Schedule für Entschlüsselung in .normale Reihenfolge kann ohne Nebenwirkungen ein Geschwindigkeitsvorteil erreicht werden. Aufwand: 1 Personentag. Des weiteren ist · anzumerken, dass verschiedene, für die Verarbeitung unterschiedlicher Schlüssellängen notwendige, Sprunganweisungen im · Code enthalten sind. Da TrueCrypt allerdings nur eine Schlüssellänge unterstützt, ist diese Möglichkeit überflüssig. Durch Entfernung dieser Sprünge könnte eine geringe Verbesserung der Ausführungszeit und Codegröße erreicht werden. Diese Änderung kann durch Entfernen der Sprunganweisungen erfolgen. Empfehlung: Entfernen der Sprunganweisungen. Aufwand: 1 Personentag; 1.3.3 x64 CPU Assemblerimplementierung ln der Datei Aes..:_x64. asm befindet sich eine Assemblerimplementierung der Aesc rypt . c Funktionen für CPUs mit AMD64-Befehlsunterstützung. Hier wird unter Windows die Microsoft x64 Calling Convention (s. (9]), unter Linux die AMD64 ABI Calling Convention {s. [10]) genutzt. Damit werden bei beiden Versionen die drei Funktionsparameter in Registern übergeben. Die x64-lmplementierung verwendet die Key Schedule aus Aeskey. c. Sie nutzt nicht die Tabellen aus der c-implementierung, sondern erzeugt selbst 4 Tabellen mit einer Größe von jeweils 2048 Byte. · Es wird der gleiche Algorithmus genutzt wie in der C-Variante, allerdings mit nur 4 Seite 11 von 114 1 2010 1.3.4 AES-NI Assemblerimplementierung Befehl Funktion AESENC Normale AES Verschlüsselungsrunde AESENCLAST Letzte AES Verschlüsselungsrunde AESDEC Normale AES Entschlüsselungsrunde AESDECLAST Letzte AES Entschlüsselungsrunde Tabelle 1.1: Von TrueCrypt verwendete AES-NI Befehle [4] Die Implementierung nutzt die Key Schedule aus dem C-Code. Aus!_lagen bzgt. Ausführungszeit und Angreifbarkelt der Key Schedule können somit übernommen werden. FOr die Verarbeitung der Daten erfordert die AES Implementierung mit Hardwarebeschleunigung durch den Verzicht auf Lookup-Tabellen deutlich weniger Speicher als alle anderen Implementierungen.- Weiterhin werden deutlich weniger Instruktionen durchgeführt, die außerdem keine datenabhängige Ausführungszeit besitzen. Damit bietet diese Implementierung eine konstante, datenunabhängige Ausführungszeit, und Ist zudem · deutlich schneller als alle anderen Implementierungen. Als Angriffspunkt bleibt somit nur die Key Schedule, da diese von der Standard-C-Implementierung übernommen wird. 1.3.5 Unterschiede bei Bootloader-lmplementierung Wenn TrueCrypt im Fuii-Disk-Encryption {FDE) Mode, d.h. Verschlüsselung der Festplatte inklusive der Betriebssystem-Partition, genutzt wird, ist die Implementierung des AES speicheroptimiert. Diese Entscheidung ist darin begründet, dass der von TrueCrypt genutzte Bootloader im Master Boot Record der Seite 12 von 1141 I 2010

\(8 \~ NYA FYA 9EN 91ENS:J'GE8A.t..YCH Festplatte gespeichert werden muss. Dieser bietet allerdings nur 62 Sektoren Speicherplatz für den Bootloader, was bei einer Sektorgröße von 512 Byte ca. 32 KB entspricht. Die Tabellen aus der geschwindigkeitsoptimierten Version wOrden beispielsweise bereits einen großen Teil des zur Verfügung stehenden Speichers verwenden. Loop-Unrolling würde den Speicherbedarf der AES-Funktionen ebenfalls erhöhen. Die Bootleader-Implementierung wird nur während des Bootvorgangs genutzt. Im Verlauf des Bootens wird das Volume-Passwort an eine Speieherstelle geschrieben, von wo der Windows-Treiber das Passwort ausliest. Dann wird der Windows-Treiber für Lesen und Schreiben genutzt (s. AP4, Abs. 1.2.4). Die speicheroptimierten Bootleader-Implementierungen finden sich in Aessmall. c und Aessmall_x86. asm. Tabellen werden nur für die normalen Runden genutzt, die Lookups der letzten Runde werden aus den Werten dieser Tabellen berechnet Den verwendeten Byte- und Wort-Registern werden ausschließlich zulässige Werte zugewiesen. Diese Assembler-Implementierung bringt eine eigene Funktion für die Key Schedule mit. Sie nutzt nur eine Tabelle für die Speicherung der Rundenkonstante Rcon und der S-Box. 1.4 Übersetzung des AES-Codes Bei den C-lmplementierungen werden in bestimmten Bereichen verschiedene Compiler unterschieden. Speziell berücksichtigt werden die in Tabelle . 1.2 dargestellen Compiler und Versionen. .Hierdurch werden Fehler in alten Compilerversionen umgangen, sowie zusätzliche Geschwindigkeitsoptimierungen durchgeführt. 1.3.6 C smalllmplementierung Compiler Die Implementierung Aessmall. c wird bei FDE im Bootleader genutzt. Diese Implementierung führt den AES Algorithmus wie im Standard vorgeschlagen durch. Zur Beschleunigung der GF(2 8)-Multiplikation in der MixColumns-Operation wird eine vorberechnete Multiplikationstabelle genutzt. Es werden nur Byte- und Word-Typen genutzt, denen ausschließlich zulässige Werte zugewiesen werden. Die inverse Chiffre ist analog implementiert. Die kOmpakte Implementierung bringt außerdem eine eigene Implementierung der Key Schedule mit. Diese setzt den Standard mit Byte-Datentypen um. Der verwendete Algorithmus ist identisch zu Fig. 11 in [5]. der temporären Variablen hinzufügen. Auch in dieser Implementierung sind Reste der Originalimplementierung von Dr. B. Gladman [1] vorhanden, mit denen weitere Schlüssellängen implementiert wurden. Durch Entfernung dieser Codefragmente könnte ein minimal verringerter Speicherbedarf und eine schnellere Ausführungszeit erreicht werden. Gerade hier, im speicherbeschränkten Boot-Modus, ist eine solche Optimierung sinnvoll. Makro GCC Versionen GNUC Microsoft C Watcom C MSC VER _WATCOMC_ <=800,>=1300 >=1100 Tabelle 1.2: Compiler und Versionen, die in TrueCrypt unterschieden werden Die folgenden Unterscheidungen werden gemacht: • Microsoft c: Es werden verschiedene Optimierungen eingeschaltet, wenn der Microsoft c Compiler eingesetzt wird (Aestab. h, Aescrypt. c, Aesopt. h, Aessmall.c). FOr. Compiler bis zur Versionsnummer 800 werden statische Tabellen deaktiviert. • GCC und Microsoft C: Diese Compiler werden bei Aes_x64. asm unterschieden, um die entsprechende Calling Convention für Windows bzw. Linux zu verwenden. • Watcom C: Calling Convention für bestimmte Funktionen zu cdec/.definiert. . Problem: Die temporären ·variablen tt, te, tl, t2 und t3 enthalten Schlüsselmaterial und werden vor Beenden der Funktion nicht sicher überschrieben. Behebung: Sicheres Überschreiben Aufwand: 1 Personentag. NYR FYA 9EN 91ENS:J'GE8A.t..YCH Die Unterscheidungen haben keinen Einlluß auf die korrekte Funktionsweise der Algorithmen . . Empfehlung: Entfernen der Verarbeitung von SchlOssein der Länge 128 und 192 Bits. Aufwand: 1 Personentag. 1.5 Bewertung AES 1.3.7 xB6 Assemblersmall Assemblerimplementierung Um die Ergebnisse der in den vorangegangenen Abschnitten beschriebenen Untersuchung auf einen Blick darzustellen, folgt nun eine Zusammenfassung der relevanten Eigenschaften der AES Implementierungen. Die Implementierung AesSmall_x86. asm wird alternativ bei FDE im Bootleader genutzt. Die Implementierung führt den im Standard vorgeschlagenen Algorithmus identisch durch. Hier werden für die Ver- und EntschiOsselung jeweils 8 Tabellen mit 256 Byte Einträgen genutzt. Diese Tabellen werden von Aestab. c importiert. Aes tab. c wird fOr die Boot-Implementierung so Oberseizt, dass die TabeDen zur Laufzeit erzeugt werden. Analog wird fOr die inverse Operation vorgegangen. Seite 13 von 114 1 2010 1.5.1 Standardkonformität Die untersuchten Implementierungen setzen den AES Algorithmus standardkonform um. Seite 14 von lU 1 12Q10

VS 'JS NYR FÜR QEN QIENSTGEBRAYCH NYR FÜR QEN QIENSTGEBRAYCH Versionen erstellte Volumes öffnen zu können. 1.5.2 Geschwindigkeit Die Implementierungen in TrueCrypt sind sehr schnell und für verschiedene Befehlssätze optimiert. Außerdem wird eine generische, aber ebenfalls schnelle C Implementierung bereit gestellt, die auf Architekturen genutzt werden kann, für die noch keine Assemblerimplementierung existiert. 1.5.3 Vertrauenswürdigkeit Die Implementierung der kryptagrafischen Algorithmen wird als vertrauenswürdig erachtet. Die Algorithmen sind korrekt implementiert und Daten werden gemäß der entsprechenden Standards verarbeitet. Es sind keine Hintertüren eingebaut. Es wurden keine Datenlecks gefunden. - 1.5.4 Sicherheitsaspekte Bei der Untersuchung hinsichtlich- der Sicherheit der AES-Implementierungen wurde festgestellt, dass die hier verwendeten Implementierungen, mit Ausnahme der auf Hardwarebeschleunigung basierenden AES-NI Implementierung, anfällig für Timing- Angriffe sind. Die Anfälligkeit für Timing-Angriffe existiert bei allen schnellen AES- Implementierungen in Sottware [7]. Die Praktikabilität solcher Angriffer wird hier nicht bewertet. Die AES-NI.Implementierung ist nicht anfällig für diesen Angriff. - DarOber hinaus wurde die Implementierung auf Speicherallokations- Speicherzugriffsfehler untersucht. Solche Fehler wurden nicht entdeckt. und 1.5.5 Empfehlung Die Implementierungen können mit Oberschaubaren Änderungen übernommen werden. Wir empfehlen, die Implementierung mit AES-NI zu wählen, da diese keine Angriffsmöglichkeiten bezüglich Timing aufweist und die höchste Geschwindigkeit bietet. 1.6.1 Standardkonformität Im XTS Standard wird ein Datenträger zweistufig in kleinere Verarbeitungseil'lheiten aufgeteilt. So besteht ein Datenträger aus bis zu 2 128-2 Blöcken der Größe 128 Bit, aufgeteilt in Dateneinheiten von bis zu 220 ·128 Bit (s. Abbildung 1.1). Ciphertext Stealing wird nicht betrachtet, da TrueCrypt keine Unterstützung dafür bietet. TrueCrypt unterstützt XTS-AES-256 mit Dateneinheiten, die ausschließlich eine Größe von 512 Byte haben (Crypto/Crypto. h, z. 37; und s. Text 1.3). Dies ist konform zu den Standards. Ciphertext Stealing, wie im Standard optional definiert, ist somit nicht notwendig und nicht implementiert. 512 Byte entspricht der üblichen Sektorgröße von Festplatten (Anmerkung: Miderweile gibt es Festplatten mit einer Sektorgröße von 4096 Bytes. Diese können ohne Nachteile in Blöcke von 512 Byte · Größe aufgeteilt werden). if (length BYTES_PER_XTS_BLOCK) ~ TC_THROW~FATAL_EXCEPTION; Text 1.3: EncryptionModeXTS.cpp, Bytes · z. 65f. ,.length" ist die Länge des Klartextes in XTS nutzt zwei unterschiedliche AES-256-Schlüssel, einen Tweak und einen Offset Der Tweak i ist eine fortlaufende Nummer, die beliebig initialisiert wird. Die beiden AES E;inheiten benötigen die Schlüssel Key1 und Key2. Die AES-Einheiten werden entsprechend ihren SchlOssein im Folgenden als AES1 und AES2 bezeichnet. Der Wert T wird hier als Whitening-Wert bezeichnet. Datenträger / _//// 1.6 Analyse XTS Encryption Mode - / Der XTS-AES-256 Modus wird für die Verarbeitung der Daten im verschlüsselten Valurne (s. Abs. 4.4) und für die Verschlüsselung des Headers (s. Abs. 4.3.4) genutzt. Der XTS Encryptiori Mode ist von der IEEE in [12) spezifiziert und vom NIST in [13) mit einer kleinen Änderung übernommen worden: Das NIST verlangt eine Beschränkung der Größe einer Dateneinheit ("data unit", s. [12], Abs. 4.3.1) auf maximal 220 AES Blöcke, i.e. 16 MiB. Eine Dateneinheit ist ein Datenblock, für den der gleiche Schlüssel und Kontext (. key scope") genutzt wird. Der Schlüsselkontext beinhaltet einen Tweak Wert, die Größe einer Dateneinheit und die Datenlänge. Alle Dateneinheiten besitzen eine identische Größe. Spezifiziert sind XTS-AES-128 und XTS-AES-256 mit 256 respektive 512 Bit Schlüsseln. XTS ist abgesehen von den Legacy-Modi (LRW, CBC) der einzige von TrueCrypt unterstützte Verschlüsselungmodus. Die Legacy-Modi können bei der Erstellung eines neuen Volumes nicht ausgewählt werden und existieren nur, uin mit alten TrueCrypt- Seite 15 von 114 2010 / /' _.,.···"·· . ./ J' •.-·· _/_,-_,.-···' ,, "·-.., Dateneinheit "--,,,, "......._ AES Block 0 127 Abbildung 1.1: Aufteilung des Datentrligers im XTS Modus Ober die Anforderung des Standards, AES zu nutzen, hinaus unterstützt TrueCrypt Seite U von 114j 2010

V-S NI:IR FOR 91ö1N 91ENSTG~ö1BRAI:ICM 'JS im XTS Modus auch Mehrfachverschlüsselung der Daten mit Serpent und (Twofish oder Blowfish) und AES sowie ausschließliche Nutzung anderer Chiffren ([12] und [13] verlangen und erlauben ausschließlich AES). Die Mehrfachverschlüsselung ersetzt beide AES Ver-/Entschlüsselungsinstanzen durch die alternative Chiffre. 1.6.2 Korrektheit der Implementierung NI:IR FYR DEN 91ENSTGEBRAI:ICM Informationen, die sich hier extrahieren lassen, sind Informationen über die Position innerhalb von Sektoren, an denen Daten geschrieben werden. Der Code in Text 1.2 hat nach Übersetzung durch den Compiler typischerweise eine datenabhängige Laufzeit, da im .if'-Teil der Verzweigung mehr Code ausgeführt wird als im .else"- ·zweig. Der XTS Betriebsmodus ist gemäß dem im Standard vorgeschlagenen Algorithmus implementiert. j wird immer mit 0 initialisiert und die nachfolgende Multiplikationen mit tii fortlaufend durch Shifts und XORs implementiert: if (block >= startBlock) { *whiteniilgValuesPtr64-- = *whiteningValuePtr64++; *whiteningValuesPtr64-- = *whiteningValuePtr64; t = AES-enc(Key>, i) etse whiteningValueptr64++; for j = 0 to 512/8-1: MSB := } Text 1.2: ·DatenabMngige AusfiJhrungszeit · im XTS-Modus, abMngig von · Schreibposition t121 t = t << 1 t = t XOR MSB*135 next j Dieser Algorithmus entspricht einer Multiplikation von t mit ai für alle j von 0 bis 63 im GF(212"). Da in TrueCrypt maximal eine Multiplikation mit a 31 (512-Byte Dateneinheiten entSprechen 32 AES Blöcken) erforderlich ist; führt die Implementierung die Multiplikation im benötigten Rahmen korrekt durch. Die Funktionen zur · Ver- und Entschlüsselung (EncryptionModeXTS: : EncryptBuffer /EncryptBufferXTS bzw. EncryptionModeXTS: : DecryptBuffer /DecryptBufferXTS) unterscheiden sich ausschließlich im Aufruf von AES1, wo diese entsprechend der Ver- bzw. Entschlüsselungsrichtung aufgerufen wird. ln beiden wird zunächst ein Array erstellt, in dem die notwendigen Whitening-Werte T (s. [12], Abs. 5.3.1, Figure 1) gespeichert werden. Anschließend .werden diese Werte T mittels XOR mit dem .Plaintext verknüpft, das Ergebnis PP dann verschlüsselt und die verschlüsselten Daten CC wiederum mit T verknüpft. Die Vorverarbeitung und das anschließende übergeben von großen Blöcken an die AES-Routine ermöglicht die Nutzung einer für große Datenmengen optimierten AES-Ver- und EntschiOsselungsimplementierung. Die Schnittstelle ist aufgrund der . Verwendung von Byte-Arrays Endianess- unabhängig. Intern werden . die Daten allerdings in 32- oder 64-Bit Variablen verarbeitet, weshalb die Endianess relevant ist. Sie wird entsprechend der Anforderung der AES-Implementierung in den Algorithmenblöcken angepasst. 1.6.3 Sicherheitsaspekte Danach wurde der Algorithmus hinsichtlich Schwächen bzgl. Seitenkanalangriffen untersucht. Hierbei zeigt sich, dass die Potenzierung und Multiplikation in GF(2 128) solche Schwächen besitzt. Mögliche Schwächen in den verwendeten Chiffren werden hier nicht behandelt, setzen sich aber natürlich durch den XTS Modus hindurch fort. 1 finalCarry = (*whiteningValuePtr64 & exseeeeeeeeeeeeeeeuLL) ? 135 : e; *whiteningValuePtr64-- <<= 1; if (*whiteningvaluePtr64 & exseeeeeeeeeaeeeeeuLL) *(whiteningValuePtr64 + 1) 1=. 1; *whiteningValuePtr64-- <<= 1; Text 1.3: Datenabhatlgige Laufzeit in der Potenzierung im XTS Modus Bewertung: . Der Unterschied der Laufzeit ist so gering, dass er von anderen Operationen währende der Ausführung verdeckt wird und· praktisch nicht genutzt werden kann. Bewertung: Die Implementierung des XTS ist standardkonform. Seite 17 von 114 Außerdem wird in TrueCrypt j für jeden Sektor mit 0 initialisiert, und somit können die Potenzen von a durch Shitts (a0 =0x1, a 1=0x2, a 2=0x4, a 3=0x8, etc), Multiplikation des MSB mit 135 und anschließende XOR-Addition erzeugt werden. Shitts innerhalb eines Registers sind in modernen CPUs (AMD ab K5, Intel ab Pentium) typischeiweise nicht datenabhangig und somit nicht angreifbar durch Zeitmessung. Allerdings erfordert der XTS-Aigorithmus ein Rotation über 128 Bit und damit Ober die Registergröße · hinaus, so dass die Daten in zwei 64-Bit- oder vier 32-Bit- Registern gespeichert werden. Der Transter des MSB Ober Registergrenzen .hinaus wird wie in · Text 1.3 dargestellt durchgeführt. Die Ausführungszeit von Verzweigungen ist nicht konstant, weshalb diese Passage keine konstante Ausführungszeit besitzt und somit eine Messung der Ausführungszeit Rückschlüsse auf den Whitening-Wert erlaubt. 12010 1.6.4 Geschwindigkeit FOr die Verschlüsselung eines einzelnen XTS-Biockes (128 Bit) werden zwei AES- Verschlüsselungen benötigt, für die Entschlüsselung eine AES-Ver- und eine AES- Entschlüsselung: Jeweils eine Verschlüsselung für die Erzeugung des Whitening- Seite 18 von 114 1 2010

'1& NUR FÜR 9EN 91EN&TGEBRAUGH 'J.& Wertes, sowie eine Ver/Entschlüsselung für die Verarbeitung der mit denWhitening- Werten verknüpften Daten. Wenn eine ganze Dateneinheit von 512 Byte verschlüsselt wird, ist nur eine Berechnung von AESz notwendig. Für die Ver-/Entschlüsselungen werden zwei Cipher-lnstanzen an die Funktion übergeben. Somit ist es möglich, die Key Schedule für beide Instanzen genau einmal zu berechnen und nictit abwechselnd die Rundenschlüssel für AES1 und AESz berechnen zu müssen. Für Linux ist der XTS-Modus in der Datei Volume/Enc r'yptionModeXTS. cpp umgesetzt Hier wird, wie oben beschrieben, AES1 mit großen Datenblöcken (bis zu 512 Byte, d.h. einer XTS data unit) aufgerufen. Alle Datentypten sind ausreichend groß, um standardkonform Volumes biS zu 2"64*16 Byte = 256 Eiß verarbeiten zu können. Bei größeren Volumes muss für startDataUnitNo ein größerer Datentyp genutzt werden, sowie die darauf aufbauende Verarbeitung angepasst werden. Unter Windows wird die Datei Common/Xt s. ( c 1h) genutzt. Es existieren eine für parallele Ausführung der Verschlüsselung Funktion (EncryptBufferXTSParallel) sowie eine Version, in der blockparallele Ausführung der Verschlüsselung nicht unterstützt wird (EncryptBufferXTSNonParallel). So ist die erste, parallele Variante identisch zu der unter Linux verwendeten Variante. Der serielle Algorithmus verschlüsselt die einzelnen AES-Biöcke nach Verl<nüpfung mit den Whitening"Werten direkt, ohne die Whitening-Werte vorher in einem Array zu speichern. Der XTS-Modus . ist in TrueCrypt effizient implementiert. Implementierung kann in der vorliegenden Formbeibehalten werden. · Bewertung: Die NUR FÜR 9EN 91EN&TGE8RAUGM Implementierung, auf Code von Brian Gladman. Dieser Code ist nicht so exirem wie der AES Code auf Geschwindigkeit optimiert. Es wird nur beschränkt Loop-Unrolling durchgeführt (es werden 16 Schritte der 5 Runden innerhalb eines Schleifendurchlaufs berechnet, nicht die komplette Hashfunktion). Der vorliegende Programmcode implementiert cien Standard. Die hierzu durchgeführten Schritte entsprechen in der Reihenfolge größtenteils der Durchführung im Standard. Unterschiede sind im . Abschnitt Es werden keine alternativen "Nachrichtenverarbeitung" aufgeführt. Darstelh:mgsweisen wie bei der AES-Implementierung verwendet. Der Algorithmus ist in die Funktionen sha512_begin( ), sha512_hash( ), sha512_compile(} und sha512_end() aufgeteilt. Diese Funktionen allezieren keinen Speicher. Sofern sie korrekt aufgerufen werden, greifen sie nur auf zulässige Speicherbereiche zu und halten den erlaubten Wertebereich von Variablen ein. Für die Daten wird durchgängig mit 64-Bit-Variablen gearbeitet. 128 Diese Implementierung unterstützt Nachrichten bis zu 2 -1Bit Länge. Sollte eine Nachricht Obergeben werden, die länger ist, wird der Fehler nicht erkannt. Dieses Problem ist praktisch allerdings nicht relevant. Vorverarbeitung ln sha512_begin() wird der Hashwert mit den im Standard definierten Werten initialisiert (s. Abschnitt 5.3.5 in [14]). Der hier verwendete memcpy-Aufruf ist sicher, da die korrekte Größe des Datenfeldes als Parameter angegeben wird. Nachrichtenverarbeitung 1.7 Analyse Hashtunktionen TrueCrypt bietet die Hashfunktionen RIPEMD-160, SHA-512, SHA-1 und Whirlpool an. Hashfunktionen werden in TrueCrypt in der Mischfunktion des Zufallszahlengenerator (s. Abs. 4.2.2) und der SchlOsselableitung mit PKCS#5- PBKDF2 genutzt (s. Abs. 4.3). Untersucht werden. die Hashfunktionen SHA-512 und · RIPEMD-160. Derzeit unterstützt TrueCrypt ausschließlich RIPEMD-160 für den Fuii-Disk-Encrpytion Modus. Da.RIPEMD-160 jedoch nicht mehr als sicher angesehen wird, untersuchen wir abschließend die Möglichkeit, diese Funktion durch SHA-512 zu ersetzen. Voraussetzung hierfür ist, dass der SHA-512-Code im TrueCrypt-Bootloader abgeiegt werden kann. 1.7.1 SHA-512 SHA-512 ist in Sha2. ( h I c) gemäß dem Standard [14] implementiert. Außer SHA- 512 werden auch SHA-224, SHA-256, SHA-384 Obersetzt und in die Objektdatei einbezogen. Diese werden von TrueCrypt allerdings nicht verwendet. ·somit wäre hier eine Reduktion der Größe der Objektdatei durch Entfernen dieser Funktionen möglich. Dies ist insbesondere bei einer potenziellen Verwendung von SHA-512 im Boot-Modus sinnvoll. Die Implementierung basiert, wie auch die AES- selte lW von u• I 12010 sha512_hash () erzeugt die Aufteilung der gepaddeten Eingangsnachricht in 1024- Bit-Biöcke, die anschließend mittels sha512_compile () in den Hashwert eingearbeitet werden. ln diesem Teil erfolgt, sofern nötig, die Anpassung der Daten- · Endlaness an die Computer-Endianess. sha512_compile () führt die Hashberechnung der einzelnen Blöcke durch. Hierbei werden die Schritte 1-3 des Abschnitts 6.4.2 des Standards kombiniert durchgeführt. Die acht Variablen a-h des Standards werden in einem Array uint_64t v[8] gespeichert. Das Umkopieren der Zwischenvariable a-h wird durch versetzten Zugriff auf die Variablen ersetzt. D.h. für t 0 entspricht a v[7], für t = 1 gilt a = v[6]. Abschließend erfolgt die Aktualisierung des Hashwertes durch Addition des für dieses Datenpaket berechneten Resultats. Die Kombination dieser Schritte ist der einzige Unterschied zu den im Standard spezifizierten Schritten. Die in TrueCrypt durchgeführten Operationen sind äquivalent zurn Standard. = = Nachbearbeitung Zum Schluß wird durch Aufruf von shaS12_end ( ) das Padding hinzugefügt (s. Abschnitt 5.1.2 in [14]) und der Hash-Wert der kompletten Nachricht extrahiert (s. Abschnitt 5.3.5 in [14]). Hier wird außerdem die ·Endianess korrigiert, falls die Seite 20 von 114 f 201.0