AP6.Ressourcenanalyse_v1.0_geschwrzt_.pdf

Dieses Dokument ist Teil der Anfrage „Untersuchungen zum Verschlüsselungsprogramm „TrueCrypt“

/ 107
PDF herunterladen
Verhältnis AMD Athlon X2 zu Intel i7 60 Minimale MB/s 50 40 AMD Athlon X2 7750 64-Bit Intel i7-Core 64- Bit 30 20 10 0 1 2 3 Tests durchgeführt auf 500MB Ramdisk 1) Linux nativ 2) TrueCrypt mit Linux-Crypto 3) TrueCrypt mit interner Krypto 2.2.2 MultiCore versus SingleCore Moderne CPUs bestehen heutzutage aus mehreren Kernen (z.B. DualCore, QuadCore). Diese können vom Betriebssystem einzeln angesteuert werden, sodass es möglich ist, einzelne Prozesse auf dedizierten CPU-Kernen auszuführen. Dies ist dann besonders von Vorteil, wenn Anwendungen auf einem „thread“-Modell basieren und Teile parallel ausgeführt werden können. Der Mehraufwand durch das zusätzliche „thread“-Management ist in der Regel vernachlässigbar, sodass die Annahme getroffen werden kann, dass MultiCore-CPUs schneller sind als SingleCore-CPUs. Betrachtet man z.B. die Ergebnisse des TrueCrypt-internen Benchmarks (siehe Kapitel 4.2) unter Windows im Höchstleistungsmodus und vergleicht die effektiven Geschwindigkeiten bei MultiCore-Systemen, so erkennt man, dass diese Annahme für den reinen Algorithmusablauf zu stimmen scheint. Acer Aspire One DualCore SingleCore Lenovo X61s DualCore SingleCore HP EliteBook 8540p QuadCore SingleCore 27,1 MB/s 14,8 MB/s 113 MB/s 64,9 MB/s 234 MB/s 105 MB/s Tabelle 1: Vergleich TrueCrypt-interner Benchmark für MultiCore vs. SingleCore Der Geschwindigkeitsvorteil beim Einsatz von MultiCore-Systemen liegt im Schnitt bei 80-120%. Es gibt allerdings Ausnahmen, in denen der Overhead durch den Einsatz von MultiCore zu einer langsameren Performance führt. Dies ist immer dann der Fall, Seite 11 von 107 | | 2010
11

wenn auf Daten zugegriffen wird, die kleiner sind als eine Kernelseite (in der Regel 4096 Byte = 4 kB). So sind automatisch Dateisysteme mit einer Blockgröße in Höhe einer Sektorgröße (512 Byte) für den Einsatz bei MultiCore-Systemen inperformanter als bei SingleCore-Systemen. Die folgende Tabelle veranschaulicht die Geschwindigkeitsunterschiede bei unterschiedlichen Blockgrößen: Name: Acer Aspire One Acer Aspire One 32-Bit / 64-Bit: 32-Bit 32-Bit Anzahl Kerne: DualCore SingleCore Linux-Crypto- Geschwindigkeit in MB/s in MB/s 512 Byte 9,8 10,1 1024 Byte 10,3 10,6 2048 Byte 10,5 8,7 4096 Byte 24,0 20,0 8192 Byte 23,9 22,2 16384 Byte 24,0 22,5 32768 Byte 24,0 22,1 Name: HP EliteBook 8540 HP EliteBook 8540p 32-Bit / 64-Bit: 64-Bit 64-Bit Anzahl Kerne: QuadCore SingleCore Linux-Crypto- Geschwindigkeit in MB/s in MB/s 512 Byte 56,4 59,3 1024 Byte 59,7 59,8 2048 Byte 57,3 63,5 4096 Byte 148,0 127,0 8192 Byte 148,0 128,0 16384 Byte 134,0 128,0 32768 Byte 149,0 129,0 Name: HP EliteBook 8540 HP EliteBook 8540p 32-Bit / 64-Bit: 32-Bit 32-Bit Anzahl Kerne: QuadCore SingleCore Linux-Crypto- Geschwindigkeit in MB/s in MB/s 512 Byte 51,2 52,4 1024 Byte 53,4 53,9 2048 Byte 52,0 55,2 4096 Byte 127,0 110,0 8192 Byte 127,0 111,0 16384 Byte 127,0 111,0 32768 Byte 127,0 111,0 Tabelle 2: Geschwindigkeitsunterschiede in Abhängigkeit der Blockgröße und der Kernanzahl Seite 12 von 107 | | 2010
12

