¨ T RUHR-UNIVERSITA

BOCHUM

Fakult¨ at f¨ ur Elektrotechnik und Informationstechnik

Studienprojekt im Studiengang Angewandte Informatik u¨ber das Thema Weiterentwicklung der Software TrueCrack zur Verbesserung der Performanz im Zusammenhang mit W¨ orterbuchattacken auf verschl¨ usselte TrueCrypt-Container

Eingereicht bei Herrn. Prof. Dr. Roland Gabriel Lehrstuhl f¨ur Wirtschaftsinformatik Fakult¨at f¨ur Wirtschaftswissenschaft von cand. rer. inf. cand. rer. inf. cand. rer. inf.

Bastian Blankemeier Henryk Jaskowiak Benjamin Meis

Abgabetag

30. M¨arz 2012

Inhaltsverzeichnis

I

Inhaltsverzeichnis 1 Erkl¨ arung

1

2 Abstract

2

3 Einleitung 3.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Strukturierung der Arbeit . . . . . . . . . . . . . . . . . . . . . . .

3 3 4

4 Theoretische Grundlagen 4.1 TrueCrypt . . . . . . 4.2 TrueCrack . . . . . . 4.3 CUDA . . . . . . . . 4.4 Qt . . . . . . . . . . 4.5 Client-Server Modell .

. . . . .

5 5 6 8 10 11

. . . .

14 14 15 18 24

6 Leistungstests 6.1 Testbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Testszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Testergebnisse und Auswertung . . . . . . . . . . . . . . . . . . . .

37 37 37 38

7 Fazit

45

Anhang

II

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 TrueCrack Extended / TrueCrack 5.1 Problemstellung . . . . . . . . 5.2 Anforderungen . . . . . . . . . 5.3 Entwurf . . . . . . . . . . . . . 5.4 Implementierung . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Optimized . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

Abbildungsverzeichnis

III

Tabellenverzeichnis

IV

Literaturverzeichnis

V

1

Erkl¨ arung

Wir erkl¨aren, dass das Thema dieser Arbeit nicht identisch ist mit dem Thema einer anderen von uns eingereichten Arbeit.

Wir versichern weiterhin, dass wir die Arbeit selbst¨andig verfasst und keine anderen als die angegebenen Quellen benutzt haben. Die Stellen der Arbeit, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen sind, haben wir unter Angabe der Quellen der Entlehnung kenntlich gemacht. Dies gilt sinngem¨aß auch f¨ur gelieferte Zeichnungen, Skizzen und bildliche Darstellungen und dergleichen.

—————————————— —————————————— Datum Unterschrift

—————————————— —————————————— Datum Unterschrift

—————————————— —————————————— Datum Unterschrift

2

Abstract

Die Sicherheit von sensiblen Daten hat in den letzten Jahren, gerade aufgrund der h¨oheren Pr¨asenz des Internets, auch bei Privatanwendern einen immer h¨oheren Stellenwert eingenommen. Aus diesem Grund werden h¨aufig Programme zur Verschl¨usselung von sensiblen Daten eingesetzt. TrueCrypt ist eines der bekanntesten Programme, welches die Verschl¨usselung von Daten oder ganzen Festplatten erm¨oglicht. Die Sicherheit solcher Verschl¨usselungssysteme steht immer im direkten Zusammenhang mit dem Aufwand, das Passwort f¨ur die verschl¨usselten Daten zu finden. An dieser Stelle setzt das Programm TrueCrack an, welches versucht mit Brute-Force- und W¨orterbuchattacken die Passw¨orter der von TrueCrypt verschl¨usselten Daten zu finden. Im Rahmen dieses Studienprojektes wurde die Software TrueCrack, im Hinblick auf eine Verbesserung der Performanz, weiterentwickelt. Dabei wurden vorrangig zwei Aspekte verfolgt. Zum einen wurde TrueCrack um eine Multi-GPU-Funktionalit¨at erweitert, sodass ein Zugriff auf mehrere Grafikkarten innerhalb eines Computersystems m¨oglich ist - genannt TrueCrack Optimized. Zum anderen ein Client-Server System implementiert, wodurch ein Rechnerverbund aufgebaut werden kann, in welchem die Menge aller zu testenden Passw¨orter auf die einzelnen Clients im Netzwerk aufgeteilt wird - genannt TrueCrack Extended. Anhand verschiedener Tests wird gezeigt, dass die Leistung durch die umgesetzten Funktionalit¨aten und die damit verbundene Verteilung der Rechenlast stark ansteigt. Dennoch zeigen die Ergebnisse, dass die Sicherheit von TrueCrypt-Volumes - unter der Voraussetzung der Wahl eines geeigneten Passwortes - bei der Rechenleistung aktueller Hardware nicht gef¨ahrdet ist.

3

Einleitung

Durch die zunehmende Pr¨asenz des Internets tritt - auch unter Privatanwendern - immer h¨aufiger der Wunsch nach der Sicherheit der eigenen Daten in der Vordergrund. TrueCrypt ist ein kostenloses Open-Source-Programm, das dem Anwender erm¨oglicht die eigenen Daten auf verschiedene Arten zu verschl¨usseln. Die Sicherheit aller aktuellen Verschl¨usselungsverfahren beruht auf der Sicherheit des verwendeten Passwortes. Im Rahmen dieses Projektes wird mit der Weiterentwicklung der Software TrueCrack die Sicherheit solcher Verfahren u¨berpr¨uft, indem die maximale Anzahl berechenbarer Passw¨orter in einem bestimmten Zeitraum analysiert wird. Dabei wurde die Prozesskette von der Anforderungserhebung, u¨ber den Entwurf, bis hin zur Implementierung durchlaufen. Basierend auf der erstellen Software wurden Testszenarien entwickelt, um eine Steigerung der Performanz, anhand der resultierenden Daten, aufzuzeigen.

3.1

Zielsetzung

Das Ziel dieses Studienprojektes ist es die auf TrueCrypt basierende Software TrueCrack funktional zu erweitern. Dabei soll vor allem eine Verbesserung der Performanz erzielt werden. Aus diesem Grund wird die Anwendung in zwei Richtungen erweitert. Zum einen soll die Leistung von TrueCrack durch eine Optimierung des CUDA-Codes und zus¨atzlich durch das Hinzuf¨ugen von Muti-GPU-Funktionalit¨at direkt verbessert werden. Zum anderen soll auf Basis dieser verbesserten TrueCrack-Version ein ServerClient Framework entwickelt werden, welches es erm¨oglichen soll die Rechenlast auf verschiedene Clients zu verteilen. Ebenso wie TrueCrack soll auch das Server-Client Framework den Startvorgang u¨ber die Konsole unterst¨utzen, um eine Batchverarbeitung zu erm¨oglichen.

Einleitung

3.2

4

Strukturierung der Arbeit

Diese Studienprojektdokumentation dient dazu, den Ablauf und die Durchf¨uhrung des Projektes zu dokumentieren. Dazu wird in diesem Kapitel zun¨achst eine Einlei¨ tung in das Thema, sowie eine Ubersicht u¨ber die Strukturierung der Arbeit gegeben. Anschließend werden in Kapitel 4 die theoretischen Grundlagen beschrieben, welche f¨ur das Verst¨andnis und die Umsetzung des Projektes ben¨otigt wurden. Dazu geh¨ort insbesondere eine Beschreibung der Programme TrueCrypt und TrueCrack, welche die Basis des Projektes bilden. Außerdem werden dort die verwendeten Programmiersprachen und Frameworks beschrieben. In Kapitel 5 wird ein detaillierter Einblick in die Konzeption und Entwicklung von TrueCrack Optimized und TrueCrack Extended gegeben. Außerdem werden im Ausblick Anregungen und Hilfestellungen f¨ur die Weiterentwicklung der Software thematisiert. In Kapitel 6 werden die durchgef¨uhrten Tests dokumentiert. Daf¨ur werden zun¨achst die Testszenarien beschrieben, bevor die Ergebnisse analysiert und ausgewertet und die daraus gezogenen Schlussfolgerungen er¨ortert werden. Abschließend werden im 7. Kapitel die Anforderungen res¨umiert und anhand der erreichten Ziele und Ergebnisse ein Fazit gezogen.

4

Theoretische Grundlagen

Dieses Kapitel umfasst die f¨ur das Studienprojekt notwendigen theoretischen Grundlagen, wie Beschreibungen der Softwareprodukte TrueCrypt und TrueCrack, der NVIDIAArchitektur CUDA, des Qt Frameworks von Nokia, sowie einer allgemeinen Darstellung des Server-Client-Modells.

4.1

TrueCrypt

TrueCrypt ist eine Software zur Verschl¨usselung von Datenspeicher und ist f¨ur Windows, Linux, sowie Mac OSX konzipiert. Es handelt sich um ein Open-Source-Projekt, der gesamte Quellcode kann somit u¨ber die offizielle Internetpr¨asenz1 heruntergeladen werden. TrueCrypt basiert auf dem Quellcode der Software E4M (Encryption for the Masses), dessen Entwicklung im Jahr 2000 eingestellt worden war und ist aktuell in der Version 7.1a kostenlos verf¨ugbar. Eine besondere Eigenschaft von TrueCrypt ist die sogenannte “on-the-fly”-Verschl¨usselung. Dabei k¨onnen Dateien in einen verschl¨usselten und von TrueCrypt eingebundenen Datenspeicher kopiert oder verschoben werden, TrueCrypt verschl¨usselt diese Daten automatisch zur Laufzeit. Zur Ver- und Entschl¨usselung einer Datei oder eines Datentr¨agers stellt TrueCrypt drei Algorithmen bereit, den Advanced Encryption Algorithm (AES), den SerpentAlgorithmus, sowie den Twofish-Algorithmus. Bei allen drei Algorithmen handelt es sich um symmetrische Verfahren, die im sogenannten XTS-Modus betrieben werden. Der XTS-Modus stellt eine leichte Abwandlung des XEX-Modus (Xor-encrypt-Xor) dar und benutzt im gegensatz zum XEX-Modus zwei voneinander unabh¨angige Schl¨ussel, statt einen Schl¨ussel[ML08]. Alle drei Algorithmen ben¨otigen somit eine Schl¨ussell¨ange von 256 Bit und arbeiten mit einer Blockgr¨oße von 128 Bit. TrueCrypt bietet dar¨uber hinaus drei Hash-Algorithmen an: RIPEMD-160, SHA-512 und Whirlpool, auf dessen Funktionsweisen hier aber nicht n¨aher eingegangen wird.

1

http://www.truecrypt.org/

Theoretische Grundlagen

6

Bei einem Datenspeicher, f¨ur den TrueCrypt in Bezug auf die Ver- und Entschl¨usselung ausgelegt ist, kann es sich konkret um einen Dateicontainer handeln, jedoch auch um eine ganze Festplatte, eine Festplattenpartition, einen USB-Stick oder ¨ahnliche Speichermedien. Im weiteren Verlauf wird von einem TrueCrypt-Volume gesprochen. Im Rahmen dieses Projektes werden ausschließlich Datei-Volumes (file-hosted) und Festplatten-Volumes (device-hosted) betrachtet. Ein solches TrueCrypt-Volume ist von TrueCrypt eindeutig spezifiziert und in mehrere Abschnitte aufgeteilt. Die ersten 512 Bytes jedes Volumes sind der sogenannte Header. Der Header beinhaltet alle In¨ formationen die f¨ur das Uberpr¨ ufen von Passw¨ortern ben¨otigt wird und ist daher der einzige Teil der Volumes, der hier n¨aher betrachtet wird. Die Struktur eines Volume-Headers ist sehr wichtig f¨ur den Entschl¨usselungsprozess. Der Header beinhaltet jedoch keine Informationen dar¨uber, mit welchem Verschl¨usselungs-Verfahren und Hash-Algorithmus ein Volume erstellt wurde. Daher werden beim Entschl¨usseln mit einem Passwort, immer alle Kombinationen der Verfahren getestet. Da nicht auf die korrekt entschl¨usselten Daten innerhalb des Volumes gepr¨uft werden kann, dient der Header dabei als Kontrollmechanismus. Die ersten 64 Bytes des Headers bilden das Salt2 , welches aus zuf¨alligen Bytes besteht. Dieses Salt wird ausschließlich f¨ur die Berechnung der Hash-Werte verwendet. Die n¨achsten 4 Byte sind besonders wichtig, denn sie bilden die verschl¨usselte ASCII Zeichenfolge TRUE“ und ” ¨ spielen somit f¨ur die Uberpr¨ ufung eines Passwortes eine entscheidende Rolle. Wird diese Zeichenfolge nach der Entschl¨usselung des Headers gefunden, dann wurden die richtigen Verfahren und das richtige Passwort verwendet. Jedoch m¨ussen je nach verwendetem Hash-Algorithmus bis zu 2000 Iterationen der Schl¨ussel-Herleitungs-Funktion berechnet werden. Dadurch ist der Rechenaufwand f¨ur ¨ das Uberpr¨ ufen jedes einzelnen um ein vielfaches h¨oher. Mit dieser Methode sollen Brute-Force- und W¨orterbuch-Attacken zus¨atzlich erschwert werden.[Fou]

