Suchen

FPGAs: Mehr Sicherheit durch dynamische partielle Rekonfiguration

Autor / Redakteur: Alexander Krutwig * / Michael Eckstein

Field Programmable Gate Arrays lassen sich ganz oder teilweise rekonfigurieren. Diese Fähigkeit kann man nutzen, um die Systemsicherheit elektronischer Schaltungen zu verbessern.

Firmen zum Thema

Verwirrung durch fliegenden Wechsel: Dynamisches Rekonfigurieren erschwert Angriffe auf FPGA-Bausteine erheblich.
Verwirrung durch fliegenden Wechsel: Dynamisches Rekonfigurieren erschwert Angriffe auf FPGA-Bausteine erheblich.
(Bild: gemeinfrei / Pixabay )

FPGAs sind für viele Applikationen unverzichtbare Komponenten. Doch die flexiblen System-on-Chip-Bausteine (SoC) haben Schwachstellen, die sie unter Umständen angreifbar machen. Zwar gibt es für viele Szenarien Gegenmaßnahmen, doch sind diese meist statisch und daher mit überschaubarem Aufwand überwindbar. Besser geeignet sind dynamische Gegenmaßnahmen: Diese verändern das Angriffsziel immer wieder und unvorhersehbar, was Angriffe erheblich erschwert.

Möglich ist zum Beispiel, Algorithmen auf dem FPGA lokal zu verschieben oder durch funktional gleichwertige Implementierungen zu ersetzen, die den Rhythmus und die Angriffspunkte des Angreifers unterbrechen sollen. Akteure in einem vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Forschungsprojekt SECREC evaluieren derzeit solche dynamischen Gegenmaßnahmen gegen eine Attacke auf einen Kryptoalgorithmus. Diese sollen die bisher verwendeten statischen Verfahren ergänzen.

Kryptographische Algorithmen in Gefahr

Implementierungen von Algorithmen auf FPGAs bieten einige Vorteile wie gute Erweiterbarkeit und Flexibilität. Allerdings müssen diese Implementierungen sicher genug sein, um die verwendete IP (Intellectual Property) und sensible Daten – etwa im vermeintlich sicheren On-Board-Speicher hinterlegte Schlüssel – zuverlässig schützen zu können.

Ausgerechnet kryptografische Algorithmen sind in statischen Embedded-Systemen in Gefahr: Selbst wenn die implementierten Verschlüsselungsverfahren aus mathematischer Sicht ausreichend sicher sind, kann ein Angreifer Zusammenhänge zwischen Stromverbrauch, Rechenzeit oder elektromagnetischer Abstrahlung mithilfe von Seitenkanalangriffen ermitteln. Daraus kann er Rückschlüsse auf den verwendeten Algorithmus ziehen, die Systemsicherheit möglicherweise aushebeln und an sensible Daten wie eben hinterlegte private Schlüssel gelangen.

Vielfältige Möglichkeiten für Angriffe auf FPGAs

Angriffe auf FPGAs und ihre Gegenmaßnahmen lassen sich in drei Gruppen aufteilen: Seitenkanalangriffe, Fehlerinjektionsangriffe sowie Reverse Engineering/Modification. Nicht-invasive Seitenkanalangriffe zielen nicht auf das Beeinflussen der Kryptoalgorithmen auf den FPGAs zur Laufzeit. Vielmehr entschlüsseln sie quasi die Schaltung, indem sie Kenngrößen wie Zeitverhalten, Energieverbrauch oder die elektromagnetische Abstrahlung beobachten. Fehlerinjektionsangriffe (invasive Angriffe) zielen hingegen auf das Auslösen von Bitkippern während der Programmausführung ab. Diese lassen sich auf unterschiedliche Weise provozieren, etwa indem die Schaltung außerhalb der spezifizierten Frequenzen betrieben wird und so Taktungenauigkeiten (Glitching) entstehen.

Auch der Betrieb unter- oder oberhalb der definierten Spannungsgrenzen kann eine Schaltung aus dem Tritt bringen, ebenso wie gezielte Photoneninjektionen, also das Bestrahlen mit einem Laserstrahl. Die ersten beiden Typen invasiver Angriffe lassen sich mit geringem Aufwand durchführen, wohingegen der letztgenannte Angriff umfangreichere Ausrüstung sowie gute Vorkenntnisse über das Layout der Schaltung zum Festlegen des Angriffspunktes voraussetzt. Beim Reverse Engineering analysieren Angreifer die Netzliste, um daraus Rückschlüsse auf das Design zu ziehen.

