Blockchain, verteiltes Hauptbuch (distributed Ledger) und vertrauenswürdige Dritte (TTP)

Und warum das Hersteller von IoT-Sensoren interessieren sollte?

Zukünftig werden Sensordaten für die Verarbeitung über komplizierte IoT-Architekturen in die Cloud übertragen. Warum ist eine Blockchain-Netzwerkstruktur vorteilhaft für diese Informationsverteilung verglichen mit einer zentralisierten Datenbank in industriellen IoT-Anwendungen?

Was genau ist Blockchain eigentlich?

Blockchain ist ein: „offenes, verteiltes Hauptbuch, das Transaktionen zwischen zwei Parteien effizient auf überprüfbare und permanente Weise aufzeichnet.“ [1]. Die Blockchain-Technologie wurde bereits vor zehn Jahren am 3. Januar 2009 entwickelt.

Nach dem ersten Ursprungsblock wurde ein Block (Datensatz) von sogenannten Miners [2] an den nächsten mittels kryptografischem Hashing gebunden. Kein vorhergehender Block kann ohne Aktualisierung der folgenden Blöcke in allen Kopien der Kette verändert, ausgetauscht oder gelöscht werden. Jeder Knotenpunkt im System hat eine Kopie der Kette. Dieser Mechanismus sorgt dafür, dass das System mit jedem Knotenpunkt zuverlässiger wird, denn die in einem Block geschriebenen Daten können nicht mehr verändert (bzw. gefälscht) werden. Heute ist die Blockchain (Datensatzkette) und ihre berühmteste Anwendung „Bitcoin“ ein weltweites Phänomen. – Die in diese Blöcke geschriebenen Daten sind die „finanziellen“ Transaktionen zwischen zwei Parteien. Es ist letztendlich ein elektronisches Hauptbuch. Deshalb wird die Blockchain manchmal als ein verteiltes Hauptbuch bezeichnet.

Beispiel für eine Blockchain: Bitcoin

Da alle Knotenpunkte unabhängig voneinander sind und alle eine Kopie der Kette (bzw. des Hauptbuches) haben, ist keine einzelne Person für eine zentral zertifizierte Kopie verantwortlich. Jeder hat die echte Kette. Ein vertrauenswürdiger Dritter (trusted third party - TTP) ist nicht notwendig. Bitcoin wird als Kryptowährung bezeichnet, da sie garantiert, dass niemand einfach Bitcoins „drucken“ bzw. generieren und somit die Währung entwerten kann. Bei einer normalen Währung ist die Zentralbank des jeweiligen Landes dafür verantwortlich – eine einzelne potenzielle Schwachstelle. Die dezentrale Währung „Bitcoin“ ist unabhängig von jeglichem „Druck einer Regierung“. Bitcoin hat keinen TTP, kann nicht durch eine technische Dienstverweigerungsattacke angegriffen werden (DoS - Denial of Service) und ihr Betrieb kostet praktisch nichts.

Visa bietet die gleiche Funktionalität für Kredittransaktionen. Aber da Visa keine verteilte Technologie nutzt, investiert das Unternehmen jährlich große Summen, um seine zentralisierte Client/Server-Architektur vor DoS-Attacken zu schützen. Weltweit sind Millionen Kunden (Kreditkartenautomaten) mit seinem Hauptserver verbunden. Visa gewährleistet die Leistung seines Systems und seine Sicherheit – sie sind somit der TTP – und verlangt eine großzügige Entschädigung für seinen Aufwand in Form von Gebühren.

Wohin mit all den Daten?

Nun stellt sich die Frage, wohin mit den Daten, die zukünftig von den Milliarden Sensoren in der IoT-Welt generiert werden. Selbst wenn man eine zentralisierte Client/Server-Architektur, die leistungsfähig genug und gegen DoS-Attacken gesichert ist, bauen könnte, sollte wirklich ein Unternehmen die Daten aller Sensoren weltweit kontrollieren? Sensordaten könnten direkt im Hauptbuch gespeichert werden und individuelle Kunden könnten individuelle Sensoren direkt kontaktieren und ihre Daten unabhängig, sicher und kostengünstig, ohne teure TTPs als Zwischenhändler, erhalten.

Konzept und Herausforderungen von Smart Contracts

Smart Contracts sind Computerprotokolle, die auf jedem Knotenpunkt in der Kette ausgeführt werden. Definierte Eingangsdaten führen zu definierten Ausgabedaten (idealerweise wie ein rechtliches Dokument). Diese Smart-Contract-Entscheidungen sind zuverlässig, da sie überall ausgeführt werden und das Ergebnis wird in der Datensatzkette auf transparente, überprüfbare und permanente Weise dokumentiert.

Smart Contracts laufen auf einer virtuellen Maschine, die unabhängig von der Hardware, auf der sie ausgeführt wird, sein muss, da es alle möglichen Knotenpunkte ausführen muss und deshalb keinen Zugriff auf Hardware- bzw. Sensorinformationen hat. Eine weitere große technische Hürde: Smart Contracts laufen auf jedem Knotenpunkt, und wenn die Information nur von einem Sensor verfügbar ist, empfiehlt es sich nicht, dass viele Millionen Knotenpunkte gleichzeitig dieselben Informationen vom selben Sensor abfragen.

