Sicherheit in Hardware Hardware-Root-of-Trust: TPM 2.0 & Co.

Anbieter zum Thema

Bürklin GmbH & Co. KG

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

Security-by-Design verlangt heute integrierte Hardware-Sicherheit: Ohne einen Hardware Root of Trust sind Embedded-Systeme, IoT-Geräte oder Fahrzeugsteuerungen nicht mehr abzusichern. Mit dem EU Cyber Resilience Act und Normen wie IEC 62443 oder ISO/SAE 21434 wird Hardware-basierte Sicherheit zudem zur Voraussetzung für Compliance.

Reine Software-Sicherheitsmechanismen reichen nicht aus, um Missbrauch zu verhindern. Firmware-Manipulationen, Supply-Chain-Angriffe und Schadcode-Injection in Bootloader oder Kernel zeigen, dass Vertrauen auf der Hardware-Ebene beginnen muss. Genau hier setzt das Konzept des Hardware Root of Trust (HRoT) an – einer unveränderlichen Vertrauensebene, die bereits beim Einschalten des Geräts aktiv wird.

„Bis jetzt wurden fast alle vernetzten Geräte ohne echte grundlegende Sicherheit gebaut und sind daher durch heimtückische Cyberangriffe sowohl in der Silizium-Lieferkette als auch nach der Bereitstellung im Feld verwundbar“, enthüllt Dominic Rizzo, Gründer und CEO von zeroRISC. Das nordamerikanische Startup bietet die ersten quelloffenen Silizium-Chips mit hardwarebasierten „Root of Trust“-Komponenten (HRoT) an mit einer Secure-Boot-Umgebung für Geräte der IoT-Infrastruktur, Mainboards und Netzwerkkarten. Die Sicherheitsarchitektur entstand in Zusammenarbeit mit Experten der ETH Zürich und des Max Planck Instituts im Rahmen des OpenTitan-Projektes und ist kryptografisch bereits postquantenfähig.

Bildergalerie

Vertrauen ab Werk

Die IEC 62443-4-2 beschreibt Sicherheitsanforderungen für Komponenten industrieller Automatisierungs- und Steuerungssysteme – darunter Authentisierung, Integrität, Vertraulichkeit und Schutz kryptografischer Schlüssel, während die IEC 62443-3-3 die Systemebene abdeckt. Weder ein Secure Boot noch ein Hardware Root of Trust werden in der Norm explizit vorgeschrieben; sie stellen jedoch eine anerkannte technische Maßnahme dar, um die dort definierten Integritäts- und Authentizitätsanforderungen zu erfüllen. In der Praxis setzen viele Hersteller Secure-Boot-Mechanismen und TPM-basierte Vertrauensanker ein, um die Konformität mit IEC 62443-4-2 nachweisbar umzusetzen.

Um den regulatorischen Vorgaben der UNECE R155/R156 zu entsprechen, müssen Fahrzeughersteller (OEMs) ein umfassendes Cybersecurity Management System etablieren und sowohl die Authentizität als auch die Integrität von Software-Updates nachweisen können. Zu den hierfür gebräuchlichen Implementierungsansätzen zählen unter anderem Technologien wie Secure Boot und Attestation mit einem Hardware-Root-of-Trust.

Ein Trusted Platform Module (TPM) ist ein direkter und bewährter Weg, diese Anforderungen umzusetzen – jedoch bei Weitem nicht die einzige Option. Zunehmend rücken neben klassischen TPM-Chips auch Secure Elements, Hardware Security Modules (HSMs) sowie SoCs mit integrierter Root-of-Trust-Funktionalität in den Fokus innovativer Sicherheitsarchitekturen.

Während TPMs vor allem durch Standardisierung und Kompatibilität punkten, bieten Secure Elements oft geringeren Energieverbrauch und lassen sich in kleineren Bauformen realisieren – Beides ein Vorteil für batteriebetriebene Geräte. HSMs hingegen adressieren Hochsicherheitsanwendungen mit erweiterten Kryptofunktionen und Zertifizierungsoptionen.

Elektronikhersteller stehen vor der Herausforderung, zwischen wenigen, aber grundverschiedenen Sicherheitsarchitekturen zu wählen.

