Auf der Suche nach dem universellen IoT-Sicherheitsstandard

Die heterogene Natur von IoT-Geräten

IoT-Geräte sind divers. Auch wenn man bei einem IoT-Gerät meist an etwas denkt, das man sehen, anfassen und mit dem man interagieren kann, wie z. B. ein Smartphone, geht ihre Zahl weit darüber hinaus. Oftmals benötigen sie keinerlei menschliche Interaktion. Das trifft beispielsweise auf Sensoren zu, die mit ihrer Umgebung interagieren, um die Temperatur in kontrollierten Umgebungen zu melden oder ob eine Tür in einer entfernten Einrichtung geöffnet oder geschlossen ist, oder um über den An-/Aus-Status eines Lichtschalters in einem Smart Building zu informieren. IoT-Geräte können auch Gateways sein, die Kommunikationswege absichern und über die Daten von einem Endpunkt in die Cloud übertragen werden, oder Aktoren, die automatisch Lichter ausschalten, wenn niemand da ist. Oder sie übernehmen Funktionen innerhalb einer kritischen Infrastruktur wie etwa in der Energieversorgung, um Produktionsumgebungen verfügbar zu halten oder Telekommunikationszentren zu steuern.

Es gibt unzählige Arten von IoT-Geräten und ebenso viele Arten wie jedes einzelne von ihnen in seiner Umgebung eingesetzt wird. Der konkrete Anwendungsfall ist einzigartig. Jedes Gerät verfügt über unterschiedliche technische Funktionen und kann möglicherweise in eine Reihe von IoT-Plattformen integriert werden. IoT-Umgebungen und -Geräte sind nicht selten in ihrer Bandbreite oder Gerätekapazität (Akku, Speicher, Rechenleistung) begrenzt. Ähnliches gilt für IoT-Geräteplattformen, die im Vergleich zu Desktop-Computern eine enorme Diversität hinsichtlich der Software aufweisen. Beim Desktop-Computing gibt es nur eine Handvoll Betriebssysteme. Die Zahl der eingebetteten Systeme auf der Geräteseite ist um ein Vielfaches höher, weil viele Plattformen kundenspezifisch sind. Bei so viel Diversität gemeinsame Standards zu finden, ist alles andere als trivial und behindert die Entwicklung von universellen IoT-Standards.

Branchenführer mit branchenspezifischen Standards

Trotz unzähliger Geräte und der großen Bandbreite von Anwendungsfällen arbeiten die Industriezweige gemeinsam daran, anwendungsfallspezifische IoT-Sicherheits- und Konnektivitätsstandards zu entwickeln. Einige davon wurden bereits unterbreitet. Es kommt vor, dass diese Standards sich mit der Zeit weiterentwickeln. Diese Weiterentwicklung sehen wir etwa, wenn wir PKI-basierte Implementierungen im IoT damit vergleichen, wie eine PKI heute in der Web-PKI-Welt standardisiert ist. In der Web-PKI gibt es öffentliche Zertifizierungsstellen, das Certificate Authority/Browser (CA/B) Forum und die Webbrowser selbst. Es gibt eine etablierte, traditionelle Methode, um Webserver im Anwendungsfall abzusichern. Dabei handelt es sich um einen allgemein anerkannten Standard und Standardanwendungsfall für eine PKI. Die Baseline Requirements des CA/B Forum dienen als Richtschnur. Der Bedarf für einen Browser-Standard wird durch ein offenes Ökosystem von Clients in der Umgebung angetrieben – alle Webbrowser und Benutzer müssen sich mit einer offenen und breiten Palette von Servern verbinden.

Wenn wir eine PKI für IoT-Ökosysteme betrachten, sieht das teilweise anders aus. Während eine Web-PKI hauptsächlich öffentliche Vertrauensmodelle nutzt, verwendet eine IoT-PKI eher geschlossene, private Ökosysteme. Im Moment sind die Vertrauensmodelle in vielen IoT-Ökosystemen eher geschlossen, weil sich das IoT noch in einem frühen Entwicklungsstadium befindet. In der Regel stellt ein OEM-Anbieter den gesamten Stack bereit – vom Gerät bis in die Cloud. Sie betreiben die Cloud oder, was wahrscheinlicher ist, arbeiten mit einem Cloud-Betreiber wie Microsoft oder Amazon zusammen. Diese Vertrauensmodelle innerhalb des Ökosystems sind derzeit geschlossen und isoliert.