Statische Gegenmaßnahmen alleine reichen nicht aus

Ziel ist es, sicherheitsrelevante Komponenten zu identifizieren und in Zusammenhang zu bringen, um den Hardwareschutz einer Schaltung zu manipulieren oder Trojaner einzuschleusen, die über den Zustand der Schaltung Auskunft geben können. Zu den beschriebenen Angriffen gibt es auch Gegenmaßnahmen. Diese sind aber größtenteils statisch, was grundsätzlich eine Schwäche in der Verteidigungslinie ist. So ist es möglich, Seitenkanalangriffe über Maskierung (Ausführen der Algorithmen mit maskierten Eingabewerten), Verbergen (zufällige Berechnungen durch Dummy-Module, um Pausen oder zusätzliches Rauschen zu erzeugen) oder Fresh Rekeying (Erzeugung von neuen Schlüsseln, die aus verwendeten Schlüsseln erzeugt werden) zu erschweren.

Bild 1: Bei einer Seitenkanalattacke werden Stromspuren oder elektromagnetische Abstrahlungen während der Verschlüsselungsvorgänge perOszilloskop gemessen und mit einem PC ausgewertet.
Bild 1: Bei einer Seitenkanalattacke werden Stromspuren oder elektromagnetische Abstrahlungen während der Verschlüsselungsvorgänge perOszilloskop gemessen und mit einem PC ausgewertet.
(Bild: VCG)

Fehlerinjektionsangriffe können durch fehlererkennende und -korrigierende Codes im laufenden Betrieb entdeckt und gegebenenfalls behoben werden. Infective Computing ist eine Mischung der beiden genannten Verfahren. Es zerstört beim Entdecken eines Fehlers den Output des Algorithmus durch Zufallswerte. Eine Bitstream-Verschlüsselung oder das Verschleiern der Netzliste kann Reverse Engineering erheblich erschweren. Da ein FPGA die Möglichkeit bietet, Komponenten durch andere Komponenten funktionell gleichwertig zu ersetzen (z.B. XOR-Gate durch eine Kombination von AND-Gates und OR-Gatter), versucht man durch eine kompliziertere Netzliste den Aufwand für den Angreifer zu erhöhen.

Dynamische Rekonfiguration für AES-Verschlüsselung

Bild 5: Die AES-Verschlüsselung ist ein rundenbasierter Kryptoalgorithmus. Abhängig von der Schlüssellange dauert die Verschlüsselung 10, 12 oder 14 Runden. Die Eingangsnachricht wird mit einem Rundenschlüssel verrechnet und die Bytes durch mathematische Methoden vertauscht.
Bild 5: Die AES-Verschlüsselung ist ein rundenbasierter Kryptoalgorithmus. Abhängig von der Schlüssellange dauert die Verschlüsselung 10, 12 oder 14 Runden. Die Eingangsnachricht wird mit einem Rundenschlüssel verrechnet und die Bytes durch mathematische Methoden vertauscht.
(Bild: Mixed Mode)

Bei FPGAs ist es möglich, die geladene Schaltung im laufenden Betrieb auszutauschen, den Baustein also dynamisch zu rekonfigurieren. Die meisten modernen FPGAs sind zudem in der Lage, nur bestimmte, im Design gezielt gekennzeichnete Teile der Schaltung zu verändern. Dieses Verfahren nennt sich dynamische partielle Rekonfiguration. Der Vorteil liegt auf der Hand: Das für den Angreifer nicht vorhersehbare, teilweise wiederholte Verändern seines Ziels und dessen Eigenschaften macht alle erschlichenen Erkenntnisse nutzlos.

Als Studienobjekt für die Evaluierung wird die AES-Verschlüsselung (Advanced Encryption Standard) untersucht. Sie wurde 2001 entwickelt und ein Jahr später zu einem Standardverfahren für Verschlüsselung erklärt. AES nimmt fixe Eingangsblockgrößen von 128 Bits (16 Bytes) und verschlüsselt diese mit einem Schlüssel einstellbarer Länge (128, 192 oder 256 Bits). Dieser kryptographische Algorithmus wird skriptgesteuert mit Daten versorgt und zunächst über einen Seitenkanalangriff beobachtet: Dazu erfasst ein elektromagnetischer Sensor, der an einer Entkopplungskapazität einer Stromversorgungsleitung (Power Line) des FPGAs anliegt, die Abstrahlung über die Ausführungszeit, die auf einem Oszilloskop dargestellt wird.

