Table of Contents

Das Imperativ von Secure Boot in Embedded IoT Security

Die Verbreitung von Geräten mit Internetanschluss in allen Branchen – von medizinischen Monitoren und industriellen Steuerungen bis hin zu Smart Metern und Home Automation Hubs – hat eine riesige Angriffsfläche geschaffen. Ein kompromittiertes Gerät am Rand kann als Zugang zu größeren Netzwerken dienen, Datendiebstahl ermöglichen oder physischen Schaden verursachen. Eine der grundlegendsten Abwehrmechanismen gegen solche Bedrohungen ist die Einrichtung einer vertrauenswürdigen Ausführungsumgebung ab dem Moment, an dem die Leistung angewendet wird. Secure Boot, ein Chain-of-Trust-Mechanismus, der jede Phase des Startprozesses kryptographisch überprüft, ist zu einer nicht verhandelbaren Anforderung für eingebettete IoT-Systeme in Produktionsqualität geworden.

Ohne sicheren Boot kann ein Angreifer mit physischem oder Softwarezugriff den Bootloader oder die Firmware durch eine bösartige Version ersetzen, die über Neustarts hinweg bestehen bleibt, eine Technik, die als "persistentes Rootkit" bekannt ist. Sobald das Gerät unter vom Angreifer kontrolliertem Code bootet, ist jede nachfolgende Schicht - Betriebssystem, Anwendungen und Daten - kompromittiert. Der sichere Bootvorgang verhindert nicht nur diese Klasse von Angriffen, sondern bietet auch die Grundlage für höhere Sicherheitsfunktionen wie authentifizierte Firmware-Updates, Fernbestätigung und Geräteidentität.

Was ist Secure Boot? Eine kryptographische Vertrauenskette

Kernprinzip: Verifizieren vor dem Vertrauen

Secure Boot ist ein hardwareerzwungener oder hardwareunterstützter Prozess, der sicherstellt, dass jeder Code, der nach einem Reset ausgeführt wird, authentisch und unbefugt ist. Er basiert auf einer root of Trust (RoT) – einer unveränderlichen Komponente, typischerweise einem Read-only-Masken-ROM oder einem dedizierten Sicherheitsmodul –, die einen oder mehrere öffentliche Schlüssel speichert. Während des Starts beginnt die root of Trust eine Verifizierungskette: Sie überprüft die digitale Signatur der nächsten Stufe (der Bootloader der ersten Stufe oder das Firmware-Image der zweiten Stufe), und so weiter, bis das Betriebssystem und der Anwendungscode geladen sind. Wenn eine Signaturprüfung in einer Phase fehlschlägt, stoppt der Bootprozess und das Gerät tritt in einen ausfallsicheren Zustand ein (z. B. Wiederherstellungsmodus oder permanenter Stein).

Kryptografische Grundlagen

Secure Boot verwendet asymmetrische Kryptographie (Public-Key-Infrastruktur oder PKI). Ein privater Schlüssel, der sicher in der Umgebung des Geräteherstellers aufbewahrt wird, signiert jedes Firmware-Image. Der entsprechende öffentliche Schlüssel wird im unveränderlichen Speicher des Geräts gespeichert. Während der Überprüfung berechnet der Bootloader einen Hash des Firmware-Images und vergleicht es mit dem entschlüsselten Signaturwert. Eine Übereinstimmung stellt sicher, dass das Bild vom Eigentümer des privaten Schlüssels signiert wurde und nicht verändert wurde Intransit oder Speicherung. Übliche Algorithmen sind RSA-2048/4096 und ECDSA (P-256/P-384). Die Hash-Funktion ist normalerweise SHA-256 oder SHA-384.

Unterscheiden von Secure Boot von anderen Boot-Sicherheitsfunktionen

Secure Boot wird oft mit gemessenem Boot verwechselt (in TPM-basierten Systemen wie Trusted Boot in Windows oder gemessenem Start in Linux verwendet). Während Secure Boot die Ausführung von nicht vertrauenswürdigem Code verhindert, zeichnet der gemessene Boot den gesamten ausgeführten Code in PCRs (Plattformkonfigurationsregister) eines TPM auf, ohne den Bootvorgang unbedingt zu stoppen. Authenticated Boot wird manchmal synonym mit Secure Boot verwendet, aber sorgfältige Anbieter unterscheiden zwischen den beiden: Authentifizierter Boot führt Prüfungen durch, kann aber das Gerät in einem eingeschränkten Modus fortsetzen. In diesem Artikel impliziert Secure Boot Durchsetzung - das Gerät bootet nicht, wenn die Überprüfung fehlschlägt.

Warum Secure Boot für Embedded IoT-Geräte wichtig ist

Physische und Remote-Angriffsrisiken

Eingebettete Geräte werden häufig in unbeaufsichtigten Umgebungen eingesetzt, in denen Angreifer physischen Zugriff auf Flash-Speicher, UART/JTAG-Ports oder Speicherchips erhalten können. Ohne sicheren Boot kann ein Angreifer eine modifizierte Firmware blinken, die Sicherheitssensoren deaktiviert, sensible Daten ausfiltert oder das Gerät in einen Botnet-Teilnehmer verwandelt. Selbst Fernangriffe, wie die Ausnutzung einer Netzwerkstack-Schwachstelle zur Ausführung von beliebigem Code, können persistent werden, wenn der Angreifer in Flash schreiben kann.

Regulierungs- und Industriemandate

Regierungen und Industrieverbände verlangen zunehmend einen sicheren Boot für vernetzte Geräte. Der EU Cyber Resilience Act , Kaliforniens SB-327 (IoT-Sicherheitsgesetz) und die NISTIR 8259 Richtlinien betonen alle die Integrität des Geräts vom Boot. Gesundheitsgeräte mit FDA-Zulassung erfordern oft einen sicheren Boot, um die Sicherheitsstufen IEC 62304 und SWaP zu erfüllen. Für Hersteller, die in regulierte Märkte verkaufen möchten, ist der sichere Boot nicht mehr optional.

Kernkomponenten eines Secure Boot Systems

Hardware Root of Trust (RoT)

Die RoT ist der Anker der gesamten Vertrauenskette. Sie muss unveränderlich sein (kann nicht durch Software verändert werden) und eine sichere Umgebung für die Speicherung kryptographischer Schlüssel bieten.

  • Read-only Memory (ROM) bootloader – Ein kleines Programm, das während der Herstellung in den Chip programmiert wurde. Es enthält den öffentlichen Schlüssel und die erste Verifizierungslogik. Diese sind am sichersten, da sie nach der Herstellung nicht überschrieben werden können.
  • Trusted Platform Module (TPM) – Ein dedizierter Sicherheitschip, der RSA/ECC-Operationen ausführen, Schlüssel speichern und versiegelten Speicher bereitstellen kann.
  • Secure Element (SE) – Ähnlich wie ein TPM, aber oft für Geräte mit geringem Stromverbrauch, mit kleinem Formfaktor entwickelt. Es läuft normalerweise mit einer Java Card oder einem nativen Applet zur sicheren Boot-Verifizierung.
  • ARM TrustZone / Intel CSE / AMD PSP – On-Chip-Isolation, die eine vom normalen Betriebssystem getrennte "sichere Welt" schafft. Die in dieser Welt laufende Firmware kann einen sicheren Boot- und Wartungsvorgang für Schlüsselmaterial in hardwaregesicherten Sicherungen durchführen.

Signieren von Schlüsseln und Zertifikatshierarchie

Groß angelegte IoT-Bereitstellungen verwenden eine dreistufige PKI: eine Root CA (offline, selten verwendet), eine Zwischensignierungs-CA und gerätespezifische Schlüsselpaare. In vielen Implementierungen speichert das Gerät nur den Root CA Public Key (oder seinen Hash) als RoT. Alle Firmware-Images werden vom Zwischenschlüssel signiert und das Gerät überprüft die Signaturkette des Zwischenzertifikats zurück zum Root. Diese Architektur ermöglicht das Entziehen kompromittierter Zwischenschlüssel, ohne das unveränderliche RoT zu ersetzen. Key Management ist die wichtigste Betriebslast: Der Verlust des privaten Schlüssels bedeutet, dass alle Firmware-Updates unmöglich werden.

Bootloader und Verifikationsstufen