4.2

TrueCrack

TrueCrack ist ein unter der GNU GPL Lizenz stehendes Programm, welches auf dem Quellcode von TrueCrypt basiert und zur Anwendung von Brute-Force-, sowie W¨orterbuch-Attacken auf TrueCrypt-Volumes konzipiert ist. Es wurde von Luca Vaccaro und Riccardo Zucchinali entwickelt. TrueCrack ist unter dem Betriebssystem Linux lauff¨ahig und bietet die Optionen die n¨otigen Berechnungen f¨ur eine Attacke 2

SALT = Zuf¨allige Zeichenfolge, wird h¨aufig der Eingabe von Hash-Funktionen angeh¨angt

Theoretische Grundlagen

7

entweder nur auf der CPU3 auszuf¨uhren oder eine Kombination aus CPU und GPU4 Berechnungen zu w¨ahlen, bei der die geschwindigkeitsrelevanten Berechnungen auf der GPU der Grafikkarte ausgef¨uhrt werden. Um diese Funktionalit¨at zu bieten, wurde f¨ur die Programmierung CUDA (siehe Abschnitt CUDA) von NVIDIA genutzt. Aus diesem Grund ist die Benutzung von GPU Berechnungen nur mit einer vorhandenen CUDA-f¨ahigen NVIDIA-Grafikkarte m¨oglich. Der Quellcode von TrueCrack besteht gr¨oßtenteils aus relevanten Codest¨ucken des Quellcodes von TrueCrypt. Somit wurden die entsprechenden Algorithmen und Programmabl¨aufe zum Entschl¨usseln der TrueCrypt-Volumes u¨bernommen. Zus¨atzlich wurde das Programm um die Funktionalit¨at der GPU-Unterst¨utzung erweitert. Die aktuelle Version von TrueCrack umfasst das Kryptosystem AES im XTS-Modus und die Hashfunktion RIPEMD160 im CPU-Modus, sowie auch den Modus mit GPUUnterst¨utzung und ist auf der Webseite Google Code“ der Google Inc. frei verf¨ugbar5 . ” TrueCrack muss f¨ur das eigene System kompiliert werden, dabei muss ausgew¨ahlt werden, ob die Berechnungen mit oder ohne GPU-Unterst¨utzung ausgef¨uhrt werden sollen. Mit diversen Parametern kann daraufhin das Programm gestartet werden. Ein Beispielhafter Aufruf kann wie folgt aussehen: ./truecrack -t TRUECRYPT_VOLUME -w WORDLIST_FILE -b 1024 Die folgende Tabelle zeigt alle Parameter und ist der offiziellen Google Code“-Seite ” entnommen, wobei die Erkl¨arungen ins Deutsche u¨bersetzt wurden. -h -t -w

–help –truecrypt FILE –wordlist FILE

-m

–maxlength INT

-c

–charset STRING

-b -v

–blocksize INT –verbose

Listet Informationen zur Benutzung auf TrueCrypt Volume Datei W¨orterbuch Modus, ließt W¨orter aus der Datei FILE ein Brute-Force Modus, INT gibt die maximale L¨ange der zu generierenden W¨orter an Brute-Force Modus, erstellt nur W¨orter aus in STRING enthaltenen Buchstaben Blockgr¨oße der parallel verarbeiteten W¨orter listet die verarbeiteten Passw¨orter in der Konsole auf

Tabelle 4.1: Parameter von TrueCrack

3

CPU = central processing unit GPU = graphics processing unit 5 http://code.google.com/p/truecrack/ 4

Theoretische Grundlagen

4.3

8

CUDA

CUDA steht f¨ur Compute Unified Device Architecture und ist eine Architektur von Nvidia, die es erlaubt die Berechnungseinheiten von Nvidia-Grafikkarten, die sogenannten Cuda-Cores anzusprechen. Laut offiziellen Daten wurden bis heute u¨ber 250 millionen CUDA-f¨ahige Grafikkarten verkauft. Diese Grafikkarten werden nicht nur f¨ur den privaten Gebrauch gekauft, sondern unter anderem auch in den meisten Rechenzentren und diversen Industrie- und Betriebszweigen verwendet. Beispiele hierf¨ur sind das Erforschen neuer Medikamente in der Pharmaindustrie, oder die Beschleunigung von Numerix, einer Software die f¨ur Finanzm¨arkte das Gegenparteirisikos errechnet. Die Programmierung f¨ur CUDA kann in hohen Programmiersprachen wie C/C++ erfolgen, was eine leichtere Einbettung in schon vorhandene Softwarel¨osungen erm¨oglicht. Es gibt auch schon eine Vielzahl an Firmen, die CUDA in ihren Programmen verwenden oder spezielle auf CUDA basierende Dienste anbieten. Um den Grund f¨ur die Verwendung von GPU’s anstatt herk¨ommlicher CPU’s zu verstehen, ist zuerst ein Vergleich der Designprinzipien beider Prozessarten notwendig. CPU’s sind daf¨ur konzipiert, einige wenige Threads6 m¨oglichst schnell abzuarbeiten. Dabei arbeiten CPU’s auf verschiedenen Daten und k¨onnen w¨ahrend der Laufzeit zwischen den Threads wechseln. Zudem k¨onnen sie innerhalb eines Arbeitschrittes verzweigen, wie z.B. bei Rekursionen, und dadurch sehr komplexe Aufgaben bew¨altigen. GPU’s hingegen weisen eine Architektur auf, die darauf ausgelegt ist m¨oglichst viele Threads gleichzeitig zu erm¨oglichen. Die Abarbeitungsgeschwindigkeit der einzelnen Threads einer GPU ist im Allgemeinen nicht so hoch wie auf einer CPU. Daher werden GPU’s eher f¨ur stark parallelisierbare Aufgaben verwendet. Nicht jede Aufgabe kann mit einem parallelen Ansatz gel¨ost werden. Hierf¨ur muss gegeben sein, dass die Aufgabe in mehrere Teilschritte aufgeteilt werden kann. Diese Teilschritte m¨ussen komplett voneinander unabh¨angig sein, sprich die Teilaufgaben d¨urfen nicht von den Ergebnissen anderer Teilaufgaben abh¨angen. Weitere Probleme k¨onnen entstehen, wenn aus mehreren parallelen Abl¨aufen auf die selben Daten zugegriffen bzw. diese ver¨andert werden. In solchen F¨allen muss auf eine konsistente Datenhaltung geachtet werden, was in der Regel durch eine Synchronisierung der Arbeitsabl¨aufe realisiert wird. Eine solche Synchronisierung ist ein Kontrollmechanismus und wird immer in dem Code des Hauptprozessors ausgef¨uhrt. Folgende Grafik aus dem Jahr 2010, zeigt die Leistungsunterschiede zwischen den 6

Thread = Eine einzelner Ausf¨ uhrungsstrang eines Prozesses

Theoretische Grundlagen

9

damaligen Top-Modellen der CPU’s und GPU’s in einem Aufgabengebiet, das parallel bearbeitet werden kann. Hier aus dem Spezialgebiet der Berechnung von neuronalen Netzen durch die Firma und Anwendung NeuroSolutions. Sehr klar zu erkennen ist, dass die beste GPU bis zu 65 mal schneller zu einem Ergebnis kam als die CPU. NeuroSolutions CPU gegen NeuroSolutions CUDA (GPU) 3,16

24,19 Nvidia Tesla C2050 3GB Nvidia GTS 1GB 51,46

Nvidia 9500 GT 1GB

Intel® i7Core™ 920 @ 2.67 GHz 207,08 0

50

100

150

200

250

Simulationszeit in Sekunden (weniger ist besser)

Abbildung 4.1: Vergleich der Leistung von CPU vs GPU der Software NeuroSolutions Quelle: selbsterstellt auf Basis von http://www.neurosolutions. com/products/cuda/sample.html Eine Besonderheit von CUDA ist, dass ein Programm zu einem viel sp¨ateren Zeitpunkt, als dem seiner Erstellung auch noch von der h¨oheren Leistung zuk¨unftiger Grafikkarten profitiert. Hierf¨ur und um die Vielzahl an Threads zu koordinieren ist ein spezielles Konzept notwendig. In CUDA werden einzelne Threads in sogenannten Blocks“ gruppiert, welche wieder” um in einem Grid“ angeordnet sind. Beide Gruppierungen erlauben eine Anordnung ” in bis zu drei Dimensionen. Als Beispiel f¨ur die maximalen Gr¨oßen der Dimensionen werden die einer NVIDIA Geforce GTX 570 genannt:

Grid Block

X-Dimension 65535 1024

Y-Dimension 65535 1024

Z-Dimension 65535 64

Tabelle 4.2: Dimensionen von Grid/Blocks/Threads einer NVIDIA GTX 570 Hierbei ist jedoch noch die absolute Grenze von Threads innerhalb eines Blocks zu beachten. Dieser Wert variiert je nach Grafikkarten-Modell und kann von CUDA ausgelesen werden. Bei der GTX 570 ist die die h¨ochstm¨ogliche Anzahl an Threads innerhalb eines Blocks auf 1024 limitiert. Dies bedeutet, dass das Produkt aus den drei Dimensionen eines Blocks nicht 1024 u¨berschreiten darf. 64 x 8 x 2 w¨are beispielsweise zul¨assig, da es genau 1024 ergibt, ebenso wie 1024 x 1 x 1. Der Sinn einer Aufteilung

This decomposition preserves language expressivity by allowing threads to cooperate when solving each sub-problem, and at the same time enables automatic scalability. Indeed, each block of threads can be scheduled on any of the available processor cores, in any order, concurrently or sequentially, so that a compiled Theoretische Grundlagen 10 CUDA program can execute on any number of processor cores as illustrated by Figure 1-4, and only the runtime system needs to know the physical processor in mehrere Dimensionen ist dabei von der zu bearbeitenden Problemstellung und der count. Logik der L¨osung abh¨angig. This scalable programming model allows the CUDA architecture to span a wide Wichtig dass Zerlegung der Aufgaben bzw. and das memory Starten eines Kernels7 , marketist, range byCUDA simply die scaling the number of processors partitions: auf derthe großen Vielzahl an Threads, zur Laufzeit u¨bernimmt. So and kann from high-performance enthusiastautomatisch GeForce GPUs and professional Quadro Tesla computing products a variety of mehrere inexpensive, mainstream GeForce eine neuere Grafikkarte untertoUmst¨ anden Blocks parallel ausf¨ uhren,GPUs w¨ahrend (see Appendix A for a list of all CUDA-enabled GPUs). eine ¨altere die Blocks sequentiell abarbeiten muss. Multithreaded CUDA Program Block 0

Block 1

Block 2

Block 3

Block 4

Block 5 Block 5

Block 6 Block 6

Block 7

GPU with 2 Cores

GPU with 4 Cores

Core 0

Core 1

Core 0

Core 1

Core 2

Core 3

Block 0

Block 1

Block 0

Block 1

Block 2

Block 3

Block 2

Block 3

Block 4

Block 5

Block 6

Block 7

Block 4

Block 5

Block 6

Block 7

A multithreaded program is partitioned into blocks of threads that execute independently from each

other, so that a GPU with more cores will automatically execute Abbildung 4.2: Automatische Aufteilung von Bl¨ ockenthe beiprogram CUDAin less time than a GPU with fewer cores. Quelle: http://developer.download.nvidia.com/compute/ DevZone/docs/html/C/doc/CUDA_C_Programming_Guide.pdf

Figure 1-4. Automatic Scalability

4.4

Qt

Qt (engl. cute) ist ein unter der LGPL (1: GNU Lesser General Public Licence) stehendes Framework8 f¨ur die Programmiersprache C++ und stellt neben einer m¨achtigen

CUDA C Programming Guide Version 4.1 7 8

Kernel = CUDA-Funktion die von jedem Thread auf der GPU ausgef¨ uhrt wird Framework = Ein Programmierger¨ ust, welches spezifische Funktionen zur Verf¨ ugung stellt

5

Theoretische Grundlagen

11