Das Trusted Platform Module 2.0 (TPM 2.0), entwickelt von der Trusted Computing Group (TCG) und standardisiert in ISO/IEC 11889, ist seit Jahren der De-facto-Standard für Hardware-verankerte Sicherheit in Computern, Industrie-Controllern und IoT-Geräten; er bildet den kryptografischen Anker für die Integrität von Firmware, Betriebssystem und Anwendungen.

Das Trusted Platform Module (TPM) 2.0 – aktuell in der Version 184 vom März 2025 – speichert kryptographische Schlüssel, misst Firmware- und Softwareintegrität und ermöglicht es, die komplette Vertrauenskette – vom ersten Bootvorgang bis zur Cloud-Attestierung – nachweisbar abzusichern.

Ob im Steuergerät eines Fahrzeugs, im Edge-Controller einer Fertigungszelle oder im vernetzten Sensor: TPM 2.0 misst jeden Systemstart, schützt geheime Schlüssel und erkennt Manipulationen, um Missbrauch zu unterbinden. Der Standard integriert sich in Embedded-Designs, Automotive-Architekturen und industrielle Netzwerke – und wird zur Grundvoraussetzung für Zero Trust, sichere Lieferketten und souveräne IoT-Infrastrukturen.

Windows 11 verlangt TPM 2.0 (und UEFI Secure Boot-Fähigkeit). Bei Secure Elements ist von kompakteren Sicherheitschips die Rede, die primär auf die Schlüsselspeicherung und Authentifizierung spezialisiert sind und mit optionaler Unterstützung für digitale Signaturen oder Zertifikate auftrumpfen können. Typische Einsatzfelder umfassen IoT-Sensoren, Wearables, Low-Power-Edge-Geräte, Zahlungsterminals, Smartcards, Verbraucherelektronik und dergleichen andere. Sie bieten kein vollständiges Plattform-Trust-Modell (kein Measured Boot) und nutzen proprietäre, herstellerspezifische APIs (z. B. NXP, Microchip, ST).

Ein Hardware Security Module (HSM) ist die High-End-Variante eines Hardware-RoT für sicherheitskritische Anwendungen. HSMs übernehmen umfangreiche kryptografische Aufgaben, oft im Zusammenspiel mit Secure Enclaves in CPUs/SoCs, und schützen Identitäten ganzer Systemverbünde, von Cloud-Rechenzentren bis zu Fahrzeugflotten. Sie bieten Sicherheit nach FIPS 140-3 Level 3 oder höher und sind mandantenfähig, aber teuer und komplex in der Implementierung.

Zwischen TPM und HSM positioniert sich OpenTitan, eine quelloffene Root-of-Trust-Plattform. Sie wurde von lowRISC, Google, Western Digital, Nuvoton und weiteren Partnern initiiert wurde, um eine verifizierbare, auditierbare Alternative zu proprietären TPM- und Secure-Element-Chips zu schaffen.

Unter der Haube eines TPM-2.0-Moduls

Ein TPM 2.0 ist kein klassischer Speicherchip, sondern ein eigenständiger Kryptoprozessor. Seine Architektur umfasst drei zentrale Funktionsblöcke:

• Endorsement Key (EK): Eine vom Hersteller erzeugte, unveränderliche Hardware-Identität des TPM.

• Storage Root Key (SRK): Der oberste Schlüssel zur Verschlüsselung aller weiteren Daten, die im TPM gespeichert werden.

• Platform Configuration Registers (PCRs): Register, die Hashwerte gemessener Systemkomponenten (BIOS, Bootloader, Kernel, Treiber) erfassen.

Während des Startvorgangs misst das TPM jede Komponente, verknüpft die Hashwerte miteinander und dokumentiert so den „Measured Boot“. Stimmen alle PCR-Werte mit den Referenzwerten überein, gilt das System als vertrauenswürdig. Bei Abweichungen wird die Freigabe sensibler Schlüssel verweigert.