Der Bootprozess ist in mehrere Phasen unterteilt, um jede Stufe klein genug zu halten, um in On-Chip-ROM oder sicheren Speicher zu passen, während gleichzeitig ein komplexes Betriebssystem geladen werden kann:

  • Stage 0 (ROT) – ROM-Code lädt den Bootloader der ersten Stufe (FSBL) und überprüft seine Signatur.
  • Stufe 1 (FSBL) – Initialisiert DRAM, lädt den Bootloader der nächsten Stufe (wie U-Boot oder einen proprietären Loader) aus Flash und überprüft seine Signatur.
  • Stage 2 (SSBL) – Initialisiert den Gerätebaum, lädt den Betriebssystemkernel (Linux, Zephyr, FreeRTOS, etc.) und überprüft die Kernel-Bildsignatur.
  • Stage 3 (OS Kernel) – Nach der Kernelausführung kann die vertrauenswürdige Ausführungsumgebung (TEE) Benutzerraumanwendungen verifizieren oder signierte Kernelmodule laden.

Jede Stufe reduziert die Angriffsfläche, da die vertrauenswürdige Rechenbasis erst nach Verifizierungsdurchgängen wächst.

Schritt-für-Schritt-Implementierungshandbuch für Embedded IoT

Schritt 1: Definieren Sie das Bedrohungsmodell und die Vertrauensgrenzen

Vor der Implementierung analysieren Sie den physischen Einsatz des Geräts, die Netzwerkverbindung und den Wert der Daten, die es verarbeitet. Beispielsweise kann ein batteriebetriebener Sensor, der nur über BLE kommuniziert, ein anderes Risikoprofil aufweisen als eine sicherheitskritische industrielle SPS. Das Bedrohungsmodell bestimmt die erforderliche Stärke des RoT, die Schlüsselgröße und ob der Widerruf unterstützt werden muss.

Schritt 2: Wählen Sie eine Hardware-Plattform mit sicheren Boot-Funktionen

Nicht alle Mikrocontroller unterstützen sicheren Boot. Wählen Sie einen Chip mit einem unveränderlichen ROM-Bootloader, On-Chip-Schlüsselspeicher (z. B. eFuses oder OTP NVRAM) und einem eingebauten Hardware-Kryptobeschleuniger. Zu den führenden Anbietern, die robuste sichere Boot-Lösungen anbieten, gehören:

  • NXP i.MX RT und i.MX 8/9 Serie – Hochsicherer Boot (HAB) mit SHA-256 und RSA; unterstützt verschlüsselte Boot-Images.
  • STM32MP1 / STM32H7 – STM32 sicherer Boot mit X-CUBE-SBSFU (Secure Boot and Secure Firmware Update).
  • Mikrochip SAM L10/L11 – TrustZone und sicherer Boot mit Schlüsselschutz im manipulationssicheren Speicher.
  • Espressif ESP32-C3/S3 – Sicherer Boot V2 mit digitaler Signaturverifizierung, Unterstützung für Flash-Verschlüsselung.
  • Renesas RA Family – Sichere Crypto Engine (SCE) und sicherer Boot mit Schlüsselschutz.
  • ARM Cortex-M33/M55 – TF-M (Trusted Firmware-M) Referenzimplementierung mit sicherem Boot.
  • Intel / AMD x86 IoT Prozessoren – UEFI Secure Boot und Boot Guard (versteckter On-Die-Schlüssel).

Wenn der gewählte SoC keine Hardware-RoT enthält, können Sie ein diskretes TPM (z. B. Infineon SLB9670) oder ein sicheres Element (Mikrochip ATECC608A) hinzufügen. Externe Hardware-RoTs sind teurer, bieten jedoch Upgrade-Fähigkeit.

Schritt 3: Generieren und Speichern der Wurzel des Vertrauens

Während der Geräteherstellung muss jedes Gerät seinen eindeutigen oder gemeinsamen Root-Public-Key in den unveränderlichen Speicher programmiert haben. Für die Produktion mit hohem Volumen verwenden die meisten Hersteller einen Flash-on-Produktion-Ansatz, bei dem der öffentliche Schlüssel als einmalige Operation in eFuses geblasen wird. Der private Schlüssel wird niemals der Fabrikhalle ausgesetzt; die Signatur wird offline auf einem Build-Server in einer gesicherten Enklave durchgeführt. Codieren Sie denselben Schlüssel nicht auf allen Geräten fest, wenn dieser Schlüssel extrahiert wird, werden alle Geräte anfällig. Verwenden Sie eindeutige Schlüssel pro Gerät oder mindestens pro Charge mit Widerrufsfunktion.

