Die Implementierung einer Sicherheitsarchitektur für jedes IoT-System mit Hardwarebeschränkungen (begrenzter RAM, Flash, Rechenleistung) ist eine große Herausforderung. Darüber hinaus erlaubt das Sicherheitsmandat der EU im Rahmen des Cyber Resilience Act (CRA) keine CE-zertifizierten vernetzten Produkte mehr ohne eine kohärente Sicherheitsarchitektur (vollständige Umsetzung bis 2027).
Unsere Sicherheitsarchitektur
Symbiotic Security stellt einen Paradigmenwechsel in der IoT-Sicherheitsarchitektur dar, bei dem Hardware, Software, Netzwerkkomponenten und sogar menschliche Bediener synergetisch zusammenarbeiten, um ihre jeweiligen Grenzen zu überwinden. Während Hardware beispielsweise von Natur aus statisch und daher potenziell widerstandsfähiger gegen böswillige Modifikationen ist, kann Software dazu beitragen, diese Grenzen zu überwinden. Gleichzeitig kann ein gut durchdachtes Hardware-Design die Schwächen der von ihr ausgeführten Software ausgleichen. Letztendlich müssen alle wesentlichen architektonischen Säulen bereits in der ersten Entwurfsphase berücksichtigt werden, um ein solides Sicherheitskonzept zu schaffen. Daher trennen wir die Geräteseite (Hardware & Software) nicht von der IT-Seite. Stattdessen denken wir ganzheitlich und berücksichtigen alle Bausteine gleichzeitig.
Geräteseitig bieten wir Bare-Metal- und RTOS-Lösungen auf Basis von ARM Cortex M0 bis M85 an. Unser Portfolio konzentriert sich speziell auf Demoprojekte (Bootloader und Anwendung), um die volle Bandbreite der Möglichkeiten und die Flexibilität dieses Ansatzes zu demonstrieren. Eine zusätzliche PC-Utility-Software unterstreicht die zusätzlichen Sicherheitsvorkehrungen für die Geräteprüfung und -registrierung. Eine flexible und erweiterbare Infrastruktureinheit unseres Partners Peak Solution GmbH ergänzt unser Produkt. Im Gegensatz zur üblichen Vorgehensweise, bei der Kunden und Entwickler ihre Endgeräte mit einem generischen Cloud-basierten Infrastrukturdienst verbinden müssen, finden Sie auf der Website unseres Partners weitere Informationen zur serverseitigen Technologie:
Sicheres IoT steht und fällt grundsätzlich mit dem Konzept „Security-by-Design“. Zu diesem Zweck sind kritische Komponenten wie Produktion (Electronics Manufacturing Services, EMS), Erstkonfiguration sowie Schlüssel- und Zertifikatsbereitstellung intelligent in unsere Technologie integriert. Darüber hinaus erstreckt sich unser Design weit über die übliche Zielumgebung hinaus, um Kunden bei praktischen Aspekten wie Registrierung, Produktlebenszyklus und Neubereitstellung zu unterstützen und so die zugrunde liegende Nachhaltigkeit und Cyber-Resilienz zu stärken.
Unzureichende Lösungen (Stand der Technik):
- Herstellerintegrierte Geheimnisse:
verstößt gegen die CRA-Anforderung, keine fest codierten Anmeldeinformationen zu verwenden - Trusted Platform Module (TPM)-basierte Attestierung:
teuer und erfordert weiterhin vorinstallierte Herstellerschlüssel - Manuelle Konfiguration:
fehleranfällig und nicht skalierbar für Millionen von Geräten - Selbst softwarebasierte OTA-Lösungen basieren auf statischen Geheimnissen, was sie minderwertig und deutlich eingeschränkter macht
- Moderne Physical Unclonable Function (PUF)-Lösungen verbessern die physische Sicherheit, bleiben aber statisch und daher im Falle einer Kompromittierung nicht tragfähig
Die größte Herausforderung bei vernetzten Geräten heute
Das Problem der Erstregistrierung ist seit jahrzehnten eine Herausforderung, insbesondere im Bereich der Public-Key-Infrastruktur (PKI). Bis heute stellt sie ein grundlegendes Paradoxon in der traditionellen IoT-Sicherheit dar:
- Sichere Registrierung erfordert bereits vorhandene sichere Kanäle
- => Die Einrichtung sicherer Kanäle erfordert eine Authentifizierung
- => Die Authentifizierung erfordert vorab freigegebene Geheimnisse oder Anmeldeinformationen
(gemeinsam mit dem Electronic Manufacturing Service (EMS) oder der Lieferkette)
Durchbrechen wir diesen Teufelskreis!
Alles beginnt mit der Entscheidung, während der Herstellungsphase auf die Bereitstellung von Geheimnissen, kryptografischen Schlüsseln oder PKI-Zertifikaten in ein IoT-Gerät zu verzichten. Die Mehrwerte sprechen für sich:
- Entlastung der Lieferkette
- Reduzierte Angriffsfläche, reduzierter Herstelleraufwand (z. B. EMS & OEM) dank vollständiger Transparenz und Zero-Trust-Prinzip
- Die Registrierung (PKI- & Firmware-Injektion + „Verbindung“ mit der Infrastruktur) liegt im alleinigen Ermessen des Gerätebesitzers, -betreibers und seiner Zielumgebung
Die drei Säulen des Zero Knowledge Initial Enrolment (ZKIE)-Systems:
- Bare-Metal-"smart"-Bootloader
- Registrierung: Initial Registration Tool (IRT)
- ZKIE-Server (Bootstrap-Authentifizierung, sicheres Firmware-Repository, PKI, Over-The-Air (OTA) und Automatisierungs-Workflows)
Gerätebesitzer und -betreiber müssen sich nur auf drei Komponenten/Dienste konzentrieren:
- Eine Anwendungsfirmware für das IoT-Gerät
- Die Bereitstellung des ZKIE-Server (selbstgehostet, Software-as-a-Service usw.)
- Schnittstelle zum vorhandenen Identitätsanbieter (IdP) und der spezifische Authentifizierungsmodus (z.B. über das IRT-Tool, mit oder ohne FIDO 2FA usw.)
Funktionsprinzip
Der Endkunde kann entweder unseren Full-Service (ZKIE-Server) nutzen, um die Zertifikatserstellung und -bereitstellung zu automatisieren, oder sich für die Anbindung an seine vorhandene PKI entscheiden, um die vollständige Sicherheit und Governance-Compliance zu gewährleisten.
In beiden Fällen ist keine Anwendungsfirmware auf dem Gerät vorinstalliert.
Die Geräteregistrierung / Installation erfolgt in den folgenden Schritten:
- Das IoT-Gerät wird ausschließlich mit dem minimalistischen ZKIE-Bootloader verkauft, geliefert und installiert.
- Nach der physischen Verbindung aktiviert der Installateur oder Betreiber die Geräteregistrierung mithilfe des IRT-Tools als zusätzlichen Gatekeeper.
- Das Gerät erstellt einen eindeutigen Verifizierer und überträgt ihn über den sicheren Out-of-Band (OoB)-Kanal des IRT-Tools an den ZKIE-Server.
- Der Installateur (d. h. der menschliche Betreiber) wird z. B. durch FIDO-Zwei-Faktor-Authentifizierung gegenüber der Zielinfrastruktur authentifiziert.
- Das Gerät ruft die zugewiesene Server-URL (über den gegenseitig authentifizierten und verschlüsselten OoB-Kanal) ab, um sich später zu verbinden.
- Der Server kann das Gerät anhand seines Verifizierers dem zugewiesenen Infrastruktur-Tenant zuordnen.
- Der Server erstellt die entsprechenden PKI-Zertifikate, die zugehörigen Konfigurationsdetails und weist dem Gerät eine Firmware zu. Frage
- Das Gerät öffnet einen Zero-Knowledge-Kommunikationskanal zum ZKIE-Server
- Der Server sendet die PKI-Zertifikate, die Firmware und spezifische Konfigurationen an das Gerät
- Nun kann das Gerät mit seinem neuen Zertifikat direkt in den Produktionsmodus wechseln, um an der obligatorischen TLS-Kommunikation (Transport Layer Security) mit jedem Infrastruktur-Backend teilzunehmen
- Bei Verdacht auf eine Sicherheitsverletzung oder böswillige Veränderung kann das betroffene Gerät per Fernzugriff gelöscht werden.
Danach kehrt das Gerät automatisch in die Bootstrap-Phase zurück, um den ZKIE-Prozess erneut zu durchlaufen.
An diesem Punkt generiert das Gerät einen neuen geheimen Schlüssel, der selbst den erfolgreichen Angriff unwirksam macht.
Da der sichere Lösch- und Fallback-Mechanismus den ZKIE-Workflow sowie die anschließende Firmware-Bereitstellung automatisch auslöst, kann er auch auf die gleiche einfache Weise genutzt werden, um Firmware-Updates (OTA) im Feld zu installieren. Selbst wenn also eine der oberen Wenn Kommunikationsschichten als „defekt“ gelten (z. B. TLS aufgrund abgelaufener Zertifikate oder inkompatibler Einstellungen), würde der Bootloader das Gerät wieder auf den Ausgangspunkt zurücksetzen und ausschließlich generisches TCP/IP nutzen.
Die potenziell schädliche Anwendungsschicht ist nicht mehr für OTA-Updates verantwortlich.
Folglich widerruft die Infrastruktur automatisch die kompromittierte Geräteidentität/das kompromittierte Zertifikat und generiert gleichzeitig ein neues, einwandfreies Zertifikat, das dem Gerät unverzüglich zur Verfügung gestellt wird. Dies ist ein entscheidender Vorteil zur Unterstützung der Geschäftskontinuität und Cyber-Resilienz gemäß der CRA-Verordnung.
Komponenten und Schnittstellen der ZKIE-Architektur
Wir bieten Bootloader für verschiedene MCU-Anbieter an und ermöglichen die Anpassung des Bootloaders an die jeweilige MCU-Wahl des Kunden und andere spezifische Anforderungen.
Zur Unterstützung von Kundenanwendungen bieten wir außerdem unsere eigene Entwicklungsplatine, die GENESIS-Plattform, an.
Sie verfügt über zwei Renesas EK-Boards: die RA4-MCU für alle Peripherieanschlüsse (z. B. kundenspezifische Feldbusanwendungen) sowie die RA8 als Hauptkern-MCU.
Die RA8 bietet hohe Leistung, Geschwindigkeit und Performance und ebnet so den Weg für anspruchsvollste Kundenanwendungen. Es ist jedoch möglich, ihn je nach Bedarf durch eine andere MCU zu ersetzen, da die Konnektivitätshardware auf den WIZnet W5500 TCP/IP-Stack (W6300 in Kürze verfügbar) ausgelagert wird.
Wir sind auch Renesas RA ecosystem partner:
Weitere Informationen zu unserem GENESIS-Board finden Sie in diesem Artikel:
Autor:
