Symmetrische Kryptographie auf GPUs

Transkript

1 Symmetrische Kryptographie auf GPUs Mikael Voss 15. Juli 2009 Die folgende Seminararbeit erläutert verschiedene Verfahren der symmetrischen Datenverschlüsselung vor dem Hintergrund der Nutzbarkeit auf GPUs und stellt anschließend ein Paper vor, das dieses Wissen praktisch anwendet. 1

2 Inhaltsverzeichnis 1 Einführung Stromverschlüsselung Blockverschlüsselung Rijndael Betriebsmodi Anwendung Architektur Lookup-Tabellen Deskriptoren Performanz Parallele Betriebsmodi Serielle Betriebsmodi Fazit 13 2

3 1 Einführung 1.1 Stromverschlüsselung Stromverschlüsselungsalgorithmen erzeugen aus dem Schlüssel, abhängig von einem internen Zustand, einen sogenannten Schlüsselstrom, der bitweise mit dem Klartext XOR-verknüpft wird und so den Geheimtext erzeugt. Zur Enschlüsselung wird dieser erneut mit dem Schlüsselstrom verknüpft und erzeugt so den Klartext. Da bei den meisten Algorithmen dieser Art jeder Zustand des Verschlüsselungsalgorithmus vom vorherigen abhängt [3], sind sie von Natur aus seriell. Eine Implementation auf der Graphikkarte wäre also sinnlos, da sie keine Steigerung des Durchsatzes bewirken, jedoch die Latenz (durch den Transfer zur Graphikkarte) enorm erhöhen würde. Verschlüsselung G i = K i T Si für i = 1... n Entschlüsselung K i = G i T Si für i = 1... n (a) Verschlüsselung (b) Entschlüsselung Abbildung 1: Stromverschlüsselung Der bekannteste Stromverschlüsselungsalgorithmus dürfte RC4 sein, der zur Verschlüsselung in drahtlosen Netzwerken nach IEEE verwendet wird. 1.2 Blockverschlüsselung Blockverschlüsselungsalgorithmen verschlüsseln Klartexte blockweise (üblicherweise in Größen von 64 bis 256 Bits), indem sie diese abhängig vom Schlüssel transformieren. Da jeder Block unabhängig ver- und entschlüsselt werden kann, können Blockchiffre enorm von einer Portierung auf die Graphikkarte profitieren. Verbreitete Blockverschlüsselungsalgorithmen sind Lucifer (DES), Rijndael (AES) und Twofish, die zur Verschlüsselung von Datenübertragungen (SSL/TLS), Dokumenten, Nachrichten (OpenPGP) und Datenträgern verwendet werden. 3

4 1.2.1 Rijndael Der Rijndael-Algorithmus wurde 1998 von Vincent Rijmen und Joan Daemen entwickelt und arbeitet mit Block- und Schlüsselgrößen von 128, 192 und 256 Bit und ist wie folgt gegliedert: 1. Schlüsselexpansion 2. Vorrunde a) Rundenschlüssel hinzufügen 3. Hauptrunden a) Substitution b) Transposition c) Mischen d) Rundenschlüssel hinzufügen 4. Schlussrunde a) Substitution b) Transposition c) Rundenschlüssel hinzufügen Bei der Schlüsselexpansion werden die Rundenschlüssel erzeugt, die im späteren Verlauf (Schritte 2a, 3d und 4c) mit dem Block verknüpft werden. Darauf folgen eine Vorrunde, abhängig von der Schlüssellänge acht, zehn oder zwölf Hauptrunden und eine Schlussrunde. Im Substitutionsschritt (3a und 4a) werden jeweils acht Bit des Blocks an Hand einer Lookup- Tabelle (auch Substitutionsbox genannt) ersetzt, bei der anschließenden Transposition nach einem bestimmten Schema verschoben und schließlich beim Mischen mit Konstanten multipliziert und die Ergebnisse verknüpft. [4] Diese drei Schritte lassen sich durch eine Reihe von Tabellen-Lookups ersetzen und so beschleunigen. Auf einem System mit einer Wortbreite von 32 Bit, kann eine Verschlüsselungsrunde so auf 16 Lookups und 12 XOR-Verknüpfungen reduziert werden. [4] [5] Der Advanced Encryption Standard spezifiziert den Rijndael-Algorithmus mit einer Blockgröße von 128 Bit Betriebsmodi Wird jeder Block unabhängig von den anderen verschlüsselt (Electronic Code Book-Verfahren), so ergibt sich das Problem, dass die Struktur des Klartextes möglicherweise aus der Struktur des Geheimtextes ersichtlich ist, weil ein Klartext immer den gleichen Geheimtext erzeugt. Verschlüsselung G i = f S (K i ) für i = 1... n Entschlüsselung K i = fs 1 i) für i = 1... n 4

