Die weltweite Verflechtung der

Transkript

1 AES in FPGAs Implementierung des Advanced Encryption Standards in Hardware Der Rijndael-Algorithmus ist Bestandteil einer Vielzahl zentraler Applikationen für den verschlüsselten Datenaustausch sowie aktueller Datenformate (XML). Für die Speicherung oder die Übertragung großer Datenmengen müssen die Verschlüsselungsalgorithmen in Hardware realisiert werden. In FPGAs lässt sich der Algorithmus als IP-Core schnell und kostengünstig bei geringem Platzbedarf implementieren. Von Eilert Backhus, Harald Würfel, Oliver Riesener und Prof. Dr. Stefan Wolter Die weltweite Verflechtung der Wirtschafts- und Gesellschaftssysteme erfordert die zunehmende Realisierung offener, verteilter und vernetzter Systeme zur Erfassung, Übermittlung, Verarbeitung und Speicherung von Informationen. Mit der Zunahme von weltumspannenden elektronischen Informationssystemen steigt auch die Gefahr des Verlustes der Verfügbarkeit, Integrität und der Vertraulichkeit von Informationen [1]. Die Nutzer moderner Informations- und Kommunikationssysteme fordern daher Sicherheitstechniken u.a. gegen folgende Grundbedrohungen: Verlust der Integrität des Systems durch unerlaubten Zugriff auf die Daten bzw. durch Veränderung von Informationen. Verlust der Verfügbarkeit durch vorsätzliche Beeinträchtigung der Funktionalität oder Vorenthaltung von Informationen. Verlust der Vertraulichkeit durch unbefugte Kenntnisnahme. Verlust der Authentizität durch Vortäuschen einer falschen Identität. Mit kryptologisch abgesicherten Verfahren kann solchen Bedrohungen wirksam begegnet werden. Beim fortschreitenden Trend zur Vernetzung ist die Kryptographie die Schlüsseltechnologie zur Nutzung kostengünstiger Übertragungsmedien auch für vertrauliche Daten. Mit veralteten Algorithmen, wie z.b. DES, können verschlüsselte Daten aber inzwischen mit der Rechenleistung eines handelsüblichen PC entschlüsselt werden. Daher hatte das NIST (National Institute of Standards and Technology) 1997 einen Wettbewerb ausgeschrieben. Unter der Bezeichnung AES sollte ein neuer symmetrischer Blockchiffrieralgorithmus a0,0 a0,1 a0,2 a0,3 a1,0 a1,1 a1,2 a1,3 geschaffen werden, der allen heutigen Sicherheitsanforderungen genügt, in allen Design- und Implementierungsaspekten öffentlich bekannt und weltweit lizenzkostenfrei nutzbar ist. Im Oktober 2000 setzte sich der Algorithmus Rijndael von Joan Daemen und Vincent Rijmen aus Belgien gegen 14 konkurrierende Algorithmen durch und wurde unter der Bezeichnung Advanced Encryption Standard (AES) am 26. November 2001 veröffentlicht [2] und freigegeben. Die Kernanforderungen an den AES waren wie folgt definiert: Blockgröße N b = 128 bit. Variable Schlüssellängen 128, 192 und 256 bit. Mindestens so schnell und sicher wie Triple-DES. Über den Standard hinaus bietet der Rijndael-Algorithmus noch weitere Blockgrößen von 192 bit und 256 bit. Der AES-Algorithmus Der AES unterliegt im Gegensatz zum früheren DES keinen Exportbeschränkungen. Damit kann er ohne Genehmigungen weltweit eingesetzt werden. Bereits jetzt gibt es Anwendungen, in denen er genutzt wird, und es ist zu erwarten, dass er in wenigen Jahren zum ultimativen symmetrischen Chiffrierverfahren geworden ist. Der Algorithmus wird z.b. in [3, 4] sehr ausführlich beschrieben. Weitere Informationen über den mathematischen Hintergrund des Algorithmus findet man auch bei [5]. Daher wird hier nur ein Überblick für das grundlegende Verständnis gegeben. Als Beispiel dient eine Schlüssellänge von 128 bit in der Betriebsart Electronic Codebook (ECB). Daraus folgt laut AES-Spezifikation eine Rundenzahl N r = 10 und eine Rundenschlüsselgröße N k = 4. a (i,j) b (i,j) Bild 1. Symbol und Ablauf der Transformation SubBytes (Substitution). b1,0 b1,1 b1,2 b1,3 b2,0 b2,1 b2,2 b2,3 b3,0 b3,1 b3,2 b3,3 In der Terminologie von Rijndael wird ein Datenblock in seinem jeweiligen Bearbeitungsstand als Zustand (engl. State) bezeichnet. Ein Zustand besteht aus einem Feld von 16 byte Größe. Jede Transformation innerhalb einer Runde nimmt Änderungen an dem Zustand vor. Die Bytes werden in einer Matrix angeordnet, in der jede Spalte bzw. Zeile zusammen 32 bit ergeben. Für den AES ergibt sich so eine Zustandsmatrix der Dimension 4 4. Der Index i kennzeichnet die Zeilennummer, der Index j die Spaltennummer. Rijndael ist aus einzelnen Transformationsschichten aufgebaut, die nacheinander unterschiedliche Wirkungen auf jeweils einen gesamten Datenblock ausüben. In Klammern sind die Namenserweiterungen für die 54 Elektronik 8/2003