In sicherheitskritischen Embedded-Anwendungen – von Steuerungen bis Edge-Controllern – sorgt ein Hardware-Root-of-Trust für einen manipulationssicheren Systemstart. In Embedded-Designs sichert das TPM die Firmware-Integrität, schützt Signaturen von Software-Updates und generiert eindeutige Geräteidentitäten. Viele Entwickler nutzen es, um Secure-Boot-Ketten zu implementieren oder Remote-Attestierungen gegenüber Cloud-Plattformen zu ermöglichen. Bausteine wie Infineon OPTIGA TPM SLB 9670, STMicroelectronics STSAFE-TPM oder Nuvoton NPCT-Serie lassen sich über SPI oder I²C direkt integrieren.

In Fahrzeugen wird das TPM 2.0 zum Dreh- und Angelpunkt für funktionale Sicherheit und Cyber-Security gemäß ISO 21434 und UNECE R155 zur Angriffserkennung und Integritätsprüfung. Es verankert digitale Identitäten in ECUs, schützt Over-the-Air-Updates (OTA) und ermöglicht sichere Kommunikation innerhalb zonaler Architekturen.

In der Industrie 4.0 bilden TPMs die Basis für Zero-Trust-Edge-Knoten. Sie stellen sicher, dass nur attestierte Gateways an Produktionsnetzwerke angeschlossen werden. Über Mechanismen wie Remote Attestation können Betreiber prüfen, ob ein Gerät unverändert läuft, bevor es Zugang zu OPC UA- oder MQTT-Systemen erhält. Damit entsteht eine durchgängige Vertrauenskette vom Sensor bis zur Cloud.

Der Aufwand, TPM nach der TPM 2.0-Spezifikation (TCG) in Eigenregie zu entwickeln, ist enorm. Die Spezifikation erstreckt sich über rund 2.000 Seiten; wer sie punktgenau beachtet, muss die Implementierung dann auch noch zertifizieren lassen. Kryptografische Verfahren müssen FIPS-konform implementiert werden. Ohne Common Criteria/FIPS-Zertifizierung wird das Modul in sicherheitskritischen Anwendungen nicht zugelassen.

TPM-2.0-Chips werden daher von spezialisierten Halbleiterherstellern entwickelt und produziert, nicht von Geräteherstellern selbst. Sie sind erhältlich über Distributoren wie Mouser Electronics, Digi-Key oder Rutronik von Anbietern wie Infineon Technologies (OPTIGA TPM SLB 9670/9672), STMicroelectronics (ST33KTPM2X/2I) und Nuvoton Technology (NPCT7xx/NPCT75x).

dTPM, fTPM, iTPM

Das klassische, sicherste TPM ist ein dedizierter Mikrochip – also eine Discrete-TPM-Einheit (dTPM). Diese TPM-Chips sind vormontierte, zertifizierte Bauteile nach Common Criteria (EAL4+) oder FIPS 140-2/3 und lassen sich wie ein normaler IC auf ein PCB löten.

Ein modernes Trusted Platform Module (TPM) vereint einen sicheren Mikrocontroller-Kern, spezialisierte Kryptografie-Beschleuniger, Zufallszahlengeneratoren sowie flüchtigen und nichtflüchtigen Speicher, die gemeinsam durch physische und logische Sicherheitsmechanismen geschützt sind.

Im Inneren zeigt das Blockdiagramm eines TPM typischerweise einen SecurCore-SC300-Prozessor mit Speicherschutz, RAM, Flash und ROM, dedizierte Hardwareeinheiten für AES und andere Kryptofunktionen, einen echten Zufallszahlengenerator (NDRNG), einen Taktgenerator, eine SPI-Master/Slave-Schnittstelle sowie einen Security-Administration-Block, der die Integrität des Chips kontinuierlich überwacht.

In modernen Implementierungen kann der TPM jedoch auch direkt in das CPU-Die integriert sein (Integrated TPM, iTPM) oder als Firmware-basiertes TPM (fTPM) im isolierten Bereich der Prozessorarchitektur realisiert werden.

Wer keinen zusätzlichen Chip auf das Board setzen möchte, kann im Prinzip ein Firmware-TPM nutzen. Dieses ist eine Software-Implementierung, die zwar in der UEFI-Firmware oder im SoC ausgeführt wird, aber dedizierte Hardware-Isolation nutzt. Beispiele beinhalten AMD fTPM (in Ryzen, EPYC, embedded G-Series integriert), Intel Platform Trust Technology (PTT, eine TPM-kompatible Funktion in Intel-CPUs) und ARM TrustZone TPM (kein vollwertiges TPM 2.0, sondern TPM-Befehle für eine Secure-World-Umgebung).