Da die Ethereum-Blockchain, ein Konkurrent von Bitcoin, als erste Smart Contracts umgesetzt hat, begann sie, an einer Lösung zu arbeiten: Oracles.

Eine mögliche Lösung: Oracles

Oracles sind spezielle Knotenpunkte in einem Netzwerk, die Informationen für die Smart Contracts bereitstellen. Die Hardware-Sensoren liefern ihre Informationen und stellen sie dem Oracle bereit, welches sie an die Kette verteilt. Das Oracle funktioniert somit wie ein Daten-Proxy.

Konzept und Herausforderungen von Smart Contracts

Das Problem der Vertrauenswürdigkeit

An dieser Stelle taucht jedoch das Problem der Vertrauenswürdigkeit wieder auf. Das Oracle kann Daten der Sensoren ändern, bevor sie die Datensatzkette erreichen. Sobald die übertragenen Daten in der Datensatzkette sind, kann ihnen ohne einen TTP vertraut werden – aber den Oracle-Anbietern muss vertraut werden. Die Oracle-Anbieter lassen sich von zentralisierten Zertifizierungssystemen zertifizieren. Das bedeutet jedoch, der TTP ist wieder da (nur in einer anderen Form) und gleichzeitig zentralisiert (wie Verisign für vertrauenswürdige Webseiten). Ein einfacher DoS-Angriff auf die Zertifikat-Anbieter oder auf die Oracles selbst könnte das gesamte IoT-System außer Gefecht setzen.

Eine Option wäre, die Daten an verschiedene unterschiedliche Oracles bereitzustellen und Redundanz zu verwenden. Jedoch wird es den meisten Organisationen zu teuer werden, ausreichend Oracles einzurichten. Ein Open-Source-Oracle-Server, der universell gehostet werden kann, könnte die Lösung für die Bereitstellung der Daten, aber nicht für die Frage der Vertrauenswürdigkeit sein.

Ein Zertifikat „vertraut“ nur dem Oracle-Knotenpunkt. Der Sensor, der die Informationen bereitstellt, könnte kompromittiert sein und das Oracle würde es nicht wissen, oder – noch schlimmer – es „wäre ihm egal“. Die Oracle-Hersteller stellen nur den Service bereit, Informationen in die Datensatzkette zu bringen. Sie können realistisch nicht alle Sensor-Anbieter überprüfen.

Natürlich könnten die Sensor-Anbieter sich ebenfalls selbst zertifizieren und sagen, ihre Hardware/Firmware lässt sich nicht hacken und ist vertrauenswürdig. Aber hier taucht wieder das TTP-Problem auf, Kundenbindung und höhere Kosten für Ihr System.

Mit der Einführung eines solchen TTPs ist der Einsatz einer dezentralen vertrauenswürdigen Datensatzkette fragwürdig. Ein zentralisiertes „Standard“-Datenbank-Netzwerk bietet die gleiche Funktionalität mit, letztendlich, den gleichen Nachteilen.

Die ideale Lösung: Vertrauenswürdige Kamerasensoren

Idealerweise würden die Sensoren Daten erzeugen, die dann vom Endanwender (mit einem Smart Contract) überprüft werden können, um zu sehen, ob die Daten während des Übertragungswegs vom Sensor manipuliert wurden.

Bei einem Kamerasensor wäre zum Beispiel der erste Schritt, das Bild mit einem Hash (Streuwert) zu versehen und diesen Hash zu speichern. Wenn das Bild den Endkunden erreicht, würde er den erhaltenen Hash mit dem von ihm selbst generierten Hash vergleichen. Stimmen sie nicht überein, wurde das Bild manipuliert. Zusätzlich zu den Bilddaten kann der Hash weitere Informationen erhalten, z. B. die Firmware. Damit wäre das Bild einzigartig und würde sich auf eine spezifische Kamera und Firmware beziehen. Andere lokale Sensoren im System können vor der Übertragung in die Datensatzkette ebenfalls ihre Daten zum Hashing an das Kameramodul senden. Dann kann der Endanwender anhand des Bildes überprüfen, ob die Sensordaten manipuliert wurden.

Dies ist nur ein Beispiel für einen vertrauenswürdigen Kamerasensor [3]. Es gibt wahrscheinlich viele andere Optionen für andere Sensoren.

Fazit

Moderne wechselseitige, Blockchain-basierte Netzwerke funktionieren ohne vertrauenswürdige Dritte. Dies ermöglicht bessere Skalierbarkeit und vermeidet die Einbeziehung bezahlter vertrauenswürdiger Dritter. Leider muss die Bereitstellung von Sensordaten an Smart Contracts in der Kette über Daten-Proxys geschehen. Um eine Monopolisierung der Daten durch diese Oracle-Proxys zu vermeiden, wurde ein unabhängiger Algorithmus für die Selbstvalidierung der Daten eines Kamerasensors eingeführt. Hoffentlich werden weitere Sensorhersteller folgen, um ein wirklich dezentrales Netzwerk ohne vertrauenswürdige Dritte zu gewährleisten.

LITERATURNACHWEISE

[1] M. Iansiti, K.R. Lakhani "The Truth about Blockchain", Harvard Business Review, January 2017.

[2] D. Drescher, „Blockchain Basics“, mitp, Kapitel 14, 2017.

[3] Patent ang.