2 Kryptographie Kommunikation Zyklische Verschiebungsweite C(i) a0,0 a0,1 a0,2 a0,3 C(0) = 0 a1,0 a1,1 a1,2 a1,3 C(1) = 1 C(2) = 2 C(3) = 3 Bild 2. Symbol und Ablauf der Transformation ShiftRows (Permutation). b1,3 b1,0 b1,1 b1,2 b2,2 b2,3 b2,0 b2,1 b3,1 b3,2 b3,3 b3,0 2. Transformation ShiftRows Die Bytes des internen 128-bit-Datenblocks werden zeilenweise verschoben (Bild 2). Hierbei erfolgt eine Permutation innerhalb der Zeilen der Zustandsmatrix. Dazu werden die Bytes innerhalb der Zeilen (ausgenommen die der ersten Zeile) zyklisch verschoben. Bei der Entschlüsselung wird diese Verschiebung wieder rückgängig gemacht. Transformationsbezeichnungen der Entschlüsselung angegeben. Lineare Schichten: Die (Inv)Shift- Rows- und (Inv)MixColumns-Transformationen sorgen für eine optimale Permutation und Diffusion der Bits eines internen Datenblocks. Nichtlineare Schichten: Die (Inv)S- Box-Substitution ist eine nichtlineare Operation. Die Konstruktion der (Inv)S- Box sorgt für eine nahezu ideale Konfusion und sie bietet daher sehr guten Schutz vor differentieller und linearer Kryptoanalyse. Schlüsseladdition: Durch die Verknüpfung mit dem Originalschlüssel vor (Verschlüsselung) bzw. nach (Entschlüsselung) dem Durchlauf der einzelnen Runden und innerhalb jeder Runde mit dem jeweiligen Rundenschlüssel wirken sich die Schlüsseladditionen auf jedes Bit der Rundenergebnisse aus. Es gibt im Verlauf der Ver- bzw. Entschlüsselung eines internen Datenblocks keinen Schritt, dessen Ergebnis nicht in jedem Bit vom Schlüssel abhängig wäre. Die Erfinder von Rijndael haben für jede dieser Transformationen ein Symbol geschaffen. Mit diesen Symbolen kann der Aufbau des Algorithmus sehr übersichtlich dargestellt werden. gekehrter Reihenfolge durchgeführt. Außerdem muss eine inverse affine Transformation verwendet werden: Inverse affine Transformation Berechnung der multiplikativen Inversen Die affine Transformation besteht aus einer Multiplikation des Eingangsvektors mit einer Matrix M und anschließender Addition eines konstanten Vektors c. Da die tatsächliche Berechnung der multiplikativen Inversen aber relativ aufwendig ist, wird der gesamte Vorgang der Byte-Substitution in einer zusammengefasst, die üblicherweise als ROM implementiert wird. Den ROM-Inhalt findet man z.b. in [4]. a0,0 a0,1 a0,2 a0,3 a1,0 a1,1 a1,2 a1,3 3. Transformation MixColumns Auf jede Spalte der Zustandsmatrix wird eine Diffusion, durch Multiplikation jeder Spalte mit einer konstanten Matrix, angewendet (Bild 3). Durch die MixColumns-Transformation tritt jedes Byte einer Spalte in Wechselwirkung mit jedem anderen Byte der Spalte. Für die Entschlüsselung besitzt die Matrix, mit der die Spalten multipliziert werden, andere Werte [3, 4, 5] a0,j a1,j a2,j a3,j = b0,j b1,j b2,j b3,j b1,0 b1,1 b1,2 b1,3 b2,0 b2,1 b2,2 b2,3 b3,0 b3,1 b3,2 b3,3 1. Transformation SubBytes Jedes Byte der Zustandsmatrix wird durch eine so genannte umgewandelt (Bild 1). Die Byte-Substitution, die in einer durchgeführt wird, besteht für die Verschlüsselung aus zwei Berechnungsschritten: Berechnung der multiplikativen Inversen Affine Transformation Bild 3. Symbol und Ablauf der Transformation MixColumns (Diffusion). a0,0 a0,1 a0,2 a0,3 a1,0 a1,1 a1,2 a1,3 Für Runde i und Schlüssellänge 128 bit: Rundenschlüssel i. Nk + j j = 0 j = 1 j = 2 j = 3 k0,0 k0,1 k0,2 k0,3 k1,0 k1,1 k1,2 k1,3 k2,0 k2,1 k2,2 k2,3 = b1,0 b1,1 b1,2 b1,3 b2,0 b2,1 b2,2 b2,3 Für die Entschlüsselung wird die inverse Byte-Substitution benötigt. Dabei werden die Berechnungsschritte in um- k3,0 k3,1 k3,2 k3,3 Bild 4. Symbol und Ablauf der Transformation AddRoundkey (Addition). b3,0 b3,1 b3,2 b3,3 4. Transformation: AddRoundkey Der jeweilige Rundenschlüssel wird mit dem internen Datenblock bitweise XOR-verknüpft (Bild 4). Für die Verschlüsselung eines Datenblocks werden in Abhängigkeit von der Schlüswww.elektroniknet.de Elektronik 8/