Klassenbibliothek zus¨atzlich Werkzeuge zum Erstellen von grafischen Benutzeroberfl¨achen zur Verf¨ugung. Das Framework ist aktuell in der Version 4.8 verf¨ugbar und wird auf der Internetpr¨asenz9 kostenlos zum Download bereitgestellt. Die Klassenbibliothek beinhaltet neben grundlegenden Funktionen, wie z.B. dem Dateimanagement, der Unterst¨utzung von Multi-Threading10 und der Bereitstellung von speziellen komplexen Datentypen (QMap, QBitArray, QList, . . . ) auch erweiterte Funktionalit¨aten, wie z.B. zur Implementierung von graphischen Benutzeroberfl¨achen (GUI), der Bereitstellung von Datenbank- und Netzwerkoperationen, die Verarbeitung von XML-Dateien und vieles mehr. Ein wichtiger und zu erw¨ahnender Teil der Kernfunktionen von Qt ist der sogenannte Signal-Slot-Mechanismus. Dieser erm¨oglicht die Kommunikation zwischen definierten Objekten und stellt somit ein zentrales Element der Qt-Architektur dar. Der SignalSlot-Mechanismus erlaubt es das Signal S1 eines Objektes O1 mit einem Slot S2 eines Objektes O2 zu verbinden, sodass bei einer Emitierung von S1 , S2 aktiviert wird. Ein Signal bzw. ein Slot werden dabei durch Methoden der Objekte dargestellt und mittels einer Qt-spezifischen Syntax deklariert. Das Qt-Framework bietet u¨ber seine Funktionalit¨aten hinaus die Entwicklungsumgebung Qt Creator mit einem integrierten Designer f¨ur graphische Benutzeroberfl¨achen. Alternativ kann bei Bedarf das Qt-Framework in die Entwicklungsumgebung Microsoft Visual Studio integriert werden. Qt steht f¨ur die Betriebssysteme Windows, Linux und Mac OS X zur Verf¨ugung.

4.5

Client-Server Modell

Das Client-Server-Modell stellt eine mehrschichtige Architektur da, die eine Problemstellung auf zwei Programmteile aufteilt. Diese werden Server und Client genannt, wobei in dem Konzept nur ein Server, aber beliebig viele Clients verwendet werden. Die beiden Programme sind bis auf die Kommunikation miteinander komplett unabh¨angig und sind f¨ur die Bearbeitung unterschiedlicher Aufgabenbereiche verantwortlich. Die Kommunikation zwischen Server und Client erfolgt dabei u¨ber Anfragen und Antworten. Der Server ist hierbei passiv und wartet auf eine Anfrage eines Client. Der Client kann demnach Anfragen senden, die auf einen Dienst des Servers zugreifen. 9 10

http://qt.nokia.com/downloads engl. multi-threading = Nebenl¨aufigkeit. Bezeichnet das gleichzeitige Abarbeiten mehrerer Ausf¨ uhrungsstr¨ange innerhalb einer Anwendung

Theoretische Grundlagen

12

Client Client

Client

Client

Server

Client

Abbildung 4.3: Das allgemeine Client-Server ModellQuelle: selbsterstellt Diese Dienste sind Server-seitige Funktionen die etwas ausf¨uhren und auch Daten zur¨uck an den Client schicken k¨onnen. Unter speziellen Umst¨anden kann der Server selbst Client sein, wenn er wiederum f¨ur seine eigene Auftragsbearbeitung eine Anfrage an einen anderen Server senden muss.[Dad96] Da die Zugriffe von Clients auf den Server je nach Funktion des Servers dort Daten ver¨andern k¨onnen, und somit direkte Auswirkung auf zuk¨unftige Anfragen haben, unterteilt man die Dienste eines Servers in zwei Klassen. Die erste Klasse ist die der zustandsinvarianten Anfragen“, die besagt, dass die ” Anfrage keine Daten oder Objekte auf dem Server ver¨andert und somit keinen Einfluss auf die zuk¨unftigen Antworten des Servers nimmt. Dies ist jedoch nicht damit gleichzusetzen, dass stets die selben Ergebnisse vom Server geliefert werden, da serverseitige Ereignisse oder Zust¨ande, wie z.B. die Zeit eine Rolle spielen k¨onnen. Die zweite Klasse ist demnach die der zustands¨andernden Anfragen“. Diese k¨onnen Da” ten und Objekte auf dem Server ver¨andern und dadurch bei mehrmaligem Ausf¨uhren der selben Anfrage unterschiedliche Ergebnisse liefern. Dabei ist zu beachten, dass auch falsche oder unm¨ogliche Ergebnisse entstehen k¨onnen, wenn durch das Ver¨andern oder L¨oschen von Werten Fehler auftreten. Dies kann geschehen, wenn mehrere Clients gleichzeitig unkoordiniert auf dieselben Daten zugreifen.[CB09] Die Interaktion zwischen Server und Client kann synchron oder asynchron ablaufen. Dabei besteht der einzige Unterschied darin, dass bei einer synchronen Interaktion der

Theoretische Grundlagen

13

Client so lange seine Arbeit einstellt, bis er auf seine Anfrage eine Antwort vom Server erh¨alt. Bei einer asynchronen Interaktion w¨urde der Client seine Arbeit fortsetzen und die Antwort des Servers ereignisbasiert entgegennehmen und sp¨ater bearbeiten. Als Spezialfall gibt es noch eine Ein-Weg-Interaktion, bei der der Client auf seine Anfragen keine Antworten vom Server erwartet.[CB09]

5

TrueCrack Extended / TrueCrack Optimized

Die exakte Formulierung der vorhandenen Problematik bzw. des Problembereiches und die Aufstellung der daraus resultierenden Anforderungen an ein zu erstellendes Softwareprodukt, sind grundlegende Bestandteile des Softwareentwicklungsprozesses. Aufbauend auf den erhobenen Anforderungen kann ein Entwurf f¨ur die zu implementierende Software ausgearbeitet werden, der als Grundlage f¨ur die eigentliche Implementierung in einer Programmiersprache dient. Die folgenden Abschnitte gehen auf die drei Entwicklungsstufen Analyse (Problemstellung und Anforderungen), Entwurf und Implementierung von TrueCrack Extended und TrueCrack Optimized ein.

5.1

Problemstellung

Die grundlegende Problemstellung dieser Arbeit ist es, m¨oglichst performante W¨orterbuchattacken auf TrueCrypt-Volumes durchzuf¨uhren. Da es sich bei W¨orterbuchattacken um stark parallelisierbare Verfahren handelt, ist eine Ausf¨uhrung der entsprechenden Methoden auf einer CPU, die im Allgemeinen u¨ber wenige Kerne verf¨ugt, sehr ineffizient. Die Anwendung TrueCrack wird zu diesem Zweck als Basis genutzt und optimiert. Die Optimierung sollte einerseits die Verwendung von mehreren Grafikkarten innerhalb eines PCs, sowie eine Verbesserung des urspr¨unglichen Codes beinhalten. Ferner sollte eine Client-Server Architektur entwickelt werden, die TrueCrack in ein verteiltes System einbettet und somit beliebig skalierbar macht. Zus¨atzlich zu realisierende Funktionen waren die M¨oglichkeit lange Passwortlisten, sowie mehrere Listen und Header automatisch hintereinander abarbeiten lassen zu k¨onnen. Zudem sollten sowohl die Server als auch Clients u¨ber Terminals gestartet werden k¨onnen.

TrueCrack Extended / TrueCrack Optimized

5.2

15

Anforderungen

Eine Anforderung bezeichnet eine von der Software zu realisierende Eigenschaft. Da ein Anforderungskatalog im Allgemeinen aus einer Vielzahl an Anforderungen besteht, sind diese in logischen Gruppen zusammenzufassen, sodass sich jede Anforderungsgruppe auf einen bestimmten Teilbereich des Softwareproduktes bezieht. Die Gesamtheit aller Anforderungen bietet im weiteren Verlauf des Entwicklungsprozesses die Grundlage f¨ur den Entwurf. F¨ur die Weiterentwicklung von TrueCrack wurde ein Anforderungskatalog erstellt, der auf den Gespr¨achen zwischen der Studienprojektgruppe und dem Projektbetreuer, sowie Gespr¨achen innerhalb der Studienprojektgruppe basiert. Folgende Anforderungsgruppen (AG) konnten erstellt werden: • AG 1 : Erweiterung von TrueCrack - TrueCrack Optimized – AG 1.1 : Schnittstelle f¨ur weitere Algorithmen – AG 1.2 : Multi-GPU Erweiterung • AG 2 : Client-Server Anwendung - TrueCrack Extended – AG 2.1 : Anwendung als Server – AG 2.2 : Anwendung als Client Anforderungsgruppe 1 (AG 1) umfasst die Anforderungen bez¨uglich der bereits vorhandenen Software TrueCrack. Zum einen ist es w¨unschenswert ein TrueCrypt-Volume mit weiteren Algorithmen zu entschl¨usseln (aktuell sind nur AES und die Hashfunktion RIPEMD160 implementiert)(AG 1.1), zum anderen soll eine Multi-GPU Unterst¨utzung implementiert werden, sodass mehrere Grafikkarten eines Computers genutzt werden k¨onnen (AG 1.2). Anforderungsgruppe 2 (AG 2) umfasst die Anforderungen bez¨uglich der zu entwickelnden Client-Server Anwendung. Dabei soll die Serveranwendung die Verteilung der Informationen und Daten zu den Clients u¨bernehmen, sowie die Ergebnisse der Clients empfangen und auswerten. Die Clientanwendung f¨uhrt die entsprechenden Berechnungen durch und sendet ein Ergebnis an die Serveranwendung zur¨uck. Im Folgenden werden die sogenannten funktionalen Anforderungen f¨ur alle Anforderungsgruppen aufgelistet. Funktionale Anforderungen spezifizieren das Verhalten einer Software und bestimmen somit die Funktionen, die eine Software bereitstellen sollte. Die Bezeichnung einer funktionalen Anforderung besteht aus dem Buchstaben F (= funktionale Anforderung), sowie einer eindeutigen Nummer.

TrueCrack Extended / TrueCrack Optimized

16

Anforderungen der Anforderungsgruppe AG 1: /F0010/

TrueCrack muss in der Lage sein weitere Ver- bzw. Entschl¨usselungsalgorithmen zu benutzen /F0020/ TrueCrack muss in der Lage sein weitere Hashfunktionen zu benutzen /F0030/

TrueCrack muss u¨ber eine Schnittstelle f¨ur einen Entwickler verf¨ugen, u¨ber die weitere Algorithmen zum Code hinzugef¨ugt werden k¨onnen /F0040/ TrueCrack muss mehrere im Computer eingebaute Grafikkarten f¨ur die Berechnungen benutzen k¨onnen /F0050/ Durch eine Optimierung muss die Performanz von TrueCrack verbessert werden Anforderungen der Anforderungsgruppe AG 1.1: /F0060/

TrueCrack muss u¨ber eine Schnittstelle verf¨ugen, mit der die Liste der verwendeten Ver- bzw. Entschl¨usselungsalgorithmen und Hashfunktionen erweitert werden kann /F0070/ Diese Schnittstelle muss u¨ber die Codestruktur und/oder eine Benutzeroberfl¨ache realisiert werden Anforderungen der Anforderungsgruppe AG 1.2: /F0080/

Sind mehrere Grafikkarten in einem Computersystem verbaut, muss TrueCrack in der Lage sein, die Anzahl der Grafikkarten zu erkennen und auf diese zugreifen zu k¨onnen /F0090/ Zu pr¨ufende Passwortlisten und somit die Berechnungslast, m¨ussen auf alle verf¨ugbaren Grafikkarten auf geeignete Art und Weise verteilt werden

Anfoderungen der Anforderungsgruppe AG 2: /F0100/

Alle durchzuf¨uhrenden Operationen m¨ussen innerhalb einer ClientServer Anwendung zur Verf¨ugung stehen

Anforderungen der Anforderungsgruppe AG 2.1: /F0110/

Alle Berechnungen m¨ussen durch das Server-Modul gestartet und verwaltet werden k¨onnen /F0120/ Ein Benutzer muss u¨ber eine grafische Benutzeroberfl¨ache mit dem Server-Modul interagieren k¨onnen

TrueCrack Extended / TrueCrack Optimized /F0130/ /F0140/ /F0150/ /F0160/ /F0170/ /F0180/ /F0190/ /F0200/

/F0210/ /F0220/ /F0230/

/F0240/

/F0250/

17

Ein Benutzer muss das Server-Modul u¨ber u¨ber ein Linux-Terminal starten k¨onnen Die GUI muss eine Liste aller verbundenen Client-Anwendungen darstellen Die Client-Liste muss die folgenden Eigenschaften anzeigen: Angemeldet seit, Client-IP, Passw¨orter pro Sekunde, aktiv/inaktiv Der Benutzer muss die zur Verbindung ben¨otigten Ports frei ausw¨ahlen k¨onnen Der Benutzer muss die Gr¨oße der Passwort-Pakete, die an die verbundenen Client -Anwendungen gesendet werden, angeben k¨onnen Die GUI muss u¨ber einen Informationsbereich verf¨ugen, aus dem der Benutzer die Aktivit¨aten der Server-Anwendung ablesen kann Die Berechnungen m¨ussen jederzeit unterbrochen werden k¨onnen Das Server-Modul muss u¨ber einen Algorithmus verf¨ugen, der jedem Client automatisch neue Daten sendet, wenn dieser mit einer Berechnung fertig ist Ein Benutzer muss einen Ordner ausw¨ahlen k¨onnen, in dem die abzuarbeitenden Passwordlisten hinterlegt sind Ein Benutzer muss einen Ordner ausw¨ahlen k¨onnen, in dem die abzuarbeitenden Header-Files hinterlegt sind Das Server-Modul muss in der Lage sein alle Passwortlisten und Header in geeigneter Reihenfolge abzuarbeiten und zur Laufzeit neu hinzugef¨ugte Dateien automatisch zu erkennen Das Server-Modul muss sicherstellen, dass Passwortlisten immer vollst¨andig abgearbeitet werden, auch bei Verlust der Verbindung zu einem der Clients w¨ahrend der Berechnung. Das Server-Modul muss die Ergebnisse der Berechnungen in einer Ergebnis-Datei speichern.

