MCU-basierte vs. FPGA-basierte Hardware-Vertrauensbasis: Design-Kompromisse für eingebettete Sicherheit

Table of contents

1. Einführung

2. Definitionen

3. MCU-basierte RoT: Stärken und Einschränkungen

4. FPGA-basiertes RoT: Fähigkeiten und Entwicklungskosten

5. Hybride Architekturen

6. Regulatorische Faktoren und Faktoren des Lebenszyklus

7. Auswahlkriterien für MCU, FPGA und Hybrid-RoT

7. Vergleichende Übersichtstabelle und Schlussfolgerung

Referenzen

1. Einleitung

Eingebettete Geräte werden zunehmend in Umgebungen eingesetzt, in denen robuste, hardwarebasierte Sicherheit unerlässlich ist: industrielle Steuerungen, IoT-Gateways, Telekommunikationsinfrastruktur und Automobilsysteme. Viele dieser Plattformen müssen über 10 bis 15 Jahre hinweg sicher und wartbar bleiben, oft unter gesetzlichen Auflagen, die langfristige Updates und die Behebung von Sicherheitslücken erfordern. 

Eine Hardware-Vertrauensbasis bietet: 

• unveränderliche Geräteidentität; 

• Schutz kryptografischer Schlüssel; 

• verifizierter Start und Firmware-Authentifizierung; 

• sichere Aktualisierungsmechanismen;

• Kontrolle des Gerätelebenszyklusstatus.

Derzeit gibt es zwei primäre Implementierungswege:

• MCU-basiertes HRoT: Sicherheit, die in Silizium mit fester Funktion verankert ist und vom Hersteller bereitgestellte sichere Boot-ROMs, Hardware-Beschleuniger und geschützten Speicher nutzt. 

• FPGA-basiertes HRoT: Sicherheit, die in rekonfigurierbarer Logik mit benutzerdefinierten Kryptografie-Engines, Laufzeitmonitoren und aktualisierbaren Funktionen implementiert ist. 

Dieser Artikel enthält prägnante Definitionen, vergleicht die technischen Auswirkungen der einzelnen Ansätze und skizziert Auswahlkriterien, die durch regulatorische und Lebenszyklus-Anforderungen unterstützt werden.

2. Definitionen

MCU-basierte Hardware-Vertrauensbasis

Eine Vertrauensbasis, die in einem sicheren Mikrocontroller implementiert ist, mit: 

• unveränderlichem Boot-ROM; 

• Krypto-Beschleuniger mit fester Funktion (z. B. AES-128/256, SHA-256, ECC); 

• eFuse/OTP-Geräteidentität; 

• Optionale Secure Enclave oder TrustZone-M-Isolation. 

Die Sicherheitsfunktionen hängen vom Design des Siliziumherstellers ab und können nicht über die verfügbaren Hardwareblöcke hinaus erweitert werden. 

FPGA-basierte Hardware-Vertrauensbasis

Eine Vertrauensbasis, die als benutzerdefinierte Logik innerhalb der FPGA-Struktur implementiert ist und in der Regel Folgendes umfasst: 

• Hardwaremodule für kryptografische Funktionen; 

• Sicherer Start des FPGA-Bitstroms (Verschlüsselung + Authentifizierung); 

• Laufzeitüberwachung (Erkennung von Spannungs-, Takt- oder Logikabweichungen); 

• Identität der physikalisch nicht klonbaren Funktion (PUF); 

• rekonfigurierbare oder aktualisierbare Krypto-Kerne (einschließlich neuer PQC-Algorithmen). 

Die Sicherheitsfunktionen hängen von der Qualität der HDL-Implementierung und dem Bitstream-Schutz ab. 

3. MCU-basierte RoT: Stärken und Einschränkungen

3.1 Vorteile

Geringer Stromverbrauch und niedrige Kosten
Sichere MCUs benötigen nur eine minimale Siliziumfläche und eignen sich daher für batteriebetriebene und kostensensible Designs. 

Vorhersehbares Ökosystem
Toolchains, Middleware und Sicherheitsbibliotheken (z. B. sichere Bootloader-Frameworks) sind ausgereift und werden von den Anbietern unterstützt. 