In der Embedded-Welt werden Roots-of-Trust zunehmend direkt in SoCs integriert – etwa als Arm TrustZone, Intel Boot Guard oder Infineon OPTIGA TPM. Diese Plattformen schützen Firmware, Identitäten und kryptografische Schlüssel auf Chip-Ebene.

Die dedizierte Variante als diskreter Chip (dTPM) bietet den höchsten Schutzgrad, da sie vollständig von der restlichen Hardware und Firmware separiert ist. Ein iTPM implementiert Kryptografie direkt im SoC/CPU, wie es bei Secure Enclaves von ARM, Apple, und anderen der Fall ist. Dies schafft Vorteile bei Platz und Effizienz, bietet jedoch meist eine geringere Isolation als dTPM.

Angriffsvektoren auf ein TPM

Ein Trusted Platform Module (TPM) bietet keinesfalls einen lückenlosen Schutz. Angreifer können über Firmware‑, Hardware‑ und Betriebsfehlkonfigurationen die Sicherheit eines TPMs untergraben. Fehler in der TPM‑Firmware oder in Referenzimplementierungen können das Auslesen sensibler Bereiche, das Umgehen von Zugriffsprüfungen oder das Ausführen schadhafter Befehle erlauben.

Über das Abgreifen der CPU‑TPM‑Kommunikation (z. B. LPC, SPI) oder mittels direktem Zugriff auf den TPM‑Chip lassen sich Datenpakete mitschneiden, Befehle injizieren oder Debug‑Interfaces ausnutzen. Eine kompromittierte UEFI/BIOS‑Firmware kann TPM‑Policy‑Checks umgehen, Schlüssel freigeben oder die Integritätsüberprüfungen so verändern, dass bösartige Komponenten als vertrauenswürdig erscheinen.

Einen weiteren Angriffsvektor stellen DMA und Speicher‑Dumping dar. Durch Direct Memory Access über fehlerhaft konfigurierte Peripherie oder Exploits können Angreifer Speicherbereiche auslesen, in denen TPM‑bezogene Daten temporär verarbeitet werden.

Software‑ und Konfigurationsfehler zählen zu häufigen und oft unterschätzten Ursachen von Verletzungen der Sicherheitsarchitektur. Unsichere Schlüsselverwaltung, unzureichende Zugriffsrechte, falsch konfigurierte HSM/TPM‑Treiber oder schwache Passwörter/Policies ermöglichen Angreifern, TPM‑geschützte Prozesse zu kompromittieren.

Besonders dreiste Angriffe machen sich Reset-, Löschung- und Rollback-Techniken zu Nutze. Physischer Zugriff kombiniert mit TPM‑Clearing‑Befehlen oder manipulierten Boot‑Sequenzen kann Schlüssel löschen oder Zustände herstellen, die Sicherheitskontrollen umgehen.

Typische Folgen umfassen die Offenlegung kryptografischer Schlüssel (sei es durch Extraktion oder durch Umgehung der TPM‑Schutzmechanismen), den Verlust der Systemintegrität, bei dem manipulierte Boot‑Ketten und signierte Malware als legitim erscheinen, sowie Verletzungen von Authentifizierungs‑ und DRM‑Mechanismen für den Zugang zu geschützten Inhalten, Anmeldedaten oder gesicherten Speicherbereichen.

OpenTitan: Wo Transparenz Vertrauen schafft

Sicherheitskonzepte für Hardware-Root-of-Trust verschmelzen zunehmend mit Technologien wie Confidential Computing, Secure Enclaves und Virtual Hardware Security Modules (vHSM).

Eine quelloffene Initiative namens OpenTitan hat sich zum Ziel gesetzt, klassische TPM-Angriffsvektoren zu eliminieren. Statt proprietärer Black-Box-Implementierungen verfolgt OpenTitan einen „Design-for-Verification“-Ansatz, bei dem jede Schicht – vom Siliziumlayout über die Mask-ROM-Firmware bis zum Bootprozess – öffentlich dokumentiert und überprüfbar ist.