Anforderungen der Anforderungsgruppe AG 2.2: /F0260/

Ein Benutzer muss die Client-Anwendung u¨ber ein Linux-Terminal starten k¨onnen /F0270/ Ein Benutzer muss die M¨oglichkeit haben nach dem Start der ClientAnwendung die Server-IP und die entsprechenden Ports anzugeben /F0280/ Der Client muss in der Lage sein, vom Server gesendete Datenpakete anzunehmen und entsprechend zu verarbeiten /F0290/ Der Client muss in der Lage sein die Anwendung TrueCrack aufzurufen und die entsprechenden Berechnungsergebnisse auszulesen

TrueCrack Extended / TrueCrack Optimized /F0300/

5.3

18

Der Client muss in der Lage sein, die Berechnungsergebnisse an die Server-Anwendung zu senden

Entwurf

Der Entwurf stellt den zweiten Teil der in diesem Studienprojekt verfolgten Prozesskette dar und basiert auf den in Abschnitt 5.2 zusammengestellten und definierten Anforderungen. Aus den Anforderungsgruppen AG 1 und AG 2 ergeben sich zwei Arbeitsbereiche. Zum einen die Erweiterung und Optimierung von TrueCrack und zum anderen die Entwicklung einer Client-Server Anwendung zur verteilten W¨orterbuchattacke mit Hilfe der erweiterten TrueCrack Anwendung. Der erste Abschnitt dieses Kapitels stellt den Entwurf der Client-Server Anwendung dar, der zweite Abschnitt geht auf die Erweiterung von TrueCrack ein.

5.3.1

Client-Server Anwendung

Die Server-Client Anwendung besteht aus zwei Modulen, die in einer Anwendung vereint sind. Das Server-Modul stellt alle Operationen zur Verf¨ugung, die ben¨otigt werden, um den Anforderungen der Anforderungsgruppe AG 2.1 gerecht zu werden. Das Client-Modul setzt entsprechend die Anforderungen der Anforderungsgruppe 2.2 um. Ein Benutzer kann beim Starten der Anwendung entscheiden, ob ein Server oder ein Client gestartet werden soll (siehe Abbildung 5.1). F¨ur beide Softwaremodule wird eine Architektur gew¨ahlt, die sich an das MVCMuster1 anlehnt. Da sich die Komplexit¨at beider Module jedoch im Rahmen h¨alt, wurde der Controller als Zwischeninstanz zwischen der Sicht (View) und dem Modell ¨ (Model) ausgelassen. Das in Abbildung 5.2 dargestellte Ubersichtsdiagramm visualisiert die gew¨ahlten Klassen und die entsprechenden Verbindungen. Dabei wird das ¨ Diagramm zur besseren Ubersicht einfach gehalten, Klassenmethoden und -attribute werden hier vernachl¨assigt. Dar¨uber hinaus werden Zugriffsschnittstellen, wie der Zugriff auf die optimierte Version von TrueCrack und der Zugriff auf die Softwaremodule durch den Benutzer dargestellt. Die Klassen ServerView und ServerModel stellen das Server-Modul dar, wobei die Klasse ServerView die Ansicht bzw. die Interaktionsebene mit dem Benutzer darstellt und die Klasse ServerModel das Fachkonzept des Moduls beinhaltet. Das Client-Modul 1

MVC = Model View Controller

TrueCrack Extended / TrueCrack Optimized

19

Server

Server starten

Programmstart Client starten

Client

Abbildung 5.1: Auswahl von Client oder ServerQuelle: selbsterstellt

Benutzer Klasse

Klasse

ServerView

ServerModel

GUI Methode

main() Klasse

Klasse

ClientView

ClientModel

Terminal

Anwendung

TrueCrack

¨ Abbildung 5.2: Ubersicht u¨ber die Client-Server StrukturQuelle: selbsterstellt

TrueCrack Extended / TrueCrack Optimized

20

besteht analog aus den zwei Klassen ClientView und ClientModel. Die Klasse ClientModel, als Fachkonzept des Client-Moduls, beinhaltet die Schnittstelle zur Anwendung TrueCrack Optimized, die die Berechnungen f¨ur W¨orterbuchattacken durchf¨uhrt. Server starten

Client Anmeldung

Client starten

TrueCrack Berechnungen

Sendet Datenpaket

Empfängt Datenpaket

TrueCrack starten

Ergebnisse empfangen

An Server senden

Passwort nicht gefunden

Abbildung 5.3: Beispielhafter Ablauf einer Verbindung von TrueCrack Extended Quelle: selbsterstellt Das in Abbildung 5.3 dargestellte Diagramm stellt einen exemplarischen Programmablauf dar. Startet ein Benutzer einen Server, so muss dieser vor Anmeldung eines oder mehrerer Clients konfiguriert werden. Die Konfiguration besteht aus der Auswahl der Passwort-Blockgr¨oße, sowie dem Data-Port und Control-Port. Die PasswortBlockgr¨oße bestimmt die Anzahl an Passw¨ortern, die jeweils zur Berechnung an einen Client u¨bergeben werden. Der Data-Port u¨bertr¨agt die eigentlichen Daten, wie die Passw¨orter und die Header-Datei, der Control-Port ist f¨ur den Versand von Steuerungsinformationen an die jeweilige Client-Anwendung zust¨andig. Durch die Steuerungsinformationen ist es z.B. m¨oglich einem Client mitzuteilen, dass ein richtiges Passwort bereits gefunden worden ist oder er die bestehende Verbindung beenden kann. Weiterhin muss ein Benutzer zwei Ordner des Dateisystems ausw¨ahlen. Der erste Ordner muss dabei eine oder mehrere Header-Dateien enthalten, im zweiten Ordner m¨ussen eine oder mehrere Passwortlisten als Textdatei hinterlegt sein. Befinden sich mehrere Header-Dateien im ausgew¨ahlten Ordner, so werden alle vorhandenen Passwortlisten f¨ur jede Header-Datei abgearbeitet. Die Bearbeitung einer Header-Datei ist genau dann abgeschlossen, wenn das richtige oder kein g¨ultiges Passwort gefunden wurde. Nachdem die Konfiguration des Servers durch einen Benutzer vorgenommen wor-

TrueCrack Extended / TrueCrack Optimized

21

den ist, kann eine Client-Anwendung auf einem anderen Computer gestartet werden. Dieser Computer muss sich daf¨ur mit der Server-Anwendung u¨ber ein LAN2 oder u¨ber das Internet verbinden k¨onnen. Die Client-Anwendung kann sich mit der Server-Anwendung verbinden, wenn die entsprechende Server-IP, sowie Data-Port und Control-Port gew¨ahlt wurden. Hat sich ein Client zum Server erfolgreich verbunden, wird die Header-Datei und der erste Passwortblock u¨ber den Data-Port an den Client u¨bertragen. Der Client empf¨angt diese Daten und leitet sie weiter zur Anwendung TrueCrack Optimized. Diese f¨uhrt die entsprechenden Berechnungen durch und erzeugt Ausgaben, die wiederum von der Client-Anwendung ausgelesen und u¨ber den Data-Port zur¨uck an die Server-Anwendung gesendet werden. Wurde das richtige Passwort f¨ur die aktuelle Header-Datei gefunden, gilt diese Datei als abgeschlossen und noch nicht gepr¨ufte Passw¨orter werden u¨bersprungen. Wurde das Passwort innerhalb des aktuell bearbeiteten Passwortblocks nicht gefunden, wird dem entsprechenden Client ein neuer Passwortblock zugewiesen. Sind alle Bl¨ocke der aktuellen Passwortliste abgearbeitet, wird zur n¨achsten Passwortliste gesprungen. Voraussetzung hierf¨ur ist, dass alle Clients ihre Berechnungen beendet haben. Ein vereinfachter Ablaufplan f¨ur das Szenario eines Servers mit mehreren angemeldeten Clients ist Abbildung 5.4 zu entnehmen. Sind mehrere Client-Anwendungen an der Berechnung beteiligt, so erh¨alt jeder Client bei seiner Anmeldung ein initiales Datenpaket, bestehend aus der Header-Datei und dem ersten Passwortblock. Ist ein Client mit seiner Berechnung fertig, so erh¨alt er direkt ein neues Datenpaket vom Server, sofern nicht das richtige Passwort gefunden wurde, oder alle in den Passwortdateien verf¨ugbaren Passw¨orter abgearbeitet wurden. Sind alle Passwortlisten abgearbeitet, wird zur n¨achsten Header-Datei gewechselt. Falls keine unbearbeiteten HeaderDateien mehr vorliegen, kann der Benutzer neue Verzeichnisse f¨ur Header-Dateien und/oder Passwortlisten ausw¨ahlen und den Berechnungsvorgang erneut starten.

5.3.2

Erweiterung von TrueCrack

Die Originalversion von TrueCrack ist strukturell in 4 Bereiche eingeteilt, die sich aus der Struktur der Quellcodedateien ergeben. Die Ordner Main und Common des TrueCrack-Projektes enthalten Quellcodedateien, die grundlegende Funktionalit¨aten zur Verf¨ugung stellen, sowie die Datei, die den Einstiegspunkt in die Anwendung enth¨alt. Der Ordner Crypto enth¨alt Quellcodedateien mit den Funktionen des Kryptosystems AES und der Hashfunktion RIPEMD160, basierend auf einer CPU-Implementierung. Der Ordner Cuda enth¨alt die Quellcodedateien mit den entsprechenden Funktionen f¨ur AES und RIPEMD160, basierend auf einer GPU-Implementierung f¨ur eine NVIDIAGrafikkarte. Im weiteren Verlauf wird lediglich auf die GPU-Implementierung von True2

LAN = Local Area Network

TrueCrack Extended / TrueCrack Optimized

22

Neuer Client Client 2

Client 1

Client 3

Initiales Datenpaket

gefunden

Ergebnis

Neues Datenpaket

Server

Beenden aller Berechnungen (nächste Header-Datei)

Abbildung 5.4: Beispielhafter Programmablauf bei mehreren Verbindungen Quelle: selbsterstellt Crack eingegangen, da diese im Rahmen des Studienprojektes von gr¨oßerer Relevanz ist. Abbildung 5.5 zeigt den strukturellen Ablauf von TrueCrack und relevante Teile des Gesamtprozesses, an denen eine Erweiterung vorgenommen wurde (Markierung mit einem gelben Balken). Nach einer Analyse des Quellcodes der originalen TrueCrack-Anwendung, konnten zwei Stellen ausfindig gemacht werden, an denen eine Optimierung durchgef¨uhrt werden kann. Dies betrifft die Initialisierung auf GPU-Ebene und den Aufruf des CUDAKernels. Da TrueCrack f¨ur die Nutzung einer einzigen GPU konzipiert wurde, wird diese GPU direkt angesprochen und die entsprechenden Funktionen f¨ur diese GPU ausgef¨uhrt. Um eine Multi-GPU Unterst¨utzung seitens TrueCrack zu erreichen, muss die Initialisierung, sprich der Kopiervorgang des Headers, des Salts und des Passwortblocks, sowie der Aufruf des CUDA-Kernels f¨ur jede im Computersystem vorhandene Grafikkarte durchgef¨uhrt werden.

Weiterhin kann eine Optimierung durch einen modifizierten Aufruf des CUDA-Kernels erreicht werden. Abbildung 5.6 zeigt den Ablauf der Berechnungen innerhalb des Kernels von TrueCrack. Hier wird pro zu testendem Passwort, genau ein Block mit je 10 Threads zugewiesen, die innerhalb des Kernels den Hash Header Key parallel berechnen. Die eigentliche Entschl¨usselung mittels des gegebenen Passwortes wird und kann jedoch nur durch einen Thread durchgef¨uhrt werden. Die u¨brigen 9 Threads

TrueCrack Extended / TrueCrack Optimized

23

Initialisierung Header und Passwörter Salt

Programmeinstiegspunkt

Kernel

Hash Header Key Berechnung

XTS Algorithmus

Initialisierung aller EntschlüsselungsAlgorithmus

Entschlüsselung

Abbildung 5.5: Skizzierter Ablauf von TrueCrack Optimized Quelle: selbsterstellt

CUDA-Kernel Blockgröße x , 10 Threads

T 1

T 2

T 3

T 4

T 5

T 6

T 7

T 8

T 9

Hash Header Key Berechnung

Entschlüsselung mit zugewiesenem Passwort

Leerlaufzeit

Ergebnis

Abbildung 5.6: Aufteilung der GPU-Threads in TrueCrack Original Quelle: selbsterstellt

T 10

TrueCrack Extended / TrueCrack Optimized

24