Schritt 4: Signieren Sie die Firmware-Bilder

Richten Sie eine CI/CD-Pipeline ein, die alle freigegebenen Firmware-Images mit dem entsprechenden privaten Schlüssel signiert. Für jede Firmware-Version generiert das Build-Script eine Binärdatei, berechnet den SHA-256/384-Hash und fügt die RSA-2048/4096- oder ECDSA-Signatur hinzu. Viele Anbieter-SDKs bieten Signatur-Tools an; für benutzerdefinierte Bootloader können Sie verwenden und die Signatur für den Ziel-Bootloader formatieren.

Wichtig: Signieren Sie nicht nur die Firmware-Nutzlast, sondern auch deren Metadaten (z. B. Versionsnummer, Ziel-Hardware-ID, Bildlänge). Dies verhindert Rollback-Angriffe, bei denen ein Angreifer auf eine ältere, anfällige Firmware-Version zurückgreift. Anti-Rollback-Schutz wird in der Regel durch die Speicherung der minimal zulässigen Version in einem sicheren Zähler (z. B. monotoner Zähler im TPM- oder OTP-Speicher) implementiert.

Schritt 5: Konfigurieren Sie den Bootloader zur Verifizierung

Customizing U-Boot (Linux-basierte Systeme)

Aktivieren Sie für Systeme, die U-Boot verwenden, CONFIG CHAIN OF TRUST und CONFIG VERIFICATION INSECURE und stellen Sie den öffentlichen Schlüssel-Blob bereit. U-Boots verified boot (VBOOT) Mechanismus unterstützt verifizierte Bilder mit Metadaten (obligatorisch für Versionsrollback).

Mit MCUBoot (für RTOS oder Zephyr)

MCUBoot ist der De-facto-Standard für sicheres Booten auf ARM Cortex-M und ähnlichen Mikrocontrollern. Es unterstützt die Signaturverifizierung mit RSA, ECDSA und ist mit Bildverschlüsselung konfigurierbar. MCUBoot integriert sich in die Zephyr RTOS-Bootkette und arbeitet mit externem Flash. Seine Architektur unterstützt Dual-Image-Swaping (A/B-Update-Mechanismus) und einen Single-Image-Slot mit Fehlerwiederherstellung.

Anbieterspezifische Bootloader

Für NXP i.MX konfigurieren Sie den HAB (High Assurance Boot) über das CST-Tool. Für STM32 verwenden Sie X-CUBE-SBSFU, das sowohl sicheres Boot- als auch sicheres Firmware-Update in einem einzigen Paket enthält. Für ESP32 aktivieren Sie CONFIG SECURE BOOT V2 in der Menükonfiguration und führen das Signaturskript aus .

Schritt 6: Implementieren Sie das sichere Firmware-Update Over-the-Air (FOTA)

Der sichere Bootstart ist nur so stark wie sein Update-Mechanismus. Wenn ein Angreifer über einen OTA-Kanal nicht signierte Firmware einfügen kann, wird die Überprüfung beim nächsten Booten durch den sicheren Boot abgefangen, aber es könnte eine Denial-of-Service-Bedingung entstehen. Der Updateprozess selbst muss die Signatur überprüfen, bevor er in die Boot-Partition schreibt. Die empfohlene Architektur ist ein dual-bank (A/B)-Update:

  • Bank A läuft aktuelle Firmware; Bank B ist leer oder hält die letzte bekannte gute Version.
  • Der Bootloader bootet von der Bank mit der höchsten Version, die die Signaturprüfung besteht.
  • Wenn ein OTA-Update fehlschlägt (Checksumme oder Signatur ungültig), kehrt der Bootloader zur anderen Bank zurück und erhält die Gerätefunktionalität.
  • Bei erfolgreichem Update setzt der Bootloader ein Flag, um von der neuen Bank zu booten.

Alle Updates müssen mit dem gleichen (oder verketteten) privaten Schlüssel signiert werden. immer benötigen versionsbasierte Nonce oder monotonen Zähler, um Wiederholungsangriffe zu verhindern, bei denen ein älteres signiertes Bild wiedergegeben wird.

Real-World Implementierungsarchitekturen

ARM TrustZone-M (Cortex-M23/M33) mit TF-M

