Zero Trust wird häufig mit Benutzerkonten, Netzwerksegmentierung oder Cloud-Security verbunden. Diese Maßnahmen sind wichtig, sie setzen jedoch voraus, dass die Systeme, von denen aus kommuniziert und auf die zugegriffen wird, selbst vertrauenswürdig eingeordnet werden können. Gerade bei verteilten Edge-, Router-, Gateway- und Industrial-IoT-Architekturen beginnt diese Frage deshalb nicht erst im Netzwerk, sondern bei der Identität und dem nachweisbaren Zustand des Geräts. Hardware- und Firmware-Security schaffen dabei keine vollständige Zero-Trust-Architektur, aber eine technische Vertrauensbasis, auf der weitere Maßnahmen wie Zugriffskontrolle, verschlüsselte Kommunikation und Software-Security aufbauen können.

Zero Trust beginnt nicht erst im Netzwerk

Ein Zero-Trust-Ansatz folgt dem Grundsatz, dass kein Benutzer, kein Dienst und kein Gerät allein aufgrund seines Standorts oder seiner bisherigen Verbindung automatisch als vertrauenswürdig gilt. Jede Zugriffsentscheidung muss im jeweiligen Kontext geprüft werden. In der Praxis gehören dazu unter anderem Identitäten, Berechtigungen, Netzwerkpfade, Anwendungen und der Sicherheitszustand eines Systems.

Die technische Vertrauensfrage wird allerdings oft zu spät gestellt. Eine Firewall kann eine Verbindung kontrollieren, ein Segment kann Zugriffe begrenzen und ein Cloud-Dienst kann Anmeldungen bewerten. Keine dieser Maßnahmen beantwortet allein die Frage, ob das angeschlossene Gerät tatsächlich das erwartete Gerät ist und ob es mit einer autorisierten Firmware betrieben wird. Genau hier setzt die Hardware- und Plattformebene an.

Warum auch Geräte Vertrauen nachweisen müssen

In einer klassischen, zentralen IT-Umgebung lassen sich Systeme häufig über Verzeichnisdienste, feste Standorte und standardisierte Verwaltungsprozesse einordnen. Am Edge ist die Situation heterogener: Router, Gateways, Edge Computer, Sensorik und industrielle Steuerungskomponenten stehen an vielen Standorten, kommunizieren mit unterschiedlichen Gegenstellen und werden teilweise über lange Zeiträume betrieben. Ein angeschlossenes Gerät ist deshalb nicht schon dann vertrauenswürdig, wenn es das richtige Netzwerk erreicht.

Eine Geräteidentität beantwortet zunächst die Frage, mit welchem System die Gegenstelle kommuniziert. Technisch kann diese Identität beispielsweise über einen individuellen kryptografischen Schlüssel, ein Zertifikat oder einen geschützten Geräteverweis abgebildet werden. Entscheidend ist, dass die Identität einem konkreten Gerät zugeordnet ist und der zugehörige private Schlüssel nicht einfach ausgelesen oder kopiert werden kann. Dafür kommen je nach Plattform etwa ein TPM, ein Secure Element oder andere hardwarebasierte Schutzmechanismen infrage.

Mit zunehmender Zahl vernetzter Systeme wird diese Unterscheidung wichtiger. Wenn viele Geräte ähnliche Funktionen ausführen, an unterschiedlichen Orten eingesetzt werden und miteinander Daten austauschen, reicht eine allgemeine Netzwerkzugehörigkeit als Vertrauenssignal nicht aus. Geräteauthentifizierung hilft, legitime Kommunikationspartner von nicht autorisierten oder unbekannten Systemen zu unterscheiden. Sie ist damit eine wichtige Voraussetzung für belastbare Zugriffsentscheidungen, aber noch keine vollständige Sicherheitsarchitektur. Das gilt besonders für vernetzte Geräte aus dem Industrial-IoT-Portfolio, die über lange Zeiträume und an verteilten Standorten im Einsatz sind.

Vom Hardware Root of Trust zur verifizierten Firmware

Root of Trust, Chain of Trust, Secure Boot und Firmware-Authentizität greifen ineinander. Sie lassen sich als zusammenhängender Aufbau verstehen, der von einem geschützten Anker in der Hardware bis zur geprüften Firmware im Betrieb reicht.

Hardware Root of Trust

Ein Hardware Root of Trust ist vereinfacht ein besonders geschützter Vertrauensanker innerhalb einer Plattform. Er kann Schlüsselmaterial speichern, kryptografische Prüfungen unterstützen oder den Startprozess absichern. Der entscheidende Punkt ist nicht, dass Hardware jede Manipulation verhindert, sondern dass sie einen Ausgangspunkt bereitstellt, dessen Eigenschaften für nachgelagerte Prüfungen genutzt werden können.