5 (a) Original [1] (b) Verschlüsselt [2] Abbildung 2: Electronic Code Book-Verfahren Cipher Block Chaining Im Cipher Block Chaining-Verfahren (kurz CBC) wird dieses Problem beseitigt, indem jeder Klartextblock einer Nachricht vor seiner Verschlüsselung mit dem vorherigen Geheimtextblock XOR-verknüpft wird. Da der erste Block einer Nachricht keinen vorherigen besitzt, wird dieser mit einem zufällig generierten Initialisierungsvektor verknüpft, der zusammen mit der Nachricht übertragen wird. Weil jeder Block erst verschlüsselt werden kann, wenn alle vorherigen verschlüsselt wurden, ist das Verfahren nicht parallelisierbar. Verschlüsselung G 1 = f S (K 1 IV ) G i = f S (K i G i 1 ) für i = 2... n Entschlüsselung K 1 = fs 1 1) IV K i = fs 1 i) G i 1 für i = 2... n 5

6 Abbildung 3: Cipher Block Chaining Counter-Modus Ein weiteres Verfahren, das die Schwächen des ECB-Modus beseitigt, ist der Counter-Modus (kurz CTR), bei dem ein Zähler verschlüsselt und anschließend mit dem entsprechenden Klartextblock XOR-verknüpft wird. Die Parallelisierbarkeit hängt hierbei entscheidend vom verwendeten Zähler ab. Üblicherweise besteht dieser aus der Blocknummer, die mit einer zufälligen Nonce 1 verknüpft wird, sodass alle Blöcke unabhängig verschlüsselt werden können. Zähler Z i = N i für i = 1... n Verschlüsselung G i = f S (Z i ) K i für i = 1... n Entschlüsselung K i = fs 1 i) G i für i = 1... n 1 Amalgation aus Number used once 6

7 Abbildung 4: Counter-Modus 7

8 2 Anwendung Dass die genannten Parallelisierungsmöglichkeiten bei der symmetrischen Verschlüsselung auch in der Praxis ausnutzen lassen, demonstrieren Owen Harrison und John Waldron in ihrem Paper Practical Symmetrical Key Cryptography on Modern Graphics Hardware [7], in dem sie eine Architektur beschreiben, mit deren Hilfe Nachrichten auf der Graphikkarte verschlüsselt werden können. Als Verschlüsselungsalgorithmus wird eine optimierte Rijndael- Variante mit einer Blockgröße von 128 Bit sowohl in parallelen, als auch in seriellen Betriebsmodi eingesetzt, von denen exemplarisch CTR und CBC vorgestellt werden. Als Hardwareplattform dient den Autoren eine Nvidia G80-GPU (8800GTX-Graphikkarte), die mit Hilfe des CUDA-Framework programmiert wird. 2.1 Architektur Abbildung 5: Architektur Wie aus Abbildung 5 ersichtlich, findet die Schlüsselexpansion auf dem Hauptprozessor statt, weil sie von serieller Natur ist und deshalb nicht von einer Verlagerung auf die GPU profitiert. Die erzeugten Rundenschlüssel werden zusammen mit Nachrichtendeskriptoren im Texturspeicher abgelegt, deren Struktur in Abschnitt näher beleuchtet werden soll, während die Nachrichten selbst in den Global memory geladen werden. 8

9 Die eigentliche Verschlüsselung findet auf der GPU statt, wo bei parallelen Betriebsmodi jeder Klartextblock einer Nachricht durch einen eigenen Thread bearbeitet wird, während bei seriellen Modi jeder Thread eine ganze Nachricht verarbeiten muss Lookup-Tabellen Da die Geschwindigkeit der optimierten Rijndael-Variante stark von der Zugriffszeit auf die notwendigen Lookup-Tabellen 3 abhängt, werden diese im Shared memory abgelegt, der die kürzesten Zugriffszeiten bei wahlfreiem Lesen verspricht [7, Seiten 3 und 4]: kohärent wahlfrei Shared memory 0, 204s 0, 433s Constant memory 0, 176s 0, 960s Texture memory 0, 702s 1, 238s Tabelle 1: Ausführungszeit für Lesezugriffe Weiterhin werden die Tabellen in Form von vier Arrays gespeichert, um sich die interne Aufteilung des Shared memory in gleichzeitig ansprechbare Bänke zu nutze zu machen. Es zeigt sich ein deutlicher Unterschied im Verschlüsselungsdurchsatz: Shared memory Constant memory Texture memory 1 4KiB 5, 945 Gb s 4, 123 Gb s 4, 200 Gb s 4 1KiB 6, 914 Gb s 4, 085 Gb s 4, 197 Gb s Tabelle 2: Durchsatz im CTR-Modus Deskriptoren Um die Arbeit der GPU-Threads zu koordinieren, werden Deskriptoren verwandt, die jedem Thread abhängig von einer logischen Identifikationsnummer einen Klartextblock (parallele Modi) oder eine ganze Nachricht (serielle Modi) zuweisen. Die Deskriptoren sind in über Referenzen in einem sparse array (siehe Abbildung 6) angeordnet, das jedem Thread erlaubt, mit einer quadratischen Suche die von ihm zu verschlüsselnden Nachrichtenblöcke zu ermitteln. Durch die Verwendung eines sparse array, muss nicht für jeden Block ein Eintrag gespeichert werden. Die Threads müssen nur nach dem Eintrag mit der größten Thread-ID suchen, die kleiner oder gleich ihrer eigenen ist und können durch Subtraktion der beiden auf die ihnen zugewiesene Blocknummer der Nachricht schließen. 2 vergleiche Cipher Block Chaining im Abschnitt vergleiche Abschnitt