3 Chiffrierschlüssel Schlüssel-Byte (0) Schlüssel-Byte (1) Schlüssel-Byte (2) Schlüssel-Byte (3) Schlüssel-Byte (4) Schlüssel-Byte (4. Nk - 1) Bild 5. Umwandlung vom Chiffrierschlüssel zu den ersten N k Rundenschlüsseln. Zur Bildung des Rundenschlüssel- Arrays wird der Chiffrierschlüssel zunächst in 32-bit-Worte aufgeteilt, die gleichzeitig die ersten Elemente des Arrays sind. Rundenschlüssel 0 Rundenschlüssel 1 Rundenschlüssel 2 Rundenschlüssel N k - 1 Rundenschlüssel-Array Byte 0 Byte 1 Byte 2 Byte 3 Rundenschlüssel 0 Rundenschlüssel 1 Rundenschlüssel 2 Rundenschlüssel N k - 1 sellänge 10, 12 oder 14 Runden benötigt. Dementsprechend wird für jede Runde ein anderer Rundenschlüssel benötigt. Die Rundenschlüssel werden aus dem Chiffrierschlüssel abgeleitet. Diese Ableitung wird weiter unten beschrieben. Die Rundenschlüssel für die Entschlüsselung müssen in umgekehrter Reihenfolge aus dem Rundenschlüssel-Array ausgelesen werden. Erzeugung der Rundenschlüssel Die Art der Erzeugung der Rundenschlüssel ist relevant für die Sicherheit eines krypthographischen Verfahrens. Bei Rijndael werden aus dem Chiffrierschlüssel Rundenschlüssel gebildet, deren Anzahl um 1 größer sein muss als die Anzahl der Runden. Jeder Rundenschlüssel hat die Größe eines Datenblocks. Die Rundenschlüssel bilden ein Array aus 32-bit-Worten. So benötigt man für den AES mit 128 bit Blocklänge und 10 Runden ein Array mit 44 i = 1 Modify 1 Rundenschlüssel N k Rundenschlüssel N k + 1 Rundenschlüssel N k + 2 Rundenschlüssel 2. Nk - 1 Elementen: (10 + 1) 128/32 = 44 (Bild 5). Die ersten vier Elemente sind der Schlüssel für die den Runden vorausgehende XOR-Verknüpfung mit den Eingangsdaten, und für jede Runde bilden je vier weitere Elemente aus dem Array den Schlüssel für die XOR-Verknüpfung am Rundenende. Zur Bildung des Rundenschlüssel-Arrays wird der Chiffrierschlüssel in 32-bit-Worte aufgeteilt, die gleichzeitig die ersten Elemente des Arrays sind. Das daran anschließende Element wird aus der XOR-Verknüpfung des ersten und des modifizierten letzten Elements des aufgeteilten Chiffrierschlüssels gebildet. Die Folgeelemente entstehen aus dem jeweils 2-ten bis N-ten Element des aufgeteilten Chiffrierschlüssels und dem vorangegangenen Element durch XOR-Verknüpfung (Bild 6). Die Modifikation des letzten Elements aus dem Chiffrierschlüssel läuft folgendermaßen ab: Zunächst wird das Element um ein Byte nach links rotiert. Dann wird jedes Bild 6. Schema der Expansion der zusätzlichen (N r N k )-Rundenschlüssel für N k 6. Byte durch die ersetzt. Das höchstwertige Byte dieses so erhaltenen Zwischenwerts wird mit einer Rundenkonstante XOR-verknüpft. Die Rundenkonstanten beginnen mit dem Wert 1 (x 0 ) für die Runde 1, für jede folgende Runde wird die vorangegangene Konstante mit 2 (x 1 ) multipliziert (Linksschieben). Wenn der Überlauf erreicht wird, muss der Wert wieder i = 2 Modify 1 Rundenschlüssel 2. Nk Rundenschlüssel 2. Nk + 1 Rundenschlüssel 2. Nk + 2 Modify 1 : Rundenschlüssel 3. Nk - 1 Bild 7. Modifikationsmodul für den N k -ten Rundenschlüssel. Die Bytes werden mit der Operation RotByte rotiert; zum dann höchstwertigen Byte (Byte 1) wird anschließend der in der Tabelle abgelegte Wert der Rundenkonstante RC(i) addiert. Rundenkonstante (i) auf ein Byte reduziert werden. Dafür wird der resultierende Wert modulo des irreduziblen Polynoms m(x) = x 8 +x 4 +x 3 +x 1 +x 0 genommen. Da diese Operationen zur Bestimmung der Rundenkonstanten sehr aufwendig sind, aber nur eine kleine Zahl von Rundenkonstanten benötigt wird, liegt es nahe, diese in einer kleinen Tabelle abzuspeichern, die durch einen Rundenzähler indiziert wird. Dieses Verfahren gilt für Schlüssel bis 192 byte Länge (N k 6). Bei längeren Schlüsseln werden zusätzlich Arrayelemente über en umgewandelt, bevor sie XORverknüpft werden, und zwar immer dann, wenn der Arrayzähler modulo Byte 0 Byte 1 Byte 2 Byte 3 RotByte Byte 1 Byte 2 Byte 3 Byte 0 i RC (i) 0 00h 1 01h 2 02h 3 04h 4 08h 5 10h 6 20h 7 40h 8 80h i RC (i) 9 1Bh 10 36h 11 6Ch 12 D8h 13 ABh 14 4Dh 15 9Ah der Schlüsselwortanzahl den Wert 4 ergibt (Bild 7). Die AES-Runde Auch der AES ist, wie viele andere Algorithmen zur symmetrischen Verschlüsselung, rundenbasiert. Das heißt, die gleichen Operationen werden mehrmals hintereinander auf die zu verschlüsselnden Daten angewendet. Beispielhaft für die Verschlüsselung (128 bit Schlüssel- und Datenblocklänge) wird die Abfolge der Transformationen innerhalb einer regulären Runde schematisch in Bild 8 veranschaulicht. Dabei ist zu beachten, dass vor der ersten Runde bereits eine XOR- Verknüpfung der Eingangsdaten mit dem ersten Rundenschlüssel N k (0) stattfindet und in der letzten Runde keine MixColumns-Transformation durchgeführt wird (irreguläre Runde). Zur Entschlüsselung werden sämtliche 56 Elektronik 8/2003