Diese Konfiguration ist noch in der Entwicklung. Wir beobachten die Entwicklung von Identitätsstandards und IoT-Identitätsstandards eher in branchenspezifischen Ökosystemen. Standards entwickeln sich beispielsweise in Gruppen wie der Wi-SUN Alliance, einer Organisation, die die Einführung von interoperablen, sogenannten Smart Ubiquitous Networks vorantreibt, oder das LXI Consortium (LAN eXtensions for Instrumentation), eine Gruppe von führenden internationalen Test- und Messunternehmen, die gemeinsam an einem Kommunikationsstandard für die Entwicklung und Steuerung von Test- und Messgeräten arbeiten.

Es gibt zahlreiche weitere Beispiele für branchenspezifische Anwendungsfälle, die die Konsistenz innerhalb der jeweiligen Sparte vorantreiben, wie z.B. in der Automobilbranche oder im Bereich Consumer Home. Das deckt sich mit unseren Prognosen, auch hinsichtlich der Abweichungen zu dem, wie Identitätsmodelle im Web eingesetzt werden. So haben sich die ehemals geschlossenen Ökosysteme zunächst zu teilweise privaten oder teilweise öffentlichen weiterentwickelt. Hin zu etwas, das breiter und angemessener ist als ein allgemeiner Authentifizierungs- oder Identitätsstandard für diese Ökosysteme. Die einzelnen Industriezweige tragen dazu dabei, gewisse Grundstandards zu etablieren, die sich mit dem wachsenden Reifegrad des IoT wahrscheinlich zu weitergefassten Standards entwickeln werden.

Neue Architekturkonzepte

Jeder vertikale IoT-Sektor und jeder Anwendungsfall hat unterschiedliche Architekturmuster. Es gibt aber auch hier einige Gemeinsamkeiten, die sich aus der IEEE 802.1 AR-Spezifikation ergeben, und sich allmählich in IoT-Ökosystemen durchsetzen. Gemeint sind die weiter gefassten und generellen, konzeptionellen Komponenten einer IDevID und einer LDevID. Sie kommen in Architekturkonzepten zum Tragen, die von Branchen und Anwendungsfällen etwas unabhängiger sind.

Eine IDevID (anfängliche Geräteidentität) ist in der Regel langlebig, idealerweise durch sichere Hardware geschützt und repräsentiert die Kernidentität des Geräts, vergleichbar einer Geburtsurkunde. Eine LDevID (lokale Geräteidentität) ist ein lokal signifikantes Zertifikat auf Zugriffsebene mit kürzerer Lebensdauer und Zugriff auf die Umgebung, eher etwas wie ein Führerschein. Dies ist eines der eher branchenunabhängigen Architektur-Identitätsmuster, die inzwischen bei Kunden zum Einsatz kommen. Bei der Implementierung muss man aber einige sorgfältige Überlegungen zur Lieferkette anstellen. Zunächst gilt es zu entscheiden, wo und wie die IDevIDs sicher in das Gerät, die Komponente oder den Chipsatz eingebracht werden. Das heißt, sowohl auf welcher Ebene der Geräteplattform als auch in welcher Phase des Herstellungsprozesses. Der nächste Schritt besteht darin, einige dieser IDevID-Vertrauensattribute, die idealerweise während der Herstellung sicher bereitgestellt wurden, in eine lokal signifikante, funktionsfähige LDevID umzuwandeln. Denn sie sind es, die dem Gerät ermöglichen, sich mit dem IoT-Ökosystem zu verbinden und dort zu arbeiten. LDevIDs werden in der Regel während des Gerätelebenszyklus häufiger gewechselt. Dieses IDevID/LDevID-Muster ist eine der architektonischen Identitäts-Blaupausen, auf die sich eine PKI im IoT zunehmend stützt.

Die Frage nach einem universellen IoT-Sicherheitsstandard ist nicht ganz klar fomuliert, und man braucht mehr als eine einzeilige Antwort. Das IoT ist nicht nur zu divers für einen einzigen Standard (obwohl das durchaus eine legitime Erklärung wäre). Vielmehr ist es noch in seiner Entstehens- und Wachstumsphase und auf der Suche nach potenziellen Gemeinsamkeiten. Und diese Bewegung wird in Sachen Standards vermutlich zu größerer Homogenität führen als es jetzt der Fall ist.