10 Abbildung 6: Übersetzung der Thread-IDs [7, Seite 8] 2.2 Performanz Abbildung 7: Durchsatz im CTR-Modus [7, Seite 5] Abbildung 7 vergleicht die Durchsätze verschiedener AES/CTR-Implementationen, darunter eine für die Nvidia 7900GT-Graphikkarte, die 2007 von Harrison und Waldron im Paper AES 10

11 Encryption Implementation and Analysis on Commodity Graphics Processing Units vorgestellt wurde und eine für das obsolete Close To Metal-Interface von AMD, die im Paper Symmetric Key Cryptography on Modern Graphics Hardware von Yang und Goodman aus dem selben Jahr beschrieben wird, sowie zwei weitere für 2008 übliche x86-64-prozessoren. Es zeigt sich, dass sich der Verschlüsselungs-Durchsatz im Vergleich zu bisherigen GPUund CPU-basierten Implementationen enorm steigern lässt, jedoch wird deutlich, dass eine gewisse Mindestdatenmenge notwendig ist, um die GPU ausreichend zu sättigen. Daneben wird deutlich, dass die Übertragung der Daten aus dem Hauptspeicher auf die Graphikkarte einen erheblichen Flaschenhals darstellt: Vernachlässigt man diese, kann die Datenrate im Vergleich zur schnellsten CPU-Implementation verzehnfacht werden, während man unter Berücksichtigung der Transfers nur eine Vervierfachung beobachten kann. [7, Seiten 5 und 6] Zukünftige Graphikkarten werden dieses Problem durch eine bessere Anbindung an das Host-System möglicherweise abmildern Parallele Betriebsmodi Abbildung 8: Durchsatz paralleler Betriebsmodi [7, Seite 10] Wie Abbildung 8 zeigt, können in parallelen Betriebsmodi die höchsten Durchsätze bei möglichst großen Nachrichten erreicht werden. Hier steigt der Durchsatz fast proportional 11

12 zur Zahl der Nachrichten und flacht ab, wenn die GPU sich ihrer Sättigungsgrenze nähert. Wählt man kleinere Nachrichten, steigt der Durchsatz nur gemächlich und erreicht niedrigere Maximalwerte. Dies ist möglicherweise durch schlechteres Cacheing-Verhalten durch die Zahl der Nachrichtendeskriptoren zu erklären. [7, Seite 10] Serielle Betriebsmodi Abbildung 9: Durchsatz serieller Betriebsmodi [7, Seite 11] Im Gegensatz zu parallelen Betriebsmodi, ist es in seriellen Modi schwieriger, die GPU zu sättigen, da jeder Block einer Nachricht vom selben Thread bearbeitet werden muss. Es ist also eine große Zahl an Nachrichten notwendig, um angemessene Verschlüsselungsdurchsätze zu erreichen. Ab einer Nachrichtengröße von mehr als 512 Blöcken zeigt sich ein starker Performance- Zusammenbruch bei einer großen Zahl von Nachrichten, dessen Ursache nicht ausreichend geklärt werden konnte. [7, Seite 11] 12

13 3 Fazit Owen Harrison und John Waldron haben mit ihrer Arbeit gezeigt, dass es dank moderner Programmiermethoden wie CUDA möglich und sinnvoll ist, symmetrische Datenverschlüsselung auf Graphikkarten durchzuführen. Durch eine geschickte Konzeption von Programm und Datenstrukturen ist es ihnen gelungen, sowohl in parallelen, als auch in seriellen Betriebsmodi, einen enormen Geschwindigkeitsvorteil gegenüber rein CPU-basierten Rijndael- Implementationen zu erreichen, der durch zukünftige Graphikkarten noch gesteigert werden wird. Literatur [1] Larry Ewing, Linux 2.0 Penguins, lewing/linux/ [2] Imagen de Tux cifrada por método ECB, Wikimedia commons, 20. Mai 2006, ecb.jpg [3] K. Kaukonen, R. Thayer, A Stream Cipher Encryption Algorithm Arcfour, IETF Draft, 1999, [4] Advanced Encryption Standard, Wikipedia, Revision , 2009, Encryption Standard [5] G. Bertoni et al., Efficient Software Implementation of AES on 32-Bit Platforms, Springer, 2003 [6] M. Dworkin, Recommendation for Block Cipher Modes of Operation, NIST Special Publication A, 2001, [7] Owen Harrison, John Waldron, Practical Symmetrical Key Cryptography on Modern Graphics Hardware, 17th USENIX Security Symposium, 2008, 13