Gleichzeitig zeigt sich aber auch, dass der ursprünglich reine Geschwindigkeitsvorteil der reinen CPU-Zeit beim Einsatz auf Dateisystemen nicht mehr so groß ist. Jedoch bietet der Einsatz von MultiCore-CPUs den Vorteil, dass mehrere Aufgaben gleichzeitig ausgeführt werden können, sodass eine zu hohe Betriebslast durch den Einsatz von Verschlüsselung besser verteilt werden kann. Tests auf SingleCore- CPUs zeigen, dass die CPU-Auslastung bei 100% liegt, sodass während der reinen Kryptooperation keine weiteren Dienste parallel ausgeführt werden, sodass das System in dieser Zeit hängt. In der Regel ist dies je nach System mehr oder weniger bemerkbar, da hier auch die Festplattenzugriffszeit eine Rolle spielt. Im MultiCore-Betrieb liegt die Auslastung des einzelnen Core, welcher gerade die Kryptooperation durchführt, ebenfalls bei 100%, jedoch stehen weitere Cores für den regulären Betriebsablauf zur Verfügung, sodass das System nicht hängt. 2.2.3 CPU-Taktfrequenz Das Verhältnis des Datendurchsatzes in Abhängigkeit von der CPU-Taktrate ist nahezu linear. • • Intel i7, 64-Bit: Es wurde die Taktraten 1333 Mhz sowie die maximale Taktrate von 2666 Mhz gewählt. Die erreichten Messwerte verdoppelten sich bei einer Verdopplung der Taktrate (25,28 MB/s versus 56,5 MB/s). Intel Core2Duo, 64-Bit: Es wurde die Taktrate 800 Mhz sowie die maximale Taktrate von 1600 Mhz gewählt. Hier haben sich die Messwerte zwar nicht verdoppelt, sie stiegen lediglich um 43% (13,8 MB/s versus 24,5 MB/s). Dies kann unter anderem mit der langsameren Speicherbandbreite zusammenhängen. Zur Vereinfachung der weiteren Tests reicht es dennoch aus, sich die minimalen und maximalen Frequenzen der jeweiligen CPUs anzusehen. Die Performance bei den Zwischen-Taktfrequenzen verhält sich nahezu linear. 2.2.4 Lesevorgang versus Schreibvorgang Das Lesen von (verschlüsselten) Daten ist schneller als das Schreiben von (verschlüsselten) Daten. Daher werden im Folgenden lediglich die Geschwindigkeiten von Schreibvorgängen gemessen. 2.2.5 64-Bit CPUs versus 32-Bit CPUs 64-Bit CPUs sind schneller als 32-Bit CPUs. Daher werden zur Bestimmung von maximaler Performance die Messwerte unter einer 64-Bit Architektur gemessen. 2.2.6 Einsatz von AES-Hardwarebeschleunigern Der Einsatz von Hardware-Beschleunigern, wie z.B. die neuen AES-NI-Instruktionen in Intel's Core-i7-CPU erhöhen signifikant den Kryptodurchsatz beim Einsatz von AES. Allerdings setzt dies den Einsatz von AES als Algorithmus zwingend voraus. Um eine realistische Abschätzung der minimalen Hardwarekonfiguration für den Einsatz einer Festplattenverschlüsselung zu erzielen und um nicht auf AES als Kryptoalgorithmus festgelegt zu sein, werden im Folgenden zunächst der Geschwindigkeitsvorteil beim Einsatz von Hardwarebeschleunigern bestimmt, im Seite 13 von 107 | | 2010
13

