Leseprobe
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
1. Einleitung
1.1. Problemstellung
1.2. Zielsetzung
1.3. Vorgehensweise
1.4. Fachliche Anforderungen
2. Grundlagen
2.1. Definitionen
2.2. Verschlüsselungsarten
2.2.1. Symmetrische Verschlüsselung
2.2.2. Asymmetrische Verschlüsselung
2.2.3. Hybride Verschlüsselung
2.3. Abhängigkeit zwischen Schlüssellänge und Sicherheitsniveau
2.4. Verschlüsselungsplattformen von Microsoft-Betriebssystemen
2.4.1. Microsoft CryptoAPI (CAPI)
2.4.2. Cryptography API: Next Generation (CNG)
2.5. Zeitmessung
3. Entwicklung und Nutzung der Testumgebung
3.1. Konzeption
3.1.1. Framework
3.1.2. Programmkonzept
3.1.3. Zu erwartende Schwierigkeiten
3.2. Implementierung der Testumgebung
3.2.1. Erste Schritte
3.2.2. Symmetrische Kryptosysteme
3.2.3. Asymmetrische Kryptosysteme
3.2.4. Hashalgorithmen
3.2.5. Zeitmessung
3.2.6. Benutzerschnittstelle
4. Messung und Auswertung
4.1. Maßnahmen zur Qualitätssicherung
4.2. Erwartung an die Ergebnisse
4.3. Durchführung der Messung
4.4. Ergebnisse
4.5. Bewertung
5. Fazit
Anhang
Quellenverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abbildung 1: Funktionsweise hybride Ver- und Entschlüsselung
Abbildung 2: Initialisierung des 128-Bit langen AES-Schlüssels für die CAPI
Abbildung 3: Ablaufschema CAPI und CNG
Abbildung 4: Verifizierung des Chiffretextes mit Microsoft Visual Studio
Abbildung 5: Deklaration der Funktionen für symmetrische Kryptosysteme
Abbildung 6: Deklaration der Funktionen für asymmetrische Kryptosysteme
Abbildung 7: Deklaration der Funktionen für Hashverfahren
Abbildung 8: Gestaltung der Oberfläche mit Hilfe von Microsoft Visual Studio
Abbildung 9: Bedingter Funktionsaufruf der Schaltfläche „entschlüsseln“
Abbildung 10: Funktion zur Anzeige von Rückmeldungen
Abbildung 11: Messergebnisse symmetrische Kryptosysteme (Verschlüsselung)
Abbildung 12: Messergebnisse symmetrische Kryptosysteme (Entschlüsselung)
Abbildung 13: Messergebnisse asymmetrische Kryptosysteme
Abbildung 14: Messergebnisse Hashverfahren
1. Einleitung
Thema dieser Projektarbeit ist der Vergleich der Leistungsfähigkeit zwischen der Kryptographie- plattform CryptoAPI und dessen Nachfolger Cryptography API: Next Generation der Microsoft Corporation. Im ersten Teil dieser Einleitung erfolgt eine ausführliche Beschreibung der Prob- lemstellung. Nachfolgend wird das Ziel, welches mit dieser Arbeit verfolgt wird, vorgestellt. Die konkrete Vorgehensweise des Praxisteils wird im dritten Unterpunkt des Kapitels präsentiert. Abschließend erfolgt eine kurze Erläuterung der fachlichen Anforderungen an die Projektdurch- führung.
1.1. Problemstellung
Ein Blick in die Schlagzeilen einschlägiger IT-Zeitschriften macht schnell ersichtlich, wie es in der letzten Zeit vermehrt zu Hackerangriffen, also dem unberechtigten Eindringen in Unterneh- mensnetze, kam. Der Hauptgrund dafür liegt häufig weniger in immer raffinierteren Methoden seitens der Angreifer, sondern viel mehr in unzureichend geschützten Informationssystemen.
So passiert es in der heutigen Anwendungsentwicklung immer wieder, dass Verschlüsselungs- algorithmen, -verfahren und -bibliotheken für neue Produkte verwendet werden, die heute schon als veraltet oder unsicher gelten. Hintergrund ist die Tatsache, dass Entwickler oft wenig Erfah- rung im Umgang mit neuen Kryptographieplattformen haben und selbst bei Interesse die Aus- wahl entsprechender Literatur oder beispielhaften Programmierquelltexten stark eingeschränkt ist. Als Konsequenz können Software-Entwickler und -Designer nur schlecht abschätzen, wie sich ein neuer Algorithmus oder eine neue Verschlüsselungs-Bibliothek auf ihr Softwareprodukt in Hinblick auf Leistung und Sicherheit unter Berücksichtigung des Implementierungsaufwands auswirken könnte.
Ein Beispiel dafür ist die CryptoAPI der Microsoft Corporation, die bei fast allen Entwicklungen im Microsoft-Umfeld, trotz der Verfügbarkeit einer umfangreicheren und leistungsstärkeren Wei- terentwicklung namens Cryptography API: Next Generation, auch heutzutage noch Verwendung findet.
1.2. Zielsetzung
Im Rahmen der Projektarbeit soll vordergründig ein Vergleich zwischen der alten und momentan noch vielfach verwendeten Kryptographieplattform CryptoAPI und der mit Windows Vista eingeführten Kryptographieplattform Cryptography API: Next Generation der Microsoft Corporation durchgeführt werden. Ziel ist es entsprechende Erkenntnisse zu erlangen, in wie fern sich ein Umstieg auf eine neuere Plattform zum einen positiv auf das Softwareprodukt auswirken könnte, zum anderen aber auch welche Risiken dies mit sich bringen würde.
Mit Hilfe dieser Projektarbeit sollen Software-Entwickler und -Designer anschließend eine einfache, kompakte und leicht zugängliche Möglichkeit haben die Vor- und Nachteile jeweiliger Verschlüsselungsplattformen- und -algorithmen individuell zu beurteilen. Um die Referenztauglichkeit der Arbeit zu erhöhen, soll der Vergleich primär durch die Entwicklung, Ausführungen und anschließende Auswertung einer Testumgebung erfolgen, wodurch Entwickler die Möglichkeit erhalten, dessen Programmquelltext direkt nutzen zu können.
1.3. Vorgehensweise
Zu Beginn der Projektarbeit werden die für das Verständnis der weiteren Ausführungen notwen- digen Grundlagen vermittelt. Neben der Definition wichtiger Begriffe, wird in einem gesonderten Abschnitt auf die Arbeits- und Funktionsweise verschiedener Verschlüsselungsarten eingegan- gen. Die bereits erwähnten Verschlüsselungsplattformen der Microsoft Corporation werden da- bei separat behandelt.
Im nachfolgenden Schritt steht die Entwicklung einer zur Performancemessung geeigneten Te- stumgebung im Mittelpunkt. Dabei muss festgelegt werden, in welcher Form und mit welchen Daten die Arbeitsgeschwindigkeit jeweiliger Algorithmen gemessen werden kann. Nach erfolg- reicher Entwicklung jeweiliger Beispielprogramme und Durchführung entsprechender Messun- gen der Leistungsfähigkeit, soll eine Auswertung stattfinden. Dabei werden die Ergebnisse zu- sammengefasst, miteinander verglichen und analysiert. Anhand dieser werden dann Schlussfol- gerungen gezogen, in wie fern sich die Verwendung jeweiliger Algorithmen positiv oder negativ auf die Qualität von Software-Produkten auswirken könnte. Dies soll mit Visualisierungen und genauen Erklärungen untermauert werden. Am Ende der Arbeit werden alle Ergebnisse in ei- nem Fazit zusammengefasst und diskutiert.
1.4. Fachliche Anforderungen
Bezüglich der Definition der Anforderungen wird die in der Literatur häufig zu findende Einteilung in funktionale, nicht funktionale Anforderungen, Design- und Prozessbedingungen als Basis verwendet.1 Die Anforderungen des Projektes wurden während eines Gespräches mit dem zu- ständigen Projektbetreuer im Detail festgelegt.2 Bezüglich der funktionalen Anforderungen kam man überein, dass die zu entwickelnde Testumgebung alle notwendigen Funktionen zur Durch- führung des Leistungsvergleiches beinhalten muss. Damit muss diese alle gängigen Kryptosys- teme beider Programmierschnittstellen unterstützen. Besonderes Augenmarkmal soll dabei auf die neueren Technologien aus der Kryptografie (allen voran das sog. ECC-Verfahren, siehe 2.2.2.), welche ausschließlich in der neuen API implementiert sind, gelegt werden. Zusätzlich wurde seitens des Projektbetreuers der Wunsch geäußert, die Arbeitsgeschwindigkeit der heute gängigsten Hashverfahren (SHA-1 und SHA-2, siehe 2.1.) jeweils beider Programmierschnittstellen gegenüberzustellen.
Die nicht-funktionalen Anforderungen beschränkte man lediglich auf die Pflicht, Messungen mit Hilfe von Testdaten durchzuführen und dabei sicherzustellen, dass die Resultate möglichst unverfälscht und somit relevant für die Auswertung sind. Welche Form diese Testdaten haben und wie die Messung letztendlich durchgeführt wird, kann dabei frei gewählt werden, solange die obigen Kriterien erfüllt sind.
Hinsichtlich der Designbedingungen formulierte der Projektbetreuer konkrete Kriterien. Diese besagen, dass als Programmiersprache C/C++ in der Microsoft-Entwicklungsumgebung Visual Studio verwendet werden soll und die Testumgebung auf einem kompatiblen x86-Prozessor unter dem Betriebssystem Microsoft Windows (ab Vista) lauffähig sein muss. Hintergrund dessen sind dabei weniger persönliche Präferenzen, sondern sind praktische Gründe, denn Visual Studio mit C/C++ wird bei der Entwicklung vieler Produkte innerhalb des Unternehmens verwendet, wodurch es problemlos möglich ist, auf bestehendes Wissen zurückzugreifen. Ferner ist die erwähnte Kombination der Hard- und Software-Plattform die weltweit am weitesten verbreitete3, so dass eine hohe Praxisrelevanz gewährleistet ist.
2. Grundlagen
Dieses Kapitel soll die für die Projektarbeit relevante theoretische Basis vermitteln. Zunächst werden allgemeine Begriffe, die in der gesamten Projektarbeit verwendet werden, definiert. Der Schwerpunkt liegt jedoch klar auf den Erklärungen der beiden Verschlüsselungsarten, dessen Kenntnis für die nachfolgende Entwicklung der Testumgebung und anschließender Auswertung von großer Wichtigkeit ist. Im Zuge dessen findet die Erklärung der Abhängigkeit zwischen Schlüssellänge und Sicherheitsniveau gesondert statt, zumal diese eine wichtige Rolle in der Auswahl der zu vergleichenden Verschlüsselungsverfahren spielt. Da letztendlich der praktische Fokus auf der Verwendung der beiden Verschlüsselungsplattformen der Microsoft Corporation liegt, werden diese ebenfalls gesondert in einem weiteren Unterpunkt dargelegt.
2.1. Definitionen
Verschlüsselung (Encryption): Unter einer Verschlüsselung versteht man die Abbildung eines (lesbaren) Klartextes mit Hilfe eines Schlüsseltextes in einen (unlesbaren), sogenannten, Chiffretext. Die dazugehörige, konträre Aktivität, bei welcher der Chiffretext wieder in einen Klartext umgewandelt wird, wird als Entschlüsselung (Decryption) bezeichnet.4 Die Motivati- on dessen ist der Schutz von „Daten vor unbefugtem Zugriff.“5 Dies hat vor allem im Zeital- ter der Informationstechnologie und der zunehmenden globalen Vernetzung einen sehr ho- hen Stellenwert, da die gegenseitige Kommunikation in der Regel über öffentliche Daten- netze erfolgt und man folglich ohne eine adäquate Verschlüsselung Gefahr laufen würde, Unberechtigten einen „einfachen Zugang zu brisanten Informationen [zu] ermöglichen.“6
Kryptosystem: Kryptosysteme (bzw. Verschlüsselungsverfahren oder -algorithmen) führen die eigentliche Operation zur Ver- und Entschlüsselung mit Hilfe von mathematischen Berech- nungen aus. Der Begriff der Kryptosysteme beschränkt sich dabei nicht nur auf dem Einsatz entsprechender Software, sondern umfasst auch die manuelle Anwendung mit der Hand oder mit Hilfe von zweckerfüllenden Maschinen.7 Die Funktionsweise eines Kryptosystems ist sehr häufig publiziert und kann frei eingesehen werden. Dies hat den Vorteil, dass die
Algorithmen weitgehend auf Schwachstellen durch Sicherheitsexperten untersucht werden können.8
Schlüssel (key): Der Schlüssel (auch Schlüsseltext genannt) ist ein essenzieller Bestandteil der Ver- und Entschlüsselung. Wätjen definiert in seinem Buch den Schlüssel als „Informations- träger für die Verschlüsselung des Klartextes bzw. Entschlüsselung des Chiffretextes.“9 Da letztendlich nur die Kenntnis des Schlüssels ermöglicht, einen Chiffretext wieder in einen Klartext umzuwandeln, basiert folglich die faktische Sicherheit - zumindest bei Algorithmen ohne bekannte Schwachstellen - „nicht auf den Eigenschaften des Algorithmus.“10
Stromverschlüsselung: Die Stromverschlüsselung ist ein Verfahren eines Kryptosystems, bei welchem „eine Folge von Bits, Zeichen oder Bytes mit einem Strom von Schlüssel-Bits, - Bytes oder -Zeichen verschlüsselt“ wird.11
Blockverschlüsselung: Die Blockverschlüsselung ist ein aktuell häufig verwendetes Prinzip eines Kryptosystems, bei welchem die zu verschlüsselnden Daten in gleich große Blöcke unterteilt und anschließend unabhängig voneinander ver- bzw. entschlüsselt werden.12
Digitale Signaturen: Eine digitale Signatur ist eine „spezielle, schlüsselabhängige Prüfsumme, die im Zusammenhang mit einem digitalen Dokument ähnliche Eigenschaften aufweist wie eine Unterschrift von Hand.“13 Durch diese Eigenschaft ist es einem Empfänger möglich zu überprüfen, ob die Nachricht tatsächlich durch den zugehörigen Sender erstellt worden ist.14
Kryptografische Hashfunktion: Unter einer Hashfunktion versteht man ein Verfahren, um ein- zelnen Daten (genannt Urbild) einen bestimmten, berechneten Wert (genannt Hashwert) zuzuweisen. Hashwerte dienen in der Praxis als Prüfsumme, mit welcher sich sicher über- prüfen lässt, ob das Urbild nachträglich verändert worden ist. Indem jedoch aus Daten mit einem variablen, unbegrenztem Umfang nur ein begrenzt langer Hashwert berechnet wer- den kann, ist es durchaus möglich, dass unterschiedlichen Urbildern der gleiche Wert zu- gewiesen wird. Man spricht dabei von einer Kollision. Kryptografische Hashfunktionen zeichnen sich in der Regel durch eine hohe Zuverlässigkeit hinsichtlich der Vermeidung solcher Kollisionen aus.15
Application Programming Interface (API): Bei einer API handelt es sich um eine Program- mierschnittstelle, die es Anwendungsentwicklern ermöglicht aus ihren Applikationen heraus auf bereits bestehende Komponenten eines anderen Programmes oder Programmteile zu- zugreifen.16
2.2. Verschlüsselungsarten
In diesem Abschnitt werden die Verschlüsselungsarten vorgestellt, dessen Funktionsprinzip die Grundlage aller Kryptosysteme ist.17 Die konkreten Verschlüsselungsalgorithmen werden nachfolgend nur kurz erwähnt, da die Kenntnis deren Arbeitsweise für die weitere Ausführung des Projektes unbedeutend ist.
2.2.1. Symmetrische Verschlüsselung
Bei der symmetrischen Verschlüsselung, die bereits zur Zeit von Julius Cäsar Verwendung fand und folglich als die klassische Verschlüsselungsart gilt, wird sowohl für den Vorgang der Ver- schlüsselung, als auch für den der Entschlüsselung, der gleiche Schlüssel verwendet. Wird eine Nachricht verschlüsselt und anschließend versendet, müssen also Sender und Empfänger Kenntnis über diesen Schlüssel haben. Hierbei besteht das zentrale Problem. Zwar ist denkbar, dass der Schlüssel auf physischem Wege, beispielsweise auf einem externen Medium, überge- ben gibt, allerdings ist dies in der Praxis (v.a. im Mehrbenutzerbetrieb) nicht immer praktikabel. Folglich wird oft ein Übertragungskanal verwendet. Nicht selten ist dies ein öffentliches Daten- netz, wie etwa das Internet.18 Zur Lösung dieses Dilemmas wurde Mitte des 20. Jahrhunderts ein Verfahren mit dem Namen „Diffie-Hellman-Schlüsselaustausch“ entwickelt, welches „es Kommunikationspartnern [ermöglicht], über einen abhörbaren Kommunikationskanal einen Schlüssel auszutauschen.“19
Lange Zeit war der sog. Data Encryption Standard, kurz DES, der Industriestandard für die symmetrische Verschlüsselung von Daten. Da der Algorithmus jedoch bereits 1977, also zu ei- ner Zeit als die Rechenleistung weitaus geringer als die heutige war, entwickelt wurde, gilt dieser mittlerweile als veraltet. Die größte Schwachstelle bei diesem Kryptosystem ist der Umstand, dass nur Schlüssellängen von 56-Bit unterstützt werden (siehe Unterpunkt 2.3. für mehr Infor- mationen). War es 1977 noch absolut utopisch eine Nachricht durch ausprobieren aller mögli- chen Schlüsselkombinationen zu entschlüsseln (man spricht dabei von einem sogenannten Bru- te-Force-Angriff), ist dies heutzutage bereits in unter einem Tag möglich.20 Damit ist das Ver- schlüsselungsverfahren nicht mehr für sicherheitsrelevante Daten geeignet. Um das Verfahren nicht vollständig obsolet werden zu lassen, entwickelte man eine abgeänderte Version mit der Bezeichnung Triple-DES, bei der die Daten dreifach durch drei verschiedene Schlüssel ver- schlüsselt werden. Faktisch betrachtet hat damit der Schlüssel die dreifache Länge, also 168 Bit. Dies gewährleistet eine deutlich höhere Sicherheit.21
Nichtsdestotrotz soll ein neues, im Jahre 2000 offiziell vorgestelltes22, später zum Industriestan- dard zertifiziertes und bereits heute weitläufig verwendetes Verschlüsselungsverfahren namens Advanced Encryption Standard (AES), DES bald vollständig ersetzen. AES bietet durch die Un- terstützung von Schlüssellängen bis 256 Bit ohne bekannte Schwachstellen eine, selbst auf län- gere Sicht betrachtet, hohe Sicherheit. Diese Überlegenheit kann auch auf die Arbeitsgeschwin- digkeit übertragen werden, denn AES ist weitaus schneller als DES und dessen Derivate.23
2.2.2. Asymmetrische Verschlüsselung
Im Gegensatz zur symmetrischen Verschlüsselung, werden bei der asymmetrischen Verschlüsselung jeweils zwei unterschiedliche Schlüssel für die Ver- (öffentlicher Schlüssel) und Entschlüsselung (privater Schlüssel) benötigt. Diese Verschlüsselungsart ist vergleichsweise neu und wurde erst 1978 der Öffentlichkeit vorgestellt.24
Der öffentliche Schlüssel kann dabei, wie der Name vermuten lässt, von jedem eingesehen wer- den, während beim privaten Schlüssel, ähnlich der symmetrischen Verschlüsselung, auf strikte Geheimhaltung zu achten ist. Grundlage der asymmetrischen Verschlüsselung bildet ein Phä- nomen aus der Mathematik, welches Einwegfunktion genannt wird. Bei einer Einwegfunktion handelt es sich schlicht gesagt um „eine Funktion, die einfach zu berechnen ist, deren Umkeh- rung jedoch nur mit großem Aufwand berechnet werden kann.“25 Eine der bekanntesten Einweg- funktionen ist die Primzahlen-Multiplikation mit dem darauf verbundenem Faktorisierungsprob- lem. Gegenstand dessen ist der Umstand, dass kein bekanntes Verfahren existiert, welches das Ergebnis der Multiplikation zweier Primzahlen zuverlässig rückfaktorisiert. Damit ist es notwen- dig alle nur erdenklichen Primzahlkombinationen durchzuprobieren, wodurch jedoch - v.a. beim Einsatz hoher Primzahlen - ein erheblicher Rechenaufwand entsteht. Genau auf diesem Prinzip basiert RSA26, das bekannteste Verfahren aus dem Bereich der asymmetrischen Kryptosyste- me.
Generell haben asymmetrische Verfahren den Nachteil, dass deren Arbeitsgeschwindigkeit deutlich unter der von symmetrischen Kryptosystemen liegt. In der Literatur ist dazu häufig von einer Abweichung um den Faktor 1.000 zu lesen.27
2.2.3. Hybride Verschlüsselung
Aufgrund der langsamen Operationsgeschwindigkeit asymmetrischer Verschlüsselungsalgorithmen, werden diese in der Praxis nicht zur Verschlüsselung größerer Datenmengen verwendet. Deshalb entwickelte man die sog. hybriden Kryptosysteme. Diese verbinden den Vorteil der hohen Arbeitsgeschwindigkeit symmetrischer Kryptosystemen mit dem der hohen Sicherheit beim Schlüsselaustausch in asymmetrischen Verschlüsselungsalgorithmen.
Hierzu wird die eigentliche Nachricht mit einem symmetrischen Kryptosystem verschlüsselt, während dieses bei dem dazugehörigen geheimen Schlüssel durch ein asymmetrisches Verfah- ren bewerkstelligt wird. Der Nachrichtenempfänger kann dann mit seinem privaten Schlüssel den geheimen Schlüssel dekodieren, mit welchem er im Anschluss aus dem Chiffretext den Klartext erzeugen kann.28
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Funktionsweise hybride Ver- und Entschlüsselung29
2.3. Abhängigkeit zwischen Schlüssellänge und Sicherheitsniveau
Die Analyse der Abhängigkeit zwischen Schüssellänge und Sicherheitsniveau muss aufgrund der unterschiedlichen Funktionsweise symmetrischer und asymmetrischer Kryptosysteme iso- liert voneinander erfolgen. Daneben beruht die nachfolgende Ausführung auf der Annahme, dass die dazugehörigen Verschlüsselungsverfahren keine bekannte Schwachstelle haben.
Bei symmetrischen Verschlüsselungsalgorithmen ist die einfachste Angriffsmöglichkeit eine voll- ständige Schlüsselsuche. Folglich hängt die Sicherheit von der Anzahl aller möglichen Schlüs- selkombinationen ab. Diese ist abhängig von der Schlüssellänge und verdoppelt sich mit jedem zusätzlichen Bit eines Schlüssels. Nach aktuellem Stand der Technik, benötigt ein Supercompu- ter ca. 46.000 Jahre für die vollständige Schlüsselsuche eines 80 Bit langen Schlüssels.30 Damit können Schlüssel mit dieser Länge als sicher bewertet werden. Berücksichtigt man jedoch die schnell steigende Rechenleistung31, sollte dennoch ein längerer Schlüssel (128 Bit oder sogar 256 Bit) gewählt werden, damit der Schutz selbst zukünftigen Rechnergenerationen standhält.
Auf asymmetrische Kryptosysteme kann diese Erkenntnis jedoch nicht übertragen werden. Als Beispiel sei hierbei die RSA-Verschlüsselung erwähnt, die - wie in 2.2.2. dargestellt - auf der Einwegfunktion der Primzahlen-Multiplikation beruht. Folglich muss im Gegensatz zur symmetri- schen Verschlüsselung keine vollständige Schlüsselsuche, sondern eine Primfaktorzerlegung erfolgen. Bei gleicher Schlüssellänger ist dies eine erheblich geringerer Rechenaufwand.
Nichtsdestotrotz ist die Primfaktorzerlegung ein sehr aufwändiges Verfahren.32 Der aktuelle Weltrekord für eine Primfaktorzerlegung liegt bei einer 232-stelligen Zahl, also einem 768 Bit langem Schlüssel, und wurde mit Hilfe eines leistungsstarken Parallelrechners aufgestellt. Die Rechenzeit betrug dabei drei ganze Jahre.33 „Forscher [gehen jedoch] davon aus, dass die Re- chenleistung zum Bewältigen von RSA-1024 in rund zehn Jahren zur Verfügung stehen dürfte. Ihre Empfehlung lautet daher, alle RSA-Schlüssel mit 1024 Bit bis spätestens 2014 aus dem Verkehr zu ziehen.“34 Neuere Entwicklungen in diesem Fachgebiet verwenden jedoch immer häufiger Einwegfunktionen auf Basis sogenannter elliptischer Kurven, auch ECC-Verfahren ge- nannt.35 Diese Verfahren haben den großen Vorteil, dass ein gleichwertiger Schutz im Vergleich zu RSA gewährleistet werden kann, obwohl ein viel kürzerer Schlüssel verwendet wird.36
Zu diesem Thema veröffentlichte die US-amerikanische Bundesbehörde NIST37 nachfolgende Tabelle in einem Leitfaden, in welchem sie die Schlüssellänge unterschiedlicher Kryptosysteme bei annähernd äquivalenter Sicherheitsstufe gegenüberstellt:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Gegenüberstellung äquivalente Schlüssellängen38
2.4. Verschlüsselungsplattformen von Microsoft-Betriebssystemen
Entsprechend der Erwähnung in der Einleitung, werden nachfolgend die beiden zu vergleichenden APIs von Microsoft in chronologischer Reihenfolge vorgestellt und erläutert.
2.4.1. Microsoft CryptoAPI (CAPI)
Die CryptoAPI der Microsoft Corporation ist eine in den meisten Versionen des Betriebssystems Windows verfügbare Programmierschnittstelle, welche es Anwendungsentwicklern ermöglicht, auf verschiedene Funktionen und Algorithmen aus dem Bereich der Kryptografie zuzugreifen.39
Die Schnittstelle greift dabei auf sogenannte „cryptographic service provider“ (CSP) zu, deren Aufgabe es ist, sich um die Ausführung verschiedenartiger kryptografischer Operationen zu kümmern. Microsoft stellt dafür bereits mehrere CSPs für unterschiedliche Kryptosysteme zur Verfügung. Ein Großteil dieser ist zwar in den Bereich der asymmetrischen Verschlüsselung einzuordnen, allerdings sind zusätzlich noch Funktionen zur symmetrischen Ver- und Entschlüsselung, dem Schlüsselaustausch und Hashing implementiert.40
2.4.2. Cryptography API: Next Generation (CNG)
Cryptography API: Next Generation ist ein mit Windows Vista und Windows Server 2008 einge- führter Nachfolger der CryptoAPI. Dieser soll auf längere Sicht gesehen die bestehende Pro- grammierschnittstelle vollständig ersetzen41, wird jedoch in den aktuellen Versionen des Be- triebssystems (Windows 8 und Windows Server 2012) noch parallel zum Vorgänger eingesetzt. Dies soll eine höchstmögliche Kompatibilität zu älteren Anwendungsprogramme gewährleisten.
Die wichtigste Neuerung ist die erweiterte Individualisierbarkeit, welche es ermöglicht, den Funk- tionsumfang durch eigene Algorithmen zur Ver- und Entschlüsselung, Hashing oder Zufallszah- lengenerierung, zu erweitern. Darüber hinaus kennt CNG bereits von Haus aus viele neue Algo- rithmen. Microsoft legte bei der Entwicklung der API besonderen Wert darauf, dass sämtliche Kryptoverfahren nativ unterstützt werden, die durch den amerikanischen Geheimdienst, der Na- tional Security Agency (NSA), im Jahre 2005 als Suite B Cryptography zertifiziert worden sind. Diese Ansammlung besteht aus einem Algorithmus zur symmetrischen Verschlüsselung (AES), einem Schlüsselaustauschverfahren (ECDH oder ECMQV), einer Hashfunktion (SHA) und ei- nem Signaturverfahren (ECDSA). Alle Verfahren bieten dabei einen hohen Schutz gegen An- greifer ohne bekannte Schwachstellen und sind damit auch für die Verarbeitung geheimer Daten geeignet.42
2.5. Zeitmessung
Bereits seit dem Jahre 1981 sind in IBM-kompatiblen PCs sog. Zeitgeber (Hardware Performance Counter) in die Hardware integriert, auf die Betriebssysteme zur Durchführung einer Zeitmessung zugreifen können.43 Will man damit die Ausführungsdauer eines bestimmten Ereignisses messen, ist der direkteste Weg hierzu, die Bildung der Differenz zwischen den Zeitgeber-Werten vor Beginn und nach Ende der Aktivität.44
In heutigen Rechnersystemen sind mehrere unterschiedliche Zeitgeber verfügbar. Die neuste Entwicklung aus diesem Bereich ist der sogenannte High-Precision Event Timer (HPET), der in Zusammenarbeit zwischen Intel und Microsoft entstand45 und seit 2005 in praktisch jedem Rechnersystem Verwendung findet. Die Aktualisierungsfrequenz beträgt hierbei bis zu 10 MHz und erlaubt so Messungen im Nanosekunden-Bereich.46 Trotz solch einer hohen Genauigkeit, ist dennoch nicht ausgeschlossen, dass die Ausführungsgeschwindigkeit einzelner Prozeduren unter dem Auflösungsvermögen des Zeitgebers liegt. Praktisch gesehen wären damit beide Messwerte absolut identisch und deren Differenz null.47 Ein Lösungsansatz für dieses Problem ist die Durchführung einer Mehrfachmessung. Dabei wird die Prozedur mehrmals (beispielswei- se mit Hilfe eine Schleife) ausgeführt und lediglich die Gesamtdauer ermittelt. Indem dieser Wert durch die Anzahl der Durchläufe dividiert wird, erhält man die durchschnittliche Dauer eines Durchlaufs.48 Positiver Nebeneffekt durch die Bildung des arithmetischen Mittels ist, dass die Wahrscheinlichkeit von Messfehlern sinkt und infolgedessen eine höhere Messgenauigkeit er- reicht wird.
3. Entwicklung und Nutzung der Testumgebung
Im nachfolgenden Kapitel wird die Entwicklung und anschließende Nutzung der Testumgebung vorgestellt. Hierfür ist es zunächst notwendig eine Konzeption zu erarbeiten, mit dessen Hilfe die anschließende Entwicklung erfolgt. Ist diese abgeschlossen, wird anknüpfend der Performance- test durchgeführt, dessen Messwerte dann die Basis für die spätere Auswertung bilden.
3.1. Konzeption
Die Konzeption zur Entwicklung der Testumgebung erfolgt in drei Schritten. Als erstes muss vorab ein geeignetes Framework49, ausgewählt werden. Unabhängig von dessen Wahl, erfolgt dann die Konzeption. Abschließend wird kurz aufgelistet mit welchen Schwierigkeiten bei der Implementierung der Testumgebung zu rechnen ist.
3.1.1. Framework
Wie bei den fachlichen Anforderungen (siehe 1.4) dargelegt, wurden hinsichtlich der Designbedingungen konkrete Einschränkungen (Verwendung von Microsoft Visual Studio und der Programmiersprache C/C++) definiert. Dies führt dazu, dass die Auswahl in Frage kommender Frameworks eingeschränkt ist. Einzig die Bedienbarkeit und das optische Erscheinungsbild des Testprogrammes, können frei gewählt werden. Dabei sind zwei grundsätzliche Konzepte denkbar. Zum Einen könnte die Software als Konsolenanwendung, bei welcher alle Funktionen mit Hilfe von Tastatureingaben ausgeführt werden, realisiert werden. Zum Anderen wäre auch eine grafische Benutzeroberfläche (GUI) denkbar.
Nachdem die Vor- und Nachteile jeweiliger Varianten abgewägt worden sind, fiel die Wahl auf das letztere. Das wichtigste Argument hierbei ist die Tatsache, dass bereits ausgehend von den definierten fachlichen Anforderungen ein großer Funktionsumfang (beispielsweise die Unterstützung mehrerer Verschlüsselungsalgorithmen) im Endprodukt absehbar ist, so dass eine GUI der Übersicht und Bedienbarkeit wegen50 geeigneter ist.
[...]
1 Vgl. Schatten, A./Demolsky, M./Winkler, D./Biffl, S./Gostischa-Franta, E./Östreicher, T. (2010), S. 20ff.
2 Vgl. Fachgespräch mit Herrn F S, Software Design Engineerer und Projektbetreuer, am 17.09.2012
3 Vgl. o. V. (2012), http://gs.statcounter.com/#os-ww-monthly-201208-201208-bar
4 Vgl. Schneider, B. (1996), S. 1
5 Vgl. Schmeh, K. (2009), S. 9
6 Vgl. ebenda, S.13
7 Vgl. van Tilborg, H./Jajodia, S. (2011), S. 284f.
8 Vgl. Schmeh, K. (2009), S. 42
9 Vgl. Wätjen, D. (2008), S. 1
10 Vgl. Schneider, B. (1996), S. 4
11 Vgl. Spitz, S./Pramateftakis, M./Swoboda J. (2011), S. 24
12 Vgl. ebenda, S. 23
13 Vgl. Schmeh, K. (2009), S. 184
14 Vgl. Küsters, R./Wilke T. (2011), S.190f.
15 Vgl. ebenda, S. 209
16 Vgl. Reddy, M. (2011), S. 1
17 Vgl. Küsters, R./Wilke T. (2011), S.190f.
18 Vgl. ebenda, S. 7f.
19 Vgl. ebenda, S. 8
20 Vgl. o. V. (o. J.), http://www.sciengines.com/company/news-a-events/74-des-in-1-day.html
21 Vgl. van Tilborg, H./Jajodia, S. (2011), S. 295ff.
22 Vgl. ebenda, S. 1046
23 Vgl. Schmeh, K. (2009), S. 127ff.
24 Vgl. Küsters, R./Wilke T. (2011), S.8
25 Vgl. Schmeh, K. (2009), S. 168
26 Die Abkürzung RSA setzt sich zusammen aus den Nachnamen der Erfinder: Rivest, Shamir und Adleman, vgl. ebenda, S. 174
27 Vgl. ebenda, S. 168ff.
28 Vgl. ebenda, S. 181
29 In Anlehnung an: Schmeh, K. (2009), S. 181
30 Vgl. Schmeh, K. (2009), S. 98
31 Vgl. o. V. (o. J.), http://download.intel.com/museum/Moores_Law/Printed_Materials/Moores_ Law_Backgrounder.pdf
32 Vgl. Schmeh, K. (2009), S. 178
33 Vgl. o. V. (o. J.), http://www.rsa.com/rsalabs/node.asp?id=3723
34 Vgl. Bachfeld, D. (2010), http://www.heise.de/newsticker/meldung/RSA-768-geknackt-899073.html
35 Vgl. Schmeh, K. (2009), S. 193
36 Vgl. van Tilborg, H./Jajodia, S. (2011), S. 397
37 National Institute of Standards and Technology
38 Mit Änderungen entnommen aus: Barker, E./Barker, W./Burr, W./Polk, W./Smid, M. (2007), http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf
39 Vgl. o. V. (o. J.), http://msdn.microsoft.com/en-us/library/aa380260
40 Vgl. Viega, J. (2003), S. 238
41 Vgl. o. V. (o. J.), http://msdn.microsoft.com/de-de/library/aa376210.aspx
42 Vgl. o. V. (o. J.), http://technet.microsoft.com/en-us/library/cc730763.aspx
43 Vgl. o. V. (2002), http://msdn.microsoft.com/en-us/library/windows/hardware/gg463347.aspx
44 Vgl. Kuperberg, M. (2011), S. 83f.
45 Vgl. o. V. (2002), http://msdn.microsoft.com/en-us/library/windows/hardware/gg463347.aspx
46 Vgl. Kuperberg, M. (2011), S. 36
47 Vgl. ebenda, S. 90
48 Vgl. ebenda, S. 93
49 Ein Framework im Bereich der Software-Entwicklung ist eine Plattform, welche dem Entwickler zum Zwecke der Arbeitserleichterung eine breite Masse an bereits fertigen Basisfunktionen und Methoden bereitstellt, vgl. Schatten, A./Demolsky, M./Winkler, D./Biffl, S./Gostischa-Franta, E./Östreicher, T. (2010), S. 311ff.
50 Vgl. Badertscher, K./Romano, R. /Scheuring J. (2007), S. 123