sind f¨ur diese Zeit stillgelegt, bis der berechnende Thread ein Ergebnis ausgibt. Hier kann eine Optimierung erzielt werden, indem f¨ur jedes Passwort nur 1 Thread alle Berechnungen durchf¨uhrt, daf¨ur jedoch pro Block 512 Threads gestartet werden. Dadurch ergeben sich mehrere Performanzvorteile. Dies beinhaltet dann die Berechnung des Hash Header Keys, sowie die eigentliche Entschl¨usselung. Zum einen k¨onnen wesentlich mehr Passw¨orter gleichzeitig an die Grafikkarte zur Berechnung u¨bergeben werden, wodurch weniger zeitaufwendige Kopiervorg¨ange notwendig sind, und zum anderen verringert eine h¨ohere Anzahl an Threads pro Block die Auswirkungen der Speicher-Latenzzeiten.

5.4

Implementierung

Die Implementierung basiert auf dem in Kapitel 4 vorgestellten Entwurf. Die ClientServer Anwendung TrueCrack Extended wird in der Programmiersprache C++ und dem QT-Framework umgesetzt. TrueCrack Optimized wird in der Sprache C und den vom CUDA-Framework zur Verf¨ugung gestellten Funktionen programmiert.

5.4.1

Client-Server Implementierung

Die Projektstruktur der Client-Server Anwendung ergibt sich aus dem in Abschnitt 5.3.1 gezeigten Klassendiagramm. Im Folgenden werden die einzelnen Dateien, sowie die enthaltenen Funktionalit¨aten beschrieben. main.cpp

Enth¨alt die Programmeinsprungsmethode main(...). Hier werden die Argumente, die ein Benutzer mit an das Programm geben kann bearbeitet. Entsprechend wird ein Server oder ein Client gestartet ServerModel.h Enth¨alt die Definition der Klasse ServerModel, sowie die Enumeration ClientStatus“ und die Enumeration ClientInfo“ ” ” ServerModel.cpp Enth¨alt alle Implementierung der in ServerModel.h definierten Methoden ClientModel.h Enth¨alt die Definition der Klasse ClientModel, sowie die Struktur DC Result“ (= decription result) ” ClientModel.cpp Enth¨alt alle Implementierungen der in ClientModel.h definierten Methoden ServerView.h Enth¨alt die Definition der Klasse ServerView inklusive der Anbindung an die Formulardatei ServerView.ui“ ” ServerView.cpp Enth¨alt alle Implementierungen der in ServerView.h definierten Methoden

TrueCrack Extended / TrueCrack Optimized ClientView.h ClientView.cpp ServerView.ui

25

Enth¨alt die Definition der Klasse ClientView Enth¨alt alle Implementierungen der in ClientView.h definierten Methoden Enth¨alt die Definition der grafischen Benutzeroberfl¨ache des Servers im XML-Format

Die Dateien AboutWindow.h, AboutWindow.cpp und AboutWindow.ui dienen lediglich zur Anzeige des Informationsfensters der Server-/Client-Anwendung und werden im weiteren Verlauf nicht weiter betrachtet. Die Client-Anwendung wird mit Erzeugung eines Objektes der Klasse ClientView gestartet (siehe Codeausschnitt 5.1).

Codeausschnitt 5.1: Erstellung der Client-Anwendung 1 2

ClientView * clientView = new ClientView () ; clientView - > start () ;

Die Methode start() erzeugt ein Objekt der Fachkonzeptklasse ClientModel und wartet auf die Eingabe der Server-IP-Adresse und der Ports, bevor mit der Methode clientModel→initialize() die Verbindung zum Server aufgebaut wird. Die Verbindung des Daten-Sockets zum Server innerhalb der Klasse ClientModel wird exemplarisch im Codeausschnitt 5.2 dargestellt.

Codeausschnitt 5.2: Verbindung des Daten-Sockets zum Server 1 2 3 4 5 6 7 8 9 10 11 12 13

// Initialize sockets dataSocket = new QTcpSocket ( this ) ; // Setup dataSocket connect ( dataSocket , SIGNAL ( connected () ) , this , SLOT ( slo tDataC onnect ed () ) ) ; connect ( dataSocket , SIGNAL ( readyRead () ) , this , SLOT ( re ce iv eD ec ry pt In fo () ) ) ; // Connect the dataSocket to receive TrueCrack data dataSocket - > connectToHost ( serverAddress , i_dataPort ) ; // Check if connection successfull if (! dataSocket - > waitForConnected (1000) ) return false ; // Timeout

Der Signal-Slot-Mechanismus des QT-Framework kann an dieser und vielen weiteren

TrueCrack Extended / TrueCrack Optimized

26

Stellen im Code sehr gut zur Kommunikation zwischen Objekten genutzt werden. Im Codeausschnitt 5.2 wird in Zeile 5 das Signal readyRead“ mit der Slot-Methode re” ” ceiveDecryptInfo“ verbunden. Diese wird somit aufgerufen, wenn Daten vom Server an den Client gesendet wurden. Innerhalb dieser Methode werden die empfangenen Daten in der richtigen Reihenfolge ausgelesen und in die entsprechenden Variablen geschrieben. Es muss zuerst eine Information u¨ber die Gr¨oße des Passwortblocks empfangen worden sein, damit der Header und der Passwortblock empfangen werden k¨onnen. Wurden alle Daten erfolgreich vom Server zum Client u¨bertragen, ruft die Client-Anwendung die Anwendung TrueCrack Optimized mit den empfangenen Daten auf. Dies geschieht in der Methode startHeaderDecryption“ der Klasse ClientModel. ” TrueCrack Optimized wird dabei als Unterprozess der Client-Anwendung gestartet, wobei der Programmaufruf mit den entsprechenden Argumenten durchgef¨uhrt wird, wie in Codeausschnitt 5.3 zu sehen ist.

Codeausschnitt 5.3: TrueCrack Optimized Programmaufruf 1 2 3 4 5 6 7 8 9 10 11 12

QObject * parent = new QObject () ; QProcess * tcProcess = new QProcess ( parent ) ; connect ( tcProcess , SIGNAL ( r e a d y R e a d S t a n d a r d O u t p u t () ) , this , SLOT ( g e tD e c ry p t io n R es u l t () ) ) ; QStringList args ; args n e x t P e n d i n g C o n n e c t i o n () ; QString ipAdress = dataSocket - > peerAddress () . toString () ; // Connect controlSocket to readyRead () - Signal to receive results from client connect ( dataSocket , SIGNAL ( readyRead () ) , this , SLOT ( r ec e i v eC l i en t R es u l t () ) ) ; // lock Mutex to synchronise access of the clientList mutex - > lock () ; // Check if client is already in list if ( clientList . contains ( ipAdress ) ) { ClientInfo * client = clientList . value ( ipAdress ) ; client - > dataSocket = dataSocket ; client - > i _ f i n i s h e d P a s s w o r d s C o u n t = 0; client - > runsSinceDate = QDate :: currentDate () ; client - > runsSinceTime = QTime :: currentTime () ; } else { ClientInfo * client = new ClientInfo ; client - > dataSocket = dataSocket ; client - > status = Idle ; client - > b _ w a i t i n g F o r R e s p o n s e = false ; client - > i _ f i n i s h e d P a s s w o r d s C o u n t = 0; client - > lastBlock . clear () ; client - > runsSinceDate = QDate :: currentDate () ; client - > runsSinceTime = QTime :: currentTime () ; clientList . insert ( ipAdress , client ) ; } // unlock Mutex mutex - > unlock () ; // Send decrypt information sendDecryptInfo ( dataSocket ) ;

Damit die Server-Anwendung zu jedem Zeitpunkt Informationen dar¨uber hat, ob ein Client noch verbunden ist, er gerade Berechnungen durchf¨uhrt oder die Verbindung nicht mehr besteht, da der entsprechende Computer evtl. abgest¨urzt ist, sendet die Server-Anwendung in regelm¨aßigen Abst¨anden ein sogenanntes Keep-Alive-Signal zu allen verbundenen Clients. Dazu wird die Methode keepAliveCheck“ der Klasse ser” verModel durch einen QTimer aufgerufen. Codeausschnitt 5.9 zeigt den Inhalt der Methode keepAliveCheck“. ”

TrueCrack Extended / TrueCrack Optimized

30

Codeausschnitt 5.9: Keep-Alive Methode des Servers 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

// Check if at least 1 client available if (! clientList . isEmpty () ) { // Close all sockets QMapIterator < QString , ClientInfo * > i ( clientList ) ; // Variable to check if all clients are finished bool b _ a l l C l i e n t s F i n i s h e d = true ; while ( i . hasNext () ) { i . next () ; ClientInfo * client = i . value () ; // Check if server is still waiting for a keep - alive response if ( client - > b _ w a i t i n g F o r R e s p o n s e ) { // Check if client was registered as " Running " if ( client - > status == Running ) { // Put current client block back on pwBlickList pwBlockList . append ( client - > lastBlock ) ; } if ( client - > status != Not_Responding ) { // Set client as Not_Responding client - > status = Not_Responding ; // Set bool b _ a l l C l i e n t s F i n i s h e d = false ; } } // Keep alive request signal (5) qint64 stillAlive = 5; // Send signal client - > controlSocket - > write (( const char *) & stillAlive , sizeof ( qint64 ) ) ; // Set wai ti ng Fo rR es po ns e client - > b _ w a i t i n g F o r R e s p o n s e = true ; // Check if client is still running if ( client - > status == Running ) b _ a l l C l i e n t s F i n i s h e d = false ; } if (! b _ a l l C l i e n t s F i n i s h e d ) { d i s t r i b u t e D e c r y p t i o n D a t a () ; } else if ( pwBlockList . empty () ) // Make sure all PW Blocks have been processed { log ( " All clients are finished and no password has been found \ nfor header file so far , switching to next password file .\ n " ) ; r e a d N e x t P a s s w o r d F i l e () ; d i s t r i b u t e D e c r y p t i o n D a t a () ; }

45 46

47 48 49 50

}

TrueCrack Extended / TrueCrack Optimized

31

Die Methode keepAliveCheck“ pr¨uft den Status von jedem Client, der in der Client” Liste hinterlegt ist. Falls die Server-Anwendung ein Keep-Alive-Signal an einen Client gesendet, aber nach dem durch den Timer definierten Zeitintervall noch keine Antwort erhalten hat, wird gepr¨uft, ob der Client zur vorherigen Zeit Berechnungen durchgef¨uhrt hat oder nicht. Ist ersteres der Fall, so wurden die Berechnungen des entsprechenden Passwortblocks nicht fertiggestellt und dieser Passwortblock muss anderen verbundenen Clients zur Verf¨ugung stehen. Daf¨ur wird er an die gesamte Passwortblockliste angeh¨angt. Um zu gew¨ahrleisten, dass kein Passwortblock verloren geht, sprich nicht berechnet wird, wird mit der Methode distributeDecryptionData“ ” daf¨ur gesorgt, dass im Falle, dass alle restlichen Bl¨ocke an die Clients verteilt wurden, der Block einer abgebrochenen Berechnung von einem anderen Client u¨bernommen werden kann, obwohl die restlichen Clients bereits davon ausgegangen sind, dass die aktuelle Passwortliste vollst¨andig berechnet worden ist. Wurde eine Passwortliste vollst¨andig abgearbeitet, d.h. alle Passwortbl¨ocke wurden von den Clients berechnet, so wird zur n¨achsten Passwortliste gewechselt und die Berechnungen werden auf die gleiche Weise fortgesetzt.

5.4.2

Implementierung der Optimierungen von TrueCrack

Die angestrebten Optimierungen von TrueCrack sind einerseits eine Erweiterung des Codes, sodass mehrere vorhandene Grafikkarten - falls vorhanden - eines PC’s automatisch f¨ur die Berechnungen verwendet werden. Andererseits gilt es den vorhandenen Code f¨ur eine bessere allgemeine Performanz zu optimieren. Die Aufteilung der Rechenlast auf mehrere Grafikkarten muss vom Programmierer u¨bernommen werden, da CUDA die automatische Aufteilung nicht beherrscht. Bevor eine Aufteilung f¨ur mehrere Grafikkarten vorgenommen werden kann, muss jedoch zun¨achst ermittelt werden, wie viele CUDA-f¨ahige Grafikkarten in dem System verf¨ugbar sind. Dies wird u¨ber die CUDA-interne Funktion cudaGetDeviceCount(X)“ ” realisiert, die in die u¨bergebene Variable X“ die entsprechende Anzahl speichert. Es ” ist dabei nicht notwendig die Grafikkarten im sogenannten SLI“-Modus von NVIDIA ” zu betreiben, da mit CUDA auch auf voneinander separierte Grafikkarten zugegriffen werden kann. Zun¨achst gilt es die vorhandenen Initialisierungsschritte im Code so anzupassen, dass diese automatisch f¨ur alle Grafikkarten ausgef¨uhrt werden. Diese Schritte beinhalten ¨ das Reservieren von Speicher auf der Grafikkarte, sowie das Ubermitteln der zu be-