Anschluss daran allerdings sämtliche Tests ohne Hardwarebeschleuniger durchgeführt. Dies hat den Vorteil, dass man auch die Geschwindigkeit von anderen in Software implementierten Algorithmen realistischer abschätzen kann. HP EliteBook 8540p unter Linux mit AESNI ohne AESNI QuadCore 64-Bit 1,5 GB/s 242 MB/s SingleCore 64-Bit 563 MB/s 117 MB/s QuadCore 32-Bit 995 MB/s 200 MB/s TrueCrypt-Benchmark der reinen Algorithmen Faktor ca. 6x ca. 5x ca. 5x 512 Byte Blöcke mit AESNI ohne AESNI Faktor QuadCore 64-Bit 90 MB/s 55 MB/s ca. 1,6x SingleCore 64-Bit 105 MB/s 60 MB/s ca. 1,75x 4096 Byte Blöcke mit AESNI ohne AESNI Faktor QuadCore 64-Bit 270 MB/s 150 MB/s ca. 1,8x SingleCore 64-Bit 230 MB/s 130 MB/s ca. 1,75x Einsatz von AES-NI auf realen Blockdevices (RAMDisk) Tabelle 3: Vergleich der Geschwindigkeiten bei Einsatz von Intel's Hardwarebeschleunigung AES-NI Die Tabelle zeigt, dass die reine Ausführungszeit der Algorithmen durch TrueCrypt ca. 5-6x schneller beim Einsatz der AES-Hardwarebeschleunigung ist, als bei reinen Software-Operationen ohne Hardwareunterstützung. Jedoch zeigt sich, dass sich im echten Einsatz auf einem Blockgerät dieser Geschwindigkeitsvorteil auf ca. 70-80% reduziert. Seite 14 von 107 | 2010
14

2.3 Testszenarien Dieser Abschnitt beschreibt die Testszenarien, die im Rahmen der Arbeiten von AP6 durchgeführt werden. Ein Verweis auf die erzielten Testergebnisse der einzelnen Szenarien wird jeweils in Klammern referenziert. 2.3.1 Ist-Zustand Feststellen des Ist-Zustandes (Bestimmung der Messgrößen) ohne den Einsatz von Verschlüsselung. (siehe 4.3) 2.3.2 Performance der Krypto-Algorithmen Die folgenden Tests werden zunächst losgelöst von einem physischen Medium nur innerhalb einer virtuellen Festplatte im RAM ausgeführt. Als Ramdisk-Größe wurde 500MB gewählt: • Geschwindigkeitsmessung der ◦ TrueCrypt-internen Krypto-Implementierung unter Windows (siehe 4.2, 4.4.2, 5.2, 5.4) ◦ TrueCrypt-internen Krypto-Implementierung unter Linux (siehe 4.2, 4.4.1, 5.2, 5.3) • Vergleich der ◦ TrueCrypt-internen Krypto-Implementierung mit den Implementierungen innerhalb des Linuxkernels (siehe 4.4.1) ◦ Geschwindigkeit bei Einsatz von Hardware-Beschleunigung (z.B. AES-NI bei Intel i7 CPU, siehe 2.2.6, 5.2.3, 5.3.3, 5.4.3) 2.3.3 Auswirkungen auf die Performance durch das verwendete Dateisystem • Dateisysteme unter Windows: ◦ FAT32 ◦ NTFS (siehe 4.5.3, 5.4) • Dateisysteme unter Linux ◦ EXT3 ◦ REISERFS ◦ VFAT ◦ XFS (siehe 4.5.1, 4.8, 5.6) Seite 15 von 107 | | 2010
15

2.3.4 Auswirkungen auf die Performance in Abhängigkeit von der Blockgröße • Nativer Blockzugriff mit unterschiedlichen Blockgrößen unter Linux ◦ 512 Byte ◦ 1024 Byte ◦ 2048 Byte ◦ 4096 Byte (Kernel page) • (siehe 4.8, 5.3, 5.6.2) 2.3.5 Erstellen eines TrueCrypt-Volumes Durchführung der folgenden Tests und Messungen innerhalb des verschlüsselten TrueCrypt-Volumes: Auswirkungen auf die Performance durch die Größe der zu öffnenden Dateien • Kleinste Dateigröße (Sektorgröße) • Kleine Dateigröße (Kernel page) • Mittlere Dateigröße (wenige KB) • Große Dateigröße (wenige MB) • Riesige Dateigröße (>500MB – 1GB) (siehe 5.6) Auswirkungen auf die Performance durch die Anzahl der zu öffnenden Dateien • Packen / Entpacken von vielen kleinen Dateien (siehe 4.5) • Compilieren von Sourcecode mit vielen kleinen Dateien (siehe 4.6) 2.3.6 Full-Disc-Encryption • Komplett-Verschlüsselung der Systempartition unter Windows • Vergleich der Systemstart-Zeiten • Vergleich der Programm-Startzeiten (siehe 4.7, 5.5) Seite 16 von 107 | | 2010
16

