Reverse Engineering nicht ¨offentlicher Kryptographiealgorithmen
Felix Schuster 14. Januar 2010
Studienarbeit
Ruhr-Universitat¨ Bochum Lehrstuhl fur¨ Netz- und Datensicherheit Professor Jorg¨ Schwenk
Nicht zur Ver¨offentlichung bestimmt. Keine Weitergabe außerhalb des fur¨ die Anerkennung als Studienarbeit und die Bewertung notwendigen Rahmens. Ich danke Prof. Dr. J¨org Schwenk fur¨ die Betreuung dieser Arbeit. Ebenfalls bedanken m¨ochte ich mich bei Dr. Gregor Leander fur¨ die freundliche Unterstutzung¨ bei Fragen zu S-Boxen sowie bei Ingrid und Norbert Schuster und Josefin Annemuller¨ fur¨ das Korrekturlesen.
2 Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung5 1.1 Uberblick¨ ...... 5 1.2 Vorwort...... 5 1.3 Zielstellung...... 6 1.4 Das Ziel: Chiasmus...... 7 1.5 Einstieg Reverse Engineering...... 7 1.5.1 x86 Assembler Grundlagen...... 8 1.6 Verwendete Software...... 9 1.6.1 GSTOOL...... 9 1.6.2 Windows XP SP2 in VMware Player...... 11 1.6.3 zynamics BinNavi...... 11 1.6.4 IDA - The Interactive Disassembler...... 12 1.6.5 PyEmu...... 12 1.6.6 Microsoft Visual Studio 2008...... 12 1.7 Eigene Programme...... 13
2 Lokalisierung von Chiasmus im GSTOOL 14 2.1 Reverse Engineering GSTOOL.EXE...... 15 2.1.1 Einschub: Differential Debugging...... 15 2.2 Reverse Engineering MPCrypt.dll...... 19 2.2.1 Analyse der bereitgestellten Funktionalit¨at...... 22 2.2.1.1 calcKeySchedule...... 22 2.2.1.2 generateKey...... 23 2.2.1.3 encryptDecryptFile...... 23 2.2.1.4 encryptString...... 24 2.2.1.5 decryptString...... 24 2.2.1.6 intToHexString...... 25 2.2.1.7 hexStringToInt...... 25 2.2.1.8 comFunc0 - comFunc6...... 25
3 Extrahierung und Spezifikation von Chiasmus 26 3.1 Verschlusselung¨ ...... 26 3.1.0.9 Einschub: Argumente und lokale Variablen im Stackframe... 26
3 Inhaltsverzeichnis
3.1.0.10 Einschub: Verifizierung der Korrektheit mit PyEmu...... 30 3.1.1 Grafische Beschreibung...... 33 3.2 Entschlusselung¨ ...... 35 3.2.1 Grafische Beschreibung...... 36 3.3 Key-Schedule...... 38 3.3.1 Grafische Beschreibung...... 39
4 Analyse von Chiasmus 41 4.1 Korrektheit des Verfahrens...... 41 4.2 Abh¨angigkeiten der Konstanten...... 45 4.3 S-Boxen...... 46 4.3.1 Erste Orientierung...... 46 4.3.2 Lineare Attacke...... 46 4.3.3 Differenzielle Attacke...... 50 4.3.4 Berechnungsvorschrift...... 52 4.4 Kryptographische Einordnung...... 53 4.4.1 Verabeitungsgeschwindkeit...... 53
5 Angriff gegen Schlusselgenerierung¨ im GSTOOL 55 5.1 Beschreibung...... 55 5.2 Analyse...... 56 5.2.1 Allgemein: Wieso srand(time()) keine gute Wahl ist...... 56 5.3 Angriff...... 58 5.3.1 Weitere Einschr¨ankung des Schlusselraums¨ ...... 59
6 Fazit 61
Literaturverzeichnis 62
A Anhang 64 A.1 Eigene Chiasmus-Implementierung in C++...... 64 A.2 PyEmu Skripte...... 69 A.3 Flowgraphs...... 71
4 1. Einleitung
1 Einleitung
1.1 Uberblick¨
In dieser Arbeit wird erstmals eine Spezifikation des nicht ¨offentlichen Kryptographieverfahrens Chiasmus des Bundesamtes fur¨ Sicherheit in der Informationstechnik (BSI) mit Hilfe von Re- verse Engineering gewonnen. Nach der Anfertigung einer ersten Implementierung in der Programmiersprache C++ werden weitere Analysen durchgefuhrt,¨ die Aufschluss uber¨ die ursprungliche¨ Spezifikation und Eigen- schaften der Chiffre bringen. So werden unter anderem die S-Boxen des Chiasmus-Verfahrens auf ihre Resistenz in Hinblick auf die lineare und differenzielle Kryptanalyse untersucht. Die Arbeit schließt mit einer Attacke gegen die Schlusselgenerierung¨ der speziellen Chiasmus- Implementierung im Programm GSTOOL des BSI. Dabei wird die betreffende Implementierung komplett gebrochen.
1.2 Vorwort
Ein Großteil der Kryptographieliteratur fur¨ Einsteiger zitiert an einem Punkt Auguste Kerckhoff mit seinen bekannten Prinzipien, um dem Leser zu vermitteln, dass ein gutes Kryptographie- verfahren keiner Geheimhaltung bedarf. Vielmehr f¨ordere die Ver¨offentlichung eines Verfahrens dessen Sicherheit, weil es so dem Urteil und der Analyse der internationalen Expertenschaft ausgesetzt werde. So sind heutzutage auch beinahe alle breit eingesetzten Algorithmen und eine große Anzahl von popul¨aren Kryptographieanwendungen fur¨ jedermann frei einsehbar. Das mehrere Jahre dau- ernde ¨offentliche Auswahlverfahren fur¨ den Advanced Encryption Standard (AES) hat enorm zur Vertrauensbildung gegenuber¨ dem gew¨ahlten Algorithmus beigetragen und erfolgreich bis dahin unbekannte Schw¨achen in anderen Verfahren aufgedeckt. Trotz der Vorteile und Erfolge fur¨ ¨offentliche A, gab und gibt es Verfahren und Anwendungen, deren Funktionsweise bewusst geheimgehalten wird. Die Grunde¨ dafur¨ sind vielf¨altig. Zun¨achst geht mit einer Geheimhaltung prinzipiell immer erstmal ein Sicherheitsgewinn einher. Unsiche- re, wie sichere Verfahren werden sicherer, weil die Arbeit fur¨ Kryptanalytiker ohne Kenntnis der genauen Spezifikationen in jedem Fall erschwert wird. Fur¨ die Autoren und Nutzer einer
5 1. Einleitung solchen Chiffre ist es jedoch schwerer zu entscheiden, zu welcher der beiden Gruppen ihr Ver- fahren geh¨ort - der der sicheren oder doch der der unsicheren. In der Vergangenheit wurden Kryptographieverfahren mitunter auch als Firmengeheimnisse betrachtet - h¨aufig weil in ihre Entwicklung Geld geflossen war und man die Ergebnisse nie- mandem kostenlos zur Verfugung¨ stellen wollte. Bekannte Beispiele hierfur¨ sind die Chiffren RC41 und CSS2. Beide Algorithmen wurden gegen den Willen ihrer Rechteinhaber in den 90er Jahren publik. Seitdem konnten mehrere, zum Teil schwerwiegende Schw¨achen in beiden nach- gewiesen werden. Im Fall von CSS ist bekannt, dass die unautorisiert ver¨offentlichte Version mit Hilfe von Reverse Engineering einer Softwareimplementierung entstand. Mit Reverse Engineering wird gemeinhin der Vorgang des Nachvollziehens von Entwicklungs- schritten in umgekehrter Reihenfolge bezeichnet. Dabei kann es sich bei dem Zielobjekt um etwas Abstraktes wie eine Software, aber auch um etwas Greifbares wie einen Motor handeln (den man von Hand auseinander nimmt). Das Ziel ist in jedem Fall das Gleiche: Es sollen Informationen uber¨ Funktionsweisen und den inneren Aufbau gewonnen werden, die anders nicht zug¨anglich sind. Genau mit diesem Reverse Engineering von kryptographischen Anwendungen besch¨aftigt sich diese Arbeit.
1.3 Zielstellung
Das Ziel dieser Arbeit ist, mit Hilfe von Reverse Engineering die Funktionsweise des bisher nicht ¨offentlichen Kryptographieverfahrens Chiasmus offenzulegen. Dazu werden die entsprechenden Algorithmen in den Kapiteln zwei und drei im Assemblercode3 der PC-Anwendung GSTOOL lokalisiert und anschließend spezifiziert. In dem darauf folgenden Kapiteln wird zus¨atzlich dazu noch ein genauerer Blick auf die Eigen- schaften des Chiasmus geworfen - der Prozess des Reverse Engineerings wird gewissermaßen eine Ebene h¨oher fortgesetzt. Im letzten, funften¨ Kapitel wird schließlich ein Angriff gegen die spezielle Chiasmus-Implementierung im GSTOOL demonstriert.
1Rivest Cipher 4: Von RSA Security entwickelte Stromchiffre [14]. Wird u.a. in der WLAN-Verschlusselung¨ WEP eingesetzt. 2Content Scrambling System: Der bei Video-DVDs eingesetzte Kopierschutz. Basiert auf einer 40 Bit Strom- chiffre. 3Unter Assembler wird gemeinhin die Programmiersprache verstanden, die ein Prozessor direkt versteht. Nativ ausfuhrbare¨ Programme, wie z.B. EXE-Dateien unter Windows, enthalten generell Assemblercode. Hier wird Assembler fur¨ x86-Prozessoren betrachtet.
6 1. Einleitung
1.4 Das Ziel: Chiasmus
Das Bundesamt fur¨ Sicherheit in der Informationstechnik (BSI) setzt in seinen kryptographi- schen Anwendungen unter anderem die selbst entwickelte Blockchiffre Chiasmus zur Datenver- schlusselung¨ ein. Die genaue Spezifikation des Verfahrens ist ausdrucklich¨ nicht ¨offentlich und wird entsprechend unter Verschluss gehalten. Die vermutlich einzige ¨offentliche Quelle fur¨ Informationen zu Chi- asmus ist die Webseite des BSI. Dort ist zu erfahren, dass das Chiasmus-Verfahren uber¨ eine gultige¨ Zulassung fur¨ Daten mit der Anforderung Verschlusssache - Nur fur¨ den Dienstge- ” brauch“ (VS-NfD) verfugt¨ und mit einer Schlussell¨ ¨ange von 160 Bits auf 64 Bits langen Daten- bl¨ocken zur Ver- und Entschlusselung¨ arbeitet. Von den 160 Bits des Schlussels¨ sollen dabei nur 128 effektiv zur Sicherheit beitragen, die ubrigen¨ 32 Bits wurden,¨ wie zum Beispiel auch beim DES Algorithmus, zur Fehlererkennung verwendet [7]. Implementierungen des Chiasmus sind zumindest in den beiden BSI-Softwareprodukten GS- TOOL [8] und Chiasmus fur¨ Windows/Linux [7], sowie der integrierten IPSec-L¨osung SINA (Sichere Inter-Netzwerk Architektur) [9] zu finden. W¨ahrend die letzteren beiden Produkte nur an Beh¨orden und besonders schutzbedurftige¨ Unternehmen vertrieben werden, handelt es sich beim GSTOOL um eine ¨offentliche Software, die von jedem beim BSI zu bestimmten Li- zenzkosten bezogen werden kann. Eine kostenlose, fur¨ 30 Tage voll funktionsf¨ahige Testversion l¨asst sich direkt von der Webseite des BSI herunterladen. Auf der Softwareimplementierung der Algorithmen des Chiasmus-Verfahrens in dieser Testversion werden im Folgenden s¨amtliche Analysen durchgefuhrt.¨
1.5 Einstieg Reverse Engineering
Prinzipiell gilt, dass sich jegliche in einem Computerprogramm implementierte Funktionalit¨at mit mehr oder weniger Aufwand von außen offenlegen l¨asst. Alles was fur¨ einen Prozessor lesbar ist, l¨asst sich uber¨ gr¨oßere oder kleinere Umwege auch wieder fur¨ einen Menschen lesbar machen.
Dazu mussen¨ die bei der Programmerstellung erfolgten Arbeitsschritte des Compilers ruckg¨ ¨an- gig gemacht werden. Was sich zun¨achst nach einer leicht zu automatisierenden Aufgabe anh¨ort, ist in der Realit¨at ohne manuelle Arbeit kaum zu bewerkstelligen. Zwar l¨asst sich der eigentliche Befehlsfluss einer Anwendung schnell mit Hilfe eines Disassemblers wieder in eine lesbare Ab- folge von Assemblerbefehlen umwandeln, jedoch ist das Ergebnis meistens sehr unubersichtlich¨ und wenig aussagekr¨aftig. H¨aufig ist eine iterierte Analyse eines Programmteils notwendig, um die eigentlich Funktions- weise und den Zweck dessen zu erkennen. So lassen sich oft eine Vielzahl von einzelnen Assem-
7 1. Einleitung
Abbildung 1.1.: Reverse Engineering Prozess blerbefehlen auf einen einzigen Befehl in der Ausgangssprache (z.B. C++ oder Visual Basic) zuruckf¨ uhren.¨ Die Kunst besteht darin, Optimierungen und Standardkonstruktionen moderner Compiler zu erkennen und zuruck¨ zu ubersetzen.¨ Ebenso wichtig ist es, tats¨achlich vom Ent- wickler konzipierte und programmierte Funktionalit¨at von der bereitgestellten Funktionalit¨at eines Frameworks zu unterscheiden. Im Idealfall ist das Ergebnis wieder eine leicht verst¨andliche Darstellung der interessanten Teile des Zielprogrammes - zum Beispiel in Form eines kompilierbaren, ¨aquivalenten Quellcodes in einer Hochsprache.
1.5.1 x86 Assembler Grundlagen
Die x86 Architektur und ihr Nachfolger x64 sind die Basis jedes PC- und jedes modernen Apple- Systems. Beinahe alle Hauptprozessoren der beiden bekannten Hersteller Intel und AMD fallen in diese Gruppe. In dieser Arbeit wird ausschließlich Assemblercode fur¨ x86 Prozessoren bearbeitet. Dazu seien hier kurz einige Grundlagen und die g¨angige Terminologie erl¨autert. Grob betrachtet kann ein x86 Prozessor auf Daten an zwei Orten zugreifen: Auf Daten im Ar- beitsspeicher und auf Daten in seinen internen Registern. W¨ahrend der Arbeitsspeicher verh¨altnism¨aßig langsam ist, kann er doch eine große Menge von Daten beinhalten. Andersherum verh¨alt es sich mit den internen Registern des Prozessors. Von diesen besitzt der Prozessor nur eine begrenzte Anzahl. Zudem k¨onnen die Register in der Re- gel jeweils nur 32 Bits an Daten aufnehmen. Dafur¨ stellen sie den schnellsten Speicher dar, der einem x86 Prozessor zur Verfugung¨ steht. Entsprechend werden diese Register sehr h¨aufig, beinahe in jedem Assemblerbefehl, verwendet. Obwohl aktuelle Prozessoren uber¨ eine Vielzahl an Registern fur¨ verschiedenste Aufgaben ver- fugen,¨ trifft man bei der Analyse von x86 Assemblercode in den allermeisten F¨allen nur auf die acht Basisregister EAX, EBX, ECX, EDX, ESI, EDI, ESP und EIP, die jeweils 32 Bits lang
8 1. Einleitung sind. Dabei k¨onnen die ersten sechs theoretisch beliebig fur¨ die Datenverarbeitung verwendet werden. Eine typische Befehlsfolge sieht im Disassembler beispielsweise wie folgt aus: 0040104F mov eax , dword ptr [ ebx+0Ch] 00401052 imul eax , 12h
Die erste Spalte gibt hier die virtuellen Adressen (VA) der Befehle im Arbeitsspeicher in hexa- dezimaler Schreibweise an. Man spricht von virtuellen Adressen, weil auf x86 generell jedem Prozess ein eigener virtueller Arbeitsspeicher von vier GBytes Gr¨oße zur Verfugung¨ steht. Um die Umsetzung im eigentli- chen, physischen Arbeitsspeicher kummert¨ sich das Betriebssystem. Im weiteren Verlauf dieser Arbeit werden virtuelle Adressen in der Form 0x0040104F hexadezimal notiert. Die zweite Spalte des Disassemblies gibt den Operator an, w¨ahrend die dritte Spalte die betref- fenden Operanden anzeigt. Als Operanden k¨onnen je nach Befehl Konstanten, Register oder Zeiger auf Daten im Ar- beitsspeicher angegeben werden. Wird ein Ausdruck wie in der ersten Zeile durch eckige Klam- mern umschlossen, so wird das Ergebnis des Ausdrucks als Adresse im Arbeitsspeicher interpre- tiert und dort entsprechend lesend oder schreibend zugegriffen. dword ptr zeigt dabei an, dass es sich um einen Zeiger auf einen Wert vom Typ Dword (double word) handelt. Neben dem 8 Bits langen Byte wird auch der 32 Bits lange, aus vier Bytes bestehende Datentyp Dword in dieser Arbeit an mehreren Stellen verwendet.
Der erste der beiden Befehle bewirkt hier, dass der Wert C16 = 1210 tempor¨ar auf den Wert im Register EBX addiert wird. Das Ergebnis wird dann als Zeiger auf einen 32 Bits langen Wert im Arbeitsspeicher interpretiert. Wegen des Operators mov wird dieser Wert aus dem Arbeitsspeicher schließlich in das Register EAX geschrieben.
Der zweite Befehl bewirkt die Multiplikation des Wertes in EAX mit der Konstanten 1216 =
1810.
1.6 Verwendete Software
Die im Folgenden aufgefuhrten¨ Programme wurden fur¨ den Reverse Engineering Prozess in dieser Arbeit verwendet.
1.6.1 GSTOOL
Version: 4.5 BUILD 2082 (Kostenlose 30-Tage Testversion)
9 1. Einleitung
Das Programm GSTOOL wird seit Ende der neunziger Jahre vom BSI angeboten. Sp¨ates- tens seit Versionsschritt 3 wird es extern in der Sprache Visual Basic von der Firma Steria Mummert Consulting entwickelt. Wie der Name GrundSchutz Tool andeutet, besteht die ei- gentliche Funktion des Programmes nicht in kryptographischen Anwendungen, sondern in der Planung und Verwaltung von IT-Sicherheitsmaßnahmen.
Abbildung 1.2.: GSTOOL Oberfl¨ache, Verschlusselungsfunktion¨
Es bietet dem Anwender die M¨oglichkeit, IT-Systeme und Anwendungen innerhalb eines Un- ternehmens oder einer Beh¨orde zu erfassen und nach Gesichtspunkten des IT-Grundschutzes4 zu analysieren und zu bewerten [6]. Insgesamt wird eine große Anzahl von Funktionen angeboten, auf die hier im Einzelnen nicht weiter eingegangen werden soll. Es sei bloß festgehalten, dass das Hauptanwendungsgebiet des GSTOOLs nicht die Datenverschlusselung¨ ist. Fur¨ den weiteren Verlauf dieser Arbeit ist ausschließlich die integrierte Verschlusselungsfunk-¨ tion interessant, die [...] die Ubertragung¨ von Export-Dateien uber¨ potentiell unsichere Uber-¨ ” tragungsmedien [...]“ [6] schutzen¨ soll. Diese Verschlusselungsfunktion¨ verwendet, laut Hand- buch, das Chiasmus-Verfahren und verfugt¨ uber¨ einen eigenen Generator zur Schlusselerzeu-¨ gung. Die zugeh¨orige Benutzeroberfl¨ache l¨asst sich uber¨ den Menupunkt¨ Extras→Verschlus-¨ ” selung“ aufrufen. Dort lassen sich Schlusseldateien¨ erzeugen, importieren und exportieren. Mit diesen Schlusseln¨ k¨onnen dann prinzipiell beliebige Dateien ver- und entschlusselt¨ werden - auch nach Ablauf der 30 t¨agigen Testperiode.
4Vom BSI festgelegter Standard fur¨ die Erstellung von Sicherheitsmaßnahmen. Namensgebend fur¨ das GSTOOL.
10 1. Einleitung
1.6.2 Windows XP SP2 in VMware Player
Die komplette Laufzeitanalyse des GSTOOLs wurde innerhalb eines virtualisierten PCs mit Windows XP Service Pack 2 Installation durchgefuhrt.¨ Windows XP bekam den Vorzug gegen- uber¨ neueren Windows Versionen, weil bei diesem noch kein Address Space Layout Randomi- ” zation“5 zur Anwendung kommt, was das Debugging unn¨otig verkompliziert h¨atte. Zur Virtualisierung wurde VMware Player der Firma VMware verwendet.
1.6.3 zynamics BinNavi
Version: 2.2.0
Das Tool BinNavi der Firma zynamics dient der ubersichtlichen¨ Darstellung von disassem- bliertem Programmcode und der Veranschaulichung von Programmabl¨aufen zur Laufzeit. Ein Programm wird dabei als ein gerichteter Graph verstanden, bei dem jede Funktion einen Knoten und jeder statische Aufruf von Funktionen untereinander eine Kante darstellt. Dieser gerichtete Graph, der alle m¨oglichen Pfade innerhalb eines Programmes darstellt, wird Callgraph genannt. Analog stellt BinNavi den Programmfluss innerhalb von Funktionen dar. Zusammengeh¨orende Bl¨ocke von Assemblerinstruktionen, Basic Blocks genannt, werden als Knoten interpretiert - m¨ogliche Sprunge¨ zwischen diesen Bl¨ocken als Kanten. So besteht zum Beispiel eine klassi- sche if-then-else Anweisung aus drei Knoten und zwei Kannten (if→then und if→else). Der gerichtete Graph einer Funktion wird Flowgraph genannt.
Abbildung 1.3.: Flowgraph einer Funktion aus GSTOOL.exe mit if-then-else Anweisung im ersten Basic Block. if→then gruner¨ Pfeil, if→else roter Pfeil
BinNavi kombiniert diese Art der Darstellung mit der F¨ahigkeit den Kontrollfluss durch einen Call- oder Flowgraph eines Programmes bzw. einer Funktion aufzuzeichnen. Beginn und En-
5ASLR ist eine Technologie die das Ausnutzen von Sicherheitslucken¨ in Software erschweren soll. Dazu werden ausfuhrbare¨ Dateien nicht mehr an eine bestimmte, sondern an eine zuf¨allig gew¨ahlte Adresse im Speicher geladen.
11 1. Einleitung de einer solchen Aufzeichnung k¨onnen dabei beliebig festgelegt werden. Diese Funktion eignet sich hervorragend um Programmfunktionen und disassemblierten Programmcode einander zu- zuordnen und wird im praktischen Teil dieser Arbeit verwendet. Die fur¨ diese Funktion be- n¨otigte Debugger-Technologie ist fur¨ verschiedene Hardwareplattformen und Betriebssysteme implementiert. Zus¨atzlich wird BinNavi hier fur¨ das konventionelle Debugging des GSTOOL Prozesses verwendet. Stattdessen h¨atte auch jeder andere Windows User-Mode Debugger, wie zum Beispiel OllyDbg, verwendet werden k¨onnen. Ich selbst bin im Rahmen meiner Anstellung bei der zynamics GmbH seit 2006 an der Programmierung von BinNavi beteiligt.
1.6.4 IDA - The Interactive Disassembler
Version: 5.4
Bei IDA handelt es sich um das Standardwerkzeug im Bereich des Reverse Engineering. Sei- ne Kernfunktion besteht darin, aus kompilierten Programmen wieder lesbaren Assemblercode zu generieren (Disassemblierung). Die St¨arken von IDA liegen in seiner guten Erweiterbarkeit durch Plugins und seiner intelligenten Analyse von Code und Daten eines kompilierten Pro- grammes. IDA unterstutzt¨ explizit eine Vielzahl von Dateiformaten, wie zum Beispiel Portable Executable (.exe), und verfugt¨ von Haus aus uber¨ Signaturen fur¨ bekannte Frameworks. Das Programm wird in dieser Arbeit zur Generierung von Disassemblies fur¨ BinNavi und zur manuellen Analyse verwendet.
1.6.5 PyEmu
Version: Revision 19 Issue 1
IDA l¨asst sich unter anderem mit Hilfe von Skripten in der Sprache Python automatisieren. Das Open-Source Projekt PyEmu bietet die M¨oglichkeit, uber¨ diese Schnittstelle einzelne x86 Assembler Codeabschnitte innerhalb von IDA zu emulieren. In dieser Arbeit wird PyEmu dazu verwendet, die im GSTOOL enthaltene Chiasmus Implementierung direkt anzusprechen und fur¨ bestimmte Eingaben zu testen. Die so erhaltenen Ausgaben werden dann benutzt, um die Korrektheit der eigenen C++ Implementierung des Chiasmus zu verifizieren.
1.6.6 Microsoft Visual Studio 2008
S¨amtlicher C++ Programmcode in dieser Arbeit wurde mit Microsofts Entwicklungsumgebung Visual Studio 2008 fur¨ Windows Systeme entwickelt und kompiliert.
12 1. Einleitung
1.7 Eigene Programme
Im weiteren Verlauf dieser Arbeit wird an mehreren Stellen auf selbstentwickelte Programme hingewiesen. Diese wurden im Rahmen dieser Arbeit in den Programmiersprachen C++ und Python erstellt. Sowohl die Quellcodes, als auch die zugeh¨origen kompilierten Versionen sind auf dem beiliegen- den Datentr¨ager zu finden. Die Quellcodes der in C++ entwickelten Programme liegen in Form von Visual Studio 2008 Projekten vor.
13 2. Lokalisierung von Chiasmus im GSTOOL
2 Lokalisierung von Chiasmus im GSTOOL
In diesem Kapitel sollen die Kernalgorithmen des Chiasmus-Verfahrens innerhalb des GSTOOLs lokalisiert werden und eine erste Analyse erfolgen. Typischerweise besteht eine Blockchiffre aus den Teilen Verschlusselung,¨ Entschlusselung¨ und einem Key-Schedule zur Berechnung von Runden- oder Teilschlusseln¨ aus einem Ausgangsschlussel.¨ Genau diese drei Algorithmen wer- den gesucht.
Nach der Installation des GSTOOLs zeigt ein Blick in den angelegten Programmordner, dass die Anwendung im Wesentlichen aus drei ausfuhrbaren¨ Dateien zu bestehen scheint.
\GSTOOL.exe \Bin\MPCrypt.dll \Bin\DBAttacher.exe
Trotz ihres Namens l¨asst sich MPCrypt.dll zun¨achst nicht direkt mit der gesuchten Chias- mus Implementierung in Verbindung bringen. So zeigt eine kurze Uberpr¨ ufung¨ des Export- Tables1 der Dll mit IDA, dass einem externen Aufrufer augenscheinlich keine Funktionen mit kryptographischem Kontext bereitgestellt werden.
Abbildung 2.1.: Darstellung des Export-Tables von MPCrypt.dll in IDA
Zudem lassen sich in der GSTOOL.exe direkt auch keine Verweise auf MPCrypt.dll finden - weder im Import-Table2 noch unter den von IDA automatisch erkannten Zeichenketten.
1Dynamic link libraries dienen auf Windows Betriebssystemen dazu, zur Laufzeit eines Programmes weitere Funktionalit¨at hinzuzufugen.¨ Dazu wird eine Dll nachtr¨aglich in den Adressraum des entsprechenden Pro- grammes geladen - sie wird gewissermaßen zur Laufzeit gelinkt“. Generell enth¨alt der Export-Table einer ” Dll Zeiger auf s¨amtliche von ihr bereitgestellten Funktionen. 2Der Import-Table stellt das Gegenstuck¨ zum Export-Table dar. Hier werden alle zum Programmstart nach- zuladenden Dlls und Funktionen aufgefuhrt.¨ Mit Visual Basic erstellte Applikationen wie die GSTOOL.exe importieren direkt jedoch immer nur Funktionen der entsprechenden Visual Basic Dll (hier: MSVBVM60.dll)
14 2. Lokalisierung von Chiasmus im GSTOOL
So wird die Analyse von MPCrypt.dll hinten angestellt und zun¨achst GSTOOL.exe genauer auf das Enthalten des Chiasmus hin uberpr¨ uft.¨
2.1 Reverse Engineering GSTOOL.EXE
Bei GSTOOL.exe handelt es sich mit einer Dateigr¨oße von rund 13 MB um ein ungew¨ohnlich großes Programm. Auch in der heutigen Zeit, in der Speicherplatz nur noch eine untergeordnete Rolle spielt, trifft man selten auf Executables mit einem solchen Gewicht. So erreicht selbst eine ausgesprochen komplexe Anwendung wie FireFox 3 diese Marke nur knapp und auch nur, wenn alle im Paket enthaltenen ausfuhrbaren¨ Dateien zusammengez¨ahlt werden (firefox.exe alleine ist rund 300 KB groß). Entsprechend ist das Bild in IDA - es werden 10388 Funktionen innerhalb der GSTOOL.exe gefunden. Von diesen werden 235 von IDA selbstst¨andig als Standardfunktionen erkannt und benannt. Diese Komplexit¨at ist nur in Teilen dem eigentlichen Umfang des Programmes geschuldet. Der Import-Table der GSTOOL.exe zeigt, dass das Programm mit Visual Basic 6 entwickelt wurde (ausschließliches importieren von MSVBVM60.dll Funktionen ist hier ein hinreichendes Kriterium). In dieser Sprache entwickelte Anwendungen sind Prinzip bedingt fast immer gr¨oßer als ¨aquivalente Programme in C/C++ oder auch Delphi. Visual Basic 6 Programme k¨onnen als eine Aneinanderreihung von Aufrufen von Standardbibliotheksfunktionen betrachtet werden. So werden eigentlich einfache Anweisungen h¨aufig in eine Folge von mehreren Bibliotheksaufrufen ubersetzt,¨ was im Resultat zu vergleichsweise vielen ben¨otigten Assemblerbefehlen fuhrt.¨ Bei solch einer großen Menge an Assemblercode ist eine strukturierte Analyse unerl¨asslich. Allein das manuelle Untersuchen von nur wenigen Prozent der unbekannten Funktionen der GSTOOL.exe durfte¨ viel Zeit in Anspruch nehmen und w¨are noch dazu wenig ergiebig.
2.1.1 Einschub: Differential Debugging
Mit BinNavi ist es m¨oglich, so genanntes Differential Debugging“ durchzufuhren.¨ Dazu werden ” mindestens zwei Kontrollflusse¨ eines Programmes durch dessen Callgraph zur Laufzeit aufge- nommen (analog genauso m¨oglich fur¨ einzelne Funktionen und ihre Flowgraphen). Das Ergebnis ist jeweils eine Menge von besuchten Knoten, die eine Untermenge der Knoten des Callgraphs darstellt. Mit diesen Mengen l¨asst sich dann innerhalb von BinNavi arbeiten. Prinzipiell ist es m¨oglich eine Fulle¨ von Operationen auf den Mengen auszufuhren.¨ Die beiden interessantesten sind jedoch die Schnitt- und Differenzmengenbildung.
15 2. Lokalisierung von Chiasmus im GSTOOL
Die Vorgehensweise und Anwendung soll anhand des Beispiels eines fiktiven Kryptographiepro- grammes verdeutlicht werden, das zum Ver- und Entschlusseln¨ von Dateien auf der Festplatte verwendet wird. Um die kryptographischen Komponenten zu isolieren werden zun¨achst zwei
Mengen von Knoten erstellt: T1 durch das Aufzeichnen des Kontrollflusses w¨ahrend der Ent- schlusselung¨ einer Datei, T2 durch das Aufzeichnen w¨ahrend der Verschlusselung¨ einer Datei. Naturlich¨ werden bei beiden Vorg¨angen eine Vielzahl von Funktionen aufgerufen, von Aufrufen der Benutzeroberfl¨ache, uber¨ Dateisysteminteraktionen bis hin zu den gesuchten kryptographi- schen Funktionen. Weil Ver- und Entschlusselung¨ uber¨ die Benutzeroberfl¨ache angestoßen und in beiden F¨allen Dateien sowohl geschrieben als auch gelesen werden, ist davon auszugehen, dass ein Großteil der Elemente von T1 und T2 identisch ist. Zieht man nun die Menge T2 von der Menge T1 ab, so sind in der resultierenden Menge nur noch Knoten enthalten, die aus- schließlich w¨ahrend der Entschlusselung¨ aktiv waren. Der Kreis der Kandidaten, die als die gesuchten kryptographischen Funktionen in Frage kommen, sollte stark eingeschr¨ankt worden sein. Formell l¨asst sich der Vorgang vereinfacht wie folgt beschreiben:
MGUI = {g1, g2, g3, ...},Mfilesystem = {f1, f2, f3, ...},Mcrypto = {cdec, cenc}
Mcallgraph = MGUI ∪ Mfilesystem ∪ Mcrypto
T1 = {g1, g5, f2, cdec, f3},T2 = {g1, g5, f3, cenc, f2}
T1 ∩ T2 = {g1, g5, f2, f3}
T1\T2 = {cdec}
Ein weiteres Beispiel: Angenommen eine Anwendung verwendet eine Feistel-Chiffre, wie zum Beispiel den DES-Algorithmus. Diese Art von Chiffren zeichnet sich vor allem dadurch aus, dass zum Ver- und Entschlusselung¨ dieselbe Rundenfunktion verwendet wird. Durch das Bilden der Schnittmenge der jeweils beim Ver- und Entschlusseln¨ aktiven kryptographischen Funktionen innerhalb des Programmes (beispielsweise alle Funktionen einer bestimmten Dll), l¨asst sich auch hier der Prozess des Identifizierens abkurzen.¨ Im Regelfall sollte die Rundenfunktion der Feistel-Chiffre als einer von wenigen Knoten in der Schnittmenge enthalten sein.
Die technische Grundlage, die das Aufzeichnen eines Kontrollfluss erm¨oglicht, ist relativ simpel. Zu Beginn eines Aufzeichnungsvorgangs, wird auf die erste Assemblerinstruktion jeder Funktion im Callgraph oder jedes Basic Blocks im Flowgraph ein Software-Breakpoint gesetzt. Trifft ein Programm bei seiner Ausfuhrung¨ auf so einen Software-Breakpoint, so wirft es eine Exception
16 2. Lokalisierung von Chiasmus im GSTOOL
(Ausnahme). Durch das Aufzeichnen dieser Exceptions l¨asst sich der Fluss durch ein Programm leicht protokollieren.
Diese Technik wird nun zur Suche des Chiasmus innerhalb der GSTOOL.exe verwendet. Dazu wird wie im obigen Beispiel zum Differential Debugging“, der Kontrollfluss durch den Call- ” graph w¨ahrend des Ver- und des Entschlusselns¨ einer Datei aufgezeichnet. Um m¨oglichst wenig uninteressante Aktivit¨aten mitzuschneiden, wird mit der Aufzeichnung erst nach dem Ausw¨ah- len der beteiligten Dateien und unmittelbar vor dem Ausfuhren¨ der Ver- bzw. Entschlusselung¨ begonnen. Entsprechend wird die Aufzeichnung nach dem Erscheinen der abschließenden Sta- tusmeldung ( Datei wurde verschlusselt.“¨ bzw. Datei wurde entschlusselt.“)¨ wieder beendet. ” ” Die Mengen der jeweils besuchten Knoten im Callgraph seien Tenc und Tdec. Nach Durchfuhrung¨ des Versuchs, enthalten beide Mengen 38 Elemente.
Bestimmt man Tenc\Tdec, so zeigt sich, dass Tenc nur die folgenden zwei Funktionen enth¨alt, die nicht auch in Tdec enthalten sind:
Funktion Virtuelle Adresse Knoten (Basic Blocks) Kanten sub 7B3B51 0x007B3B51 53 71 sub 4A7A4B 0x004A7A4B 54 72
Tabelle 2.1.: Tenc\Tdec
Es gibt also nur zwei Funktionen, die w¨ahrend derVerschlusselung¨ verwendet werden, aber nicht bei der Entschlusselung.¨ Ein Ausschnitt der Darstellung von Tenc ist in Abbildung 2.2 zu sehen.
Dabei sind ebenfalls in Tdec enthaltene Funktionen blau markiert.
Abbildung 2.2.: Ausschnitt Tenc ∩ Tdec blau, Tenc\Tdec grun¨
Schnell zeigt sich, dass es sich bei sub 4A7A4B und sub 7B3B51 praktisch um ein und diesel- be Funktion handelt. So besteht sub 4A7A4B nur aus einem zwei Instruktionen langen Basic
17 2. Lokalisierung von Chiasmus im GSTOOL
Block, der an den Anfang von sub 7B3B51 springt. Eine anschließende manuelle Analyse der relativ großen Funktion sub 7B3B5 offenbart: Ent- gegen der anf¨anglichen Vermutung, sind in dieser Funktion keine Operationen enthalten, die auf die Implementierung eines Kryptographiealgorithmus schließen lassen. Indikatoren hierfur¨ w¨aren zum Beispiel iterierte Codeabschnitte und Operationen auf Bit-Ebene wie XOR, OR oder Shifts. Gleiches gilt auch fur¨ die statischen Unterfunktionen von sub 7B3B51. Stattdessen dient ein Großteil des in sub 7B3B51 enthaltenen Codes der Erstellung und Ge- nerierung von Zeichenketten. Dazu werden die aus MSVBVM60.dll importierten Funktionen vbaStrMove, vbaStrCat, vbaStrCopy und vbaStrCmp jeweils an mehreren Stellen auf- gerufen. Verarbeitet werden dabei Zeichenketten wie Die Datei wurde entschlusselt.“¨ oder Die ” ” angegebene Datei ist bereits vorhanden[...]“3. Offensichtlich werden hier die Statusnach- richten, die den Nutzer uber¨ den Verlauf der angestoßenen Operation informieren, erstellt. Die weitere Analyse von sub 7B3B51 zeigt, dass die Ruckgabewerte¨ von Funktionen, die dy- namisch uber¨ das Prozessorregister EAX aufgerufen werden, daruber¨ entscheiden, welche der Statusnachrichten dem Nutzer pr¨asentiert wird. EAX wird dazu mit einem Zeiger auf eine Tabelle von Funktionszeigern geladen. Aufrufe dieser Funktionen erfolgen dann wie an Adresse 0x007B4F58:
007B4F58 c a l l dword ptr [ eax+2Ch]
Hier wird beispielsweise in die elfte Funktion der Tabelle verzweigt4. Was zun¨achst nach einer ungew¨ohnlichen oder umst¨andlichen Konstruktion aussehen mag, ist tats¨achlich ganz allt¨aglich. Objektorientierte Konstrukte in Hochsprachen werden von Compi- lern auf diese Weise ubersetzt.¨ Auf welche Tabelle EAX genau zeigt, l¨asst sich am einfachsten zur Laufzeit mit einem Debugger bestimmen. Es zeigt sich, dass die verwendete Funktionszeigertabelle an der virtuellen Adresse 0x10014788 liegt. Diese Adresse befindet sich außerhalb des Bereiches, den die GSTOOL.exe zur Laufzeit im virtuellen Speicher belegt5. Man k¨onnte vermuten, dass die Adresse innerhalb des Heaps oder Stacks der Anwendung liegt, jedoch ist 0x10000000 die Standardbasisadresse fur¨ applikationsspezifische Dlls auf Windows Systemen. So ist auch MPCrypt.dll an 0x10000000 geladen und 0x10014788 ist eine Adresse innerhalb des Datansegments der Dll. Die dort liegen- de Tabelle enth¨alt ausschließlich Zeiger auf Funktionen innerhalb der MPCrypt.dll. Aus GSTOOL.exe werden also fur¨ das Ausfuhren¨ von kryptographischen Operationen Funktio-
3Die innerhalb von sub 7B3B51 verwendeten Zeichenketten liegen im Unicode-Format vor. Diese werden hier von IDA nicht automatisch erkannt und mussen¨ erst von Hand als solche deklariert werden. 4 Auf 32 Bit Plattformen haben Zeiger eine L¨ange von vier Bytes. Mit 2C16 = 4410 = 11 ∗ 4 zeigt [eax+2Ch] auf das 11. Vier-Bytes-Wort an der Speicherstelle, auf die EAX zeigt. 5GSTOOL.exe wird auf Windows XP Systemen immer an 0x00400000 geladen, der Standardadresse fur¨ Exe- cutables. Bei Gr¨oße von D24000h Bytes im geladenen Zustand, belegt die GSTOOL.exe den Speicherbereich 0x00400000 - 0x01124000.
18 2. Lokalisierung von Chiasmus im GSTOOL nen innerhalb von MPCrypt.dll uber¨ eine Funktionszeigertabelle aufgerufen. Diese Funktionen werden dabei, wie oben schon gesehen, nicht uber¨ den Export-Table von MPCrypt.dll expor- tiert. Stattdessen zeigt eine weitere Analyse, dass GSTOOL.exe und MPCrypt.dll uber¨ Microsofts Component Object Model“ (COM) kommunizieren und ein Client-Server Paar bilden. Da- ” bei weisen die von MPCrypt.dll direkt exportierten Funktionen DllRegisterServer, DllUnre- gisterServer, DllGetClassObject und DllCanUnloadNow daraufhin, dass MPCrypt.dll als so genannter In-Process Server“ [1] der GSTOOL.exe zur Laufzeit Funktionalit¨at bereitstellt. Die ” Funktionstabelle an 0x10014788 wird im Folgenden funcTable genannt.
2.2 Reverse Engineering MPCrypt.dll
Nachdem die Analyse der GSTOOL.exe ergeben hat, dass MPCrypt.dll fur¨ das Ausfuhren¨ von Verschlusselungsoperationen¨ verantwortlich ist, wird in dieser Datei weiter nach den Chiasmus- Algorithmen gesucht. Mit 770 von IDA erkannten und davon rund 300 automatisch benannten Funktionen ist MP- Crypt.dll bedeutend ubersichtlicher¨ als GSTOOL.exe. Ein Blick in die Liste der erkannten Zeichenketten offenbart: Entwickelt wurde die Dll offenbar mit Microsoft Visual C++ 6.06. Auch tauchen mehrere Strings auf, die das Wort Chiasmus“ enthalten. ” Die in sub 7B3B51 (GSTOOL.exe) verwendete Tabelle funcTable enth¨alt Referenzen auf 14 Funktionen (siehe Tabelle 2.3f ur¨ eine genaue Auflistung). Ob und in welcher dieser Funktionen genau die Algorithmen des Chiasmus implementiert sind, soll erneut mit Hilfe von Differential ” Debugging“ herausgefunden werden. Die Mengen der w¨ahrend der Ver- und Entschlusselung¨ im 0 0 Callgraph von MPCrypt.dll besuchten Knoten seien Tenc und Tdec. 0 0 Nach dem Aufzeichnen der beiden Abl¨aufe, enth¨alt Tenc 119 und Tdec 107 Funktionen. Das Bil- 0 0 den der Differenzmenge Tenc\Tdec zeigt, dass die 15 in Tabelle 2.2 gegebenen Funktionen nur w¨ahrend der Verschlusselung¨ aktiv waren.
Die automatisch von IDA generierten und von BinNavi ubernommenen¨ Namen der Funktionen zeigen, dass nur eine der in der Schnittmenge enthaltenen 15 Funktionen nicht Teil des Stan- dardframeworks ist. Der Verdacht liegt nahe, dass die einzige fur¨ IDA unbekannte Funktion sub 10002904 Teile der gesuchten Verschlusselungsroutine¨ enth¨alt. Eine erste Analyse der Funktion verst¨arkt den Eindruck: sub 10002904 erh¨alt als Argumente zwei Arrays, auf die iterativ eine Vielzahl von Bit-Ebene Operationen angewandt werden. Zu-
6IDA erkennt zudem automatisch die statisch gelinkte Visual C++ Laufzeitumgebung. Daher ruhrt¨ auch der hohe Anteil an automatisch erkannten Funktionen.
19 2. Lokalisierung von Chiasmus im GSTOOL
Funktion Virtuelle Adresse Basic Blocks Kanten sub 10002904 0x10002904 3 3 ?seekp@ostream@@QAEAAV1@J@Z 0x10007337 7 9 ?seekoff@filebuf@@UAEJJW4seek dir@ios@@H@Z 0x10007860 10 14 ?seekpos@streambuf@@UAEJJH@Z 0x1000813E 1 0 sprintf 0x10008EFA 4 4 malloc 0x1000962D 1 0 lseek 0x1000A63B 4 4 lseek lk 0x1000A6A0 10 12 output 0x1000D4A6 176 272 write char 0x1000DBE7 6 6 write multi char 0x1000DC1C 5 7 write string 0x1000DC4D 5 7 get int arg 0x1000DC85 1 0 aulldiv 0x10011470 11 16 aullrem 0x100114E0 11 16 0 0 Tabelle 2.2.: Tenc\Tdec dem wird die Funktion statisch nur von sub 10002794 und sub 10003386 aufgerufen, welche zu den 14 in der Tabelle funcTable referenzierten Funktionen geh¨oren.
0 0 0 0 Abbildung 2.3.: Tenc ∩ Tdec blau, Tenc\Tdec grun¨
Dass es sich bei sub 10002904 tats¨achlich um den Kern der Verschlusselung¨ des Chiasmus- Verfahrens handelt, l¨asst sich endgultig¨ zur Laufzeit mit einem herk¨ommlichen Debugger veri- fizieren. So enthalten die beiden an sub 10002904 als Argumente ubergebenen¨ Arrays Teile des Inhalts der ausgew¨ahlten Schlusseldatei¨ und einen 64 Bits Block (acht Zeichen) der Klartext- datei. Die 64 Bits lange Ausgabe der Funktion l¨asst sich sp¨ater in selber Form wieder in der Chiffratdatei finden.
20 2. Lokalisierung von Chiasmus im GSTOOL sub 10002904 wird im Folgenden mit encCore bezeichnet.
0 0 Die passende Entschlusselungsfunktion¨ l¨asst sich analog uber¨ die Bildung von Tdec\Tenc fin- den. Man kann sich jedoch auch ein h¨aufiges Designmerkmal moderner Blockchiffren zunutze machen: encCore verwendet zwei Byte-Arrays, die an den virtuellen Adressen 0x1001422C und 0x1001432C liegen. Auf diese wird an insgesamt acht Stellen in encCore zugegriffen. Wie im n¨achsten Teil der Arbeit ausfuhrlicher¨ gezeigt wird, handelt es sich bei diesen Arrays um S-Boxen, wie sie h¨aufig in Blockchiffren vorkommen. Neben den jeweils vier Referenzen aus encCore verfugt¨ jede der beiden S-Boxen noch uber¨ vier weitere Referenzen aus der bis hierhin unbekannten Funktion sub 10002C4B. Diese ist encCore im Aufbau sehr ¨ahnlich. Wie oben beschrieben, l¨asst sich auch hier zur Laufzeit verifizieren, dass es sich bei sub 10002C4B um die zu encCore inverse Entschlusselungsfunktion¨ des Chiasmus handelt. Im Folgenden wird sub 10002C4B mit decCore bezeichnet. Zudem wird die S-Box an 0x1001422C mit sbox0 be- nannt, die an 0x1001432C mit sbox1 . encCore und decCore verfugen¨ jeweils uber¨ 12 Runden. Insgesamt werden in einem Ver- oder Entschlusselungsvorgang¨ 26 Teilschlussel¨ mit einer L¨ange von jeweils 32 Bits verwendet. Pas- send zu den bereits in der Einleitung zitierten Angaben in [7], arbeiten beide Funktionen auf einem Klartext- bzw. Chiffretextblock von 64 Bits. Eine genaue Analyse der beiden Funktionen und des zugeh¨origen, bis hierhin noch nicht loka- lisierten, Key-Schedules (keySchedCore) erfolgt im n¨achsten Kapitel.
Da bei Blockchiffren bei der Ver- und Entschlusselung¨ typischerweise derselbe Key-Schedule 0 0 verwendet wird, ist die entsprechende Funktion sowohl in Tenc als auch in Tdec enthalten. 0 0 Die Bildung der Schnittmenge Tdec ∩ Tenc w¨are also ein logischer Ansatz zur Lokalisierung des Key-Schedule-Algorithmus. Diese Schnittmenge ist hier jedoch sehr groß und enth¨alt eine Vielzahl von unbekannten Funktionen. So wird hier ein anderer Weg beschritten und stattdessen werden im folgenden Abschnitt die von MPCrypt.dll uber¨ funcTable bereitgestellten 14 Funktionen analysiert. Neben der Lokalisierung des Key-Schedule Algorithmus hat dies noch den nutzlichen¨ Nebeneffekt, dass N¨aheres uber¨ die konkrete Chiasmus-Implementierung im GSTOOL erfahren werden kann.
21 2. Lokalisierung von Chiasmus im GSTOOL
2.2.1 Analyse der bereitgestellten Funktionalit¨at
Wie bereits gezeigt, stellt MPCrypt.dll der GSTOOL.exe als In-Process Server Funktionalit¨at in Form von COM-Komponenten bereit. So ist es GSTOOL.exe als COM-Client unter anderem m¨oglich, uber¨ die Funktionstabelle funcTable verschiedene Funktionen rund um das Chiasmus- Verfahren zu nutzen. Welche Funktionalit¨at dabei genau bereitgestellt wird, soll in diesem Abschnitt gekl¨art werden. So soll vor allem der bisher noch nicht lokalisierte Key-Schedule Algorithmus des Chiasmus gefunden werden. Auf die genaue Vorgehensweise bei der Analyse wird im Einzelnen nicht weiter eingegangen. Die betreffenden Funktionen sind ubersichtlich¨ und mit Assemblerkenntnis leicht verst¨andlich. Tabelle 2.3 enth¨alt alle uber¨ funcTable angebotenen Funktionen.
Neuer Name Virtuelle Adresse IDA Name comFunc0 0x100069DC sub 100069DC comFunc1 0x100069E6 sub 100069E6 comFunc2 0x100069F0 sub 100069F0 comFunc3 0x1000647E sub 1000647E comFunc4 0x1000648D sub 1000648D comFunc5 0x100067EF sub 100067EF comFunc6 0x100068E6 sub 100068E6 encryptString 0x10002794 sub 10002794 decryptString 0x10002A8F sub 10002A8F intToHexString 0x10002E9A sub 10002E9A hexStringToInt 0x100030CB sub 100030CB calcKeySchedule 0x10002685 sub 10002685 generateKey 0x100011D9 sub 100011D9 encryptDecryptFile 0x10003386 sub 10003386 Tabelle 2.3.: Funktionstabelle funcTable an 0x10014788
Es ist zu beachten, dass der fiktive Datentyp ARRAY
2.2.1.1 calcKeySchedule
Signatur: int calcKeySchedule(ARRAY
22 2. Lokalisierung von Chiasmus im GSTOOL
Diese Funktion expandiert die ersten 160 Bits (funf¨ Dwords) der Eingabe key auf 832 Bits (26 Dwords), die in keySchedule zuruckgegeben¨ werden. Bei diesen 832 Bits handelt es sich um 26 vorberechnete Teilschlussel¨ zu jeweils 32 Bits die direkt von encCore und decCore zur Ver- bzw. Entschlusselung¨ verwendet werden k¨onnen. Hier wird also der Key-Schedule fur¨ eine Chiasmus Sitzung erstellt. Zur Berechnung dessen, verwendet calcKeySchedule die Funktion sub 1000119A, die im Folgenden keySchedCore ge- nannt wird.
Mit der Entdeckung dieser Funktion ist das Trio der gesuchten Algorithmen kom- plett. encCore , decCore und keySchedCore beschreiben zusammen das Chiasmus- Verfahren vollst¨andig.
2.2.1.2 generateKey
Signatur (vermutlich): int generateKey(void unused, ARRAY
Generiert wird ein insgesamt 832 Bits (26 Dwords) langer, noch nicht expandierter, Schlus-¨ sel, der uber¨ generatedKey zuruckgegeben¨ und anschließend von GSTOOL.exe unver¨andert in die betreffende Schlusseldatei¨ geschrieben wird. Soll der Schlussel¨ zum Ver- oder Entschlusseln¨ verwendet werden, so wird er zuvor mit der Funktion calcKeySchedule expandiert, wobei nur die ersten 160 Bits berucksichtigt¨ werden. Die restlichen 627 Bits haben also keine Funktion und sind nutzlos.
Mit generateKey erstellte Schlussel¨ sind hochgradig unsicher und lassen sich fast immer mit Hilfe eines einzigen Chiffrats rekonstruieren. Eine genaue Betrachtung der inneren der Funktionsweise und des Angriffs erfolgt in Kapitel funf¨ Angriff gegen Schlusselgenerierung¨ im GSTOOL“. ”
2.2.1.3 encryptDecryptFile
Signatur: int encryptDecryptFile(ARRAY
Diese Funktion wird direkt von GSTOOL.exe verwendet, wenn der Nutzer des Programmes die Ver- oder Entschlusselung¨ einer Datei anst¨oßt. Das Argument mode gibt dabei an, ob ver- oder entschlusselt¨ werden soll. pathInputFile und pathOutputFile enthalten die absoluten Pfade
23 2. Lokalisierung von Chiasmus im GSTOOL der beiden zu verwendenden Dateien. Es werden encCore oder decCore zusammen mit dem in keySchedule enthaltenen, bereits expandierten Schlussel¨ verwendet. Wird eine verschlusselte¨ Datei erstellt, so wird an ihren Anfang die Zeichenkette GSTOOL ” 3.0 - Chiasmus Encrypted File - OriginalFileSize:“ geschrieben. Diese wird gefolgt von einer 16-stelligen Zahl, die die Gr¨oße in Bytes der ursprunglichen¨ Datei angibt. Die Angabe wird ben¨otigt, da Chiasmus auf Bl¨ocken von acht Bytes (64 Bits) arbeitet. Ist die Gr¨oße einer Aus- gangsdatei kein Vielfaches von acht, so wird beim Verschlusselungsvorgang¨ der letzte Block mit Null-Bytes aufgefullt.¨ Diese mussen¨ beim Entschlusseln¨ wieder entfernt werden. Verwendet wird der Chiasmus im Electronic Code Book“ (ECB) Modus7. ”
2.2.1.4 encryptString
Signatur: int encryptString(ARRAY
Die Funktion dient dazu, eine einzelne Zeichenkette zu verschlusseln.¨ Dazu erwartet sie einen be- reits expandierten, 832 Bits langen Schlussel¨ im Argument keySchedule. Dieser wird verwendet, um mit Hilfe der Funktion encCore die in inputString ubergebene¨ Zeichenkette zu chiffrieren. Der Klartext wird dabei nicht mit dem Chiffrat uberschrieben,¨ sondern uber¨ das Argument outputData ausgegeben. Chiasmus wird hier ebenfalls im ECB Modus verwendet.
2.2.1.5 decryptString
Signatur: int decryptString(ARRAY
Die Funktion stellt das Gegenstuck¨ zu encryptString dar. In Abh¨angigkeit von dem Schlussel¨ in keySchedule das ubergebene¨ Chiffrat in inputDataEnc wieder zu einem String entschlusselt,¨ welcher in outputStringPlain zuruckgegeben¨ wird. Zur Entschlusselung¨ wird dabei decCore ver- wendet.
7Der ECB Modus ist der Einfachste unter den ublichen¨ Betriebsmodi fur¨ Blockchiffren. Klartextbl¨ocke werden dabei komplett unabh¨angig voneinander verschlusselt¨ und somit fur¨ einen bestimmten Schlussel¨ immer auf dieselben Chiffretextbl¨ocke abgebildet. Dieser Modus besitzt offensichtlich Schw¨achen. Beispielsweise k¨onnen wiederkehrende Nachrichtenteile einfach erkannt werden.
24 2. Lokalisierung von Chiasmus im GSTOOL
2.2.1.6 intToHexString
Signatur (vermutlich): int intToHexString(void unused, ARRAY
Eine einfache Funktion ohne direkten Bezug zum Chiasmus. Die uber¨ inputData eingegebene Byte-Kette wird hexadezimal interpretiert und als String uber¨ outputString wieder ausgegeben.
2.2.1.7 hexStringToInt
Signatur(vermutlich): int hexStringToInt(void unused, BSTR inputString, ARRAY
Fuhrt¨ dieselbe Operation wie intToHexString in umgekehrter Richtung aus.
2.2.1.8 comFunc0 - comFunc6
Die ersten sieben Funktionen in funcTable stellen ausschließlich COM bezogene Funktionalit¨at, wie zum Beispiel einen COM typischen Reference-Counter, bereit. Sie sind fur¨ die weitere Betrachtung uninteressant.
25 3. Extrahierung und Spezifikation von Chiasmus
3 Extrahierung und Spezifikation von Chiasmus
Die drei Funktionen encCore ,decCore und keySchedCore bilden zusammen das Chiasmus- Verfahren. Sie wurden im vorherigen Teil der Arbeit innerhalb des GSTOOLs lokalisiert und extrahiert. In diesem Teil soll nun, anhand des vorliegenden Assemblercodes der Funktionen, eine m¨oglichst genaue Spezifikation von Chiasmus erfolgen. Erkl¨artes Ziel dabei ist es, m¨oglichst nahe an die ursprungliche¨ Spezifikation des BSI heranzukommen. Dazu gilt es zwei Schichten der Programmoptierung ruckg¨ ¨angig zu machen: Zun¨achst durch den Compiler vorgenommene und anschließend durch die Entwickler der Software vorgenommene Optimierungen. Wer sich selbst schon einmal die Referenzspezifikation eines Kryptographiealgorithmus n¨aher angesehen und im Anschluss einen Blick auf eine tats¨achliche Softwareimplementierung gewor- fen hat, kennt das Problem. H¨aufig sind schon im Quellcode viele Aspekte der eigentlichen Spezifikation kaum oder gar nicht mehr zu erkennen. So werden beispielsweise zur Geschwin- digkeitsoptimierung Werte vorberechnet und zur Laufzeit nur noch in Tabellen nachgeschlagen oder eigentlich unterschiedliche Funktionen zu einer einzigen großen zusammengefasst.
3.1 Verschlusselung¨
Der Flowgraph der Funktion encCore ist auf Seite 72 dargestellt. Bei der Abbildung ist zu beachten, dass der grune¨ gestrichelte Pfeil nur allgemein die Iteration des mittleren Blockes an- zeigt, und nicht eine bestimmte Sprungstelle (tats¨achlich wird in der Schleife von 0x100029EE nach 0x10002904 gesprungen).
Wie man es von einer Funktion zum Verschlusseln¨ von Daten erwartet, erh¨alt encCore zwei Argumente - jeweils einen Zeiger auf den zu bearbeitenden Klartext und auf den dabei zu verwendenden Schlussel.¨ Im Flowgraph auf Seite 72 sind diese beiden Argumente als pData und pKey benannt. Zudem wurden die Namen der beiden lokalen Variablen von var 4 und var 8 auf x und y ge¨andert.
3.1.0.9 Einschub: Argumente und lokale Variablen im Stackframe
Ausdrucke¨ wie ss :[ebp + pData] sind in dem Flowgraph auf Seite 72 an mehreren Stellen zu finden. Dieser und andere Ausdrucke¨ bewirken nicht, dass etwa eine Addition von dem Argu-
26 3. Extrahierung und Spezifikation von Chiasmus ment pData und dem Register EBP stattfindet. Stattdessen wird ein einfacher Zugriff auf das Argument durchgefuhrt.¨ Dazu enth¨alt EBP hier, passend zu seinem Namen Extended Base ” Pointer“, einen Zeiger auf die Basisadresse des so genannten Stackframes der Funktion. Der Stackframe hat eine feste Gr¨oße und enth¨alt typischerweise alle Argumente, lokalen Variablen und die Rucksprungadresse¨ einer Funktion1. Auf lokale Variablen und Argumente l¨asst sich so einfach uber¨ ihre Position im Stackframe relativ zur Basisadresse in EBP zugreifen. Das erste Argument einer Funktion liegt bei einer solchen Konstruktion zum Beispiel 8 Bytes (2 Dwords) unter der Basisadresse2. Folglich kann innerhalb dieser Funktion uber¨ die relative Adressierung [ebp + 8] lesend und schreibend darauf zugegriffen werden. Um das Analysieren einer Funktion zu vereinfachen, ersetzt IDA die Indizes des Stackframes eigenst¨andig durch Namen. So wird aus [ebp + 8] der Ausdruck [ebp + arg 0] fur¨ das erste Ar- gument und aus [ebp − 4] der Ausdruck [ebp + var 4] fur¨ die erste lokale Variable. Diese automatisch vergebenen Namen lassen sich entsprechend der Erkenntnisse der weiterge- henden Analyse weiter anpassen.
Im ersten der drei Basic Blocks im Flowgraph wird das Argument pData in das Register EAX geschrieben, w¨ahrend EDI den Zeiger auf den Schlussel¨ aus pKey erh¨alt. Im weiteren Verlauf der Funktion werden beide Register nur noch fur¨ den Zugriff auf die zu verschlusselnden¨ Daten bzw. den Schlussel¨ verwendet. Ebenfalls im ersten Basic Block wird pData wiederverwendet und bekommt den Wert zw¨olf zugewiesen, um fortan als Z¨ahler fur¨ die Iteration des zweiten Blockes zu dienen. Dieser ruft sich so lange wieder selbst auf, bis pData den Wert Null enth¨alt. Dabei wird pData in jeder Iteration dekrementiert (siehe 0x100029EB). Dies liefert die erste konkrete Eigenschaft des Chiasmus-Verfahrens: Die Verschlusselung¨ besteht aus zw¨olf identischen Runden. Wie bereits bekannt, hat der zu verschlusselnde¨ Klartextblock eine L¨ange von 64 Bits. Dieser wird w¨ahrend der Verarbeitung in encCore in zwei Datenbl¨ocke zu jeweils 32 Bits aufgeteilt. In Anlehnung an die ubliche¨ Benennungen in anderen Blockchiffren, wird im Folgenden der erste Block an [eax] als der linke Block, der zweite Block an [eax+4] als der rechte Block bezeichnet.
Der linke Block und der rechte Block in der i-ten Runde werden zudem auch Li und Ri ge- nannt. Die erste Ver¨anderung an den Klartextdaten wird bereits im ersten Basic Block, vor dem Ein- tritt in die Schleife, vorgenommen: Der linke Klartexblock wird mit den ersten 32 Bits des Schlussels¨ XOR-verknupft.¨ Im weiteren Verlauf werden beide Bl¨ocke pro Runde jeweils mit den n¨achsten, noch nicht verwen-
1Die Korrektheit dieser Aussage ist abh¨angig von der verwendeten Calling-Convention und eventuellen Eigen- heiten des jeweiligen Compilers. Bei der Calling-Convention fastcall werden beispielsweise Argumente nicht uber¨ den Stack, sondern in Registern ubergeben.¨ 2Zwischen Basisadresse und erstem Argument liegen in diesem Fall noch die Rucksprungadresse¨ und die gesi- cherte Basisadresse des Stackframes der aufrufenden Funktion.
27 3. Extrahierung und Spezifikation von Chiasmus deten 32 Bits des Schlussel¨ XOR-verknupft¨ (siehe 0x10002920 bis 0x1002925 und 0x100029E4 bis 0x100029E6). Dazu wird der Zeiger auf den Schlussel¨ in Register EDI jede Runde um acht Bytes, also 64 Bits, weitergeschoben (siehe 0x100029E8). Die letzten 32 Bits des Schlussel¨ werden außerhalb der Schleife im dritten Basic Block mit dem rechten Klartexblock XOR- verknupft.¨ Die Verwendung des expandierten Schlussels¨ von insgesamt 832 Bits in encCore l¨asst sich also wie folgt beschreiben: In jeder der zw¨olf Runden der Chiasmus-Verschlusselung¨ werden zweimal 32 Bits des expan- dierten Schlussels¨ verwendet. Diese lassen sich als insgesamt 24 Teilschlussel¨ zu je 32 Bits interpretieren. Hinzu kommt noch die Verknupfung¨ des linken Klartextblocks mit dem ersten Teilschlussel¨ vor dem Eintritt in die Schleife und die abschließende Verknupfung¨ des rechten Blockes mit dem letzten Teilschlussel¨ nach dem Austritt aus der Schleife. Der 832 Bits lange expandierte Schlussel¨ entspricht also einem Array von 26 Teilschlusseln¨ zu je 32 Bits. Diese Teilschlussel¨ werden im weiteren Verlauf dieser Arbeit auch mit Ki bezeichnet, wobei i fur¨ den Index des Teilschlussels¨ im expandierten Schlussel¨ steht. Die Teilschlussel¨ wer- den ausschließlich zur XOR-Verknupfung¨ mit den zu verschlusselnden¨ Datenbl¨ocken verwendet. Teilschlussel¨ mit geradem Index werden mit dem linken Block, Teilschlussel¨ mit ungeradem In- dex mit dem rechten Block verknupft.¨
Innerhalb des zweiten Basic Blocks fallen typische Charakteristiken von symmetrischen Krypto- graphiealgorithmen auf. So wird eine Vielzahl von arithmetischen und Bit-Ebene Operationen direkt oder indirekt auf den linken und rechten Datenblock angewandt. Zudem verwendet die Funktion in ihren Berechnungen zum Teil auff¨allige, konstante Werte (siehe 0x100297B bis 0x10002990). Diese vier, 32 Bits langen, Werte werden im Weiteren wie folgt bezeichnet:
α = 4614965B16, β = 47B9346316, γ = F AD512B516, δ = 4F 9AAC5A16
Auf den linken und rechten Datenblock wird nicht nur als Einheit in Form eines 32 Bits langen Dwords zugegriffen. Stattdessen wird gleich zu Beginn des zweiten Basic Blocks, unmittelbar nach der XOR-Verknupfung¨ mit dem entsprechenden Teilschlussel,¨ der rechte Datenblock als ei- ne Reihung von vier Bytes interpretiert. Diese Bytes werden einzeln in die bereits oben erw¨ahnte S-Box sbox0 eingegeben (siehe 0x10002930 bis 0x10002960). Die Bilder der Bytes werden nicht
28 3. Extrahierung und Spezifikation von Chiasmus
direkt wieder zuruckgeschrieben,¨ sondern zusammen als Dword in der lokalen Variablen x zwi- schengespeichert. Dabei werden das erste und das letzte Byte vertauscht. Ahnlich¨ wird mit dem linken Datenblock am Ende des zweiten Basic Blocks verfahren (siehe 0x100029AF bis 0x100029E2). Vor der Verknupfung¨ mit dem entsprechenden Teilschlussel¨ wer- den die vier Bytes des linken Datenblocks aus der Zwischenspeicherung in der lokalen Variable y geladen und in die S-Box sbox1 eingegeben. Die Ergebnisse werden in den linken Datenblock zuruckgeschrieben,¨ wobei auch hier das erste und das letzte Byte vertauscht werden. Beide S-Boxen liegen vordefiniert als statische Arrays im Datensegment der MPCrypt.dll und verfugen¨ jeweils uber¨ 256 Elemente des Typs Byte. Sie decken somit den gesamten acht Bits langen Wertebereich dieses Datentyps ab und werden zum Abbilden von Bytes auf Bytes ver- wendet. Bei diesen beiden S-Boxen handelt es sich um die Einzigen im Chiasmus-Verfahren verwendeten.
Die restlichen Abl¨aufe sollen nicht weiter anhand der Assemblerform von encCore nachvoll- zogen werden. Stattdessen wird eine Ubersetzung¨ in die Hochsprache C++ angefertigt. Der Programmcode in Listing 3.1 entspricht der ersten lauff¨ahigen und korrekten Ubersetzung¨ die w¨ahrend der Erstellung dieser Arbeit entstand.
1 union block32 { 2 DWORD dword ; 3 struct {BYTE byte0; BYTE byte1; BYTE byte2; BYTE byte3; } ; 4 } ; 5 void chiasmusEncBlock(block32 * block , block32 * key ) 6 { 7 block[0].dword ˆ= key[0].dword; 8 for ( int round=12, indexKey=1; round >0; round−−, indexKey+=2) { 9 10 block[1].dwordˆ= key[indexKey].dword; 11 12 block32 x ; 13 x.byte3=sbox0[block[1].byte0]; 14 x.byte1=sbox0[block[1].byte1]; 15 x.byte2=sbox0[block[1].byte2]; 16 x.byte0=sbox0[block[1].byte3]; 17 18 DWORD b = x . dword ; 19 DWORDe=block[0].dword>>27; 20 21 DWORD c = 32 − e ; 22 DWORD d = b >> c ; 23 b = b << e ; 24 d |= b ; 25 26 DWORD h = d*0x4614965B ; 27 DWORDf=block[0].dword * 0x47B93463 ; 28 DWORDg=block[0].dword * 0x4F9AAC5A ; 29 d *= 0xFAD512B5 ; 30 h −= f ; 31 d −= g ;
29 3. Extrahierung und Spezifikation von Chiasmus
32 33 block [ 1 ] . dword = h ; 34 DWORD k = 32 − (h>>27); 35 block32 y ; 36 y . dword = d << k ; 37 38 block [ 0 ] . dword = d ; 39 DWORD m = d >> (h>>27); 40 y . dword |= m; 41 42 block[0].byte3=sbox1[y.byte0]; 43 block[0].byte1=sbox1[y.byte1]; 44 block[0].byte2=sbox1[y.byte2]; 45 block[0].byte0=sbox1[y.byte3]; 46 47 block[0].dword ˆ= key[keyIndex+1].dword; 48 } 49 block[1].dword ˆ= key[25].dword; 50 }
Listing 3.1: Erste Ubersetzung¨ von encCore
Fur¨ diese erste Version wurden die meisten Assemblerinstruktion direkt in ihre Gegenstucke¨ in der Programmiersprache C++ ubersetzt,¨ wobei an einigen Stellen bereits mehrere Operatio- nen zu einer Anweisung zusammengefasst sind. Die große Menge an lokalen Variablen ist der Mehrfachverwendung der Register in der Assemblerform von encCore geschuldet. Die beiden Argumente block und key entsprechen den Argumenten von encCore . Da in encCore auf die linke und rechte H¨alfte des Datenblocks sowohl als Einheit als Dword, als auch als Reihung von vier Bytes zugegriffen wird, wird in Listing 3.1 der neue Datentyp block32 eingefuhrt.¨ Dieser erlaubt beide ben¨otigten Zugriffsarten ohne umst¨andliche Typkonvertierun- gen. Obwohl eigentlich nur fur¨ das Argument block notwendig, ist der Ubersichtlichkeit¨ halber auch das zweite Argument key dieses Datentyps.
3.1.0.10 Einschub: Verifizierung der Korrektheit mit PyEmu
Ubersetzt¨ man einen kompilierten Algorithmus aus seiner Assemblerform zuruck¨ in eine Hoch- sprache, so werden dabei leicht Fehler gemacht. Daher ist es notwendig, die Aquivalenz¨ der ursprunglichen¨ und der ubersetzten¨ Form des Algorithmus zu zeigen. Liefern beide Versionen fur¨ dieselben Eingabevektoren dieselben Ausgabevektoren, so ist ab einer genugend¨ großen Zahl von uberpr¨ uften¨ Paaren von einer korrekt durchgefuhrten¨ Uberset-¨ zung auszugehen. Der naive Ansatz fur¨ eine solche Verifizierung w¨are im Fall von encCore das manuelle Ausfuhren¨ der Verschlusselungsfunktion¨ des GSTOOLs fur¨ unterschiedliche Schlussel-¨ und Klartextdatei- en. Um die Ergebnisse dieser Operation mit den Ausgaben der Ubersetzung¨ von encCore ver-
30 3. Extrahierung und Spezifikation von Chiasmus gleichen zu k¨onnen, mussten¨ aber zun¨achst die genauen Abl¨aufe beim Verschlusseln¨ einer Datei verstanden worden sein oder zu uberpr¨ ufende¨ Vektoren mussten¨ etwa umst¨andlich zur Laufzeit mit einem Debugger geschrieben und ausgelesen werden. Eine einfachere Methode stellt die Verwendung von PyEmu dar. Mit diesem Framework lassen sich beliebige Codeabschnitte innerhalb von IDA emulieren. Dafur¨ evaluiert PyEmu wie ein Prozessor nacheinander die Assemblerinstruktionen innerhalb des gewunschten¨ Abschnittes. Um Zugriffe auf den Arbeitsspeicher zu simulieren, stellt PyEmu einen kunstlichen¨ Adressraum zur Verfugung.¨ Greift ein Programmabschnitt auf eine Speicher- adresse zu, so uberpr¨ uft¨ PyEmu zun¨achst, ob diese in der aktuellen Sitzung bereits verwendet wurde. Ist dies nicht der Fall, so erstellt PyEmu einen kunstlichen¨ Repr¨asentanten fur¨ die- se Adresse und initialisiert diesen mit Null-Bytes. Speicherzugriffe innerhalb der Emulierung schlagen also niemals fehl. Schreibt ein Programm einen bestimmten Wert an eine Adresse, so wird dieser dauerhaft von PyEmu unter dieser Adresse vorgehalten. Die Werte von Speicheradressen lassen sich vor und w¨ahrend einer Emulierung beliebig setzen. Das Python-Skript in Listing A.2 auf Seite 69 definiert die Funktion emulateEncCore mit der sich die Implementierung der Chiasmus-Verschlusselung¨ fur¨ beliebige Eingaben testen l¨asst3. Im Falle von encCore muss die Funktion w¨ahrend ihres Durchlaufs auf die zu verschlusselnden¨ Daten, den expandierten Schlussel¨ und die beiden S-Boxen zugreifen k¨onnen. Diese Daten lassen sich vor dem Start der Emulierung im kunstlichen¨ Speicher von PyEmu unter den gewunschten¨ Adressen ablegen. W¨ahrend Schlussel¨ und Klartext in diesem Fall an die willkurlichen¨ Adressen 0x00100000 und 0x00200000 gelegt werden, mussen¨ die S-Boxen an ihren vorgegebenen Adressen zu finden sein. Dazu wird die gesamte .rdata“ Section der MPCrypt.dll an ihre naturliche¨ Adresse geladen. ” Analog wird mit der den Programmcode enthaltenen Section .text“ verfahren4. Damit enc- ” Core Schlussel¨ und Klartext auch im kunstlichen¨ Speicher findet, mussen¨ Zeiger auf diese als Argumente ubergeben¨ werden. Dazu bietet PyEmu die M¨oglichkeit die, von Null abweichenden, Initialisierungswerte der auf dem Stack liegenden Argumente und lokalen Variablen festzulegen. Im verwendeten Skript bewerkstelligt dies die Funktion createStack. Neben den Argumenten pData und pKey definiert diese noch explizit die beiden lokalen Variablen x und y. Gestartet wird die Emulierung mit dem Aufruf emu.execute(start = encStart, end = encEnd), wobei als Grenzen die Start- und Endadresse von encCore verwendet werden.
Obwohl die Version aus Listing 3.1 rein funktional mit der Implementierung in der MPCrypt.dll identisch ist, ist davon auszugehen, dass sie sich vom ursprunglichen¨ Quellcode der Chiasmus-
3Das Skript entstand mit Hilfe der Beispielskripte des PyEmu Projekts und enth¨alt teilweise Code aus diesen. 4Ausfuhrbare¨ Dateien unter Windows Systemen sind in eine oder mehrere Sections aufgeteilt. Typischerweise legt der Linker eines Programmes separate Sections fur¨ Programmcode, initialisierte Daten, uninitialisierte Daten und Resources“ an. ”
31 3. Extrahierung und Spezifikation von Chiasmus
Verschlusselung¨ noch in vielen Punkten stark unterscheidet. In dieser unubersichtlichen,¨ der Assemblerform immer noch sehr ¨ahnlichen Fassung ist es schwer, die Chiffre weiter zu charakterisieren. Um n¨aher an die vermutete Originalversion zu kommen, ist eine iterierte Analyse und Optimierung dieser ersten erarbeiteten Version notwendig. Dazu gilt es zun¨achst, m¨oglichst viele lokale Variablen durch das Bestimmen von Abh¨angig- keiten und Zusammenfassung zu eliminieren. So lassen sich zum Beispiel die Zeilen 21 bis 24 aus Listing 3.1 zu der Anweisung DWORD d = (b << e) | (b >> c); vereinfachen. Im n¨achsten Schritt werden die beiden Variablen b und c in der Gleichung ersetzt: DWORD d = (x.dword << e) | (x.dword >> 32 − e);. Betrachtet man diese Anweisung genauer, so f¨allt auf, dass trotz der Shift-Operationen keinerlei Informationen aus x verloren gehen. Stattdessen bewirkt die zweite Shift-Operation, dass s¨amtliche h¨oherwertigen Bits, die aus x hinausgescho- ben werden, wieder als niederwertige Bits im Ergebnis auftauchen. Die gesamte Anweisung dient also eigentlich dazu, die Bits in x um den Wert in e nach links zu rotieren (ROL)5. Mit DWORD e = block[0].dword>>27; enth¨alt e dabei die funf¨ h¨oherwertigen Bits des linken Datenblockes (L). In der betrachteten Anweisung wird also der rechte Datenblock (R) nach der Byte-weisen Eingabe in sbox0 um den Wert der funf¨ h¨oherwertigen Bits von L in linker Richtung rotiert und das Ergebnis in d gespeichert. Analog lassen sich die Zeilen 34 bis 40 zusammenfassen. Hier werden die Bits in L um den Wert der funf¨ h¨oherwertigen Bits von R in rechter Richtung rotiert. Das Ergebnis wird in y gespeichert, bevor es Byte-weise in sbox1 eingegeben wird. Ubrig¨ bleiben noch die arithmetischen Operationen mit den herausstechenden Konstanten α,β,γ und δ in den Zeilen 26 bis 31. Als einzige variable Parameter in den Berechnungen werden d und L hier jeweils zweimal verwendet. Die Resultate werden letztendlich uber¨ d und h in den Zeilen 33 und 38 wieder in die beiden Datenbl¨ocke L und R geschrieben. Dabei ist zu beachten, dass aufgrund der Registerbreite von 32 Bits s¨amtliche Berechnungen automatisch modulo 232 durchgefuhrt¨ werden. Die gesamte Konstruktion l¨asst sich als zwei unabh¨angige Funktionen interpretieren, die beide in Abh¨angigkeit von d und L neue Werte fur¨ L und R berechnen:
R = f0(d, L),L = g0(L, d)
32 f0(x1, x2) = αx1 − βx2 mod 2 32 g0(x1, x2) = γx2 − δx1 mod 2
5Eine direkte Vereinfachung ist jetzt nicht mehr m¨oglich, weil C++ uber¨ keinen Operator fur¨ das Rotieren von Bits verfugt.¨
32 3. Extrahierung und Spezifikation von Chiasmus
Bis auf x und y lassen sich jetzt alle verbliebenen lokalen Variablen nach und nach entfernen. Der abschließend resultierende C++ Code der Funktion chiasmusEncBlock ist in Listing A.1 ab Seite 64 zu finden. Die dort angegebenen Konstanten unterscheiden sich teilweise von den hier verwendeten. Im Abschnitt Abh¨angigkeiten der Konstanten “ auf Seite 45 wird gezeigt, dass bestimmte Ab- ” h¨angigkeiten zwischen den hier zun¨achst verwendeten Konstanten bestehen, denen auch in der abschließende Implementierung Rechnung getragen wird.
Anhand der in diesem Abschnitt gewonnenen Erkenntnisse l¨asst sich jetzt ein Blockschaltbild erstellen, dass die Abl¨aufe innerhalb der Verschlusselungsfunktion¨ verdeutlicht.
3.1.1 Grafische Beschreibung
Siehe n¨achste Seite.
33 L0 R0
K0
L1 R1
K1
S0 S0 S0 S0
>> 27 r <<< r
32 f 0 x1 , x 2 x1 x 2 mod 2
x1 1 32 f 1 x1 , x 2 x1 x 2 mod 2 f 0 g x , x 2 1 x 1 x mod 2 32 x 2 0 1 2 1 2 x 1 32 1 g 1 x1 , x 2 2 x1 x 2 mod 2
g0 4614965B 16 x 2 47B93463 16 1 FAD512B5 >>> r >> 27 16 r 1 2 4F9AAC5A 16 1 52AED4B 16
S1 S1 S1 S1 32 Bits Dword Rotate Left <<< Rotate Right >>> 8 Bits Byte Shift Right >> XOR 5 Bits
K2
L2 R2 ... L12 R12
K25
L13 R13 Chiasmus Encryption 3. Extrahierung und Spezifikation von Chiasmus
3.2 Entschlusselung¨
Nachdem encCore bereits eingehend betrachtet wurde, gestaltet sich die Analyse von decCo- re bedeutend einfacher. Der Flowgraph der Funktion ist auf Seite 73 zu finden. Wie anzunehmen war, sind encCore und decCore sich in Aufbau und den verwendeten Opera- tionen sehr ¨ahnlich. So lassen sich schnell die bereits bekannten Konstrukte zum Rotieren der Bits der beiden Datenbl¨ocke erkennen. Anders als in encCore beginnt die Verarbeitung jedoch mit dem linken Datenblock und endet mit der des rechten. Wie fur¨ eine Blockchiffre ublich,¨ werden die einzelnen Teilschlussel¨ in umgekehrter Reihenfolge im Vergleich zur Verschlusselung¨ verwendet. So beginnt die Entschlusselung¨ im ersten Basic
Block mit der XOR-Verknupfung¨ von R13 und K25 und endet mit der XOR-Verknupfung¨ von
L1 und K0 im dritten Basic Block. Zwischen den beiden Rotationsoperationen fallen erneut vier Konstanten auf. Neben den bereits bekannten α, β und δ wird an Adresse 0x10002CC4 eine neue, funfte¨ Konstante eingefuhrt:¨ = 52AED4B16.
Betrachtet man die arithmetischen Operationen genauer, so zeigt sich, dass hier zwei zu f0 und g0 unterschiedliche Funktionen verwendet werden:
L = f1(d, R),R = g1(R, d)
32 f1(x1, x2) = αx1 + x2 mod 2 32 g1(x1, x2) = βx2 − δx1 − mod 2
Analog zu der Beschreibung von encCore stellt d hier das Ergebnis der ersten Rotation dar. Eine erste Ubersetzung¨ von decCore nach C++ l¨asst sich nun anfertigen. Von der Korrektheit dieser Ubersetzung¨ kann man sich hier einfacher als noch bei encCore uber-¨ zeugen. So l¨asst sich mit der bereits verifizierten Ubersetzung¨ von encCore eine beliebig große Anzahl von Testvektoren fur¨ die Entschlusselung¨ erstellen. Die abschließende, dem Original vermutlich sehr ¨ahnliche, Implementierung chiasmusDecBlock ist ebenfalls in Listing A.1 ab Seite 64 zu finden.
Auch im Falle der Entschlusselungsfunktion¨ des Chiasmus-Verfahrens zeigt sich dessen Funkti- onsweise am besten an dem folgendem Blockschaltbild.
35 3. Extrahierung und Spezifikation von Chiasmus
3.2.1 Grafische Beschreibung
Siehe n¨achste Seite.
36 L13 R13
K25
L12 R12
K24
32 f 0 x1 , x 2 x1 x 2 mod 2 S0 S0 S0 S0 1 32 f 1 x1 , x 2 x1 x 2 mod 2 1 1 32 g 0 x1 , x2 2 x1 x2 mod 2 1 32 g 1 x1 , x 2 2 x1 x 2 mod 2 <<< r r >> 27
4614965B 16
47B93463 16 1 FAD512B5 16 x1 1 2 4F9AAC5A 16 f1 1 52AED4B x 2 16
x1 32 Bits Dword Rotate Left <<< Rotate Right >>> 8 Bits Byte Shift Right >> x g1 XOR 2 5 Bits
>> 27 r >>> r
S1 S1 S1 S1
K23
L11 R11 ... L1 R1
K0
L0 R0 Chiasmus Decryption 3. Extrahierung und Spezifikation von Chiasmus
3.3 Key-Schedule
Typischerweise besteht eine Blockchiffre nicht nur aus einer Ver- und einer Entschlusselung,¨ sondern auch aus einer Funktion zur Berechnung der einzelnen Teilschlussel,¨ dem so genannten Key-Schedule“. Die entsprechende Funktion im Falle von Chiasmus ist keySchedCore, deren ” Flowgraph auf Seite 74 abgebildet ist. Wie bereits weiter oben dargelegt, besteht der Ausgangsschlussel¨ beim Chiasmus-Verfahren aus
160 Bits, aus denen die 26 Teilschlussel¨ Ki zu jeweils 32 Bits gewonnen werden. Die Funktion keySchedCore ist weit weniger komplex als die beiden vorangegangenen und er- wartet als einziges Argument einen Zeiger auf den zu expandierenden Ausgangsschlussel¨ (pBa- seKey). Uber¨ lokale Variablen auf dem Stack verfugt¨ sie nicht. Im ersten der insgesamt funf¨ Basic Blocks wird der Zeiger auf den Ausgangschlussel¨ aus pBa- seKey in die Register ESI und ECX geschrieben (siehe 0x1000119B und 0x100011A2). Fortan wird pBaseKey selbst nicht mehr verwendet. Als letztes erh¨alt EDX den Wert 1516 = 2110, um anschließend als Z¨ahler fur¨ die Iteration des zweiten Basic Blocks zu dienen (siehe 0x100011BF). Dieser zweite Basic Block bildet den Kern des Key-Schedules des Chiasmus-Verfahrens. In jeder seiner insgesamt 21 Iterationen wird uber¨ das Register ECX zweimal lesend und einmal schrei- bend auf den Schlussel¨ zugegriffen. Der Zeiger in ECX wird dabei pro Runde um vier Bytes weiter geschoben (siehe 0x100011A7) und wandert somit jeweils einen Teilschlussel¨ weiter. 0 0 Ein Blick auf Offsets der Zugriffe auf die Teilschlussel¨ zeigt, dass Ki und Ki+2 jeweils ver- 0 6 wendet werden um Ki+5 zu berechnen . Dabei fallen die bekannte Konstruktion zum Rotieren von Werten und die Multiplikation mit einer neuen Konstante auf. Zus¨atzlich dazu wird die XOR-Verknupfung¨ angewandt.
Mit φ = 3333333316, >>> der Bit-Rotation nach rechts und ⊕ der XOR-Verknupfung¨ l¨asst sich die Berechnugsweise wie folgt angeben:
0 0 0 32 Ki+5 ≡ (Ki >>> 7) ⊕ (φ ∗ Ki+2) mod 2 mit 0 ≤ i ≤ 21
0 Offenbar werden nur die Teilschlussel¨ ab K5 aufw¨arts berechnet. Die funf¨ ersten Teilschlussel¨
K0 bis K4, die zusammen auf genau eine L¨ange von 160 Bits kommen, werden direkt aus dem Ausgangsschlussel¨ ubernommen.¨ 0 Im folgenden, dritten Basic Block erh¨alt EAX uber¨ ESI einen Zeiger auf K5 (siehe 0x100011C7) 6Man beachte, dass ECX zwischen dem ersten und zweiten Lese-Zugriff bereits um vier erh¨oht wird.
38 3. Extrahierung und Spezifikation von Chiasmus und ECX mit dem Wert funf¨ den entsprechenden Index. W¨ahrend der anschließenden Iteration des vierten Basic Blocks fungiert ECX als inkrementeller Z¨ahler (siehe 0x100011D3). Dieser Z¨ahler wird in jeder Runde auf den von EAX angezeigten Teilschlussel¨ addiert (siehe 0x100011CD). Dabei wird der Zeiger in EAX in jeder Runde um einen Teilschlussel¨ weiter geschoben (siehe 0x100011D0). Es gilt also:
0 32 Ki = Ki + i mod 2 mit 5 ≤ i ≤ 25
Zuruckgegeben¨ wird der expandierte Schlussel¨ uber¨ den Datenpuffer des Ausgangsschlussels.¨ Die C++ Ubersetzung¨ chiasmusKeySchedule der Funktion keySchedCore ist in Listing A.1 ab Seite 64 zu finden. Auch hier wurde w¨ahrend der Entwicklung die Korrektheit mit Hilfe der Emulierung durch PyEmu uberpr¨ uft.¨ Das entsprechende Skript dazu steht in Listing A.3 auf Seite 70 und ist analog zum Skript zur Emulierung von encCore aufgebaut. Die anschaulichere, grafische Darstellung des Key-Schedules folgt im Anschluss an diesen Ab- schnitt. Dort werden zwecks einer gr¨oßeren Ubersichtlichkeit¨ die Operationen des zweiten Basic
Blocks zu einem Schaltzeichen mit der Beschriftung k(x1, x2) zusammengefasst.
3.3.1 Grafische Beschreibung
Siehe n¨achste Seite.
39 Key
K5 K6 K7 K8 ... K25 160 Bits Input
5 6 7 8 i 25
K0 K1 K2 K3 K4 K5' K6' K7' K8' ... K25'
kx1, x2
kx1,x2
33333333 16
kx1,x2 32 Bits Dword
Rotate Right >>> XOR Multiplication mod 2³² kx1,x2 Addition mod 2³²
>>> 7
Chiasmus Key-Schedule 4. Analyse von Chiasmus
4 Analyse von Chiasmus
W¨ahrend im bisherigen Verlauf dieser Arbeit haupts¨achlich grundlegende Eigenschaften des Chiasmus bestimmt wurden, sollen in diesem Abschnitt die gewonnenen Ergebnisse genauer betrachtet und eingeordnet werden. Dabei ist es das Ziel, den Fokus von einer bisher program- miersprachlichen hin zu einer mathematischeren Sichtweise zu ¨andern.
4.1 Korrektheit des Verfahrens
Es wird uberpr¨ uft,¨ unter welchen Bedingungen sich bei bekanntem Schlussel¨ der Verschlusse-¨ lungsvorgang des Chiasmus-Verfahrens durch den Entschlusselungsvorgang¨ umkehren l¨asst. So sollen bisher unbekannte Eigenschaften der Funktionen f0, g0, f1 und g1 (siehe Seiten 32 und 35) und ihrer Konstanten aufgedeckt und die Korrektheit des Verfahrens gezeigt werden.
32 32 32 32 s0 : GF (2) → GF (2) , s1 : GF (2) → GF (2)
−1 s1 = s0 stellen die beiden S-Box Transformationsschichten des Chiasmus-Verfahrens inklusive der ab- schließenden Byte-Vertauschung dar. Dass die Abbildungen invers zueinander sind, l¨asst sich leicht uberpr¨ ufen.¨ Die Rotationsoperationen in linker (ROL) und rechter Richtung (ROR), sowie die Operation des Schiebens von 27 Bits nach rechts (SHR27) seien wie folgt definiert:
ROL : GF (2)32 × GF (2)5 → GF (2)32,ROR : GF (2)32 × GF (2)5 → GF (2)32
32 5 SHR27 : GF (2) → GF (2)
f0, g0, f1 und g1 werden als Abbildungen
GF (2)32 × GF (2)32 → GF (2)32
41 4. Analyse von Chiasmus angesehen. Um mit den hinter diesen Abbildungen stehenden Funktionen arbeiten zu k¨onnen, sei zudem der Isomorphismus p gegeben: 32 p : GF (2) → Z232
Bei s¨amtlichen Betrachtungen im Folgenden gilt: 1 ≤ i ≤ 11. Fur¨ die beiden ubrigen¨ F¨alle i = 0 und i = 12 l¨asst sich leicht sehen, dass die Entschlusselung¨ bei gleichem Schlussel¨ fur¨ alle Eingaben ∈ GF (2)64 invers zur Verschlusselung¨ ist.
Die Verschlusselung¨ des Chiasmus-Verfahrens l¨asst sich beschreiben als:
0 Li+1 = s1(ROR(g0(Li,Ri),SHR27(Ri+1))) ⊕ K2i (4.1)
0 Ri+1 = f0(Ri,Li) (4.2)
= f0(ROL(s0(Ri ⊕ K2i−1),SHR27(Li)),Li)
0 Ri = ROL(s0(Ri ⊕ K2i−1),SHR27(Li)),Li)
Von der Korrektheit der Gleichungen uberzeugt¨ man sich leicht anhand des Blockschaltbildes auf Seite 34. Genauso lassen sich die entsprechenden Gleichungen fur¨ die Entschlusselung¨ aufstellen.
Li = f1(ROL(s0(Li+1 ⊕ K2i),SHR27(Ri+1)),Ri+1) (4.3)
| {z0 } =Li+1 0 Ri = s1(ROR(g1(Ri+1,Li+1),SHR27(Li))) ⊕ K2i−1 (4.4) 0 Li+1 = ROL(s0(Li+1 ⊕ K2i),SHR27(Ri+1)) (4.5)
Um zu uberpr¨ ufen¨ unter welchen Bedingungen eine Entschlusselung¨ der linken Seite m¨oglich ist, wird (4.1) in (4.3) eingesetzt:
! 0 Li = f1(ROL(s0(s1(ROR(g0(Li,Ri),SHR27(Ri+1))) ⊕ K2i ⊕K2i),SHR27(Ri+1)),Ri+1) | {z } =Li+1
42 4. Analyse von Chiasmus
0 = f1(ROL(ROR(g0(Li,Ri),SHR27(Ri+1)),SHR27(Ri+1)),Ri+1) 0 = f1(g0(Li,Ri),Ri+1) (4.6)
mit (2)
! 0 0 Li = f1(g0(Li,Ri), f0(Ri,Li)) (4.7)
Mit Gleichung (4.7) steht die entscheidende Eigenschaft von f1 fest. Damit eine Entschlusselung¨ m¨oglich ist, muss gelten:
∀A, B ∈ GF (2)32
f1(g0(A, B), f0(B,A)) = A (4.8)
Unter welchen Voraussetzungen dies der Fall ist, wird nun innerhalb der Funktion f1 in Z232 uberpr¨ uft:¨
a = p(A), b = p(B)
! 32 a ≡ αg0(a, b) + f0(b, a) mod 2 ≡ α(γb − δa) + (αb − βa) mod 232 ≡ a(−αδ − β) + b(αγ + α) mod 232 | {z } | {z } ! ! =1 =0 ≡ a(−αδ − β) + b(α(γ + )) mod 232 (4.9) | {z } | {z } ! ! =1 =0 ≡ a
Setzt man die bekannten Werte der Konstanten ein, so zeigt sich, dass tats¨achlich sowohl −αδ − β = 1 als auch γ + = 0 gilt. Somit ist Gleichung (4.8) uneingeschr¨ankt korrekt und somit stellt die Entschlusselung¨ des Chiasmus-Verfahrens, zumindest fur¨ die linke Seite, bei gleichem Schlussel¨ immer die Umkehrfunktion der Verschlusselung¨ dar.
43 4. Analyse von Chiasmus
Analog wird jetzt uberpr¨ uft,¨ welche Bedingungen fur¨ die Entschlusselung¨ der rechten Seite gelten. Mit (4.2) in (4.4) ergibt sich so:
! 0 0 Ri = s1(ROR(g1(f0(Ri,Li),Li+1) ,SHR27(Li))) ⊕ K2i−1 (4.10) | {z } =Xi
Damit Gleichung (4.10) gilt, muss gelten:
! 0 Xi = ROL(s1(Ri ⊕ K2i−1),SHR27(Li)) = Ri
Also muss folgende Gleichung erfullt¨ sein, damit eine Entschlusselung¨ der rechten Seite gelingt:
0 ! 0 0 Ri = g1(f0(Ri,Li),Li+1)
mit (4.5)
0 ! 0 Ri = g1(f0(Ri,Li),ROL(s0(Li+1 ⊕ K2i),SHR27(Ri+1)))
mit (4.1)
0 ! 0 0 Ri = g1(f0(Ri,Li),ROL(s0(s1(ROR(g0(Li,Ri),SHR27(Ri+1))) ⊕ K2i ⊕ K2i),SHR27(Ri+1))) 0 0 = g1(f0(Ri,Li),ROL(ROR(g0(Li,Ri),SHR27(Ri+1)),SHR27(Ri+1))) 0 0 = g1(f0(Ri,Li), g0(Li,Ri)) (4.11)
Aus Gleichung (4.11) ergibt sich die entscheidende Eigenschaft von g1. Damit eine Entschlus-¨ selung m¨oglich ist, muss gelten::
∀A, B ∈ GF (2)32
g1(f0(A, B), g0(B,A)) = A (4.12)
Unter welchen Umst¨anden (4.12) gilt, wird innerhalb von g1 in Z232 uberpr¨ uft:¨
a = p(A), b = p(B)
44 4. Analyse von Chiasmus
! 32 a ≡ −δf0(a, b) + βg0(b, a) mod 2 ≡ −δ(αa − βb) + β(γa − δb) mod 232 ≡ a(βγ − αδ) + b(α(βδ − βδ)) mod 232 | {z } | {z } ! =0 =1 ≡ a(βγ − αδ) mod 232 (4.13) | {z } ! =1 ≡ a
Es zeigt sich, dass fur¨ die konkreten Konstanten tats¨achlich βγ − αδ = 1 gilt. Somit ist (4.12) uneingeschr¨ankt korrekt und somit stellt die Entschlusselung¨ des Chiasmus-Verfahrens bei glei- chem Schlussel¨ immer die Umkehrfunktion der Verschlusselung¨ dar.
4.2 Abh¨angigkeiten der Konstanten
Im vorherigen Abschnitt wurde gezeigt, dass die Konstanten des Chiasmus-Verfahrens keine Zufallswerte sind, sondern ganz bestimmte Abh¨angigkeiten unter ihnen bestehen. Aus den Gleichungen (4.9) und (4.13) ergibt sich folgendes unterdeterminiertes Gleichungssys- tem, dass diese notwendigen Abh¨angigkeiten in Z232 beschreibt:
γ + = 0 ⇔ γ = − −αδ − β = 1 (4.14) −αδ + βγ = 1
Durch einfaches Multiplizieren der bekannten Werte l¨asst sich zeigen:
β = 1 ⇔ = β−1
Womit sich eingesetzt in (4.14) ergibt:
− αδ − 1 = 1 ⇔ αδ = −2 ⇔ δ = −2α−1
Eine rechnerische Uberpr¨ ufung¨ best¨atigt diese Abh¨angigkeiten. Die Bedingung, dass eine Zahl x uber¨ ein multiplikatives Inverses bezuglich¨ eines Modulos m
45 4. Analyse von Chiasmus besitzt ist: ggT (x, m) = 1. Also x und m relativ prim sind. Bei α und β handelt es sich um Primzahlen. Sie verfugen¨ somit bezuglich¨ jedes Modulos m von dem sie selbst kein Teiler sind uber¨ ein multiplikatives Inverses. Im vorliegenden Fall gilt:
ggT (α, 232) = ggT (β, 232) = ggT (γ, 232) = ggT (, 232) = 1 ggT (δ, 232) = 2
4.3 S-Boxen
Die Qualit¨at der S-Boxen einer Blockchiffre entscheidet h¨aufig daruber,¨ wie anf¨allig diese gegen- uber¨ linearer und differenzieller Kryptanalyse ist. In diesem Abschnitt werden die Eigenschaften der Chiasmus-S-Box S0 (sbox0 ) in Bezug auf diese beiden Angriffstechniken uberpr¨ uft.¨ Obwohl hier nicht direkt behandelt, ergeben sich fur¨ S1 (sbox1 ) die gleichen Eigenschaften. Dabei wird sich an A Tutorial on Linear and Differential Cryptanalysis“ [10] und [5] orien- ” tiert. Auf die Beschreibung der genauen Vorgehensweisen wird bei beiden Attacken verzichtet. Stattdessen werden sie kurz umrissen. Zur Durchfuhrung¨ der notwendigen Berechnungen wurde im Rahmen dieser Arbeit die C++ Klasse SBox (CSbox.h) entwickelt. Diese kann flexibel auf S-Boxen mit einer beliebigen Anzahl von Ein- und Ausgabebits arbeiten (beispielsweise auch mit den S-Boxen des DES die eine Abbildung GF (2)6 → GF (2)4 darstellen).
4.3.1 Erste Orientierung
Die beiden S-Boxen stellen bijektive Abbildungen in GF (2)8 dar und sind invers zueinander. Eine Online-Recherche zeigt, dass beide mit großer Wahrscheinlichkeit in keiner ¨offentlich ein- sehbaren Chiffre Verwendung finden.
4.3.2 Lineare Attacke
Der Ansatz der linearen Kryptanalyse ist, die nicht linearen Teile einer Blockchiffre durch li- neare Funktionen zu approximieren. Dadurch soll es erm¨oglicht werden, uber¨ Beziehungen von Ein- und Ausgabebits Gleichungen aufzustellen, die mit einer m¨oglichst guten Wahrscheinlichkeit korrekt sind. Sind genugend¨ Ein- und Ausgabebits bekannt, lassen sich dann mit diesen Gleichungen Aussa- gen zu Schlusselbits¨ treffen.
46 4. Analyse von Chiasmus
Um eine S-Box im Speziellen zu approximieren, wird untersucht, mit welcher Wahrscheinlich- keit die Summe von bestimmten Eingabebits der S-Box gleich der Summe von bestimmten Ausgabebits der S-Box ist. Dabei wird jede m¨ogliche Kombination von Bits betrachtet. 8 Im vorliegenden Fall wird fur¨ alle a, b ∈ GF (2) die Wahrscheinlichkeit Papprox,a,b bestimmt, mit der die folgende Gleichung gultig¨ ist.
a1X1 ⊕ a2X2 ⊕ a3X3 ⊕ a4X4 ⊕ a5X5 ⊕ a6X6 ⊕ a7X7 ⊕ a8X8
= b1Y1 ⊕ b2Y2 ⊕ b3Y3 ⊕ b4Y4 ⊕ b5Y5 ⊕ b6Y6 ⊕ b7Y7 ⊕ b8Y8 ⊕ b8Y8 ⇔ < a, X >=< b, Y > ⇔ < a, X >=< b, S(X) > (4.15)
Also
8 Papprox,a,b = X ∈ GF (2) | < a, X >=< b, S(X) >
X ist dabei die Eingabe in die S-Box, Y die entsprechende Ausgabe. Die Koeffizienten ai und bi sind die einzelnen Bits von a und b. Sie geben an, welche Kombinationen von Bits aus X und Y genau betrachtet werden. 1 Leicht l¨asst sich nachvollziehen: Gilt Papprox,a,b = 2 so ist fur¨ den Angreifer fur¨ diese Werte a 1 und b nichts gewonnen, denn mit Wahrscheinlichkeit 2 l¨asst sich das Ergebnis jeder Addition in GF (2) auch erraten.
Je weiter ein Papprox,a,b jedoch von diesem Wert abweicht, desto erfolgsversprechender wird die lineare Attacke. Nach [5] l¨asst sich diese Wahrscheinlichkeit fur¨ ein Paar a, b fur¨ eine S-Box S : GF (2)8 → GF (2)8 wie folgt berechnen:
1 SW (a) P = + b approx,a,b 2 29
W Sb (a) ist der so genannte Walsh-Koeffizient an der Stelle a, b. Offensichtlich bewirken Walsh-
Koeffizienten mit einem geringeren Betrag auch eine geringere Abweichung von Papprox,a,b 1 von 2 . W Es gilt: Je kleiner der maximale Betrag der Sb (a) einer S-Box, desto schwieriger l¨asst diese sich linearisieren.
47 4. Analyse von Chiasmus
Mit Hilfe dieses Kriteriums soll die Qualit¨at der S-Box S0 des Chiasmus-Verfahrens in Bezug auf ihre Resistenz gegenuber¨ der linearen Attacke bestimmt werden. Mit a, b ∈ GF (2)8 gibt es dabei 256 ∗ 256 = 65536 Walsh-Koeffizienten, die es zu berechnen gilt. Um das Ergebnis einordnen zu k¨onnen, werden die gleichen Berechnungen auch fur¨ eine pseudo- 8 8 zuf¨allige bijektive S-Box SRAND : GF (2) → GF (2) und die Verschlusselungs-S-Box¨ des AES- 8 8 Verfahrens SAES : GF (2) → GF (2) , die nach [5] hier die sicherste bekannte S-Box darstellt ( Weltrekord“), angestellt. ” Das Programm sbox analysis.exe verwendet die C++ Klasse SBox um Tabellen der Walsh- Koeffizienten der Chiasmus-S-Box und der beiden Vergleichs-S-Boxen zu erstellen. Intern berechnet werden die Walsh-Koeffizienten dabei mit Hilfe der Fast Fourier Transforma- ” tion“ (FFT) wie in [5] beschrieben. Wird sbox analysis.exe gestartet, so werden im selben Ordner insgesamt sechs Dateien erstellt. Darunter chiasmus lin.txt, aes lin.txt und rand lin.txt, welche die Tabellen der Walsh-Koeffi- zienten enthalten. Der Zeilen- und Spaltenindex eines Koeffizienten entspricht dabei den Werten W W b und a. In der linken oberen Ecke findet sich somit S0 (0), in der unteren rechten S255(255). Die erste Zeile (b = 0) und die erste Spalte (a = 0) sind fur¨ alle S-Boxen gleich und uninteressant.
Es zeigt sich, dass fur¨ a, b 6= 0 der gr¨oßte Betrag eines Walsh-Koeffizienten sowohl fur¨ S0 als auch fur¨ SAES 32 ist. Damit bietet die S-Box des Chiasmus-Verfahrens die gleiche, sehr gute Sicherheit gegen die lineare Attacke, wie die des AES-Verfahrens.
Zum Vergleich: Die mit der C-Funktion rand() generierte S-Box SRAND kommt auf einen ma- ximalen Betrag von 72. Auf der n¨achsten Seite ist eine grafische Darstellung der drei Walsh-Spektren zu finden. Die
Unterschiede zwischen S0 und SRAND sind dort klar erkennbar.
48 W Abbildung 4.1.: S0,b(a), Chiasmus
W Abbildung 4.2.: SAES,b(a), AES
W Abbildung 4.3.: SRAND,b(a), pseudo-zuf¨allige bijektive S-Box 4. Analyse von Chiasmus
4.3.3 Differenzielle Attacke
Bei der differenziellen Attacke werden Zusammenh¨ange zwischen Ein- und Ausgabedifferenzen von Abschnitten einer Chiffre untersucht. Tritt fur¨ eine bestimmte (XOR) Differenz von zwei Eingaben mit einer uberdurchschnittlich¨ großen Wahrscheinlichkeit eine bestimmte Ausgabedifferenz auf, so lassen sich m¨oglicherweise mit genugend¨ Klartext/Chiffretext Paaren Teile des Schlussels¨ bestimmen. Wie bei der linearen Attacke stellen die S-Boxen einer Chiffre einen integralen Teil des Schutzes gegen diese Attacke dar. Eine gute S-Box zeichnet sich hier dadurch aus, dass die maximale Wahrscheinlichkeit, dass eine bestimmte Eingabedifferenz ∆X = X 0 ⊕ X 00 zu einer bestimmten Ausgabedifferenz ∆Y = Y 0 ⊕ Y 00 fuhrt,¨ m¨oglichst gering ist. Mit anderen Worten: Fur¨ jedes ∆X sollte ∆Y m¨oglichst gleichverteilt sein. Mit der Klasse Sbox kann fur¨ beliebige S-Boxen die Difference Distribution Table“ nach [10] erstellt werden. ” Diese wird fur¨ die S-Box S0 des Chiasmus-Verfahrens und zum Vergleich auch wieder fur¨ SAES und SRAND berechnet. Ein Aufruf von sbox analysis.exe erzeugt die entsprechenden Dateien chiasmus dd.txt, aes dd.txt und rand dd.txt. Da es sich bei allen drei S-Boxen um Abbildungen GF (2)8 → GF (2)8 (Byte nach Byte) handelt, gilt auch fur¨ die Differenzen: ∆X, ∆Y ∈ GF (2)8. Die Werte in den generierten Tabellen geben an, wie oft sich ein bestimmtes ∆Y fur¨ ein be- stimmtes ∆X ergibt. Der Zeilenindex steht dabei fur¨ den Byte-Repr¨asentanten des jeweiligen ∆Y , der Spaltenindex fur¨ den Byte-Repr¨asentanten des jeweiligen ∆X. Der Wert 256, der in allen drei Tabellen in der oberen linken Ecke zu finden ist, gibt also an, dass fur¨ alle 256 m¨oglichen Kombinationen von X 0 und X 00 fur¨ ∆X = 0 (keine Differenz, also X 0 = X 00 ) die jeweilige S-Box eine Ausgabedifferenz von ∆Y = 0 liefert. Dies ist naturlich¨ fur¨ jede S-Box der Fall und so werden die erste Zeile (∆Y = 0) und die erste Spalte (∆X = 0) bei der Bewertung der S-Boxen außer Acht gelassen.
Es zeigt sich, dass bei S0 als auch SAES fur¨ eine Eingabedifferenz ∆X h¨ochstens viermal diesel- be Ausgabedifferenz ∆Y auftaucht. Im Kontrast dazu ist die maximale H¨aufung eines Wertes
∆Y fur¨ ein ∆X bei der pseudo-zuf¨alligen S-Box SRAND dreimal h¨oher, n¨amlich zw¨olf. Auch hier ist also das Ergebnis, dass die S-Boxen des Chiasmus-Verfahrens wohl konstruiert und in Bezug auf ihre Resistenz gegen die differenzielle Attacke denen des AES-Verfahrens ebenburtig¨ sind. Auf der folgenden Seite ist eine grafische Darstellung der drei Difference Distribution Tables“ zu ” sehen.
50 Abbildung 4.4.: Difference Distribution Table S0, Chiasmus
Abbildung 4.5.: Difference Distribution Table SAES, AES
Abbildung 4.6.: Difference Distribution Table SRAND, pseudo-zuf¨allige bijektive S-Box 4. Analyse von Chiasmus
4.3.4 Berechnungsvorschrift
Da die S-Boxen des Chiasmus-Verfahrens und des AES-Verfahrens bezuglich¨ der Resistenz ge- gen die differenzielle und lineare Attacke uber¨ dieselben sehr guten Eigenschaften verfugen,¨ liegt die Vermutung nahe, dass jeweils eine ¨ahnliche Berechnungsvorschrift zugrunde liegt. In ihrem Buch The Design of Rijndael“ [15] geben die beiden Autoren der Rijndael/AES Chif- ” fre an, sich bei der Konstruktion ihrer S-Box stark an [11] orientiert zu haben. Dort wird auf die beweisbare, hohe Nichtlinearit¨at der Inversion in einem endlichen K¨orper hingewiesen. Auf diese baut die Berechnungsvorschrift der S-Boxen des Verfahrens: Die Eingaben in die Verschlusselungs-S-Box¨ des AES werden als Elemente in GF (28) interpre- tiert und bezuglich¨ eines bestimmten irreduziblem Polynoms aus GF (29) invertiert, die Null wird auf sich selbst abgebildet. Das Ergebnis dieser Inversion wird als Vektor in GF (2)8 inter- pretiert und mit einer affinen Abbildung noch einmal abgebildet. Es l¨asst sich zeigen, dass es keine affine Abbildung in GF (2)8 gibt, die zusammen mit der In- 8 version in GF (2 ) nach Art des AES die S-Boxen S0 oder S1 des Chiasmus erzeugt. Dies wurde im Rahmen dieser Arbeit fur¨ die Inversion bezuglich¨ s¨amtlicher irreduzibler Poly- nome aus GF (29) automatisiert uberpr¨ uft.¨ Das dafur¨ entwickelte Python-Skript sbox polynomial check.py ist auf dem beiliegenden Da- tentr¨ager zu finden. Es berechnet fur¨ eine gegebene S-Box1 fur¨ jedes der 30 in Frage kommenden irreduziblen Polynome die ersten beiden Spaltenvektoren der Abbildungsmatrix der m¨oglicher- weise verwendeten affinen Abbildung. Dieses Ergebnis wird dann vom Skript mit Hilfe der Ab- bildungstabelle der betreffenden S-Box auf Plausibilit¨at uberpr¨ uft.¨ Fur¨ die AES-S-Boxen gibt das Skript als einziges plausibles Polynom das korrekte aus. Bei Chiasmus findet das Skript einzig fur¨ S1 ein in Frage kommendes Polynom. Versucht man mit diesem weiter zu rechnen, so zeigt sich jedoch schnell, dass es sich bei dem gefundenen Polynom um einen Zufallstreffer handelt. Trotz der sehr ¨ahnlichen Eigenschaften wurden die S-Boxen des Chiasmus also anders konstru- iert als ihre Gegenstucke¨ aus dem AES. Es ist denkbar, dass die beiden Chiasmus-S-Boxen zus¨atzlich vor der Inversion noch eine zweite affine Abbildung in GF (2)8 enthalten. Dies zu uberpr¨ ufen¨ w¨are mit dem Affine Equivalence ” Algorithm“ aus [4] m¨oglich.
1Wird das Skript auf dem Datentr¨ager gestartet, so werden automatisch die Verschlusselungs-S-Box¨ des AES und S0 des Chiasmus untersucht.
52 4. Analyse von Chiasmus
4.4 Kryptographische Einordnung
Formell geh¨ort Chiasmus zur Familie der Substitutions-Permutations Netzwerke (SPN), in de- ren Reihen sich auch viele weitere bekannte Algorithmen wie AES/Rijndael oder Serpent wie- derfinden. Diese Klassifizierung folgt schon aus der Tatsache, dass Chiasmus fur¨ die Ver- und Entschlusselung¨ keine identische Rundenfunktion verwendet und es somit definitiv nicht den Feistel Netzwerken zuzurechnen ist, zu denen etwa DES und Twofish geh¨oren. Die Konstruktion des Chiasmus ist außergew¨ohnlich und scheint zumindest nicht direkt an eine andere bekannte Blockchiffre angelehnt. Als ungew¨ohnlich ist wohl die Tatsache einzustufen, dass Chiasmus sowohl Multiplikationen als auch S-Boxen einsetzt. Andere Blockchiffren wie IDEA vertrauen fur¨ die Konfusion des Klartextes allein auf Multipli- kationen und verzichten ganz auf S-Boxen [14]. Chiasmus wurde klar mit dem Blick auf x86 Prozessoren mit 32 Bits breiten Registern entwor- fen und optimiert. Dies zeigt sich an der Aufteilung der Daten auf 32 Bits lange Bl¨ocke und den Berechnungen modulo 232. W¨ahrend es die Reduktion modulo 232 bei einer Registerbreite von 32 Bits geschenkt gibt, l¨asst sie sich auf Plattformen mit kleineren Registerbreiten nur teuer erkaufen. Anders als zum Bei- spiel bei allen AES Kandidaten macht ein Einsatz des Chiasmus auf solchen Plattformen kaum Sinn. So setzt das BSI Chiasmus auch scheinbar nur in Software ein und greift im Embedded- Bereich auf einen anderes, ebenfalls geheimes Verfahren namens Libelle zuruck.¨ Wie gezeigt, verfugt¨ Chiasmus uber¨ zwei wohl konstruierte S-Boxen, die denen von AES in Be- zug auf Resistenz gegen differenzielle und lineare Attacke in nichts nachstehen. Auch mit einer Schlussell¨ ¨ange von offiziell 128 und technisch 160 Bits, ist Chiasmus auf der H¨ohe der Zeit. Inwieweit eine variable Schlussell¨ ¨ange vorgesehen ist, l¨asst sich nicht erkennen. Die Blockl¨ange von 64 Bits erscheint im Vergleich zu vielen der heute gebr¨auchlichen Blockchiffren kurz. Natur-¨ lich beeintr¨achtigen kurzere¨ Blockl¨angen nicht die Sicherheit eines Verfahren, jedoch fuhren¨ sie tendenziell zu einer langsameren Verarbeitungsgeschwindigkeit. Im Vergleich zu dem als schnell bekannten AES, erreicht Chiasmus laut dem BSI [9] rund 60% von dessen Geschwindigkeit. Wie der n¨achste Abschnitt zeigt, zeichnen die im Rahmen dieser Arbeit durchgefuhrten¨ eigenen Geschwindigkeitsmessungen ein noch deutlicheres Bild.
4.4.1 Verabeitungsgeschwindkeit
Um die Geschwindigkeit des Chiasmus beurteilen zu k¨onnen, wird die Implementierung aus Listing A.1 auf Seite 64 direkt mit der AES-Implementierung des OpenSSL Projekts [13] (128
53 4. Analyse von Chiasmus
Bits Schlussel¨ ohne FULL UNROLL2) verglichen. Dazu werden beide Chiffren zum Verschlusseln¨ eines ein GBit langen Datenstroms verwendet. Um gleiche Voraussetzungen zu schaffen, werden beide Chiffren mit Microsofts Visual C++ 2008 Compiler mit s¨amtlichen Geschwindigkeitsoptimierungen fur¨ Windows Systeme kompi- liert. Fur¨ die Ausfuhrung¨ auf einem Notebook mit Core 2 Duo P8400 Prozessor mit 2,24 GHz ergibt sich folgendes Bild:
Chiasmus 1 GBit / 5070ms SSL AES128 1 GBit / 1186ms
Hier ist AES also um mehr als den Faktor vier schneller als Chiasmus. Betrachtet man den hier von Visual C++ 2008 generierten Assemblercode fur¨ Chiasmus im Disassembler, so st¨oßt man auf ein interessantes Detail: Der Programmcode wurde vom Compiler so optimiert, dass keine einzige, langsame Multi- plikationsoperation mehr im Assemblercode zu finden ist. Es wird ausschließlich mit Shifts, Rotationen, Additionen und der XOR-Verknupfung¨ gearbeitet.
2Die Option FULL UNROLL“ bewirkt hier, dass keinerlei Schleifen verwendet und stattdessen zu iterierende ” Code-Abschnitte einfach mehrfach hintereinander in das fertige Programm geschrieben werden. Diese Technik erh¨oht fur¨ gew¨ohnlich die Ausfuhrungsgeschwindigkeit¨ eines Programmes, bl¨aht es jedoch auch auf.
54 5. Angriff gegen Schlusselgenerierung¨ im GSTOOL
5 Angriff gegen Schlu¨sselgenerierung im GSTOOL
Nachdem das Chiasmus-Verfahren vollst¨andig spezifiziert ist, wird noch einmal ein genauerer Blick auf seine Implementierung im GSTOOL geworfen. So soll in diesem letzten Teil die Sicherheit der verwendeten Schlusseldateigenerierung¨ genauer uberpr¨ uft¨ werden. Um diese ist es, so wird es sich zeigen, nicht gut bestellt, was zum Abschluss die Entwicklung eines Tools zum zuverl¨assigen und schnellen Knacken“ von verschlusselten¨ ” Dateien erm¨oglicht.
5.1 Beschreibung
Anders als viele andere Software zum Verschlusseln¨ von Dateien verfugt¨ das GSTOOL uber¨ keine Funktion zur Ableitung von kryptographischen Schlusseln¨ aus Passw¨ortern. Stattdessen wird der fur¨ eine Ver- oder Entschlusselung¨ zu verwendende Schlussel¨ stets direkt aus einer Datei gelesen. Solche Schlusseldateien¨ enthalten zwar insgesamt 104 Bytes (832 Bits) an Daten, davon ver- wendet werden jedoch immer nur die ersten 20 Bytes mit einer Gesamtl¨ange von 160 Bits. Diese werden als Ausgangsschlussel¨ direkt zur Generierung der 26 Teilschlussel¨ des Chiasmus- Verfahrens benutzt. Der genaue Aufbau einer solchen Schlusseldatei¨ ist also fur¨ den Nutzer nicht transparent. Folg- lich ist auch davon auszugehen, dass der mit Abstand gr¨oßte Teil der potentiellen Nutzer der Verschlusselungsfunktion¨ des GSTOOLs auf die hier behandelte, automatische Schlusselgene-¨ rierung zuruckgreift.¨
Klickt ein Nutzer im GSTOOL auf die Schaltfl¨ache Neu“ im Reiter Schlussel¨ verwalten“ des ” ” Verschlusselungsdialoges,¨ so ruft GSTOOL.exe uber¨ das bekannte COM-Interface die Funktion generateKey in MPCrypt.dll auf. Der 104 Bytes bzw. 832 Bits lange Ruckgabewert¨ dieser Funktion wird von GSTOOL.exe ohne Umschweife in die neu erstellte Schlusseldatei¨ geschrieben. Um die kryptographische Sicherheit der vom GSTOOL generierten Schlussel¨ bewerten zu k¨onnen, reicht es also aus, sich auf die genauere Analyse der Funktion generateKey zu beschr¨anken.
55 5. Angriff gegen Schlusselgenerierung¨ im GSTOOL
5.2 Analyse
Der Flowgraph der Funktion generateKey ist auf Seite 75 zu sehen. Innerhalb der Funktion wurden einige Standardfunktionen, wie zum Beispiel memset, bereits von IDA erkannt und au- tomatisch benannt. Fur¨ die Analyse interessant sind vor allem die drei Basic Blocks beginnend an den Adressen 0x10001226, 0x1000124C und 0x10001251. Im ersten dieser drei Basic Blocks werden Initialisierungen fur¨ die von den beiden hinteren Basic Blocks gebildeten Schleife vorgenommen. Gearbeitet wird in allen drei mit dem auf dem Stack liegenden Array Dst. Dieses hat eine L¨ange von 104 Bytes, was genau der erwarteten Gr¨oße entspricht1. Der Name Dst wurde automatisch von IDA vergeben, weil es das Array als Zielbuffer der Standardfunktion memset zuordnen konnte. Dieser Aufruf von memset an Adresse 0x10001236 setzt alle 104 (= 6816) Bytes des Arrays zun¨achst auf den Wert Null. Zuvor wird die Speicheradresse von Dst noch in das Register ESI geladen, uber¨ das im weiteren Verlauf auf das Array zugegriffen wird. Immer noch im selben Basic Block wird als n¨achstes der so genannte Seed des Standard-C Zufallsgenerators uber¨ den Aufruf der Funktion srand auf die Ruckgabe¨ der Funktion time gesetzt2 (siehe 0x1000123B bis 0x10001242). Die Schleife der beiden folgenden Basic Blocks wird 104-mal mit EDI als inkrementellem Z¨ahler durchlaufen (siehe 0x1000124C). Dabei wird in jeder Iteration die Funktion rand aufgerufen und das unterste Byte der insgesamt vier Bytes langen Ruckgabe¨ in das Array Dst geschrieben (siehe 0x10001251 und 0x10001256). Der Z¨ahler EDI fungiert dabei als Index. Danach werden keine Anderungen¨ mehr vorgenommen und der Inhalt des Arrays Dst wir an die GSTOOL.exe zuruckgegeben,¨ welche ihn in die neue Schlusseldatei¨ schreibt.
Ein neuer Schlussel¨ wird also ausschließlich durch insgesamt 104 Aufrufe von rand generiert.
5.2.1 Allgemein: Wieso srand(time()) keine gute Wahl ist
Das Verwenden von zuf¨alligen Werten als Schlussel¨ fur¨ kryptographische Operationen ist ein beliebter und bew¨ahrter Ansatz. Damit solche Schlussel¨ jedoch sicher sind, bedarf es kryptographisch sicherer Zufallszahlenge- neratoren. Zu dieser Gruppe geh¨ort das Paar der C-Standardfunktionen srand und rand nicht. 1Die L¨ange der lokalen Variable auf dem Stack l¨asst sich nicht aus dem gegebenen Flowgraph ablesen. In IDA ist dies jedoch leicht m¨oglich. 2Die Ruckgabe¨ einer Funktion erfolgt standardm¨aßig uber¨ das Register EAX. Hier wird EAX nach dem Aufruf von time direkt wieder als Argument von srand auf den Stack gepusht.
56 5. Angriff gegen Schlusselgenerierung¨ im GSTOOL
Zwar ist die interne Funktionsweise der beiden Funktionen nicht genau im C-Standard festge- legt [12], generell wird jedoch immer ein so genannter Linear Congruential Generator“ (LCG) ” verwendet, wobei sich die Konstanten von Compiler zu Compiler unterscheiden. Im vorliegenden Fall l¨asst sich die Berechnungsvorschrift nach einer kurzen Analyse des zuge- h¨origen Assemblercodes wie folgt aufschreiben:
0 0 32 ri+1 ≡ 214013 ∗ ri + 2531011 mod 2 0 ri = SHR16(ri)
0 32 und hier: r0 ≡ time() mod 2
0 Wobei ein Aufruf von srand den Seed r0 setzt und ein Aufruf von rand den n¨achsten Wert ri+1 ausgibt. Da 214013 bezuglich¨ des Modulos 232 uber¨ ein multiplikatives Inverses verfugt,¨ wird klar, dass 0 die Kenntnis eines ri genugt,¨ um alle vorangegangenen und folgenden Ausgaben von rand, und damit einen so generierten Schlussel,¨ berechnen zu k¨onnen. 0 Durch die Limitierung der Werte ri auf 32 Bits wird so die Gr¨oße des Schlusselraums¨ auf ma- ximal 232 Schlussel¨ eingeschr¨ankt. Durchsucht ein Angreifer also den Raum der m¨oglichen Schlussel¨ fur¨ ein Chiffrat, so muss er im Schnitt nur 232−1 Ver- oder Entschlusselungen¨ durchfuhren,¨ bis er den richtigen Schlussel¨ gefunden hat. Berechnungen in dieser Gr¨oßenordnung lassen sich fur¨ Blockchiffren ohne Pro- bleme auf einem modernen PC in einem Zeitraum von maximal ein paar Stunden durchfuhren.¨ Die Komplexit¨at l¨asst sich weiter reduzieren, wenn fur¨ das Setzen des Seeds die Funktion time genutzt wird. Ein Blick in die Referenz zeigt: Bei Microsofts Visual C++ liefert time die aktu- elle Systemzeit in vergangenen Sekunden seit dem 1.1.1970 [2]. Kann man also den Zeitpunkt an dem ein Schlussel¨ erstellt wurde ungef¨ahr absch¨atzen, so l¨asst sich der Angriff weiter vereinfachen. Mit 31536000 Sekunden pro Jahr, gibt es auch nur entsprechend viele unterschiedliche Schlussel¨ die innerhalb eines Jahres generiert werden k¨onnen. Weiß ein Angreifer also beispielsweise, dass ein Schlussel¨ im Jahr 2009 erstellt wurde, so verringert sich die effektive St¨arke dieses Schlussels¨ auf log2(31536000)Bits ≈ 24, 91Bits.
Mit log2(10 ∗ 31536000)Bits ≈ 28, 23Bits ergeben sich auch noch Vorteile, wenn der Angreifer den in Frage kommenden Zeitraum nur grob auf zehn Jahre eingrenzen kann. In der Praxis k¨onnte das Anderungsdatum¨ der betreffenden verschlusselten¨ Datei ein guter Anhaltspunkt fur¨ das Datum der Generierung des Schlussels¨ sein.
57 5. Angriff gegen Schlusselgenerierung¨ im GSTOOL
5.3 Angriff
Der im vorherigen Abschnitt beschriebene allgemeine Angriff wurde im Rahmen dieser Arbeit in ein parallelisiertes Programm (ksearch gst.exe) fur¨ Windows umgesetzt, das zuverl¨assig und in kurzer Zeit den Schlussel¨ zu einer mit dem GSTOOL chiffrierten Datei rekonstruiert und das Erstellungsdatum des Schlussels¨ ausgibt. Mit Hilfe der Chiasmus-Implementierung aus Listing A.1 uberpr¨ uft¨ das Programm systematisch alle in Frage kommenden Schlussel¨ ab einem bestimmten Datum fur¨ ein gegebenes Chiffrat. Die zu uberpr¨ ufenden¨ Schlussel¨ werden wie in generateKey mit Hilfe der Standardfunktion rand berechnet. Der Seed wird dabei jeweils mit srand auf den aktuell zu uberpr¨ ufenden¨ Sekunden- wert gesetzt. Der Nutzer kann das Startdatum der Suche selbst w¨ahlen und als Argument beim Programm- start ubergeben.¨ Die Sekundenrepr¨asentation des eingegebenen Startdatums ist dann der erste Seed fur¨ den ein Schlussel¨ berechnet wird. Dieser initiale Seed wird in jeder Runde inkremen- tiert (es wird eine Sekunde weitergez¨ahlt) und uber¨ srand neu gesetzt. Die Uberpr¨ ufung,¨ ob ein Schlussel¨ als korrekt in Frage kommt, beruht auf einem einfachen Kri- terium: Hat eine Klartextdatei eine L¨ange die kein Vielfaches von acht Bytes ist, so fullt¨ das GSTOOL den letzten Block dieser Datei vor dem Verschlusseln¨ mit Nullen auf eine L¨ange von acht Bytes auf. Die ursprungliche¨ Gr¨oße der Datei wird im Header der verschlusselten¨ Datei hinter OriginalFileSize:“ festgehalten. Ein Schlussel¨ l¨asst sich somit verifizieren, indem man den ” letzten Block einer Chiffratdatei entschlusselt¨ und uberpr¨ uft,¨ ob die Anzahl der vorgefundenen abschließenden Nullen mit der Anzahl der erwarteten ubereinstimmt.¨ Naturlich¨ ist dieses Kriterium nicht eindeutig und funktioniert auch nur zuverl¨assig fur¨ Dateien deren letzter Block mit mindestens drei Null-Bytes aufgefullt¨ wurde (also lKlartext mod 8 < 6). Geht man von zuf¨alligen Schlusseln¨ aus, so l¨asst sich die Fehlerwahrscheinlichkeit pro uberpr¨ uf-¨ 1 tem Schlussel¨ mit 28∗(l mod 8) angeben. Danach w¨are fur¨ drei Null-Bytes und einer zu durchsu- chenden Zeitspanne von einem Jahr mit ungef¨ahr mit ein bis zwei false positives“ zu rechnen: ” 1 224,91 ( 28∗3 F ehler/s) ∗ (31536000 s/Jahr) = 224 F ehler/Jahr. Dieses leicht ungenaue aber einfache Kriterium dient nur zu Demonstrationszwecken. Eine sinn- vollere Vorgehensweise w¨are das Entschlusseln¨ mehrere Bl¨ocke mit einer anschließenden Uber-¨ prufung¨ der Entropie. Auch eine Suche nach bekannten Datei-Headern im ersten Block w¨are in vielen F¨allen erfolgsversprechend. Wird ein Schlusselkandidat¨ gefunden, so wird automatisch die zugeh¨orige Schlusseldatei¨ erstellt und eine entsprechende Ausgabe auf die Konsole gegeben. Um den gesamten Vorgang der Schlusselsuche¨ m¨oglichst zu beschleunigen, kann die Aufgabe in- nerhalb von ksearch gst.exe auf beliebig viele Threads verteilt werden. Die gewunschte¨ Anzahl der Threads l¨asst sich als optionales Argument ubergeben.¨ Wird hier kein Wert vorgegeben,
58 5. Angriff gegen Schlusselgenerierung¨ im GSTOOL so erstellt das Programm einen Thread fur¨ jeden der dem System zur Verfugung¨ stehenden Prozessorkerne. Der Aufruf ksearch_gst.exe c:\cipher.txx c:\keys 11/30/2009 2 bewirkt eine Suche nach passenden Schlusseln¨ fur¨ die chiffrierte Datei cipher.txx“ ab dem ” Datum 30.11.2009 verteilt auf zwei Threads. Alle gefundenen Schlusselkandidaten¨ werden in den Ordner keys“ geschrieben und lassen sich direkt im GSTOOL importieren. ” Auf einem Notebook mit dem Zweikernprozessor Core 2 Duo P8400 mit 2,24 GHz wird fur¨ das Durchsuchen eines Erstellungszeitraumes von einem Jahr mit zwei Threads circa 30 Sekunden ben¨otigt. Dies entspricht in etwa der Uberpr¨ ufung¨ von zwei Millionen Schlusseln¨ pro Sekunde.
5.3.1 Weitere Einschr¨ankung des Schlusselraums¨
L¨asst man das Programm l¨anger laufen, so f¨allt ein interessantes Detail auf: Der korrekte Schlussel¨ wird immer mehrmals fur¨ verschiedene, auch in der Zukunft liegende, Zeitpunkte gefunden. Der Grund dafur¨ ist, dass das GSTOOL bei der Schlusselgenerierung¨ immer nur das letzte, niederwertige Byte ri,4 einer Ausgabe ri von rand verwendet. 0 0 0 Da rand mit ri = SHR16(ri) nur die beiden ersten, h¨oherwertigen Bytes ri,1 und ri,2 des aktuellen Zustands des LCGs ausgibt, handelt es sich bei dem Byte, das in den Schlussel¨ 0 einfließt, um ri,2. 0 Es gilt ri,4 = ri,2. 0 Das erste Byte von ri, hat also keinerlei Einfluss auf den Schlussel.¨ Folglich kann es auch bei der Schlusselsuche¨ außer Acht gelassen werden. Somit l¨asst sich der zu betrachtende Teil der Berechnungsvorschrift des LCGs aus dem vorherigen Abschnitt einschr¨anken:
0 n 0 0 0 0 o 0 32 ri+1 = ri+1,1, ri+1,2, ri+1,3, ri+1,4 ≡ 214013 ∗ ri + 2531011 mod 2
n 0 0 0 o n 0 0 0 0 o 24 ri+1,2, ri+1,3, ri+1,4 ≡ ri+1,1, ri+1,2, ri+1,3, ri+1,4 mod 2
n 0 0 0 o 0 24 ⇒ ri+1,2, ri+1,3, ri+1,4 ≡ 214013 ∗ ri + 2531011 mod 2
Der Schlusselraum¨ wird so auf 224 Elemente verkleinert. Insgesamt existieren also nur knapp 17 Millionen m¨ogliche unterschiedliche Schlus-¨ sel.
59 5. Angriff gegen Schlusselgenerierung¨ im GSTOOL
Mit dem im Rahmen dieser Arbeit entstandenen Programm ksearch2 gst.exe l¨asst sich die- ser Schlusselraum¨ fur¨ ein gegebenes Chiffrat systematisch durchsuchen. Das Programm l¨asst sich analog zu ksearch gst.exe bedienen und ben¨otigt auf dem erw¨ahnten Notebook weniger als zehn Sekunden fur¨ eine ersch¨opfende Schlusselsuche.¨ Die Schlusselgenerierung¨ des GSTOOLs ist somit gebrochen.
60 6. Fazit
6 Fazit
Das große Ziel das Chiasmus-Verfahren erstmalig zu spezifizieren wurde erreicht. Dabei ist es nicht bei einer Ubersetzung¨ in eine Hochsprache geblieben. Die Herkunft der Kon- stanten konnte nachvollzogen und wichtige Eigenschaften der Funktionen f0, g0, f1 und g1 offengelegt werden. Der vom Arbeitspensum her aufwendigste Teil dieser Arbeit - der Abschnitt S-Boxen“ - stellt ” fur¨ mich pers¨onlich auch den Interessantesten dar. Recherche und praktische Anwendung wa- ren hier ¨außerst spannend. Leider war es im zeitlich gesteckten Rahmen nicht mehr m¨oglich die genaue Berechnungsvorschrift der S-Boxen weiter zu ergrunden.¨ An dieser Stelle werden in Zukunft noch weitere Untersuchungen angestellt werden. Die Tatsache, dass ein so effektiver Angriff wie aus dem letzten Kapitel gegen die Chiasmus- Implementierung im GSTOOL m¨oglich ist, hat uberrascht¨ und gezeigt, dass Closed-Source Kryptographie, egal wie renommiert der Herausgeber ist, dramatische Sicherheitsrisiken bergen kann. Jedoch muss hier auch fairerweise nochmals angemerkt werden, dass das Hauptanwendungsge- biet des GSTOOLs nicht die Kryptographie ist. Auch wenn keine wirkliche Kryptanalyse durchgefuhrt¨ wurde, hinterl¨asst der Chiasmus an sich einen subjektiv positiven Eindruck. Das Verfahren ist elegant und wirkt durchdacht.
61 Literaturverzeichnis
Literaturverzeichnis
[1] Microsoft Corporation. Dllregisterserver function, November 2009. http://msdn. microsoft.com/en-us/library/ms682162(VS.85).aspx.
[2] Microsoft Corporation. time, time32, time64, Dezember 2009. http://msdn.microsoft. com/en-us/library/1f4c8f33.aspx.
[3] Microsoft Corporation. Safearray data type, Januar 2010. http://msdn.microsoft.com/ en-us/library/ms221482.aspx.
[4] Alex Biryukov et al. A toolbox for cryptanalysis: Linear and affine equivalence algorithms. In Advances in Cryptology – EUROCRYPT 2003, pages 33–50, Berlin / Heidelberg, 2003. Springer.
[5] G. Leander et al. Kryptographie I WS 2005/2006. Ruhr-Universit¨at, Vorlesungsskript, Bochum, 2006.
[6] Bundesamt fur¨ Sicherheit in der Informationstechnik. GSTOOL – Handbuch Version 4.5. Bundesamt fur¨ Sicherheit in der Informationstechnik, Bonn, 2008.
[7] Bundesamt fur¨ Sicherheit in der Informationstechnik. Chiasmus fur¨ windows/linux, Juli 2009. https://www.bsi.bund.de/cln_136/ContentBSI/Themen/ProdukteTools/ chiasmus/Chiasmus.html.
[8] Bundesamt fur¨ Sicherheit in der Informationstechnik. Gstool – der professionelle beglei- ter, November 2009. https://www.bsi.bund.de/cln_136/DE/Themen/weitereThemen/ GSTOOL/Uebersicht/uebersicht_node.html.
[9] Bundesamt fur¨ Sicherheit in der Informationstechnik. Sina-systembeschreibung, November 2009. https://www.bsi.bund.de/cln_136/ContentBSI/Themen/sina/ Systembeschreibung/sysbeschreibung.html.
[10] Howard M. Heys. A Tutorial on Linear and Differential Cryptanalysis. Memorial Uni- versity of Newfoundland [Online] www.engr.mun.ca/˜ howard/PAPERS/ldc tutorial.pdf, 2002.
[11] Kaisa Nyberg. Differentially uniform mappings for cryptography. In EUROCRYPT ’93, volume 765/1994, pages 55–64, Berlin / Heidelberg, 1994. Springer.
62 Literaturverzeichnis
[12] P.J. Plauger. The Standard C Library. Prentice Hall, Englewood Cliffs, 1992.
[13] OpenSSL Project. Openssl v0.9.81, aes x86core.c, November 2009. http://www.openssl. org/source/openssl-0.9.8l.tar.gz.
[14] Bruce Schneier. Angewandte Kryptographie: Protokolle, Algorithmen und Sourcecode in C. Addison-Wesley, Bonn, 1996.
[15] Joan Daemen und Vincent Rijmen. The Design of Rijndael. Springer-Verlag, Berlin / Heidelberg, 2002.
63 A. Anhang
A Anhang
A.1 Eigene Chiasmus-Implementierung in C++
/* VERSION: 11 */
/* s−boxes */ const BYTE sbox0[256] = {0x65 ,0x33 ,0xcf ,0xb9 ,0x37 ,0x64 ,0xcd ,0xf3 ,0x26 ,0x3a ,0xc1 ,0xa2 ,0x72 ,0x8a ,0x8f ,0xe3 ,0xfd ,0x56 ,0xb3 ,0x0f ,0x10 ,0x2b ,0x3e ,0xa0 ,0xbd ,0x1e ,0xab ,0x1d ,0x9c ,0xe2 ,0x87 ,0x98 ,0xa8 ,0xd3 ,0xb4 ,0xdf ,0x92 ,0x75 ,0x3b ,0x39 ,0x20 ,0xa5 ,0xfa ,0x1b ,0xbe ,0x90 ,0xf6 ,0x09 ,0xe5 ,0x61 ,0xc4 ,0xc9 ,0x06 ,0xc2 ,0xa6 ,0x1c ,0xf9 ,0x94 ,0x7b ,0x53 ,0x73 ,0x01 ,0x25 ,0x9a ,0x1a ,0xff ,0xe9 ,0x5a ,0x76 ,0x13 ,0x4b ,0x95 ,0xac ,0x0b ,0xc7 ,0xb2 ,0xb8 ,0xd6 ,0x17 ,0xa9 ,0x27 ,0xeb ,0xd1 ,0x5c ,0xc3 ,0x9b ,0x22 ,0x15 ,0x8e ,0x40 ,0x11 ,0x5e ,0x57 ,0x16 ,0xd0 ,0xb0 ,0x5d ,0x79 ,0x31 ,0xbb ,0xea ,0x4f ,0xd9 ,0xde ,0x00 ,0x0a ,0xd7 ,0xad ,0x3f ,0x99 ,0x68 ,0x34 ,0x66 ,0xf0 ,0x44 ,0x35 ,0x89 ,0x54 ,0x81 ,0xb1 ,0x84 ,0x2a ,0x8b ,0x6f ,0xc0 ,0x43 ,0xfe ,0x96 ,0x48 ,0x82 ,0x0c ,0xda ,0x74 ,0xbc ,0x21 ,0xf1 ,0x67 ,0x2e ,0xdb ,0x49 ,0xe4 ,0xd5 ,0x71 ,0x59 ,0x29 ,0xe0 ,0xa1 ,0x30 ,0xdd ,0x91 ,0x6b ,0xb7 ,0xb6 ,0x69 ,0xc5 ,0x80 ,0xaa ,0x6d ,0xa3 ,0x2c ,0x05 ,0x78 ,0xba ,0x51 ,0x14 ,0x07 ,0xd4 ,0xec ,0x7e ,0xcc ,0x24 ,0x62 ,0x9e ,0xdc ,0x8c ,0xd8 ,0x1f ,0x46 ,0xe8 ,0x9f ,0x4e ,0xa4 ,0x85 ,0x32 ,0xce ,0xa7 ,0xfc ,0xe1 ,0x97 ,0xae ,0x2d ,0x52 ,0x7d ,0x0e ,0x6c ,0x83 ,0x5f ,0xbf ,0x18 ,0x7c ,0x36 ,0x63 ,0x0d ,0xef ,0xc8 ,0x5b ,0x55 ,0x12 ,0x4a ,0xf2 ,0x70 ,0x38 ,0xf8 ,0xaf ,0x86 ,0x77 ,0x47 ,0x04 ,0x23 ,0x02 ,0x6e ,0x4c ,0x58 ,0x03 ,0x50 ,0x7a ,0x3d ,0x28 ,0xf5 ,0xe7 ,0x41 ,0xf4 ,0x45 ,0x60 ,0x6a ,0x08 ,0x88 ,0x7f ,0x9d ,0x93 ,0x4d ,0xd2 ,0x2f ,0xee ,0xe6 ,0xcb ,0xed ,0xfb ,0xca ,0xf7 ,0x19 ,0xb5 ,0x42 ,0x8d ,0xc6 ,0x3c } ;
//sbox1=inverse(sbox0) const BYTE sbox1[256] = {0x68 ,0x3d ,0xdb ,0xdf ,0xd9 ,0xa0 ,0x34 ,0xa5 ,0xeb ,0x2f ,0x69 ,0x49 ,0x82 ,0xca ,0xc1 ,0x13 ,0x14 ,0x5a ,0xcf ,0x45 ,0xa4 ,0x57 ,0x5d ,0x4e ,0xc6 ,0xfa ,0x40 ,0x2b ,0x37 ,0x1b ,0x19 ,0xb0 ,0x28 ,0x86 ,0x56 ,0xda ,0xaa ,0x3e ,0x08 ,0x50 ,0xe3 ,0x90 ,0x79 ,0x15 ,0x9f ,0xbe ,0x89 ,0xf2 ,0x93 ,0x62 ,0xb7 ,0x01 ,0x6f ,0x73 ,0xc8 ,0x04
64 A. Anhang
,0xd3 ,0x27 ,0x09 ,0x26 ,0xff ,0xe2 ,0x16 ,0x6c ,0x59 ,0xe6 ,0xfc ,0x7d ,0x72 ,0xe8 ,0xb1 ,0xd8 ,0x80 ,0x8b ,0xd0 ,0x46 ,0xdd ,0xf0 ,0xb4 ,0x65 ,0xe0 ,0xa3 ,0xbf ,0x3b ,0x75 ,0xce ,0x11 ,0x5c ,0xde ,0x8f ,0x43 ,0xcd ,0x53 ,0x60 ,0x5b ,0xc4 ,0xe9 ,0x31 ,0xab ,0xc9 ,0x05 ,0x00 ,0x70 ,0x88 ,0x6e ,0x99 ,0xea ,0x96 ,0xc2 ,0x9d ,0xdc ,0x7b ,0xd2 ,0x8e ,0x0c ,0x3c ,0x84 ,0x25 ,0x44 ,0xd7 ,0xa1 ,0x61 ,0xe1 ,0x3a ,0xc7 ,0xc0 ,0xa8 ,0xed ,0x9b ,0x76 ,0x81 ,0xc3 ,0x78 ,0xb6 ,0xd6 ,0x1e ,0xec ,0x74 ,0x0d ,0x7a ,0xae ,0xfd ,0x58 ,0x0e ,0x2d ,0x95 ,0x24 ,0xef ,0x39 ,0x47 ,0x7f ,0xbc ,0x1f ,0x6d ,0x3f ,0x55 ,0x1c ,0xee ,0xac ,0xb3 ,0x17 ,0x92 ,0x0b ,0x9e ,0xb5 ,0x29 ,0x36 ,0xb9 ,0x20 ,0x4f ,0x9c ,0x1a ,0x48 ,0x6b ,0xbd ,0xd5 ,0x5f ,0x77 ,0x4b ,0x12 ,0x22 ,0xfb ,0x98 ,0x97 ,0x4c ,0x03 ,0xa2 ,0x63 ,0x85 ,0x18 ,0x2c ,0xc5 ,0x7c ,0x0a ,0x35 ,0x54 ,0x32 ,0x9a ,0xfe ,0x4a ,0xcc ,0x33 ,0xf8 ,0xf5 ,0xa9 ,0x06 ,0xb8 ,0x02 ,0x5e ,0x52 ,0xf1 ,0x21 ,0xa6 ,0x8d ,0x4d ,0x6a ,0xaf ,0x66 ,0x83 ,0x8a ,0xad ,0x94 ,0x67 ,0x23 ,0x91 ,0xbb ,0x1d ,0x0f ,0x8c ,0x30 ,0xf4 ,0xe5 ,0xb2 ,0x42 ,0x64 ,0x51 ,0xa7 ,0xf6 ,0xf3 ,0xcb ,0x71 ,0x87 ,0xd1 ,0x07 ,0xe7 ,0xe4 ,0x2e ,0xf9 ,0xd4 ,0x38 ,0x2a ,0xf7 ,0xba ,0x10 ,0x7e ,0x41 } ;
#define L 0 #define R 1
/* convenience data−type allowing both byte −wise and dword−wise access to 32 bits values */ union block32 { DWORD dword ; struct {BYTE byte0; BYTE byte1; BYTE byte2; BYTE byte3; } ; } ;
/* magic primes alpha, beta and their multiplicative −i n v e r s e s */ #define ALPHA 0 #define BETA 1
//{{ alpha , inverse(alpha)} ,{ beta, inverse(beta)} const inversePair magic[] = {{0x4614965B , 0x5832A9D3} , {0 x47B93463 , 0x52AED4B}} ; const DWORD magicKey = 0x33333333 ;
/* standard left and right bit −r o t a t i o n s */ inline DWORD rotateLeft(DWORD val , BYTE bits) { return ( ( v a l << b i t s ) | ( v a l >> (32 − b i t s ) ) ) ; }
inline DWORD rotateRight(DWORD val , BYTE bits)
65 A. Anhang
{ return ( ( v a l << (32 − b i t s ) ) | ( v a l >> b i t s ) ) ; }
/* internal Chiasmus−functions f0, g0, f1 and g1 */ i n l i n e DWORD f 0 (DWORD x1 , DWORD x2 ) { return x1 * magic [ALPHA] . p − x2 * magic [BETA]. p; }
i n l i n e DWORD f 1 (DWORD x1 , DWORD x2 ) { return x1 * magic[ALPHA].p + x2 * magic[BETA]. inverse ; }
i n l i n e DWORD g0 (DWORD x1 , DWORD x2 ) { return x1 * (2 * magic[ALPHA]. inverse ) − x2 * magic[BETA]. inverse ; }
i n l i n e DWORD g1 (DWORD x1 , DWORD x2 ) { return x1 * (2 * magic[ALPHA]. inverse) + x2 * magic [BETA]. p; }
/* i n t e r n a l s−boxes wrappers */ i n l i n e void s0(block32 &x) { block32 temp; temp.dword = x.dword; x.byte3 = sbox0[temp.byte0]; x.byte1 = sbox0[temp.byte1]; x.byte2 = sbox0[temp.byte2]; x.byte0 = sbox0[temp.byte3]; }
i n l i n e void s1(block32 &x) { block32 temp; temp.dword = x.dword; x.byte3 = sbox1[temp.byte0]; x.byte1 = sbox1[temp.byte1]; x.byte2 = sbox1[temp.byte2]; x.byte0 = sbox1[temp.byte3]; }
/* CHIASMUS ALGORITHMS */ void chiasmusKeySchedule( const block32 baseKey[5] , block32 key[26]) { //first 5 round keys are the key itself for ( int i =0; i <5; i ++)
66 A. Anhang
{ key[i ].dword = baseKey[i ].dword; }
//calc remaining 21 round keys for ( int i =5; i <26; i ++) { DWORD a = key [ i −5]. dword ; DWORD b = key [ i −3]. dword ;
key[i ].dword = rotateRight(a,7) ˆ (b * magicKey ) ; }
//increment last 21 keys by their index for ( int i =5; i <26; i ++) { key[i ].dword += i; } } void chiasmusEncBlock(block32 data[2] , const block32 key[26]) { data[L].dword ˆ= key[0].dword;
for ( int round=12, indexKey=1; round >0; round−−, indexKey+=2) { block32 temp; //right block encryption: //add round key 1 data[R].dword ˆ= key[indexKey ].dword; // f e e d byte −wise into sbox0, swapping first and last byte s0(data[R]); //rotate left by number denoted by left block’s five highest bits temp.dword = rotateLeft(data[R].dword, data[L].dword >> 2 7 ) ; //mix with left block in f0 data[R].dword = f0(temp.dword, data[L].dword); //left block encryption: //mix with right block in g0 data[L].dword = g0(data[L].dword, temp.dword); //rotate right by number denoted by right block’s five highest bits data[L].dword = rotateRight(data[L].dword, data[R].dword >> 2 7 ) ; // f e e d byte −wise into sbox1, swapping first and last byte s1(data[L]); //add round key 2 data[L].dword ˆ= key[indexKey+1].dword; } data[R].dword ˆ= key[25].dword; } void chiasmusDecBlock(block32 data[2] , const block32 key[26]) { data[R].dword ˆ= key[25].dword;
for ( int round=12, indexKey=24; round >0; round−−, indexKey −=2) { block32 temp; //left block decryption: //add round key 2 data[L].dword ˆ= key[indexKey].dword;
67 A. Anhang
// f e e d byte −wise into sbox0, swapping first and last byte s0(data[L]); //rotate left by number denoted by right block’s five highest bits temp.dword = rotateLeft(data[L].dword, data[R].dword >> 2 7 ) ; //mix with right block in f1 data[L].dword = f1(temp.dword, data[R].dword); //right block decryption: //mix with left block in g1 data[R].dword = g1(data[R].dword, temp.dword); //rotate right by number denoted by left block’s five highest bits data[R].dword = rotateRight(data[R].dword, data[L].dword >> 2 7 ) ; // f e e d byte −wise into sbox1, swapping first and last byte s1(data[R]); //add round key 1 data[R].dword ˆ= key[indexKey −1]. dword ; } data[L].dword ˆ= key[0].dword; }
Listing A.1: Eigene Chiasmus-Implementierung in C++
68 A. Anhang
A.2 PyEmu Skripte import sys, os, time, struct, re, string
# s e t PeyEmu paths sys .path.append(r ’C: \ Program F i l e s ( x86 )\IDA\ python \pyemu ’ ) sys .path.append(r ’C: \ Program F i l e s ( x86 )\IDA\ python \pyemu\ l i b ’ )
#c o n s t s keySize = (64/8)*13 dataSize = (64/8) from PyEmu import * def createStack(emu, pData, pKey): emu . s e t s t a c k argument(0x4, pData, name=”pData”) emu . s e t s t a c k argument(0x8, pKey, name=”pKey”) emu . s e t s t a c k variable(0x4, value=1, size=4, name=”x”) emu . s e t s t a c k variable(0x8, value=2, size=4, name=”y”)
return True def emulateEncCore(data , key):
textstart = SegByName(”.text”) textend = SegEnd(textstart)
print ”%08x” % textstart print ”%08x” % textend
emu = IDAPyEmu( ) emu.debug(0)
print ”[ * ] Loading t e x t s e c t i o n bytes i n t o memory”
currenttext = textstart while currenttext <= textend : emu . set memory(currenttext , GetOriginalByte(currenttext), size=1) currenttext += 1
datastart = SegByName(”.rdata”) dataend = SegEnd(datastart)
print ”[ * ] Loading rdata s e c t i o n bytes i n t o memory ( sboxes ) ”
currentdata = datastart while currentdata <= dataend : emu . set memory(currentdata , GetOriginalByte(currentdata), size=1) currentdata += 1
#set up key and data fields keyStart = 0x00100000 dataStart = 0x00200000
encStart = 0x10002904 encEnd = 0x10002A00
69 A. Anhang
print ”[ * ] S e t t i n g up key and data f i e l d s ”
for i in range (keyStart , keyStart + k e y S i z e ) : emu . set memory(i , key[i −keyStart], size=1)
for i in range (dataStart , dataStart + d a t a S i z e ) : emu . set memory(i , data[i −dataStart], size=1)
print ”[ * ] Creating s t a c k ”
createStack(emu, dataStart , keyStart)
print ”[ * ] S t a r t i n g emulation ”
emu. execute( start=encStart ,end=encEnd) encData = emu.get memory(dataStart , d a t a S i z e )
print ”[ * ] Done ” return encData
#example code data = d a t a S i z e * [ 0xDE] key = k e y S i z e * [ 0xAB] encData = emulateEncCore(data ,key) for c in encData : print ”\\x%02x” % ord(c),
Listing A.2: Skript zur Emulierung von encCore in IDA import sys, os, time, struct, re, string
# s e t PeyEmu paths sys .path.append(r ’C: \ Program F i l e s ( x86 )\IDA\ python \pyemu ’ ) sys .path.append(r ’C: \ Program F i l e s ( x86 )\IDA\ python \pyemu\ l i b ’ )
#c o n s t s keySize = (64/8)*13 from PyEmu import * def createStack(emu, pBaseKey): emu . s e t s t a c k argument(0x4, pBaseKey, name=”pBaseKey”)
return True def emulateKeySchedCore(baseKey ):
textstart = SegByName(”.text”) textend = SegEnd(textstart)
print ”%08x” % textstart print ”%08x” % textend
emu = IDAPyEmu( ) emu.debug(0)
70 A. Anhang
print ”[ * ] Loading t e x t s e c t i o n bytes i n t o memory”
currenttext = textstart while currenttext <= textend : emu . set memory(currenttext , GetOriginalByte(currenttext), size=1) currenttext += 1
#set up key and data fields keyStart = 0x00100000
schedStart = 0x1000119A schedEnd = 0x100011D8
print ”[ * ] S e t t i n g up key f i e l d ”
for i in range (keyStart , keyStart + k e y S i z e ) : emu . set memory(i , baseKey[i −keyStart], size=1)
print ”[ * ] Creating s t a c k ”
createStack(emu, keyStart)
print ”[ * ] S t a r t i n g emulation ”
emu. execute( start=schedStart ,end=schedEnd) expandedKey = emu.get memory(keyStart , k e y S i z e )
print ”[ * ] Done ”
return expandedKey
#example code baseKey = k e y S i z e * [ 0xAB] expandedKey = emulateKeySchedCore(baseKey) for k in expandedKey : print ”\\x%02x” % ord(k),
Listing A.3: Skript zur Emulierung von keySchedCore in IDA
A.3 Flowgraphs
71 Abbildung A.1.: abc