Bild 2: Bei einem partiell rekonfigurierbaren Projekt bleibt der statische Teil während der Ausführung unverändert, die Implementierungen in der dynamischen partiellen Partition können hingegen während der Laufzeit ausgetauscht werden.
Bild 2: Bei einem partiell rekonfigurierbaren Projekt bleibt der statische Teil während der Ausführung unverändert, die Implementierungen in der dynamischen partiellen Partition können hingegen während der Laufzeit ausgetauscht werden.
(Bild: Mixed Mode)

Statischer Teil wird initial über das Gesamt-Bitfile geladen

Um ein Design dynamisch partiell rekonfigurieren zu können, muss die Logik im FPGA in je einen statischen und einen rekonfigurierbaren Teil getrennt werden. Der statische Teil bleibt während der gesamten Zeit unverändert und wird initial über das komplette Bitfile in den FPGA geladen. Der rekonfigurierbare Teil kann ein oder mehrere Module enthalten, die gegen Module mit gleichen Interfaces (also gleiche Inputs und gleiche Outputs) ausgetauscht werden können. Dies geschieht über partielle Bitfiles (.bin-Files), deren Größe nur einen Bruchteil der Größe eines kompletten Bitfiles beträgt. Die Rekonfiguration kann während der Laufzeit erfolgen. Allerdings darf die Rekonfiguration nicht während der Ausführung des Kryptoalgorithmus durchgeführt werden.

Durch die partielle Rekonfiguration ergeben sich mehrere Möglichkeiten, Angriffe zu erschweren. So ist es möglich, die AES-Verschlüsselung (beziehungsweise Teile davon) in verschiedenen Varianten zu implementieren, die sich zwar in Laufzeit und Stromverbrauch unterscheiden, aber funktional gleichwertig sind. Das Umladen kann per Trigger angestoßen werden. Dieser sollte zufällig und nicht-deterministisch ausgelöst werden, um einen effektiven Schutz gegen Seitenkanalgriffe sicherzustellen. Dafür eignet sich ein echter Zufallsgenerator (z.B. ein Ringoszillator), der den Umladevorgang nach einer zufälligen Zahl von Verschlüsselungsvorgängen oder einem nicht vorhersehbaren Zeitintervall anstößt.

Dummy-Module sollen Angreifer in die Irre führen

Eine weitere Möglichkeit besteht darin, neben einem echten AES-Algorithmus mehrere Dummy-Module des gleichen Interfaces zu definieren, die alle voneinander unabhängige partielle Partitionen auf dem FPGA sind. Über einen Trigger können die Module untereinander in die anderen Partitionen umgeladen werden. Somit werden neben der Veränderung des Ortes des echten Verschlüsselungsmechanismus (Erschwerung von Fehlerinjektionsattacken) durch die Verwendung von Dummy-Modulen auch Seitenkanalangriffe erschwert, indem sie Rauschen erzeugen und Strom verbrauchen.

Bild 3: Hardwareaufbau eines Designs zur partiellen Rekonfiguration. Der Vorgang wird über einen PRC (Partial Reconfiguration Controller) gesteuert. Der Trigger kann per Hardware oder Software erfolgen.
Bild 3: Hardwareaufbau eines Designs zur partiellen Rekonfiguration. Der Vorgang wird über einen PRC (Partial Reconfiguration Controller) gesteuert. Der Trigger kann per Hardware oder Software erfolgen.
(Bild: Mixed Mode)

Bei einer parallelen AES-Implementierung ist es möglich, für jede S-box (Substitution box, Grundkomponente symmetrischer Kryptosysteme) eine individuelle Implementierung zu konfigurieren; das bedeutet, für den Schritt der Bytesubstitution werden 16 S-boxen verwendet, damit jedes Byte gleichzeitig ausgetauscht werden kann. Durch die unterschiedlichen Timings der Module werden Seitenkanalangriffe erheblich erschwert. Zudem ist es generell möglich, lokale Constraints – also Bedingungen, die zwingend vom Wert einer Variablen erfüllt werden müssen – für die partiellen Partitionen festzulegen, um diese auf bestimmten Power Lines zu bündeln oder von diesen fernzuhalten.