Geringere technische Komplexität
Bei der Firmware-Entwicklung entfallen HDL-Design, Timing-Closure und Side-Channel-bewusste Hardware-Entwicklung. 

3.2 Einschränkungen

Feste Hardware-Logik
MCU-Kryptobeschleuniger und Speicherarchitekturen sind statisch. Eine Aktualisierung der kryptografischen Primitive oder das Hinzufügen benutzerdefinierter Schutzmaßnahmen ist nicht möglich. 

Begrenzte Rechen- und Überwachungsfähigkeiten
MCUs können kryptografische Verfahren mit hohem Durchsatz, fortschrittliche Anomalieerkennung oder komplexe Gegenmaßnahmen gegen Seitenkanäle nicht effizient unterstützen. 

Lebenszyklusbeschränkungen
Geräte mit langer Lebensdauer können die Relevanz von fest in Silizium integrierten Beschleunigern überdauern, insbesondere angesichts der bevorstehenden Post-Quanten-Standards [NIST, 2025]. 

3.3 Risikobetrachtungen

• Sichere MCUs unterscheiden sich erheblich: Einige bieten nur eine grundlegende Schlüsselspeicherung, keine vollständige HRoT. 

• Eine falsch konfigurierte TrustZone-M hinterlässt Lücken in der Vertrauensgrenze. 

• Die Qualität des Siliziums des Herstellers wirkt sich direkt auf die Sicherheit aus. 

4. FPGA-basierte RoT: Funktionen und Entwicklungskosten

4.1 Vorteile

Anpassbarer Hardware-Vertrauensanker
Entwickler können dedizierte Hardware-Engines für Authentifizierung, Schlüsselableitung, sichere Updates und Zustandsmaschinen erstellen, die auf das Bedrohungsmodell des Systems zugeschnitten sind. 

Widerstandsfähigkeit gegen Seitenkanal- und physische Angriffe
Die FPGA-Logik unterstützt fein abgestimmte Gegenmaßnahmen wie Maskierung, Leistungsausgleich, asynchrone Logik oder Taktjitter-Einfügung – Optionen, die bei festen MCU-Chips nicht verfügbar sind. 

Kryptografische Beschleunigung zur Laufzeit
Im Gegensatz zu MCUs können FPGAs die Kryptografie während des Gerätebetriebs kontinuierlich beschleunigen. Dies kommt verschlüsselten Datenpipelines, authentifizierungsintensiven Protokollen und proprietären oder neuen Algorithmen zugute. 

Lebenszyklus und Post-Quanten-Anpassungsfähigkeit
Die rekonfigurierbare FPGA-Logik kann PQC-Kerne entsprechend der Weiterentwicklung von Standards aufnehmen und erfüllt damit langfristige Supportanforderungen. 

4.2 Einschränkungen

Potenziell höherer Stromverbrauch
FPGAs mittlerer und hoher Dichte verbrauchen mehr Strom als MCUs.  

Höhere technische Komplexität
Die Entwicklung eines sicheren FPGA-basierten HRoT erfordert HDL-Fachwissen, Kenntnisse im Bereich Timing Closure und Designpraktiken, die Side-Channel-Angriffe berücksichtigen. 

Verifizierungsaufwand
Die Sicherheitsvalidierung muss eine funktionale Verifizierung, eine Timing-Analyse, eine Bitstream-Authentifizierung und eine Leckagebewertung umfassen. 

4.3 Risikobetrachtungen

• Der Schutz des Bitstreams ist unerlässlich; die Sicherheit hängt von der Schlüsselbereitstellung und einer ordnungsgemäßen AES-GCM- oder CMAC-Authentifizierung ab. 

• Eine teilweise Neukonfiguration führt zu einer zusätzlichen Angriffsfläche. 

• Nicht gehärtete Krypto-Implementierungen können über Seitenkanäle undicht sein. 

5. Hybride Architekturen

Hybride Designs kombinieren: 

• MCU als unveränderlicher Vertrauensanker, der für sicheres Booten, Geräteidentität und Lebenszyklusstatus verantwortlich ist; 

• FPGA als Erweiterung für Kryptografie mit hohem Durchsatz, aufrüstbare PQC-Module, Laufzeitmonitore oder Protokoll-Offload. 

