Standard-Framework für Blockchain-basiertes IoT-Data Management: die Entwicklersicht

Deep-Dive aus Sicht eines Blockchain-Entwicklers

Blockchain als IoT-Enabler? Das ist längst keine Neuheit mehr: Etliche Anwendungsfälle haben sich im Laufe der letzten Jahre entwickelt, dazu zählen beispielsweise die Anwendungsgebiete Supply-Chain-Management und Logistik, Healthcare oder Automotive. Diese machen sich bekannte Stärken von Blockchains zunutze; neben der Dezentralität und hohen Verfügbarkeit spielt vor allem das No-Trust Environment eine bedeutende Rolle. Die Grundlage all dieser Blockchain-basierten Systeme und letztlich auch die Entscheidungsgrundlage der Geschäftsprozesse sind Daten. Diese werden aus den unterschiedlichsten Quellen gesammelt – meist von Sensoren gemessen – und anschließend aufbereitet, aggregiert und verarbeitet.

Passend dazu hat das Institute of Electrical and Electronics Engineers (IEEE) im Januar 2021 einen Standard für ein Framework für Blockchain-basiertes IoT-Datamanagement herausgebracht (IEEE 2144.1-2020). In diesem stellen die Autoren einen Datamanagement-Lifecycle sowie darauf aufbauend ein Framework vor, welches Trusted Services durch die Erweiterung von Legacy IoT-Systemen durch Blockchain-Komponenten bereitstellen kann. Dabei handelt es sich um Services, die (oftmals) bereits in der Legacy-Welt vorhanden sind, allerdings erst durch die Umsetzung auf Basis der Blockchain Integrität und Vertrauen garantieren können.

In diesem Blogbeitrag möchte ich meine Gedanken zu diesem Framework teilen, allerdings nicht detailliert auf die konkreten Inhalte des Standards eingehen (unter anderem auch wegen Copyrights und Lizenzierung).

Vom Datamanagement-Lifecycle aus gedacht

Der Titel “Framework of Blockchain-based Internet of Things (IoT) Data Management” kündigt uns ein Framework an, welches sich mit Datamanagement in IoT-Systemen befasst. Es will zeigen, wo und wie der Einsatz von Blockchain gezielt unterstützen kann und welche Vorteile das mit sich bringt. So weit, so gut. Außerdem, so der Scope des Papers, diene dieser Standard als Leitfaden, um Datenmanagement in DLT-basierten IoT-Systemen zu etablieren.

Zugrunde liegt ein Datamanagement-Lifecycle, der die einzelnen Phasen von der Planung bis hin zur Löschung der Daten beschreibt. Vor der Implementierung des Frameworks gilt es, den Datenmanagement-Lifecycle zu definieren und die einzelnen Phasen sowie deren Bestandteile genau zu spezifizieren. Das Framework als solches wird anhand eines Schaubildes dargestellt und durch stichpunktartige Erklärungen ergänzt. Der Aufbau erinnert stark an andere Schichten-Modelle; spontan fällt mir hier das OSI-Referenzmodell ein: Jede Schicht kommuniziert mit der darüberliegenden und stellt Services für diese bereit. Zusätzlich zu den horizontalen Schichten enthält das Framework auch eine vertikale Kontrollschicht, die zentrale Aufgaben wie Monitoring oder Koordination erfüllt und Schnittstellen zu allen anderen Schichten besitzt.

Doch wo genau spielt nun die Blockchain in diesem Framework eine Rolle? Wie kann die Blockchain helfen, IoT-Systeme besser zu machen? Der Aufbau des Modells in Schichten von der Anwendungsebene bis zur Trust-Carrier-Schicht gibt einen Hinweis. Der Name Trust-Carrier-Schicht lässt vermuten, dass hier die Blockchain ihre Stärken ausspielen kann. Schließlich ist das eine ihrer Stärken: Vertrauen schaffen in einem Umfeld, wo kein Vertrauen herrscht.

Trust Carrier Layer: Vertrauen will verdient sein.

Die Trust-Carrier-Schicht ist ein Hybrid aus Legacy- und Blockchain-Welt. Wie auch alle anderen Schichten besteht sie aus vielen Bausteinen, die Supportfunktionen für die darüberliegende Schicht erfüllen. Dabei stehen all diese Funktionen unter dem Banner “Vertrauen” – wie gemacht für die Blockchain. In den Bausteinen Storage, Peer-to-Peer und Computing kommen Elemente der Blockchain zum Einsatz. Auf diese Bausteine gehe ich im Folgenden kurz ein:

Trusted Storage

Der Trusted Storage besteht aus einem Mix aus on-chain Storage und off-chain Storage, primär um Datenschutz-Regulationen erfüllen zu können. Das ergibt Sinn. Wer sich mit dem Aufbau einer Blockchain und der Thematik der on-chain-Datenspeicherung befasst hat, weiß: Alle Daten, die einmal in der Blockchain gespeichert wurden, sind öffentlich und können von jedem eingesehen werden – solange die Blockchain existiert. Also ist es oft sinnvoll, nur eine Referenz (etwa einen eindeutigen Hash) on-chain zu speichern und den eigentlichen Inhalt der Daten off-chain abzulegen. Einen tollen Artikel zu Datenschutz und Blockchain gibt es hier. Ein weiterer Aspekt, der bei der on-chain-Datenspeicherung betrachtet werden muss, sind die damit einhergehenden hohen Kosten. Denn: on-chain-Datenhaltung ist teuer! Zumindest bei den meisten öffentlichen Blockchains.

Trusted Networking

Beim Trusted Networking dreht sich alles um Kommunikation: Blockchain kann hier zur Identifikation und zum dezentralen Verwalten von Berechtigungsnachweisen (engl.: Credentials) eingesetzt werden. Berechtigungsnachweise? Identifikation? Auch wenn es im Standard nicht detailliert beschrieben wird, bietet sich hier der Einsatz von dezentralen Identitäten (DIDs) beziehungsweise Verifiable Credentials (VCs) an. In aller Kürze: Mit dezentralen Identitäten können wir Personen, Unternehmen und Dinge digital abbilden und ihnen eine technisch eindeutige und verifizierbare Identität zuordnen. Wer mehr wissen möchte, findet ausführliche Informationen in diesem Artikel.

Wie könnte das in diesem Kontext aussehen? Würde man jeder Komponente, die im IoT-Gesamtsystem eine Rolle spielt, eine eindeutige Identität und verifizierbare Berechtigungsnachweise zuordnen, so könnte man sicherstellen, dass nur befugte Komponenten miteinander kommunizieren. Außerdem ließe sich der Ursprung und die Integrität von Daten leicht nachvollziehen.

Trusted Computing

Man nehme Multiparty Computation und eine Prise Blockchain – fertig ist der Trusted Computation Layer. Hauptaugenmerk des Blockchain-Anteils liegt hier auf Data Access Control und dem Logging der Weitergabe von sensiblen Informationen.

Das scheint mir ebenfalls unter die Kategorie “Berechtigung” zu fallen. Auch hier wäre der Einsatz von VCs denkbar: Als kontrollierende Instanz im Gesamtsystem kann ich einzelnen Komponenten (hier allen Trusted-Computing-Komponenten) bescheinigen, dass sie zum Zugriff auf bestimmte Daten berechtigt sind. Andere Varianten als VCs sind bestimmt auch denkbar.

Dass Logging per Blockchain Sinn ergibt, muss vermutlich nicht weiter ausgeführt werden. Um sensible Inhalte von der Blockchain fernzuhalten, versieht man einen Datensatz mit einer nichts-sagenden UUID, loggt ein entsprechendes Event auf der Blockchain (etwa per Smart Contract), und fertig ist das unverfälschbare Logging, dass jeder nachvollziehen kann (vorausgesetzt, man ist im Besitz der benötigten, sensiblen Informationen, um mit der UUID etwas anzufangen). Feine Sache!

Vertikaler Management-Layer: One Contract to rule them all

In dieser Schicht stehen Monitoring und Koordination des Gesamtsystems im Vordergrund. Dazu bedarf es Regeln, die alle Komponenten befolgen müssen; diese werden in Form von Business Rules und Business Policies abgebildet und lenken den Ablauf auf allen Schichten. Dabei handelt es sich um eine sicherheitskritische Stelle: Wird die Komponente kompromittiert, die diese Regeln definiert, kann die Funktionsfähigkeit des Gesamtsystems nicht mehr gewährleistet werden. Hier bietet sich laut Framework der Einsatz von Smart Contracts an, eine vertrauensvolle, (de-)zentrale Stelle, die die besagten Regeln definiert und für ihre Einhaltung verantwortlich ist. Einmal auf der Blockchain deployed ist es unmöglich, diese Regeln unbemerkt zu manipulieren – eine sichere und saubere Implementierung vorausgesetzt.