Trusted Firmware-M (TF-M) bietet eine Referenzimplementierung eines sicheren Boots, eines sicheren Partitionsmanagers und eines sicheren Firmware-Updates für ARMv8-M-Systeme. Der Bootloader (BL2) von TF-M arbeitet neben MCUBoot und unterstützt Bildsignierung, Verifizierung und Anti-Rollback. Der sichere Partitionsmanager (SPM) isoliert den Anwendungscode auch nach dem Booten in "sicheren" und "nicht sicheren" Welten.

AMD/Ryzen Embedded + PSP + UEFI Secure Boot

High-End-Embedded-Systeme verwenden x86 UEFI Secure Boot (gemäß Definition in Microsofts Secure Boot-Spezifikation für Windows) in Kombination mit Platform Secure Processor (PSP) Hardware. UEFI Secure Boot verifiziert den EFI-Bootloader mit Plattformschlüsseln (PK, KEK), die in UEFI Non-Volatile RAM gespeichert sind. Für IoT-Bereitstellungen ist UEFI Secure Boot komplex, aber notwendig für Geräte, auf denen Windows IoT oder bestimmte Linux-Fans mit Shim ausgeführt werden.

NXP i.MX Hochsicherheitsboot (HAB)

Der HAB von NXP wird in Automobil- und Industriegeräten weit verbreitet eingesetzt. Er verwendet einen "Super Root Key" (SRK) Hash, der in sicheren Sicherungen gespeichert ist. Das Boot-ROM überprüft die CSF (Command Sequence File), die digitale Signaturen für jedes Bild enthält. HAB Version 4 unterstützt verschlüsselte Bilder und mehrere SRK-Tabelleneinträge für die Schlüsselrotation. Die Signierwerkzeuge (CST) sind frei verfügbar, erfordern jedoch eine sorgfältige Verwaltung der Schlüsselspeicherdatei (PKI-Baum).

Gemeinsame Herausforderungen und wie man sie mildert

Komplexität des Schlüsselmanagements

Die größte Hürde ist der Schutz des privaten Schlüssels während des gesamten Produktlebenszyklus. Best Practices: Verwenden Sie einen HSM (Hardware Security Module) oder einen Cloud-basierten Schlüsseldienst (AWS CloudHSM, Azure Key Vault) für Signiervorgänge. Drehen Sie Zwischenschlüssel regelmäßig. Implementieren Sie eine Schlüsselzeremonie, die mehrere autorisierte Unterzeichner erfordert. Fügen Sie für den Feldentzug eine Widerrufsliste als Teil der signierten Metadaten hinzu und überprüfen Sie sie während des Bootens.

Wiederherstellung von Bricked Devices

Wenn Flash beschädigt ist oder ein Update falsch installiert wird, kann das Gerät das Booten verweigern. Abschwächungen: fügen Sie einen sekundären minimalen Bootloader in einen schreibgeschützten Speicher ein, der einen Wiederherstellungsmodus über eine physische Taste, eine serielle Schnittstelle oder USB-DFU einleiten kann. Einige SoCs haben eine "Force Recovery" -Sicherung, die den sicheren Boot zu Reparaturzwecken umgeht - aber dies öffnet ein Fenster für physische Angriffe, wenn sie nicht richtig gesteuert werden.

Performance und Boot Time Overhead

Die Überprüfung der asymmetrischen Signatur kann Hunderte von Millisekunden dauern, insbesondere bei MCUs mit geringem Stromverbrauch ohne Hardware-Kryptobeschleuniger. Verwenden Sie ECDSA über RSA für kleinere Signaturen und schnellere Überprüfung. Viele Anbieter enthalten dedizierte Krypto-Engines, die Verifizierungsoperationen in weniger als 10 ms für eine 256-Bit-ECDSA-Signatur durchführen. Messen und optimieren Sie die Verifizierung jeder Stufe; verschieben Sie schwere Operationen (wie Hash-Berechnung) nach der DRAM-Initialisierung, wenn die signierten Daten klein sind.

Fehlende Einheitlichkeit der Industrie

Jeder SoC-Anbieter hat eine proprietäre sichere Boot-Implementierung. Entwickler müssen jedes Mal die spezifische Toolchain und das Skript lernen. Mit einem Open-Source-Bootloader wie MCUBoot oder U-Boot werden einige dieser Unterschiede abstrahiert. Standardisierungsbemühungen durch die Trusted Computing Group (TCG) und GlobalPlatform vereinheitlichen schrittweise Boot-Sicherheits-APIs (z. B. TAM – TCG Attestation Model, PSA Certified Level 2/3).