Die Architektur umfasst einen RISC-V-Mikrocontrollerkern, Hardwarebeschleuniger für AES, SHA und ECC sowie einen kryptografisch abgesicherten Secure-Boot-Pfad. Durch die Offenlegung von Schaltplan, Toolchain und Firmware-Quellcode können Hersteller, Behörden und Forschungseinrichtungen die Sicherheitsmechanismen unabhängig auditieren und reproduzierbar validieren.

Damit schließt OpenTitan viele der in klassischen TPMs vorhandenen Vertrauenskaskaden – etwa undurchsichtige Firmware-Komponenten, Debug-Interfaces oder eingeschränkte Testbarkeit – und bietet eine überprüfbare, Post-Quantum-erweiterbare Root-of-Trust-Plattform.

Die treibenden Kräfte hinter OpenTitan bilden ein internationales Konsortium aus Forschung, Industrie und Halbleiterentwicklung.

Zu den Gründungsmitgliedern zählen neben der gemeinnützigen Stiftung lowRISC CIC unter anderem Google, das maßgeblich an der Definition der Sicherheitsarchitektur und der Roadmap beteiligt ist, die ETH Zürich, deren Forscher den energieeffizienten Ibex-RISC-V-Core entwickelt haben sowie die Münchner Spezialistin für sichere Halbleiter und Smartcard-Technologien Giesecke+Devrient. Nuvoton Technology (ein Spin-off von Winbond) produziert die ersten physischen OpenTitan-Chips. Western Digital lässt OpenTitan-Prinzipien in seine Controller- und Speicherplattformen einfließen. Die Bosch-Gruppe ist über seine Venture-Client-Einheit Open Bosch am OpenTitan-Projekt beteiligt.

Nuvoton, das OpenTitan-Demoboard (a.k.a Voyager 1) verfügt über den ersten produktionsbereiten OpenTitan-Sicherheitschip. Dieser Chip dient als quelloffene Silicon Root of Trust (RoT) für sicheren Boot, kryptografische Operationen und Geräteattestierung. Er funktioniert ähnlich wie ein Trusted Platform Module (TPM), ist jedoch Open Source und damit transparent einsehbar sowie offen für externe Beiträge.

Im Unterschied zu klassischen TPMs bietet ZeroRISC mit seinen OpenTitan-basierten Chips bereits Post-Quantum Secure Boot an.

OpenTitan kann die vollständige TPM-2.0-Spezifikation technisch umsetzen und unterstützt alle TPM-relevanten Schnittstellen und Algorithmen wie ein klassischer TPM-Chip (RSA/ECDSA, HMAC, Secure Boot, NV-Speicher, SPI/I2C-Kommunikation usw.). Allerdings ist OpenTitan kein offiziell nach TCG/ISO zertifiziertes TPM-Modul—es gibt Stand November 2025 keinen Hinweis auf ein abgeschlossenes, anerkanntes TPM-Zertifizierungsverfahren, wie es für marktübliche TPM-Chips (z.B. nach ISO/IEC EAL4+) erforderlich ist. OpenTitan ist ein offenes Prüf- und Evaluierungsprojekt und kann für TPM-Einsatzfälle gebaut oder individuell zertifiziert werden, ist aber von Haus aus als „konforme Referenzimplementierung“ angelegt und noch nicht standardzertifiziert.

Normierungsgremien arbeiten noch aktuell an der Integration Post-Quantum-sicherer Algorithmen (FIPS 203–207), um das TPM gegen künftige Angriffe durch Quantencomputer zu härten. Mit zunehmender Bedeutung von Quantencomputern wird der Übergang zu PQ-fähiger Root-of-Trust-Hardware zunehmend relevant.

Fazit

TPM 2.0 ist mehr als ein Hardware-Sicherheitsmodul – es ist der Ausgangspunkt für eine konvergente Vertrauensarchitektur, die sich bis in Cloud- und KI-Infrastrukturen fortsetzt. (mbf)

* Anna Kobylinska und Filipe Pereia Martins arbeiten für McKinley Denali, Inc., USA.

(ID:50640313)