Der Einsatz von Smart Contracts wird allerdings nicht genauer erläutert. Wichtige Fragen, die auftreten können, werden nicht thematisiert: Was macht man, wenn diese Regeln nicht öffentlich (nicht für jeden einsehbar) sein dürfen, wenn beispielsweise Geschäftsgeheimnisse enthalten sind? Wie steht es um die Änderbarkeit im Falle von neuen oder aktualisierten Regeln?

Mir sind solche oder ähnliche Fragen an mehreren Stellen gekommen. Sie bleiben im Standard unbeantwortet, sind jedoch relevant, wenn ich ein Blockchain-basiertes IoT-System designe.

Fazit: It depends …

Alles in allem finden sich drei Teil-Komponenten innerhalb des Frameworks wieder, die zumindest anteilig auf den Einsatz von Blockchain-Technologie setzen. All diese Komponenten befinden sich in der Trust-Carrier-Schicht; darüber hinaus enthält die Management-Schicht ebenfalls Komponenten von Smart Contracts.

Bei einem fünfschichtigen Modell mit vielen einzelnen Teil-Komponenten ist der Blockchain-Anteil insgesamt minimalistisch. Zugegeben: Eine Technologie um der Technologie willen einzusetzen, hat noch kein Projekt zum Erfolg geführt. Einen Standard als Framework für Blockchain-basierte IoT-Applikationen im Titel weckte bei mir allerdings eine Erwartungshaltung, die nicht ganz erfüllt werden konnte. Mehr technische Details oder Hinweise zur Umsetzung wären für mich als Entwickler eine willkommene Ergänzung. Hier hatte ich mir von einem namhaften Journal wie dem IEEE mehr Detailtiefe erhofft: Sieht man von allgemeinen Definitionen und einleitenden Worten ab, so wird das Framework auf dreieinhalb Seiten ausgeführt. Die Literaturangabe ist aus akademischer Sicht mit einer einzigen Quelle auch eher dürftig.

Für mich als Entwickler mit Blockchain-Hintergrund hat dieser Standard wenig Nutzen, da sich für mich aus technischer Perspektive keine neuartigen Erkenntnisse ergeben. Der Einsatz von Blockchain an den benannten Stellen eines IoT-Systems ist meist naheliegend. Aus Sicht eines Entwicklers oder Architekten mit weniger Blockchain-Wissen ist dieser Standard ebenfalls wenig hilfreich, da die Begriffe Blockchain und Smart Contract als Universalworte verwendet werden. Somit kann jeder, der nicht tiefer in der Thematik drinnen steckt, mit diesen Informationen zunächst nur wenig anfangen.

Nichtsdestotrotz ergibt es durchaus Sinn, für Architekturentscheidungen und vor allem in der Planungsphase eines Blockchain-basierten IoT-Systems diesen Standard zu Rate zu ziehen. Schließlich beschreibt er aus einer recht hohen Flughöhe, dass (Blockchain-) Komponenten an bestimmten Stellen gewinnbringend eingesetzt werden können. Dabei ist es dann ratsam, sich Unterstützung durch einen Experten mit Blockchain-spezifischem Wissen zu holen, der die Frage nach konkreten, produktspezifischen Implementierungen beantworten kann.

Ausblick – Quo vadis?

Es scheint, als stünde bereits ein weiterer Blockchain-Standard für IoT in den Startlöchern: Das Projekt P2418.1 entwickelt derzeit einen Entwurf (Link) für ein Standard Framework für die Blockchain Nutzung im IoT-Umfeld. Laut Beschreibung sollen Themen wie Sicherheit und Privatsphäre eine Rolle spielen und auf Implementierungsmöglichkeiten eingegangen werden. Vielleicht wird dem Leser in diesem Standard, aufbauend auf der Vorarbeit des Standards IEEE 2144.1-2020, ein praxisorientierteres Werkzeug an die Hand gegeben und mehr Detailtiefe vermittelt.

---

Über den Autor