Field Programmable Gate Arrays lassen sich ganz oder teilweise rekonfigurieren. Diese Fähigkeit kann man nutzen, um die Systemsicherheit elektronischer Schaltungen zu verbessern.
Verwirrung durch fliegenden Wechsel: Dynamisches Rekonfigurieren erschwert Angriffe auf FPGA-Bausteine erheblich.
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: 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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel Communications Group GmbH & Co. KG, Max-Planckstr. 7-9, 97082 Würzburg einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von redaktionellen Newslettern nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung, Abschnitt Redaktionelle Newsletter.
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: 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: 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: 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.
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.