Verbessern des sicheren Boots mit komplementären Technologien

Sicherer Boot-Boot allein schützt nicht vor Laufzeitangriffen, Seitenkanal-Leckagen oder kompromittierten Update-Servern.

  • Hardware-erzwungene Isolation (z.B. ARM TrustZone, Intel SGX oder RISC-V PMP), um Schlüssel im Speicher auch nach dem Booten zu schützen.
  • Signierter und verschlüsselter Speicher (Flash-Verschlüsselung), um das Extrahieren von Schlüsseln oder Firmware-Binärdateien zu verhindern.
  • Remote attestation – das Gerät beweist seine Identität und die Integrität seiner Boot-Kette gegenüber einem Cloud-Server (z. B. mit DICE – Device Identifier Composition Engine).
  • Runtime Integritätsüberwachung – periodische Überprüfungen kritischer Coderegionen und Konfigurationsregister.
  • Vertrauenswürdige Ausführungsumgebungen (TEE), um sensible Operationen wie Schlüsselgenerierung oder kryptographische Logik in einer isolierten Welt zu hosten, auch nachdem das Betriebssystem gestartet wurde.

Future Directions: z.B. DICE, PSA Certified und Integrated Security

Die Device Identifier Composition Engine (DICE) Architektur, definiert durch die TCG, verwendet ein einfaches Hardwaregeheimnis, genannt Unique Device Secret (UDS), das für jeden Chip einzigartig ist. Beim Booten leitet die ROM-Schicht einen kryptographischen Schlüssel ab, der an die Firmware-Identität bindet. Jede Änderung der Firmware ändert den abgeleiteten Schlüssel, was ein automatisches sicheres Booten und Beglaubigen ohne einen vorgefertigten öffentlichen Schlüssel ermöglicht. DICE ist ideal für hochvolumige, kostengünstige Geräte, bei denen die PKI-Verwaltung zu teuer ist.

PSA Certified (Plattform-Sicherheitsarchitektur) bietet ein Framework für die Erstellung und Zertifizierung von IoT-Geräten mit Sicherheitsstufen von 1 (Grundschutz) bis 3 (Hardwareisolierung). Level 2 verlangt sicheres Booten, während Level 3 physische Manipulationsresistenz erfordert. Die Verwendung von PSA-zertifizierten Chips und die Einhaltung der Richtlinien reduziert das Designrisiko und erhöht das Vertrauen der Käufer.

In zunehmendem Maße wird Secure Boot direkt in das Silizium in Form von "sicheren Enklaven" auf Chipebene integriert, die alle Authentifizierungs- und Schlüsselspeicher abwickeln. Da die Kosten für diese Funktionen sinken, werden selbst die kostengünstigsten IoT-SoCs voraussichtlich mit unveränderlichem ROM und On-Die-Schlüsselspeicher ausgeliefert.

Fazit: Machen Sie Secure Boot zur ersten Verteidigungslinie

Die Implementierung von Secure Boot in Embedded IoT-Geräten ist kein triviales Unterfangen, aber es ist die wichtigste Kontrolle gegen dauerhafte Firmware-Manipulation. Durch die Einrichtung einer Hardware-verankerten Vertrauenskette können Hersteller sicherstellen, dass jedes Gerät nur in authentifizierter, unmodifizierter Firmware bootet. Der Prozess erfordert eine sorgfältige Auswahl der Hardware mit einer geeigneten Vertrauenswurzel, sorgfältiges Schlüsselmanagement und Integration mit sicheren Firmware-Update-Mechanismen. Der Aufwand zahlt sich aus in Form eines reduzierten Risikos von Kompromissen, der Einhaltung neuer Vorschriften und der Fähigkeit, vertrauenswürdige Updates über die gesamte Lebensdauer des Geräts zu liefern. Da die IoT-Angriffsfläche weiter wächst, bietet Secure Boot die grundlegende Integrität, von der alle anderen Sicherheitsmaßnahmen abhängen.

Für weitere Informationen lesen Sie NIST SP 800-193: Platform Firmware Resiliency, die TCG DICE Spezifikation und PSA Certified Richtlinien.