4 SubBytes ShiftRows MixColumns AddRoundkey Bild 8. Die Abfolge der Transformationen in einer regulären AES-Runde. Operationen der Verschlüsselung in ihrer Umkehrform (Inv) und in umgekehrter Reihenfolge durchlaufen (Bild 8 und Bild 9). Betriebsarten für Blockchiffrieralgorithmen Für Blockchiffrieralgorithmen wie Rijndael, IDEA etc. gibt es neben der bereits beschriebenen Electronic Code Book -Betriebsart (ECB) noch weitere Betriebsarten. Vom NIST sind die Betriebsarten Cipher Block Chaining (CBC), Output Feed Back (OFB), Cipher Feed Back (CFB) und Counter (CTR) in [7] standardisiert. Für alle optionalen Betriebsarten wird neben dem Schlüssel ein Initialisierungsvektor oder, Ausgangsdatensenke Eingangsdatenquelle Runde 1 Rundenschlüssel-Array 0 Rundenschlüssel-Array 1 Runden 2 bis N r - 1 (identisch mit Runde 1) Runde N r Ohne MixColumns! Rundenschlüssel-Arrays 2 bis N r - 1 Rundenschlüssel-Array N r Rundenschlüssel im Falle der CTR-Betriebsart, ein Zählwert benötigt. Diese Werte werden je nach Betriebsart auf unterschiedliche Art mit dem Datenstrom verknüpft. In der CBC-Betriebsart wird z.b. der erste Eingangsdatenwert mit dem Initialisierungsvektor XOR-verknüpft, danach verschlüsselt und der daraus resultierende Ausgangsdatenwert als Initialisierungsvektor für den nächsten Eingangsdatenwert verwendet. In der CFB-Betriebsart wird zuerst der Initialisierungsvektor verschlüsselt und dann mit dem ersten Eingangsdatenwert XOR-verknüpft. Dieser Wert wird dann als neuer Initialisierungsvektor für den nächsten Eingangsdatenwert verwendet. FPGA-Architektur Abgesehen von den en können sämtliche Stufen einer AES-Runde innerhalb von einem oder zwei Look Up Tables (LUT) pro Bit untergebracht werden, und ein Rundenregister- Flipflop teilt sich den Slice mit den LUTs. Gleiches gilt für die der ersten Runde vorgeschaltete Rundenschlüsseladdition. Um Ressourcen zu sparen, wird der AES-Algorithmus in den meis- Bild 9. Der Ablauf der gesamten AES-Verschlüsselung. Bereits vor der ersten Runde findet eine XOR-Verknüpfung der Eingangsdaten mit dem ersten Rundenschlüssel N k (0) statt; in der letzten Runde wird keine MixColumns-Transformation durchgeführt (irreguläre Runde). Zur Entschlüsselung werden sämtliche Operationen in ihrer Umkehrform (Inv) und in umgekehrter Reihenfolge durchlaufen. Die OFB-Betriebsart arbeitet ähnlich wie die CFB-Betriebsart. Unterschiedlich ist, dass der verschlüsselte Initialisierungsvektor direkt als neuer Initialisierungsvektor für den nächsten Eingangsdatenwert verwendet wird. In der CNT-Betriebsart wird anstelle des Initialisierungsvektors ein Zähler verwendet. Der Zähler muss weder bei Null beginnen noch einschrittig hochgezählt werden. Dadurch wird die Unvorhersagbarkeit gewahrt. Der Zählwert wird verschlüsselt und mit dem Eingangsdatenwert XOR-verknüpft. Die Entwicklung eines AES-Cores für FPGAs Ein wichtiger Aspekt bei der Auswahl von Rijndael für den AES war die einfache Realisierbarkeit des Algorithmus in Hard- und Software. Wobei mit einfach in diesem Falle platzsparend gemeint ist. Da gängige FPGAs schon seit einiger Zeit in mehreren Millionen Gatteräquivalenten verfügbar sind, bietet sich eine Implementierung für diese Bausteine geradezu an. Dabei kann der Algorithmus leicht in den nicht ausgenutzten Teilen eines größeren FPGA- Designs untergebracht werden, und alte Kryptocores können durch einen AES-Core ersetzt werden, ohne dass die Hardware (Leiterplatte, Bausteingröße) verändert werden muss. Im Internet findet sich eine Reihe von Quellcodes für den Rijndael-Algorithmus. Die meisten dieser Quellen können aber höchstens als Anregung verstanden werden, da sie entweder nicht richtig synthetisierbar sind oder nur Teile des Algorithmus umfassen. Zur Entwicklung eines Cores kann man sich daran orientieren, Anpassung auf die jeweilige Zielarchitektur und Optimierung der Modelle sind allerdings noch sehr aufwendig. 58 Elektronik 8/2003