Aus den hier skizzierten grundlegenden Verfahren lässt sich eine Vielzahl anderer Szenarien generieren. Ziel ist es, den Rhythmus und das Timing des Angreifers zu unterbrechen, sodass zukünftig prinzipiell ein breites Spektrum von Abwehrmaßnahmen zur Verfügung stehen kann.

Technische Umsetzung und Automatisierung

Das Laden der partiellen Bitströme in den FPGA steuert ein Rekonfigurationscontroller (PRC) von Xilinx. Hardware- und Softwaretrigger lösen den Ladeprozess aus, wobei ein Programm auf einem Mikrocontroller (extern oder als SoC kombiniert, z.B. Zynq Ultrascale+) die Softwaretrigger einspielt. Als Interface dient der ICAP (Internal Configuration Access Port), eine Art eingebetteter Mikrocontroller, der den FPGA-Speicher über einen internen Port lesen und schreiben kann. Wichtig ist, dass das komplette sowie alle partiellen Bitfiles müssen in einem sicheren Speicher (Secure Storage) liegen. Für den gesicherten Kommunikationsweg wird die ARM TrustZone mit Peta Linux evaluiert.

Unter Beteiligung des Autors ist ein Framework entstanden, das sowohl die Bibliotheken und Designs verwaltet als auch die automatisierte Generierung von gesamten und partiellen Bitstreams steuert. Es vervollständigt das von Xilinx bereitgestellte Tcl-Interface für den Vivado Non-Project Flow. Eine Adminstrationsschicht um die Quelldateien und den Tcl Non-Project Flow teilt die Dateien in Bibliotheken, Designs und Workflowkonfigurationen auf. In den Designs ist es zudem möglich, durch Anmerkungen im HDL-Code Konfigurationen anzugeben, die während der Laufzeit ausgewertet und in den Build-Vorgang miteinbezogen werden.

Modulares Framework ermöglicht weitreichende Anpassungen

Bild 4: Die Blöcke des Python SECREC-Frameworks sind in Grün und die Schritte des Tcl Non-Project Flows in Gelb dargestellt. Innerhalb dieses Flows kann ein User vor jedem größeren Schritt seine eigenen Skripte einbinden (z.B. Variantengenerierung).
Bild 4: Die Blöcke des Python SECREC-Frameworks sind in Grün und die Schritte des Tcl Non-Project Flows in Gelb dargestellt. Innerhalb dieses Flows kann ein User vor jedem größeren Schritt seine eigenen Skripte einbinden (z.B. Variantengenerierung).
(Bild: Mixed Mode)

Der Aufbau des Frameworks ist so modular gestaltet, dass es die Möglichkeit besitzt, innerhalb des Tcl Non-Project Flows Hook-Skripte einzubauen, die bestimmte Benutzerbefehle wie Variantengenerierung ausführen. Zudem ist es möglich, für architekturabhängige HDL-Designs verschiedene Toolchains anzusprechen, etwa Quartus für Intel-FPGAs oder Simulations-/Verifikations-Frameworks. Über die Konfigurationsdateien des Workflows können alle relevanten Parameter für den Designbuild, z.B. austauschbare Module sowie deren Varianten, angegeben werden, sodass nach Ausführung der Build-Automatisierung die Reports und Design Checkpoints der einzelnen Prozessschritte sowie komplette und partielle Bitfiles vorliegen. Das Framework ist in Python geschrieben.

Am Forschungsprojekt SECREC sind beteiligt: Das Deutsche Forschungszentrum für Künstliche Intelligenz GmbH in Bremen, die Robert Bosch GmbH in Renningen, Mixed Mode GmbH in Gräfelfing, Friedrich-Alexander-Universität Erlangen-Nürnberg sowie das FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie in Karlsruhe. Erste Ergebnisse der dynamischen Gegenmaßnahmen sind vielversprechend.

Weiterführende Lesetipps

Dieser Beitrag ist erschienen im Sonderheft Embedded Systems Development und Internet of Things I der ELEKTRONIKPRAXIS (Download PDF)

* Alexander Krutwig ist er technischer Leiter des BMBF-Forschungsprojekts SECREC bei Mixed Mode in Gräfelfing

(ID:46294158)