3 Testvoraussetzungen und Vorgehensweise 3.1 Installation benötigter Software Folgende Testwerkzeuge werden für die nachfolgenden Tests – neben TrueCrypt – verwendet: 3.1.1 Testwerkzeuge für Linux • cryptsetup • dd • • Bonnie++ iozone 1 2 3 4 • valgrind • Systemmonitor Diese werden wie folgt installiert: # apt-get install cryptsetup bonnie++ iozone3 valgrind Zusätzlich werden noch für Dateisystemtests die folgenden Pakete benötigt: # apt-get install reiserfsprogs xfsprogs 3.1.2 Vorgehensweise unter Linux Um Performancemessungen unter Linux durchzuführen, werden die folgenden 3 Werkzeuge 5 verwendet , die erzielten Messwerte resultieren jeweils aus sequentiellen d.h. linearen Schreibzugriffen: • dd Mittels dd können Datenblöcke direkt auf Blockgeräte geschrieben werden. dd benötigt kein zugrundeliegendes Dateisystem, die zu verwendende Blockgröße kann direkt mit angegeben werden. Im Anschluss an jeden Schreibvorgang gibt dd die benötigte Zeit sowie die durchschnittliche Leistung in MB/s aus. Folgende Befehle werden verwendet, um die Geschwindigkeit bei unterschiedlichen Blockgrößen zu messen: ◦ ◦ ◦ ◦ ◦ ◦ 1 2 3 4 5 512 Byte: dd if=/dev/zero of=$TESTBLOCKFILE bs=512 count=1000000 1024 Byte: dd if=/dev/zero of=$TESTBLOCKFILE bs=1024 count=500000 2048 4096 8192 16 Byte: Byte: Byte: kByte: dd if=/dev/zero of=$TESTBLOCKFILE bs=2048 count=250000 dd if=/dev/zero of=$TESTBLOCKFILE bs=4096 count=125000 dd if=/dev/zero of=$TESTBLOCKFILE bs=8192 count=62500 dd if=/dev/zero of=$TESTBLOCKFILE bs=16k count=31250 http://code.google.com/p/cryptsetup/ http://www.coker.com.au/bonnie++/ http://www.iozone.org/ http://www.valgrind.org Zur Automatisierung der folgenden Tests sind Skripte verfügbar. Seite 17 von 107 | | 2010
17

◦ 32 kByte: dd if=/dev/zero of=$TESTBLOCKFILE bs=32k count=15625 Bei den folgenden Messungen variiert für die einzelnen Tests lediglich das Zielblockgerät (hier identifiziert via $TESTBLOCKFILE). Um die einzelnen Testziele zu erzeugen, wird wie folgt vorgegangen: 1. Anlegen einer 500MB-großen Ramdisk (tmpfs): # mount -t tmpfs none -o size=500m $TESTPATH 2. Schreiben von 500MB in eine Datei, dabei Messen der Speichergeschwindigkeit via dd bei unterschiedlichen Blockgrößen. # dd if=/dev/zero of=$TESTBLOCKFILE bs=<512-32k> 3. Erzeugen eines Blockgerätes mittels losetup. # losetup /dev/loop0 $TESTPATH/$TESTBLOCKFILE 4. Nach Erzeugen des Blockgerätes /dev/loop0 kann der Performanceverlust durch den Device-Mapper des Linuxkernels gemessen werden. # dd if=/dev/zero of=/dev/loop0 bs=<512-32k> 5. Dieses Blockgerät wird nun mittels der Linuxkernel-Krypto verschlüsselt: # cryptsetup create test /dev/loop0 -c aes-xts-plain 6. Anschließend folgt die Bestimmung der Performance der Linuxkernel-Krypto: # dd if=/dev/zero of=/dev/mapper/test bs=<512-32k> 7. Das Krypto-Mapping wird nun wieder entfernt und das Blockgerät /dev/loop0 mittels TrueCrypt verschlüsselt und die Performancetests via dd wiederholt. # # # # cryptsetup remove test truecrypt -t --create --volume-type=Normal /dev/loop0 --encryption=AES --hash=SHA-512 –filesystem=None \ -p="no-password" --random-source=/dev/urandom \ --non-interactive truecrypt -t --mount /dev/loop0 -p="no-password" \ --filesystem=none –non-interactive \ --slot=5 dd if=/dev/zero of=/dev/mapper/truecrypt5 bs=<512-32k> 8. Die obigen Tests haben jeweils die linuxinternen Krypto-Algorithmen verwendet. Nun wird Punkt 7) wiederholt, jedoch nicht über die Kommandozeile, sondern über die grafische Benutzeroberfläche von TrueCrypt. TrueCrypt muss dazu jedoch zunächst wie in Abschnitt 3.4.2 beschrieben auf die Verwendung der internen Krypto-API umgestellt werden. 9. Zuletzt werden Tests 1-8) in unterschiedlichen Konfigurationen (QuadCore, DualCore, SingleCore – siehe Abschnitt 3.2.2) und Energiemodi (Performance, Powersave – siehe Abschnitt 3.3.2) wiederholt. Seite 18 von 107 | | | 2010
18