TrueCrack Extended / TrueCrack Optimized

32

rechnenden Daten. Mit der Funktion cudaGetDeviceCount(X)“ wird definiert, mit ” welcher Grafikkarte der darauf folgende Code ausgef¨uhrt werden soll. X“ gibt dabei ” die Nummer der Grafikkarte im System an, beginnend bei 0. Um beide Initialisierungsschritte f¨ur alle Grafikkarten durchzuf¨uhren, werden die hierf¨ur zust¨andigen Funktionen zun¨achst um Parameter f¨ur die zu initialisierende Grafikkarte erweitert. Daraufhin k¨onnen die Funktionen von außen, in einer Schleife, die u¨ber die Anzahl der Grafikkarten iteriert, aufgerufen werden. Im folgenden Codeausschnit 5.10 sind die beiden Aufrufe der Initialisierungsfunktionen cuda Init()“ und cuda Set()“ ” ” in der Datei Core.c“ zu sehen, wobei erstere den Speicher reserviert und letztere die ” zur Berechnung ben¨otigten Daten in den Grafikkartenspeicher kopiert. Dabei erh¨alt jede Grafikkarte dieselben Daten zur Berechnung.

Codeausschnitt 5.10: Aufruf der Initialisierungsfunktionen 1 2 3 4 5

for ( i =0; i < GPU_N ; i ++) cuda_Init ( CORE_blocksize , salt , header , i ) ; for ( i = 0; i < GPU_N ; i ++) cuda_Set ( block_size , blockPwd , blockPwd_init , blockPwd_length , result , i ) ;

Damit nicht alle Grafikkarten dieselben Passw¨orter berechnen, wird auf eine ModuloRechenoperation zur¨uckgegriffen. Die Modulo-Operanden sind hierbei Grafikkartennummer im System, sowie die Gesamtanzahl der verf¨ugbaren Grafikkarten. Somit kann jeder Grafikkarte anhand ihrer Reihenfolge im System ein eindeutiger Wert in ¨ der Aquivalenzklasse zugewiesen werden. Durch die Schachtelung der Rechenschritte in eine Modulo-Abfrage entscheidet somit jede Grafikkarte, bei der Ausf¨uhrung des Kernels, anhand ihrer Reihenfolge, welche Daten sie zu berechnen hat und welche sie auslassen soll. Die eindeutige Zuweisung durch das Modulo stellt dabei sicher, dass keine Passw¨orter aus der Liste doppelt berechnet, oder ausgelassen werden. F¨ur die Pr¨ufung und Berechnung mit der Modulo-Operation wird die Funktion cu” da Kernel“ um weitere Parameter erweitert. Der erste zus¨atzliche Parameter gibt die Grafikkartennummer an, der andere die Anzahl der vorhandenen Grafikkarten. Da der cuda Kernel“ von der Funktion “cuda Core” aufgerufen wird, die wiederum erst ” durch den Hauptprozessor aufgerufen wird ist es notwendig die gleichen Parameter auch in der cuda Core“ hinzuzuf¨ugen. Der folgende Codeausschnitt 5.11 zeigt den ” Aufruf der Funktion cuda Core“, welcher in einer Schleife realisiert wurde, die u¨ber ” die Anzahl der vorhandenen Grafikkarten iteriert.

TrueCrack Extended / TrueCrack Optimized

33

Codeausschnitt 5.11: Aufruf der Cuda-Core Funktion 1 2

for ( i = 0; i < GPU_N ; i ++) cuda_Core ( result , i , GPU_N ) ;

F¨ur eine weitere Optimierung der Rechenleistung, ohne Zuschalten weiterer HardwareKomponenten wird der Code auf Optimierungsm¨oglichkeiten untersucht. Dabei f¨allt zun¨achst auf, dass durch die begrenzte maximale Blockgr¨oße mehr Speicheroperationen notwendig sind. Es wird jeweils ein Block einzeln in den Grafikkarten-Speicher kopiert und dann abgearbeitet. Das Kopieren von Daten in den globalen Speicher der Grafikkarte ist sehr zeitaufwendig und sollte soweit wie m¨oglich vermieden werden. Um die Speicherzugriffe zu reduzieren, wird die Struktur des Kernels angepasst, sprich der auf den Grafikkarten auszuf¨uhrende Code. Bislang wurde pro aufgerufenen Block ein Passwort berechnet, indem zun¨achst 10 Threads den Header-Key f¨ur ein Passwort berechnet haben und anschließend von einem einzelnen Thread die Entschl¨usselung durchgef¨uhrt wurde. Dabei d¨urfen nach CUDA-Spezifikationen nur maximal 65535 Bl¨ocke pro Dimension, gleichzeitig zur Abarbeitung der Grafikkarte u¨bergeben werden. Im Original-TrueCrack bedeutet dies also, dass man h¨ochstens 65535 Passw¨orter innerhalb eines Speicherzugriffes der Grafikkarte u¨bermitteln kann. Der Kernel wird nun so umstrukturiert, dass ein einzelner Thread alle 10 Teile der ¨ Header-Key-Berechnung und zudem die Entschl¨usselung durchf¨uhrt. Diese Anderung erm¨oglicht es pro Block mehr Threads zu starten, die jeweils ein eigenes Passwort berechnen. Dadurch wird die Grenze der mit einem Speicherzugriff maximal zu u¨bertragenen Passw¨orter um den Faktor 51,2 erh¨oht, da pro Block 512 Threads gestartet werden. Dieser Wert spiegelt den maximalen Wert pro Block wieder, der mit allen CUDA-Versionen, also auch ¨alteren Grafikkarten kompatibel ist. Somit k¨onnen bis zu 33.553.920 Passw¨orter mit einem Speicherzugriff in den globalen Speicher der Grafikkarte kopiert werden, sofern gen¨ugend Grafikspeicher vorhanden ist. Original TrueCrack: Codeausschnitt 5.12: Aufruf des Kernels von Original TrueCrack 1 2

cuda_Kernel < < < blockGridSizeCurrent , 10 > > >( dev_salt , dev_header , dev_blockPwd , dev_blockPwd_init , dev_blockPwd_length , dev_result ) ;

TrueCrack Optimized:

TrueCrack Extended / TrueCrack Optimized

34

Codeausschnitt 5.13: Aufruf des Kernels von TrueCrack Optimized 1 2 3 4

int threadCount = 512; int gridSize = b l o c k G r i d S i z e C u r r e n t / threadCount ; cuda_Kernel < < < gridSize , threadCount > > >( dev_salt , dev_header , dev_blockPwd , dev_blockPwd_init , dev_blockPwd_length , dev_result , GPU_number , device_modulo , 0) ;

Ein zus¨atzlicher Effekt der Erh¨ohung der Anzahl an Threads ist eine bessere Auslastung der Grafikkarte. Dies ist darin begr¨undet, dass jede Grafikkarte nur eine begrenzte Anzahl an aktiven Bl¨ocken unterst¨utzt. Bei dem Original-TrueCrack blockiert der einzelne Thread, der f¨ur die Entschl¨usselung zust¨andig ist, f¨ur die Zeit der Entschl¨usselung einen gesamten Block. Als Ergebnis der Optimierung k¨onnen u¨ber die gesamte Laufzeit immer mehrere Threads in einem Block parallel aktiv sein, da die Arbeitsschritte voneinander unabh¨angig sind. Bei der optimierten Version muss zus¨atzlich ein Ausnahmefall abgefangen werden, um die vollst¨andige Bearbeitung aller Passw¨orter zu gew¨ahrleisten. Dieser Fall tritt ein, wenn TrueCrack eine Passwortliste u¨bergeben wird, die nicht durch 512 teilbar ist. Die Passw¨orter werden wegen der Thread-Anzahl auf Bl¨ocke ´a je 512 Passw¨orter aufgeteilt, daher entsteht bei einem nicht-Vielfachem von 512 ein Rest. Dieser Fall wird abgefangen, indem mit einer Modulo-Operation gepr¨uft wird ob ein Block mit weniger als 512 W¨ortern berechnet werden muss. Wenn dies eintritt, wird die Anzahl der restlichen Passw¨orter berechnet und die zu startende Thread-Anzahl auf den entsprechenden Wert reduziert. Zus¨atzlich wird die Funktion cuda Kernel“ um ” einen weiteren Parameter erweitert, u¨ber den ein Offset u¨bergeben werden kann. Dieser Offset gibt an, wieviele Passw¨orter bereits berechnet wurden, damit mit der ¨ Uberpr¨ ufung der Passw¨orter an dieser Stelle der Passwortliste fortgesetzt wird. Somit ist sichergestellt, dass dem Programm beliebig lange Passwortlisten u¨bergeben werden k¨onnen. Der folgende Codeausschnitt 5.14 beschreibt die Implementierung dieser Probleml¨osung.

Codeausschnitt 5.14: Implementierung beliebig langer Passwortlisten 1 2 3 4 5 6 7

if ( b l o c k G r i d S i z e C u r r e n t % threadCount != 0) { int offset = gridSize * threadCount ; gridSize = 1; threadCount = b l o c k G r i d S i z e C u r r e n t % threadCount ; c u d a T h r e a d S y n c h r o n i z e () ; cuda_Kernel < < < gridSize , threadCount > > >( dev_salt , dev_header , dev_blockPwd ,

TrueCrack Extended / TrueCrack Optimized 8 9 10

35

dev_blockPwd_init , dev_blockPwd_length , dev_result , GPU_number , device_modulo , offset ) ; }

5.4.3

Erweiterung von TrueCrack um weitere Verschlu ¨sselungsalgorithmen

F¨ur die Erweiterung von TrueCrack um weitere Algorithmen sind Eingriffe im Code und eine anschließende Neukompilierung notwendig. Es sind bereits Vorkehrungen getroffen, um weitere Hash- sowie Entschl¨usselungsalgorithmen zu implementieren. Die entsprechenden Funktionen und der Ablauf der Algorithmen sind dabei aus der offiziellen Dokumentation von TrueCrypt zu entnehmen. Ferner ist eine Anpassung des TrueCrack-Codes notwendig, die die Funktionalit¨at in CUDA-Code u¨bertr¨agt und somit Berechnungen mit GPU’s erm¨oglicht. Vor der Erweiterung von TrueCrack um weitere Algorithmen gilt es festzulegen, auf welche Art die verschiedenen Algorithmen aufgerufen werden sollen. Es ist einerseits denkbar durch zus¨atzliche Parameter eine Auswahl verschiedener Algorithmen zu erm¨oglichen. Andererseits, ¨ahnlich wie im originalen TrueCrypt, kann f¨ur jedes Passwort nacheinander jede Kombination aus Entschl¨usselungsalgorithmus und Hashfunktion getestet werden. F¨ur die Adaption des TrueCrypt-Konzeptes sind einige Aufrufe von Funktionen in teilweise geschachtelte Schleifen zu setzen, sowie eine Anpassung der Ergebnisausgabe notwendig. Eine M¨oglichkeit die Ergebnisausgabe anzupassen ist eine Vergr¨oßerung des Ergebnis-Arrays, sodass f¨ur jede Kombination aus getesteten Hash- und Entschl¨usselungsalgorithmen separate Eintr¨age f¨ur Erfolg oder Misserfolg eines Versuchs vorhanden sind. Zus¨atzlich ist es dann notwendig das Eintragen der Werte in diese Liste, durch den Kernel, u¨ber einen speziellen Offset zu regeln, der je nach benutzter Kombination errechnet wird. Die folgenden Beschreibungen sind darauf beschr¨ankt, dass alle Algorithmen automatisch durchlaufen werden sollen. Zudem wird auf eine Beschreibung der Erweiterung des Codes, f¨ur reine CPU Berechnungen, um weitere Algorithmen verzichtet, da die CPU-Berechnungen aufgrund des geringeren Durchsatzes nicht relevant sind. Um den GPU-Teil von TrueCrack um weitere Hash-Algorithmen zu erweitern, muss in der Datei CudaCore.cu“ ab Zeile 49 die Funktion global void cuda Kernel(...)“ ” ” umstrukturiert werden. Die Funktion cuda Pbkdf2(...)“, welche die Hash-Funktion ”

TrueCrack Extended / TrueCrack Optimized

36