Chain of Trust

Auf diesem Ausgangspunkt baut eine Vertrauenskette auf. Dabei prüft eine bereits vertrauenswürdige Komponente die nächste, bevor diese ausgeführt wird. Vereinfacht lässt sich die Abfolge so darstellen:

• Hardware bzw. hardwarebasierter Vertrauensanker
• Firmware und erster Bootschritt
• Bootloader und Betriebssystem
• Anwendungen und gegebenenfalls weitere Systemkomponenten

Jede Stufe kann die Authentizität oder Integrität der nächsten prüfen. Ist eine Signatur ungültig, stammt eine Komponente nicht aus einer autorisierten Quelle oder weicht ihr Prüfwert vom erwarteten Zustand ab, kann die Plattform je nach Umsetzung den Start stoppen, in einen abgesicherten Modus wechseln oder einen Fehler melden.

Secure Boot

Secure Boot ist ein möglicher Bestandteil dieser Kette. Beim Start prüft die Plattform, ob die auszuführenden Boot-Komponenten mit einem hinterlegten oder verifizierbaren Vertrauensanker übereinstimmen. In vielen Umsetzungen geschieht dies über digitale Signaturen: Die Firmware oder der Bootloader wurde von einer autorisierten Stelle signiert, und das Gerät prüft diese Signatur vor der Ausführung. Secure Boot und signierte Firmware können nicht autorisierte oder manipulierte Boot-Komponenten erkennen und ihre Ausführung verhindern. Sie sind jedoch kein allgemeiner Manipulationsschutz: Sie schützen nicht automatisch jede Anwendung, ersetzen keine Zugangskontrolle und sagen allein nichts darüber aus, ob ein Gerät im laufenden Betrieb korrekt konfiguriert ist.

Firmware-Authentizität und -Integrität

Bei Firmware geht es um zwei eng verbundene Eigenschaften. Authentizität bedeutet, dass die Firmware aus einer autorisierten Quelle stammt. Integrität bedeutet, dass sie seit ihrer Signierung nicht unbemerkt verändert wurde. Digitale Signaturen können beide Prüfungen unterstützen: Die Signatur wird mit dem öffentlichen Schlüssel der autorisierten Quelle verifiziert, zusätzlich zeigt ein kryptografischer Prüfwert, ob die vorliegende Datei dem signierten Stand entspricht. In einem realen System müssen dafür mehrere Elemente zusammenspielen: ein geschützter Vertrauensanker, eine nachvollziehbare Schlüssel- und Zertifikatsverwaltung, definierte Freigabeprozesse sowie eine Plattform, die Signaturen tatsächlich prüft. Ebenso relevant ist der Umgang mit abgelaufenen oder kompromittierten Schlüsseln und die Möglichkeit, nicht mehr vertrauenswürdige Versionen zurückzuweisen.

Diese Funktionen sind nicht in jeder Plattform automatisch vorhanden und können je nach Hersteller, Prozessor, Firmware und Produktgeneration unterschiedlich umgesetzt sein. Für die Bewertung ist daher die Aussage „Secure Boot vorhanden" allein nicht ausreichend. Entscheidend ist, welche Komponenten geprüft werden, wo die Schlüssel liegen, wie der Vertrauensanker geschützt ist und welche Reaktion bei einer fehlgeschlagenen Prüfung erfolgt.

Geräteidentität und sicherer Startprozess erfüllen dabei unterschiedliche Aufgaben. Die Geräteidentität beantwortet „Welches Gerät ist das?", Secure Boot und Signaturprüfung beantworten „Welche Software darf auf diesem Gerät starten?". Erst in Kombination entsteht ein belastbareres Bild. Das gilt auch zwischen Systemen: Edge-Geräte kommunizieren häufig mit Routern, Gateways, Servern, Sensoren oder Cloud-Diensten, und auch die Gegenstelle sollte nicht allein anhand von IP-Adresse oder Standort akzeptiert werden. Beide Partner können sich je nach Architektur über zertifikatsbasierte Verfahren gegenseitig authentifizieren. Für die Hardwareauswahl ist relevant, ob die Plattform die dafür benötigten Schlüssel sicher verwalten und diese Funktionen zuverlässig unterstützen kann, denn der Nachweis der Device Identity bleibt auch hier die Grundlage.

Warum Hardware Trust am Edge besonders relevant ist

