Cloud und es wird geklaut

Die Kryptographie und die daraus abgeleiteten Methoden zur digitalen Unterschrift, erlauben allen „Dingen“, die einen Algorithmus ausführen können, sich eindeutig auszuweisen. Anders gesagt, etwas so zu unterzeichnen, dass man eindeutig nachweisen kann, welches „Ding“ hier unterzeichnet hat. Das Problem, welches sich in der Praxis ergibt, ist der private Schlüssel und dessen Schutz. Der Schlüssel könnte kopiert werden, wobei es niemand bemerken würde und noch viel schlimmer, der Schlüssel könnte verloren gehen (technischer Defekt, versehentlich gelöscht oder überschrieben…). Es bleibt nichts anderes übrig, als den Schlüssel richtig-richtig stark zu sichern.

Durch die Sicherung des Schlüssels vor unbefugter Nutzung und Verlust, wird es allerdings schwierig diesen überall dort zu nutzen, wo man ihn braucht. Jeder der in einem Unternehmen schon einmal den Firmenstempel benötigt hat weiß, wie ein Spagat zwischen Sicherheit und Komfort aussieht.

Spätestens nach dem Zeitalter des Cloud-Computings sind wir es gewohnt, dass wir von jedem Ort der Welt und zu jedem Zeitpunkt alle Dienste nutzen können – und somit auch den Dienst etwas unterschreiben zu können. So wie wir Menschen dies gewohnt sind, so sind es auch die Programme/Tools/Apps, die wir heute nutzen, weshalb diese im Hintergrund meist die Cloud nutzen. Dort sollte aber niemals ein privater Schlüssel abgelegt werden…

Für unser Vorhaben im Zuge von ID-Ideal bedeutet dies, dass wir zwar die Cloud generell brauchen, da die Rechner am Edge nur relativ klein sind, aber dennoch die privaten Schlüssel immer dezentral – auf den Geräten – haben. Bedeutet für die Kommunikation zwischen dem Gerät und der Cloud, dass sie den selben Standards folgen müssen, denen auch eine Geräte zu Geräte Kommunikation entspricht. Mit diesen Hintergedanken ist die Open-Source Lösung SmartContractTX entstanden, ein Plugin für das Event-System Node-Red.

Wenn eine Cloudwallet keine ist. Der Spielverderber Stromzähler.

Um den Anwendungsfall unseres Projektes abbilden zu können, benötigt man zunächst Messwerte eines Stromzählers. Diese bekommt man recht einfach über ein weiteres Node-Red Plugin. Die digitale Signatur kann entweder unmittelbar auf einem Smart-Meter-Gateway erfolgen, oder simuliert und nachgelagert in Node-Red. Das Ergebnis werden immer vom Stromzähler digital unterschriebene Messwerte sein. Irgendwie müssen diese Messwerte nun weiterverarbeitet werden und in die Berechnung der Treibhausgasemission einfließen. Es sei angemerkt, dass zum Zeitpunkt der Unterschrift die Daten noch am Ort-und-Stelle der Entstehung sind.

Unser erster Ansatz war es, dass wir nun einfach eine Cloudwallet nutzen, um dort die Zählerstände zu speichern. Wir sind gescheitert! Um auf die für uns verfügbaren CloudWallets einen Datensatz ablegen zu können, war es notwendig die Zugriffsrechte auf die Wallet an den Ort der Messung zu übertragen. In einem Fall bestand dies aus einem Benutzernamen und Passwort, der fest hätte hinterlegt werden müssen. Dies widerspricht jedoch vollständig dem Ansatz von selbstbestimmten Identitäten (SSI), bei dem jedes Gerät selbst seinen Schlüssel erstellt und diesen nutzt, um sich „auszuweisen“. Von allen Sicherheitsbedenken abgesehen, gibt es keinen Grund, dass man ein Identifikationsmerkmal von außen einbringen muss. Der Merksatz, der bei uns aus dieser Irrung entstanden ist lautet:

Wenn beim Einsatz einer Self Sovereign Identity die Identität nur dadurch handlungsfähig wird, dass weitere Daten (Token, API Key, Benutzername,…) ergänzt werden, ist sie nicht selbstbestimmt und somit keine SSI.

Erster Merksatz zu Selbstbestimmten Identitäten der STROMDAO