5 Clock AES_Ready AES_Start Bild 10. Datenfluss im I3M-AES-Core. InputValid Input (15...0) v_16 AES_Running OutputValid Output (15...0) v_16 ten Fällen iterativ realisiert; d.h., dass nur die Hardware einer Runde implementiert wird und die Daten diese Hardware in Abhängigkeit von der Rundenanzahl N r wiederholt durchlaufen. Dazu wird neben einem Controller in Form einer Zustandsmaschine (Finite State Machine) zur Rundensteuerung und Schlüsselzuordnung auch ein Multiplexer benötigt, der zwischen den neuen Eingangswerten und zurückgekoppelten Daten umschaltet. Die meisten AES-Cores benötigen daher 11 Takte für die Verschlüsselung eines Blocks mit den oben genannten Beispielparametern. Durch geschickte Wahl der Lage des Multiplexers kann man die Latenzzeit auf 10 Takte reduzieren, ohne den Bedarf an Slices signifikant zu erhöhen (Bild 10). Die Xilinx-Architektur unterstützt außerdem die platzsparende Implementierung von Zustandsmaschinen mit One State Hot -Codierung. Da bei solchen Zustandsmaschinen die Zustandogik auch meist in eine Look Up Table passt, kann diese dann dem Zustandsregister im selben Slice zugeordnet werden. Der Controller im Blockschaltbild des Cores ist ausschließlich für den kryptographischen Teil zuständig. Die Interfaceblöcke besitzen ihre eigenen unabhängigen Controller. Dadurch ist es möglich, auch während der laufenden Ver- oder Entschlüsselung Daten mit weniger als 128 bit Busbreite ein- und auszugeben, ohne dass der Core angehalten werden muss. Außerdem können die Ein- und Ausgabeblöcke durch dieses modulare Konzept beliebig modifiziert werden, ohne den kryptographischen Teil verändern zu müssen. en Eigenschaften i3m_aes_ _00 i3m_aes_ _00 Operation VerschlüsselungEntschlüsselung Betriebsart ECB ECB Schlüssellänge 128 bit 128 bit Eingangsbusbreite 16 bit 16 bit Ausgangsbusbreite 16 bit 16 bit Pipeliningnein nein Taktzyklen 10 Takte 10 Takte pro Operation Zieltechnologie Xilinx Virtex-E Xilinx Virtex-E Produkt XCV100E-CSS144 XCV400E-PQ240 Geschwindigkeitsstufe 8 8 Logik-Ressourcen 854 Slices / 1340 LUTs 1203 Slices / 2047 LUTs Anzahl der Block-RAMs 10 8 max. Taktfrequenz 119 MHz 67,5 MHz max. Datenrate 1532 Mbit/s 864 Mbit/s Syntheseergebnisse für die Ver- und Entschlüsselung in den AES-Cores des I3M. Auch andere Hersteller bieten für jede Betriebsart einen extra Core an; ein Multi-Betriebsarten-Core ist in der Regel weniger leistungsfähig als ein Core, der nur eine Betriebsart beherrscht. Die Bytesubstitution der Rijndael- wird in allen bekannten FPGA-Cores mit ROMs implementiert, die die Substitutionstabelle beinhalten. Daneben gibt es noch die Möglichkeit, die Substitutionswerte aus den Eingangswerten zu errechnen. Es gibt mehrere Algorithmen, die diese Aufgabe lösen können. Sie unterscheiden sich hinsichtlich Platzbedarf und Datendurchsatz. Wenn man nur den AES als Applikation für sich betrachtet, verfügen die passenden FPGAs in der Regel über genügend Speicherblöcke zur Aufnahme der Substitutionstabellen. Stellt die Verschlüsselung innerhalb des FPGA nur eine untergeordnete Funktion dar und belegt die Hauptfunktion die RAM-Ressourcen soweit, dass die en dort nicht mehr implementiert werden können, dann bieten algorithmische Verfahren gute Alternativen für die Implementierung der. Für die Architektur der Xilinx-Virtex-Serie ergibt sich beispielsweise, dass eine Implementierung der - Tabelle in optimierter Logik 293 Slices (29 ns) und als Distributed-RAM 144 Slices (16 ns) belegen würde. Die am I3M der Hochschule Bremen untersuchten algorithmischen Lösungen benötigen lediglich 77 bis 110 Slices, dafür aber bis zu 16 Takte (Tabelle). Die Taktrate liegt je nach Algorithmus zwischen 74 MHz und 150 MHz. Wenn in einem Design der Platzbedarf des AES-Cores ohne Block-RAMs also Priorität gegenüber der Durchsatzrate hat, kann durch die Wahl des geeigneten Algorithmus ein sehr feiner Abgleich zwischen Platzbedarf und Durchsatzrate durchgeführt werden. Die kleinste erreichbare Durchsatzrate bei maximal möglicher Taktfrequenz liegt dabei immer noch im Bereich von ca. 70 Mbyte/s (ca. 550 Mbit/s). Core-Übersicht Neben den AES-Cores des I3M gibt es auch AES-Cores verschiedener anderer Anbieter. Die Cores unterscheiden sich hinsichtlich der Interfaces und der Anzahl der Optionen (Schlüsselbreite, Betriebsart). Meist wird für jede Betriebsart ein extra Core angeboten. Das rührt daher, dass die zusätzliche Hardware zur Umschaltung zwischen den Betriebsarten zu längeren Pfaden auf dem Chip führt, wodurch die maximale Taktfrequenz deutlich herabgesetzt wird. Da dies unmittelbar die maximale Durchsatzrate des Cores herabsetzt, wirkt ein Multi-Betriebsarten- Core in den Datenblättern weniger leistungsfähig als ein Core, der nur eine Betriebsart beherrscht. Im großen und ganzen ähneln sich die Cores mit gleichen Eigenschaften in Flächenbedarf und Durchsatzrate sehr, da die Variationsbandbreite in der Umsetzung sich praktisch auf das Interface beschränkt. Es ist auch zu beachten, dass der Entschlüsselungs-Core aufgrund der aufwendigeren Erzeugung des Rundenschlüssels grundsätzlich größer ausfällt als der Verschlüsselungs- Core. 60 Elektronik 8/2003