RIPEMD160 implementiert, ist dabei zusammen mit weiteren Hash-Algorithmen in eine Schleife zu setzen. Diese Schleife iteriert u¨ber alle vorhandenen Hash-Algorithmen und f¨uhrt dabei den restlichen Code der Funktion global void cuda Kernel(...)“ ” f¨ur jeden Hash-Algorithmus aus. ¨ Zum Einbinden neuer Entschl¨usselungsalgorithmen sind Anderungen in den Dateien CudaCore.cu“ und CudaXTS.cu“ notwendig. Zun¨achst gilt es in der Datei Cu” ” ” daXTS.cu“ (Zeile 397) und CudaXTS.cuh“(Zeile 111) die Funktion cuda Xts(...)“ ” ” um einen Parameter zu erweitern, u¨ber den die Art des Entschl¨usselungsalgorithmus u¨bergeben werden kann. Dieser Parameter wird dann in der Zeile 416 bei cryptoInfo→ ” ea=AES;“ anstatt dem statischem AES“ u¨bergeben. Eine Enumeration (Enum) f¨ur ” AES, Serpent und Twofish ist im Code bereits vorhanden. In der Datei CudaXts.cu“ sind die beiden Funktionen cuda EncipherBlock(...)“ ” ” (ab Zeile 117) und cuda DecipherBlock(...)“ (ab Zeile 129) in den switch-case” Anweisungen um die entsprechenden Algorithmen zum Ver-/Entschl¨usseln zu erweitern. Schließlich muss in der Datei CudaCore.cu“ in der schon bestehenden Schleife ” f¨ur die Hash-Algorithmen eine weitere, innere Schleife, hinzugef¨ugt werden. Diese iteriert u¨ber alle Entschl¨usselungsalgorithmen, sodass durch beide Schleifen alle Kombinationen aus Hashfunktionen und Entschl¨usselungsalgorithmen erzeugt werden.

6

Leistungstests

Im folgenden Kapitel wird das entwickelte System auf verschiedene Arten getestet und mit der urspr¨unglichen Version von TrueCrack verglichen. Zus¨atzlich zu dem angestrebten Leistungsgewinn sollen eventuell auftretende Schw¨achen des Systems ermittelt und somit neue Ansatzpunkte f¨ur Verbesserungen aufgezeigt werden.

6.1

Testbedingungen

Als Testsysteme stehen drei verschiedene PC-Systeme zur Verf¨ugung, die jeweils eine unterschiedliche Grafikkarte besitzen. Die einzige Gemeinsamkeit aller Grafikkarten ist, dass sie die selbe Anzahl maximaler Threads pro Block, n¨amlich 1024, verarbeiten k¨onnen. Ein System mit mehr als einer CUDA-f¨ahigen Grafikkarte steht leider nicht zur Verf¨ugung. GPU Name

Anzahl Cuda

GPU

Shader

Speicher

Kerne

Speicher

Taktung

Taktung

GTX 460

336

1024 MB

1,40 GHz

1,80 GHz

GTX 560

336

1024 MB

1,66 GHz

2,00 GHz

GTX 570

480

1280 MB

1,50 GHz

1,95 GHz

F¨ur die Tests des Server/Client-Systems wird u¨ber das Internet ein virtuelles privates Netzwerk eingerichtet, in dem die Kommunikation zwischen den einzelnen Teilnehmern stattfindet. Hierf¨ur wird der PC mit der Grafikkarte GTX 460 zum Server deklariert, auf den beiden anderen PCs wird der Client gestartet.

6.2

Testszenarien

Um vergleichbare Werte zu erhalten m¨ussen die Original-, Optimized- und ExtendedVersionen von TrueCrack soweit m¨oglich, mit den selben Parametern sowie identischen Header und Passw¨ortern getestet werden. Hierf¨ur werden zun¨achst einheitliche Passwortlisten erstellt, die nur Passw¨orter der L¨ange 10 enthalten. Die Anzahl in den Listen betr¨agt dabei 1.000, 10.000, 100.000 und 1.000.000 Passw¨orter. Der zu ent-

Leistungstests

38

schl¨usselnde Header bleibt stets in allen Tests gleich. Eine zus¨atzliche Variable in den Tests ist die zu verwendende Blockgr¨oße, d.h. die Anzahl der Passw¨orter die in einem Durchlauf von der GPU bearbeitet werden sollen. Je gr¨oßer die Blockgr¨oße, desto weniger Durchl¨aufe werden ben¨otigt, was wiederum in weniger Kommunikation zwischen CPU und GPU resultiert. Es wird hierbei eine Abweichung der Ergebnisse, bei unterschiedlichen Blockgr¨oßen, bei beiden Versionen von TrueCrack, erwartet. Die verwendeten Blockgr¨oßen sind 10%, 50% und 100% der Gesamtzahl zu berechnender Passw¨orter aus der Passwortliste. Bei dem Original-TrueCrack liegt die Obergrenze f¨ur die Blockgr¨oße jedoch bei 65535, daher kann der letzte Testlauf von 100.000 W¨ortern nicht mit 100% berechnet werden. Es wird hierbei der Wert auf die Obergrenze 65535 gesetzt. Der Testlauf mit 1.000.000 W¨ortern wird f¨ur das OriginalTrueCrack entsprechend nur einmalig mit 65535 durchgef¨uhrt. Beide TrueCrack Versionen werden dabei in der Konsole ohne laufende grafische Oberfl¨ache ausgef¨uhrt, damit die Grafikkarte nicht von anderen Prozessen beeintr¨achtigt wird. Es wird die Zeit gemessen, die f¨ur eine Passwortdatei mit entsprechender Blockgr¨oße ben¨otigt wird. Dies geschieht mit dem “time” Befehl unter Linux. Dieser Befehl zeigt die Ausf¨uhrungszeit einer Anwendung nach dessen Beendigung an. Aus der ben¨otigten Zeit und den berechneten Passw¨ortern wird anschließend die Leistung in Passw¨orter/Sekunde ermittelt. F¨ur den Test des Client/Server-Systems werden Blockgr¨oßen von 5%, 10%, 25% und 50% verwendet. Dass h¨ochstens 50% verwendet werden erschließt sich daraus, dass 2 Clients gleichzeitig angemeldet werden und daher die Arbeit bei h¨oheren Werten nicht mehr gleichm¨aßig aufgeteilt werden k¨onnte. Ferner werden nur Passwortlisten der L¨ange 100.000 und 1.000.000 verwendet. F¨ur die Auswertung wird zudem auf die Statistiken des Servers zugegriffen, aus denen die Leistung in W¨ortern/Sekunde sowie die Gesamtanzahl der verarbeiteten Passw¨orter f¨ur jeden Client entnommen werden kann.

6.3

Testergebnisse und Auswertung

Alle Testl¨aufe wurden ohne Abst¨urze oder andere Probleme absolviert, daher kann auf vollst¨andige Testergebnisse zur¨uckgegriffen werden. Zun¨achst wird der Unterschied der Leistung der Kernfunktion, also dem Entschl¨usseln von Passw¨orter untersucht.

Leistungstests

39

Zu zeigen ist, in welchem Ausmaß die Leistung von TrueCrack gesteigert werden konnte. Hierf¨ur wird der Durchsatz in Passw¨orter/s f¨ur verschiedene Passwortmengen miteinander verglichen. Um einen guten Verlauf der Leistungssteigerung zu erhalten wird der relative Leistungszuwachs betrachtet. Der Leistungszuwachs bezieht sich hierbei auf die jeweilige Passwortmenge und dessen gr¨oßtm¨ogliche Blockgr¨oße. Die Blockgr¨oße ist dabei f¨ur TrueCrack Optimized gleich der Anzahl der Passw¨orter, bei der originalen Version hingegen, liegt sie ab 100.000 W¨ortern bei 65535. Die folgende Grafik (Grafik 6.1) zeigt die berechnete Leistungssteigerung f¨ur die entsprechenden Blockgr¨oßen sowie einen Graph f¨ur den Verlauf. Hierf¨ur wird die prozentuale Mehrleistung von TrueCrack Optimized gegen¨uber dem Original berechnet.

relative Leistung von TrueCrack Optimized zu TrueCrack Original 500% 450%

400%

Leistung

350% 300% 250% 200% 150% 100% 50% 0%

1.000

10.000

100.000

1.000.000

GTX 460

90,39%

362,10%

449,64%

459,11%

GTX 560

89,41%

353,20%

449,53%

459,39%

GTX 570

52,92%

281,42%

467,31%

474,97%

Steigerung nach Anzahl Passwörter

Abbildung 6.1: Relative Leistung von TrueCrack Optimized zu TrueCrack Original Quelle: selbsterstellt Eine interessante Beobachtung ist, dass TrueCrack Extended gegen¨uber dem Original bei kleinen Passwortlisten teilweise Leistungsdefizite aufweist. Dies kann darauf zur¨uckgef¨uhrt werden, dass in der Originalversion von TrueCrack noch 10 Threads f¨ur die Berechnung eines einzelnen Passwortes gestartet werden. In TrueCrack Extended hingegen, wird jeweils nur ein einzelner Thread gestartet, um daf¨ur eine wesentlich h¨ohere Skalierbarkeit zu erreichen. Bei gr¨oßeren Passwortmengen ist aus eben diesem Grund, jedoch eine sehr deutliche Steigerung der Leistung zu erkennen. Bereits ab einer Menge von 10.000 W¨ortern wurden bis zu 350% der Leistung vom OriginalTrueCrack erreicht. Ab ca. 100.000 W¨ortern ist eine Stagnation der Leistungssteigerung zu erkennen. Eine Erh¨ohung der Passwortmenge und hierbei auch Blockgr¨oße steigert die Leistung

Leistungstests

40

fortan nur noch minimal. Grafik 6.2 zeigt die absolute Leistung der verschiedenen Versionen und PC-Konfigurationen bei unterschiedlich vielen Passw¨ortern mit jeweils maximaler Blockgr¨oße.

Skalierung der Leistung von TrueCrack Optimized

Passwörter pro Sekunde

2.500

2.000

1.500

GTX 460 GTX 560

1.000

GTX 570 500

0 1.000

10.000

100.000

1.000.000

Blockgröße

Abbildung 6.2: Passwortdurchsatz TrueCrack Original & TrueCrack Optimized mit jeweils maximaler Blockgr¨oße Quelle: selbsterstellt Wie zu erwarten war, sind die TrueCrack Optimized Versionen ab Passwortl¨angen von 10.000 deutlich Leistungsf¨ahiger als das Original. Der große Leistungsunterschied zwischen dem GTX 570 System und den anderen ist auf die h¨ohere Anzahl an CUDAKernen zur¨uckzuf¨uhren. Da diese Grafikkarte ca. 40% mehr solcher Kerne hat, kann sie auch entsprechend mehr Prozesse gleichzeitig bearbeiten. Der Unterschied zwischen GTX 460 und GTX 560 l¨asst auf eine bessere Architektur und h¨ohere Taktung der GTX 560 schließen, da beide die selbe Anzahl an CUDA-Kernen haben. Ein positives Ergebnis ist, dass TrueCrack Optimized im Allgemeinen von neuerer Hardware profitiert. Sowohl beim Original TrueCrack als auch bei der OptimizedVersion sieht man einen großen Leistungsunterschied zwischen den unterschiedlich starken Grafikkarten. Dies l¨asst darauf schließen, dass auch zuk¨unftige Grafikkarten wiederum eine h¨ohere Leistung in TrueCrack erbringen k¨onnen. Im n¨achsten Schritt wird der Einfluss der Blockgr¨oße auf die Performanz von TrueCrack Optimized untersucht. Hierbei wird die Leistung f¨ur die entsprechenden Blockgr¨oßen betrachtet. Bei Blockgr¨oßen, f¨ur die mehr als ein Wert aufgezeichnet wurde, wird dabei das arithmetische Mittel gebildet. Es ist zu beobachten, dass erst ab einer Blockgr¨oße zwischen 1.000 und 5.000 eine

Leistungstests

41

Leistungssteigerung TrueCrack Optimized

Passwörter / Sekunde

2500

2000

1500 GTX 460

1000

GTX 560 GTX 570

500

0

Blockgröße

Abbildung 6.3: Leistungssteigerung TrueCrack OptimizedQuelle: selbsterstellt Leistungssteigerung eintritt. Dies gilt f¨ur alle Testsysteme gleichermaßen, ebenso wie das Eintreten einer Stagnation ab einer Blockgr¨oße von mehr als 100.000 W¨ortern. Es ist davon auszugehen, dass durch eine weitere Erh¨ohung der Blockgr¨oße nur bei neueren Grafikkarten ein weiterer Leistungsgewinn zu verzeichnen sein wird. Als N¨achstes wird ermittelt wie groß die Leistungseinbußen der einzelnen PCs, als Client, im Server/Client-Netzwerk durch Overhead und Latenz ausfallen. Hierf¨ur werden die vom Server aufgezeichneten Leistungswerte der einzelnen Clients mit denen aus den Einzeltests verglichen. Es wird somit berechnet, wie viel Zeit durch das Client/Server-System verloren geht. Das Ergebnis spiegelt dabei die Summe aus Overhead und der Latenz wieder und soll zudem R¨uckschl¨usse auf eine optimale Gr¨oße der zu versendenden Bl¨ocke geben. Allgemein ist zu beobachten, dass die Leistungseinbuße sehr gering ausf¨allt. Bei steigender Blockgr¨oße nimmt diese sogar ab, da weniger h¨aufig Daten zwischen Client und Server ausgetauscht werden m¨ussen. Der Anstieg der GTX 570 bei der Blockgr¨oße von 100.000 liegt vermutlich an einem kurzfristig aufgetretenem Latenzproblem. Da die Einbußen jedoch allgemein bei 500.000 wieder ansteigen sind Blockgr¨oßen zwischen 100.000 und 500.000 als optimal f¨ur den Server anzunehmen. Die n¨achste Analyse besch¨aftigt sich mit der kombinierten Leistung zweier unterschiedlich leistungsstarker PCs u¨ber das Client-/Server-System. Es wird die Zeit ge-