Am Edge treffen mehrere Faktoren zusammen, die eine frühe Vertrauensprüfung wichtig machen: Systeme stehen außerhalb klassischer Rechenzentren, sind über lange Zeiträume aktiv, werden über verteilte Netze erreicht und sind teilweise physisch zugänglich. Dazu kommen heterogene Plattformen und unterschiedliche Betriebsbedingungen. Ein Router, Gateway oder Edge Computer kann dabei eine zentrale Vermittlerrolle einnehmen. Wird seine Identität nicht sauber geprüft oder startet eine nicht autorisierte Firmware, kann sich das auf nachgelagerte Systeme und Datenflüsse auswirken. Das betrifft unter anderem industrielle IoT-Installationen, Energieanlagen, Verkehrssysteme, Fertigungsumgebungen und andere kritische Infrastrukturen.

Ein Beispiel ist ein Industrial IoT Gateway, das Sensordaten aus einer Anlage bündelt und an übergeordnete Systeme weitergibt. Für eine belastbare Vertrauensentscheidung genügt es nicht, nur die Verbindung zu verschlüsseln. Das empfangende System muss möglichst auch feststellen können, ob das Gateway zur vorgesehenen Installation gehört und ob es mit einem erwarteten Plattformzustand betrieben wird. Je verteilter die Architektur und je größer die Zahl der Geräte, desto weniger tragfähig ist die Annahme, dass jedes bereits angeschlossene System vertrauenswürdig ist. Hardwarebasierte Identitäts- und Verifikationsfunktionen schaffen hier einen überprüfbaren Ausgangspunkt, auf den zentrale und dezentrale Sicherheitsmaßnahmen aufsetzen.

Hardware Security ist die Basis, nicht die vollständige Architektur

Hardware Root of Trust, Secure Boot, signierte Firmware und Geräteauthentifizierung sind wichtige Bausteine, ersetzen aber keine vollständige Zero-Trust-Architektur. Für einen ganzheitlichen Ansatz müssen weitere Ebenen zusammenspielen, etwa Zugriffskontrolle, Netzwerksegmentierung sowie Software- und Cloud-Security. Die Hardware liefert dafür keine fertige Lösung, aber die technische Grundlage, auf der diese Kontrollen verlässlicher aufsetzen.

Security beginnt bei der Systemauswahl

Die Frage nach Zero Trust sollte bereits bei der Auswahl einer Hardwareplattform gestellt werden, nicht erst nach der Inbetriebnahme. Für die technische Bewertung sind unter anderem folgende Punkte relevant:

• Unterstützt die Plattform Secure Boot und welche Boot-Komponenten werden geprüft?
• Gibt es einen TPM, ein Secure Element oder einen vergleichbaren hardwarebasierten Vertrauensanker?
• Wie werden Geräteidentitäten, Zertifikate und private Schlüssel erzeugt, gespeichert und geschützt?
• Kann Firmware aus einer autorisierten Quelle verifiziert werden, und wie reagiert das System bei einer fehlgeschlagenen Prüfung?
• Welche Möglichkeiten zur Geräteauthentifizierung und zur abgesicherten Kommunikation mit Gegenstellen sind vorgesehen?
• Welche Funktionen sind tatsächlich in Hardware und Firmware integriert, und welche müssen durch zusätzliche Software oder Infrastruktur ergänzt werden?

Ein konkretes Beispiel für einen herstellerseitigen Ansatz ist Digi TrustFence®. Das Framework bündelt mehrere der genannten Funktionen wie Secure Boot und zeigt, wie sich solche Mechanismen im Systemkontext umsetzen lassen. Welche davon im Einzelfall greifen, hängt vom jeweiligen Gerät und seiner Konfiguration ab. Entscheidend ist nicht das einzelne Schlagwort, sondern die Passung zwischen Plattform, Sicherheitsanforderungen und Gesamtarchitektur.

Mehr zu Software, Tools & Services

BRESSNER unterstützt bei der Auswahl und Integration geeigneter Hardwareplattformen anhand der projektspezifischen Security-, Schnittstellen- und Einsatzanforderungen. Dabei greifen wir auf ein breites Herstellerportfolio mit unterschiedlichen hardware- und firmwarebasierten Security-Funktionen zurück.

Fazit: Vertrauen muss nachweisbar beginnen

Zero Trust beginnt nicht mit einem einzelnen Security-Feature, sondern mit der Frage, welche technische Vertrauensbasis eine Plattform überhaupt bereitstellt. Deshalb sollten Geräteidentität und integrierte Security-Funktionen bereits bei der Hardwareauswahl berücksichtigt werden.

Mehr zu Software, Tools & Services für Industrial IoT bei BRESSNER erfahren