6 Kryptographie Kommunikation Reset Clock EncDec KeySize LoadKey LoadKeyBusy KeyLoaded ModeSelect LoadInit LoadInitBusy InitLoaded AES_Ready AES_Start AES_Running InputValid Eingansdaten 2 2/3 16 Eingangs- Interface Controller (Zustandsmaschine) Encoder/ Decoder Ausgangs- Interface 16 Schlüsselverarbeitung Output- Valid Ausgangsdaten ten Möglichkeiten, die sonst nur mit hohem Aufwand realisiert werden könnten. Beispielsweise kann in einer Anwendergruppe mit einem gemeinsamen Schlüssel trotzdem jeder Anwender von einer Zentrale vertrauliche Daten empfangen, wenn jeder Anwender seinen persönlichen Initialisierungsvektor (z.b. in Form einer Endgeräteseriennummer) besitzt. Ein solches Netzwerk zur Datenverteilung wäre weniger empfindlich gegen die Offenlegung eines Schlüssels, da zusätzlich der Initialisierungsvektor des Endteilnehmers bekannt sein müsste. jw Bild 11. Die Blockschaltung des I3M-AES-Cores zeigt die einfache Struktur; der Encoder/ Decoder und die Schlüsselverarbeitung werden von einem als Zustandsmaschine auführbaren Controller gesteuert; die Daten werden über einen 16 bit breiten Bus durch das Eingangs- und das Ausgangs-Interface ausgetauscht. Der passende Core für den im oben beschriebenen AES-Algorithmus (siehe Datenblatt und Simulationsmodell unter [6]) diene hier als Beispiel, um die Unterschiede in Flächenbedarf und Datendurchsatz zwischen Ver- und Entschlüsselung aufzuzeigen (Bild 11). Einsatzmöglichkeiten Überall dort, wo mittlere bis große Datenmengen vor unbefugter Einsichtnahme geschützt werden müssen, können FPGAs mit AES-Cores die Ver- und Entschlüsselung der Daten mit geringem Hardware-Aufwand zeitsparend durchführen. Jedes Telekommunikationsgerät und jedes Speichermedium kann von dieser Technologie profitieren, da die Cores, um die benötigten Interfaces ergänzt, schon eine Applikation für sich darstellen. Weiterhin kann man FPGA-Applikationen mit AES- Cores erweitern, um modernen Sicherheitsaspekten gerecht zu werden. Auch die zusätzlichen Betriebsarten beinhal- Literatur [1] Buchmann, J.: Einführung in die Kryptographie. Springer Verlag [2] Federal Information Processing Standards Publication 197 (NIST FIPS PUB 197), [3] Daemen, J.; Rijmen, V.: The Design of Rijndael. Springer Verlag [4] Homepage von Vincent Rijmen: kuleuven.ac.be/~rijmen/rijndael/ [5] Buchholz, J.J.: Matlab Implementation of the Advanced Encryption Standard. 2002, aes.htm [6] Homepage des I3M: [7] NIST Special Publication A: Recommendation for Block Cipher Modes of Operation Dipl.-Ing. Eilert Backhus studierte Elektrotechnik an der Hochschule Bremen. Von 1992 bis 2000 arbeitete er am Zentrum für angewandte Raumfahrttechnik und Mikrogravitation (ZARM). Danach wechselte er zur Hochschule Bremen, wo er seitdem im Studiengang Mikrosystemtechnik das Labor für den Entwurf integrierter Schaltungen und Systeme betreut. Dipl.-Ing. Harald Würfel studierte Automatisierungstechnik an der Hochschule Bremen. Von 1985 bis 2000 arbeitete er als System-Ingenieur für CAD/CAE im Bereich Militärelektronik bei STN Atlas Elektronik in Bremen. Danach wurde er Wissenschaftlicher Mitarbeiter des BMBF-Forschungsprojekts VHDL Softcores für den Advanced Encryption Standard (AES) an der Hochschule Bremen. Jetzt ist er dort Betreuer für die Labore der Studienrichtung Informationstechnik im Studiengang Elektrotechnik. Oliver Riesener ist Betreuer für das Labor für den Entwurf von Mikrosystemen und Systemadministrator im Studiengang Mikrosystemtechnik an der Hochschule Bremen. Prof. Dr.-Ing Stefan Wolter ist Professor an der Hochschule Bremen und vertritt die Gebiete Mikroelektronik und Signalverarbeitung. Er ist Leiter des Labors für den Entwurf integrierter Schaltungen und Systeme. Kontakt zu den Autoren über internet/contacts/ Elektronik 8/