Leistungstests

42

Leistungseinbuße durch Client/Server relativ 4,50% 4,00% 3,50% 3,00% 2,50% 2,00%

GTX 560

1,50%

GTX 570

1,00% 0,50%

0,00% 5.000

10.000

50.000

100.000

500.000

Blockgröße

Abbildung 6.4: Relative Leistungseinbuße durch Client/ServerQuelle: selbsterstellt messen, die der Server mithilfe der beiden Clients braucht, um 1.000.000 W¨orter zu berechnen. Dabei wird zum Vergleich die theoretisch maximale Leistung in Zeit errechnet, indem die Anzahl der zu berechnenden W¨orter durch die kombinierte Leistung der Clients geteilt wird. Die in der Abbildung XX auftretenden Verlustwerte beziehen sich auf die Verluste die durch Leerlaufzeiten, die bei unterschiedlich schnellen Clients entstehen k¨onnen.

Benötigte Zeit für 1 Million Wörter bei Client / Server 500

benötigte Zeit in Sekunden

450

die theoretische Leistung wurde errechnet über die kombinierten PWD/s , die die Karten im Netzwerk hatten

400 350 300

250

GTX 560 + GTX 570

200

GTX 560 + GTX 570 theoretisch

Verlust

150 100

50 0

50000

100000

250000

500000

Blockgröße

Abbildung 6.5: Ben¨otigte Zeit f¨ur 1 Millionen W¨orter bei Client/Server Quelle: selbsterstellt Wie zu erwarten war, sinkt die ben¨otigte Zeit bei der Blockgr¨oße 100.000 im Vergleich

Leistungstests

43

zu 50.000, da aus den vorigen Tests geschlossen wurde, dass TrueCrack ab ca. dieser Gr¨oße optimal arbeitet. Auff¨allig ist jedoch, dass stets ein Verlust zu verzeichnen ist, der ab einer Blockgr¨oße von 250.000 sogar sehr deutlich hervorsticht, und zwar in H¨ohe von ca. 2 Minuten. Die Erkl¨arung hierf¨ur liegt in der Lastverteilung anhand der Blockgr¨oße, da bei gr¨oßeren Passwortbl¨ocken der langsamere Client eben so viele Passw¨orter berechnet wie der schnelle Client. Dies kann minimiert werden, indem kleinere Blockgr¨oßen verwendet werden, wodurch schnellere Clients ihrer Leistung entsprechend automatisch mehr Passwortbl¨ocke berechnen. Zu erw¨ahnen ist ebenfalls, dass die h¨oheren Verluste bei 100.000 gegen¨uber 50.000 durch den Leistungsgewinn, den TrueCrack Optimized bei der Blockgr¨oßen-Steigerung erh¨alt, kompensiert werden und trotzdem ein besseres Ergebnis erreicht wird. Dies kann bei 250.000 und 500.000 Passw¨ortern pro Block aufgrund der ung¨unstigen Verteilung nicht mehr erreicht werden. Um dies genauer zu untersuchen wird nun die prozentuale Verteilung der Rechenarbeit an die Clients bei den unterschiedlichen Blockgr¨oßen untersucht. Hierf¨ur wird die optimale Verteilung der Rechenlast anhand der Leistungen der einzelnen Clients im Netzwerk berechnet, um einen Vergleich f¨ur die gemessenen Werte zu haben.

Lastverteilung bei Client / Server 100% 90%

80% 70% 60%

50%

GTX 570

40%

GTX 560 Optimale Verteilung

30% 20% 10%

0% 25000

50000

100000

250000

500000

Blockgröße

Abbildung 6.6: Lastverteilung bei Client/ServerQuelle: selbsterstellt An der obigen Grafik wird deutlich, dass bei zu großen Blockgr¨oßen die Arbeitslast nicht entsprechend der Leistung verteilt wird. Die Linie gibt hierbei die optimale Verteilung zwischen den beiden Clients an. Die Verteilung geschieht dabei automatisch, da jeder Client sich einen neuen Block holt, sobald er seinen alten abgearbeitet hat. Im Extremfall, bei einer Blockgr¨oße von 500.000 und einer Passwortliste von 1.000.000, erh¨alt jeder Client genau einen Block. Der schnellere Client ist fr¨uher fertig und wartet

Leistungstests

44

auf neue Arbeit vom Server. Das heißt, dass der schnellere Client auf den langsameren wartet und seine Leistung in dieser Zeit nicht genutzt wird. Die hier gezeigten Verluste k¨onnen leicht vermieden werden, indem nur Clients mit gleicher Rechenleistung verwendet werden. Andernfalls ist auch aus diesem Aspekt ein Betrieb bei einer Blockgr¨oße von 100.000 zu empfehlen, da hierbei eine nahezu maximale Leistung und gleichzeitig eine gute Verteilung der Passwortbl¨ocke m¨oglich ist. Um die Leistungsunterschiede bei parallel berechenbaren Probleme aufzuzeigen, wurde abschließend die Performanz bei der Berechnung auf der CPU mit der Leistung von TrueCrack Optimized auf einer GTX 570 verglichen.

benötigte Zeit für 10.000 Passwörter

8,46

GTX 570

benötigte Zeit 683,27

CPU

0

100

200

300

400

500

600

700

Zeit in Sekunden

Abbildung 6.7: Ben¨otigte Zeit f¨ur 10.000 Passw¨orter auf einer CPU Quelle: selbsterstellt Die Abbildung 6.7 zeigt, dass bei der Ausnutzung der Rechenkapazit¨aten von GPU’s die Leistungsunterschiede zwischen CPU und GPU sehr deutlich ausfallen. Somit kann gezeigt werden, dass der zus¨atzliche Programmieraufwand zur Umsetzung von Berechnungen auf Basis verf¨ugbarer GPU’s f¨ur stark parallelisierbare Aufgaben, wie sie in diesem Studienprojekt bearbeitet wurden, nicht nur gerechtfertigt, sondern sogar zu empfehlen ist.

7

Fazit

Das Ziel der hier dokumentierten Studienprojektarbeit war der Entwurf und die Implementierung einer Softwarel¨osung f¨ur performante W¨orterbuchattacken auf TrueCryptverschl¨usselte Container. Um die gew¨unschten Funktionalit¨aten strukturiert umsetzen zu k¨onnen, wurde ein Anforderungskatalog erstellt, der fast vollst¨andig umgesetzt werden konnte. Zum einen wurde die Anwendung TrueCrack um eine Multi-GPU Unterst¨utzung und eine leistungsf¨ahigere Verarbeitung der Daten erweitert (TrueCrack Optimized), zum anderen wurde eine Client-Server Anwendung implementiert (TrueCrack Extended), die es erm¨oglicht, die notwendigen Berechnungen in einem Netzwerk, parallel auf mehreren Clients verteilt, durchzuf¨uhren. Weiterhin konnten die f¨ur eine Erweiterung, bez¨uglich der Verschl¨usselungsalgorithmen und Hashfunktionen, notwendigen Stellen im Code von TrueCrack herausgestellt und dokumentiert werden, sodass ggf. weitere Kryptoverfahren hinzugef¨ugt werden k¨onnen. Trotz der Umsetzung einer umfassenden Softwarel¨osung zum Aufbau eines verteilten Netzwerkes und einer erheblichen Leistungssteigerung der Anwendung TrueCrack in Form der Anwendung TrueCrack Optimized, sind einige weitere Optimierungsund Erweiterungsm¨oglichkeiten denkbar. Nicht alle Anforderungen konnten im Rahmen dieses Studienprojektes umgesetzt werden. So stellt z.B. die Erstellung einer Schnittstelle bez¨uglich der Erweiterung um weitere Kryptoverfahren einen erheblichen Zeitaufwand dar. Hierf¨ur m¨usste die Codestruktur ge¨andert werden, sodass f¨ur jeden Verschl¨usselungsalgorithmus und jede Hashfunktion eine einheitliche Methode zur Verf¨ugung steht. Weiterhin konnten aufgrund der fehlenden Hardware keine Testszenarien mit mehreren Grafikkarten innerhalb eines Computersystems durchgef¨uhrt werden. Diese Testkategorie w¨urde Informationen u¨ber die Skalierbarkeit eines einzelnen Computersystems

Fazit

46

liefern. Mit entsprechender Hardware f¨ur jeden Client, k¨onnte die Leistung eines verteilten Netzwerkes weiter erh¨oht werden. Abschließend betrachtet wurde eine performante Softwarel¨osung bestehend aus zwei Komponenten erstellt, mit der es m¨oglich ist W¨orterbuchattacken auf TrueCryptverschl¨usselte Datencontainer durchzuf¨uhren. Es wurde anhand von mehreren Testszenarien gezeigt, dass die Leistung durch den Einsatz eines verteilten Netzwerks, sowie durch die codeseitige Optimierung von TrueCrack, erw¨ahnenswert erh¨oht werden konnte und somit die Komponenten TrueCrack Extended und TrueCrack Optimized die gestellten Projektziele erf¨ullen. Trotz der erfolgreichen Leistungssteigerung der Software ist, bei Wahl eines geeigneten Passwortes, die Sicherheit von Verschl¨usselungssystemen wie TrueCrypt nicht gef¨ahrdet. Mit zunehmender L¨ange eines Passwortes steigen die Kombinationsm¨oglichkeiten exponentiell an und sind somit nicht durch die vorhandenen Rechenkapazit¨aten heutiger Systeme kompensierbar.

Anhang

II

Anhang • CD mit folgenden Inhalten: – Digitale Version dieser Dokumentation in PDF-Form – Kompletter Quellcode von TrueCrack Optimized und TrueCrack Extended – Digitales Benutzerhandbuch f¨ur TrueCrack Extended in PDF-Form

Abbildungsverzeichnis

III

Abbildungsverzeichnis 4.1

Vergleich der Leistung von CPU vs GPU der Software NeuroSolutions Quelle: selbsterstellt auf Basis von http://www.neurosolutions. com/products/cuda/sample.html . . . . . . . . . . . . . . . . .

4.2

9

Automatische Aufteilung von Bl¨ocken bei CUDA Quelle: http://developer.download.nvidia.com/compute/DevZone/ docs/html/C/doc/CUDA_C_Programming_Guide.pdf . . . . . . .

4.3

10

Das allgemeine Client-Server Modell Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

12

5.1

Auswahl von Client oder Server 19

5.2

Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ Ubersicht u¨ber die Client-Server Struktur Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

19

5.3

Beispielhafter Ablauf einer Verbindung von TrueCrack Extended Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4

20

Beispielhafter Programmablauf bei mehreren Verbindungen Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

22

5.5

Skizzierter Ablauf von TrueCrack Optimized Quelle: selbsterstellt . .

23

5.6

Aufteilung der GPU-Threads in TrueCrack Original Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.7

Benutzeroberfl¨ache des Servers Quelle: selbsterstellt . . . . . . . . .

27

6.1

Relative Leistung von TrueCrack Optimized zu TrueCrack Original Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2

39

Passwortdurchsatz TrueCrack Original & TrueCrack Optimized mit jeweils maximaler Blockgr¨oße Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3

Leistungssteigerung TrueCrack Optimized Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4

40 41

Relative Leistungseinbuße durch Client/Server Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

42

Abbildungsverzeichnis 6.5

Ben¨otigte Zeit f¨ur 1 Millionen W¨orter bei Client/Server Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

6.6

42

Lastverteilung bei Client/Server Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

6.7

III

43

Ben¨otigte Zeit f¨ur 10.000 Passw¨orter auf einer CPU Quelle: selbsterstellt . . . . . . . . . . . . . . . . . . . . . . . . . .

44

Tabellenverzeichnis

IV

Tabellenverzeichnis 4.1

Parameter von TrueCrack . . . . . . . . . . . . . . . . . . . . . . .

7

4.2

Dimensionen von Grid/Blocks/Threads einer NVIDIA GTX 570 . . .

9

Literaturverzeichnis

V

Literaturverzeichnis [CB09] Klaus Chantelau and Ren´e Brothuhn. Multimediale Client-Server-Systeme (eXamen.press) (German Edition). Springer, 1 edition, 12 2009. [Dad96] Peter Dadam. Verteilte Datenbanken und Client/Server-Systeme: Grundlagen, Konzepte und Realisierungsformen (German Edition). Springer, 1 edition, 1996. [Fou]

TrueCrypt Foundation. Header key derivation, salt, and iteration count. Website.

Online verf¨ugbar bei http://www.truecrypt.org/docs/?s=

header-key-derivation besucht am 15.03.2012. [ML08] Kazuhiko Minematsu Moses Liskov.

Comments on XTS-AES.

2008.

Online verf¨ugbar bei http://csrc.nist.gov/groups/ST/toolkit/BCM/ documents/comments/XTS/XTS_comments-Liskov_Minematsu.pdf besucht am 27.02.2012.