• Bonnie++ Mittels Bonnie++ lässt sich die Performance von Blockgeräten mit Hilfe von unterschiedlichen Tests untersuchen, unter anderem das Lesen, Schreiben von Dateien mit unterschiedlichen Datei- und Blockgrößen. 1. Um diese Tests durchzuführen, ist es zunächst nötig, die Punkte 1)2)3) und 7) bzw. 8) der dd-Tests auf Seite 17 zu wiederholen, um ein verschlüsseltes Blockgerät zu erzeugen. 2. Danach wird auf dem Blockgerät ein Dateisystem erzeugt und dieses in das Dateisystem eingehängt. ▪ EXT3: # mkfs.ext3 /dev/mapper/truecrypt5 ▪ ReiserFS: # mkfs.reiserfs -b 4096 /dev/mapper/truecrypt5 ▪ VFAT: # mkfs.vfat /dev/mapper/truecrypt5 ▪ XFS: # mkfs.xfs -f /dev/mapper/truecrypt5 # mount /dev/mapper/truecrypt5 $MOUNTTARGET 3. Anschließend können die Tests mit Bonnie++ durchgeführt werden # bonnie++ -u root -d $MOUNTTARGET -s 200 -r 100 -b Der Parameter „-s“ legt hierbei die Dateigröße in MB fest, „-r“ stellt hierbei die zu verwendende Menge an Arbeitsspeicher ein. • Iozone: Iozone ist ebenfalls ein Dateisystem-Benchmarking-Werkzeug, welches eine Vielzahl an Tests durchführen kann, u.a. unterschiedliche Dateioperationen (read, write). Idealerweise führt man die Tests mit Iozone direkt im Anschluss an Punkt 3) der Bonnie++ Tests durch, da das entsprechende Dateisystem dann bereits erstellt und eingehängt ist. # iozone -a -o -n 512 -g 16m -y 512 -q 16m -f $MOUNTTARGET/iozone.test Die Parameter bedeuten: ◦ „-a“: automatischer Modus ◦ „-o“: automatisches synchronisieren mit dem Blockdevice, um Einflüsse durch Caches zu verhindern ◦ „-n“: minimale Dateigröße in kB ◦ „-g“: maximale Dateigröße in MB ◦ „-y“: minimale Blockgröße in kB ◦ „-q“: maximale Blockgröße in MB Seite 19 von 107 | | | 2010
19

3.1.3 Testwerkzeuge für Windows • • • 6 Dataram RAMDisk Version 3.5.130RC14 CrystalDiskMark Version 3.0 x64 (Release 2010/3/21) 7 8 Windows Power Shell Version 2.0 ◦ Measure-Command zur Zeitmessung • 3.1.4 Ressourcenmonitor Vorgehensweise unter Windows Unter Windows sind die notwendigen Testschritte um einiges einfacher als unter Linux, da es für TrueCrypt nicht zwei unterschiedliche Krypto-Algorithmen gibt, sodass grundsätzlich die internen Funktionen verwendet werden. Um unter Windows die gleichen Tests nachzuvollziehen, wird wie folgt vorgegangen: • Dataram RAMDisk: Zunächst wird mittels dieser Software eine RAMDisk mit 500 MB angelegt. Abbildung 1: Bildschirmfoto des Dataram RAMDisk Konfigurationswerkzeug ◦ Dazu wird die „Disk Size“ entsprechend eingestellt und auf „Start RAMDisk“ geklickt. ◦ Nun steht unter Windows ein neues Laufwerk „D:\“ zur Verfügung, welches rein aus Arbeitsspeicher besteht. 6 http://memory.dataram.com/products-and-services/software/ramdisk 7 http://crystalmark.info/software/CrystalDiskMark/index-e.html 8 Integraler Bestandteil von Windows 7 Seite 20 von 107 | | | 2010
20

Go to next pages