In der IT ist ein gern gemachtes Prinzip: „Fake it – till you make it“. Diesem folgend hatten wir uns tatsächlich kurzfristig auf eine Krücke eingelassen, bei der wir (innerhalb unseres Node-Red Flows) ein Passwort und Benutzername „hard-coded“ hinterlegt haben. Es kam, wie es kommen musste und der Stromzähler wurde getauscht. Da der Benutzername/Passwort zur Identifikation bei der CloudWallet allerdings unverändert geblieben ist, spielten alle nachgelagerten Prozesse verrückt. Works-As-Designed bedeutete hier, dass der alte Stromzähler (etliche Jahre bereits in Betrieb) einen deutlich höheren Zählerstand hatte, als der neue Zähler, der fast mit einem Zählerstand von „0“ eingebaut wurde. Die Prämisse, dass der Zählerstand immer höher wird, war hinterlegt und … da aus Sicht der Berechnungsprozesse die Unterschrift des Zählers vorhanden gewesen ist, gab es auch keinen Grund zu zweifeln.

In der Informatik macht man sich häufig Probleme, die man ohne diese nicht hat. Was durch unserem Workarround nach Cloudwallet-Schiffbruch entstanden ist, hätte es bei händischen (von Menschen durchgeführten) Prozessen nicht gegeben. Alice hätte den Zähler abgelesen und hätte wie ein Mensch reagiert, wenn plötzlich der Zählerstand niedriger gewesen wäre , was zu einer Eskalation geführt hätte in dessem Zuge wahrscheinlich bemerkt worden wäre dass der Zähler zwischenzeitlich getauscht wurde. Vom Mensch kann man hier lernen, dass man immer einen Lösungsweg neben dem „so ist es immer“ haben muss. Bewehrt hat sich für die Stabilität von Software-Architekturen das Schweizer-Käse-Modell der Resilienz, auf allen Ebenen der Verarbeitung zunächst davon ausgeht, dass die Eingangsdaten falsch sind – ein Faktum, den wir eigentlich durch die digitale Unterschrift ausschließen wollten.

Als Erkenntnis für das Projekt, haben wir jedoch etwas anderes mitgenommen. Das Problem entstand durch den Workarround, welcher notwendig wurde, da zur Identifikation ein anderes Werkzeug eingesetzt wurde, als sonst in der Architektur vorgesehen gewesen ist. Eine Schwäche, die mir persönlich schon sehr häufig in größeren Projekten mit entsprechenden Teamgrößen untergekommen ist: Das Projekt ID-Ideal soll Sichere Digitale Identitäten nutzbar machen, aber wir nutzen kurz eine ganz anderes Werkzeug zur Identitätssicherung, nur weil dieses eben schon erprobt und überall im Einsatz ist.

Wenn Du in einem System ein Werkzeug nutzen musst/willst, dann verstehe vorher, wo es überall zum Einsatz kommt und vertraue, dass es funktioniert.

Das Stromzähler-Tausch-Problem lässt sich übrigens auch mit digitalen Identitäten sehr elegant lösen. Als Vorbild kann man hier die SIM-Karten nutzen, die Mobilfunkanbieter früher an ihre Kunden versendet haben. Diese erfüllen (auch wegen des Vorhandenseins eines privaten/öffentlichen Schlüssels) alle Bedingungen einer selbstbestimmten Identität. Sobald die Karte in das Handy eingelegt wird, könnte das Handy telefonieren, aber beim Mobilfunkanbieter muss noch ein sogenanntes „Provisioning“ durchgeführt werden. Diesen Vorgang kennen wir als „Aktivierung der SIM“. Hierbei wird beim Betreiber (der im Prinzip die Cloudwallet ist), der Vertrag der SIM-Karte zugeordnet. Durch diesen Vorgang wird sichergestellt, dass jede SIM-Karte theoretisch in Betrieb genommen wird, aber auch bei Verlust auf dem Weg zum Kunden kein Schaden entstehen kann. Wichtig ist, weder auf der SIM-Karte noch auf dem Handy wird irgend eine Veränderung vorgenommen (keine Daten aktualisiert). Überträgt man dieses Vorgehen auf den Zählertausch, so ist die Lösung hier, dass die Cloudwallet jeden „Absender“ akzeptieren muss und dessen Identität vertraut. Die heutigen Stromzähler haben einen Schlüssel und signieren ihre Daten entsprechend.

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Inhalt nicht verfügbar.
Bitte erlauben Sie Cookies, indem Sie auf Übernehmen Sie auf das Banner