Diese Architektur ermöglicht es Entwicklern, die gesetzlichen Anforderungen an die Lebensdauer zu erfüllen und gleichzeitig die Stückliste und den Stromverbrauch unter Kontrolle zu halten. 

6. Regulatorische Faktoren und Faktoren im Lebenszyklus

IoT-, Industrie- und Telekommunikationsgeräte mit langem Lebenszyklus unterliegen zunehmend Vorschriften wie dem EU-Cyberresilienzgesetz (CRA), das von Herstellern Folgendes verlangt: 

• über mehrere Jahre hinweg Sicherheitsupdates bereitstellen; 

• Prozesse zum Schwachstellenmanagement aufrechterhalten; 

• sichere Update-Mechanismen gewährleisten. 

Dies verschiebt den Kompromiss beim Design: 

• MCU-only HRoT kann unzureichend sein, wenn feste Krypto-Blöcke veraltet sind. 

• FPGA oder Hybrid-HRoT ermöglicht langfristige Updates von Kryptografiemodulen und Laufzeitabwehrmechanismen. 

Die Einhaltung der Lebenszyklus-Compliance wird somit zu einem zentralen technischen Kriterium und nicht nur zu einer geschäftlichen Überlegung. 

7. Auswahlkriterien für MCU, FPGA und Hybrid-RoT

7.1 Geräteklasse und erwartete Lebensdauer

• Kurzlebige, batteriebetriebene Endgeräte → MCU. 

• Industrielle Steuerungen, Gateways, Telekommunikationsgeräte → FPGA oder Hybrid aufgrund von CRA-bedingten langfristigen Supportverpflichtungen. 

7.2 Bedrohungsmodell

• Standardmäßiger sicherer Start und Firmware-Integrität → MCU. 

• Physischer Zugriff, Seitenkanalrisiko, benutzerdefinierte Algorithmen → FPGA. 

• Gemischte Bedrohungsumgebungen → Hybrid. 

7.3 Aufrüstbarkeit

• Statische Sicherheitsanforderungen → MCU. 

• Notwendigkeit von PQC-Aktivierung oder programmierbarer Kryptografie → FPGA oder Hybrid. 

7.4 Leistung und Kosten

• Strenge BOM- und Energiebeschränkungen → MCU. 

• Moderates Leistungsbudget mit Bedarf an erweiterter Sicherheit → FPGA oder Hybrid. 

7.5 Technische Fähigkeiten

• Teams, die sich ausschließlich mit Firmware befassen → MCU. 

• Teams mit HDL- und Hardware-Sicherheitskenntnissen → FPGA. 

• Multidisziplinäre Teams → Hybrid. 

8. Vergleichende Übersichtstabelle und Schlussfolgerung

Die Wahl zwischen MCU-basierten, FPGA-basierten und hybriden HRoT-Implementierungen erfordert eine Bewertung der Lebenszyklusanforderungen, regulatorischen Verpflichtungen, Bedrohungslage, technischen Fähigkeiten und langfristigen kryptografischen Flexibilität.

Während MCUs nach wie vor optimal für kostengünstige und stromsparende Endgeräte sind, bieten FPGAs einen Weg zu maßgeschneiderter Hardwaresicherheit, Laufzeitbeschleunigung und PQC-Bereitschaft. Hybride Architekturen schließen die Lücke für Systeme, die sowohl einen stabilen, zertifizierten Vertrauensanker als auch eine leistungsstarke, aktualisierbare Sicherheitslogik benötigen. 

Referenzen

• [NIST, 2025] NIST-Standardisierung für Post-Quanten-Kryptografie. 
• [CRA, 2025] EU-Cyberresilienzgesetz – Regulatorische Anforderungen an die Produktsicherheit. 
• Sicherheit durch Design: Plug-and-Play-Hardware-Root-of-Trust mit dem M.2-FPGA-Modul von Promwad.

Lassen Sie uns Ihre Sicherheitsanforderungen besprechen

Vereinbaren Sie einen Beratungstermin mit unseren Hardware-Sicherheitsarchitekten

Wir unterstützen Gerätehersteller bei der Bewertung von MCU-, FPGA- und hybriden RoT-Optionen auf der Grundlage des Lebenszyklus, des Bedrohungsmodells und der gesetzlichen Anforderungen.

Kontaktieren Sie uns