Nachverfolgbare und verifizierbare Lieferketten stehen nicht erst seit der Verabschiedung des – durchaus kontrovers diskutierten – Lieferkettengesetzes im Fokus der Betrachtung Einiger.
Im Kern geht es darum, Warenproduktions- und Lieferketten lückenlos zu dokumentieren und überprüfbar zu machen. Ein Aspekt davon kann die manipulationssichere Speicherung der Informationen sein.
Bei oberflächlicher Betrachtung kann man hier auf die Idee kommen, eine klassische Blockchain – samt kostenintensivem und/ oder komplexem Konsensalgorithmus – zu verwenden.
Grundsätzlich ist eine Blockchain (mit Proof of something) auch geeignet, eine unveränderliche Warenkette darzustellen. Jedoch beinhaltet das, was zur heutigen Zeit unter Blockchain verstanden wird, in der Regel einen Konsensalgorithmus. Dieser ist jedoch bei einer Blockchain mit restriktiertem Zugang eher hinderlich. Um genau diese Art handelt es sich bei der hier vorgestellten Lösung: nur authentifizierte Stellen (nämlich die, die an der Lieferkette beteiligt sind), fügen Daten ein. Ein Konsens ist also mittels Authentifizierung automatisch gegeben und muss nicht erst aufwandsintensiv hergestellt werden. Auf Datenkonflikte gehen wir später noch ein. Der Meinung, dass eine private Blockchain, vereinfacht gesagt, lediglich eine sehr umständliche Datenbank ist, möchte sich die Autorin dieses Artikels ausdrücklich anschließen. Warenketten sind vom Prinzip her zugriffsbeschränkt, daher sind Vereinfachungen naheliegend.
Wir konzentrieren uns daher auf die eigentliche Bedeutung von “Blockchain”: eine Kette von Blöcken (hier: gerichteter Graph), bei der der Zustand jedes Blockes von seinen direkten Vorgängern abhängt.
Das Prinzip der Verifizierbarkeit einer “Chain of Blocks” besteht darin, dass Informationen, die den Vorgängerblock (bzw. die Vorgängerblöcke – wir kommen später noch zu dieser wichtigen Besonderheit) und dessen Inhalt verifizieren, in allen direkten Nachfolgeblöcken enthalten sind. Dafür könnte man einfach sämtliche Informationen des Vorgängerblockes in den Nachfolger übernehmen. Das bedeutet jedoch ein stetiges Anwachsen der einzelnen Blockgröße. Stattdessen verwendet man üblicherweise einen eindeutigen Repräsentanten des Blockinhaltes in Form einer Prüfsumme. So ist also in einem Block der Vorgänger durch eine Prüfsumme repräsentiert und der Vorvorgänger nur indirekt über Prüfsumme im Vorgänger enthalten. So lassen sich alle Vorgänger eines Blockes verifizieren und eine Veränderung der Vorgänger zieht eine Veränderung der Prüfsumme nach sich, was es unmöglich macht (abgesehen von Hashkollisionen), den Inhalt eines Blockes zu verändern, ohne auch alle nachfolgenden Blöcke zu verändern.
Für die Endverbrauchenden ist es entscheidend, dass auf dem Produkt sämtliche Informationen vorhanden sind, die notwendig sind, um die Warenkette vollständig zu verifizieren. Das kann eine Prüfsumme oder eine Signatur sein. Wir haben uns für letzteres entschieden. Es ist also ausreichend, die Signatur auf dem jeweiligen Produkt anzubringen. Um sie auch maschinenlesbar darstellen zu können, eignet sich ein QR-Code. Deren Speicherkapazität ist an die Größe und Auflösung gebunden. Also muss man eine Signatur auswählen, die relativ kurz ist (in Bezug auf die Zeichenanzahl), aber dennoch als kryptographisch sicher angesehen wird. Die üblicherweise auf Kassenzetteln verwendete Signatur hat deutlich über 100 Zeichen (in BASE64). Ein geeigneter Kandidat sind also ED25519 Signaturen, da sie nur aus 64 Bytes besteht. Überraschenderweise scheinen sich die Softwareautoren nicht einig darüber zu sein, was der private Schlüssel eines ED25519-Schlüsselpaares ist. Die Basis eines solchen Schlüssels bildet der sog. Seed, der aus 32 zufälligen Bytes besteht. Libsodium/ NaCL liefert jedoch etwas anderes, ebenso sensibles aus (openssl genpkey –algorithm ed25519 -> liefert PEM-Header + Seed). Dies wurde bereits vor etwa 10 Jahren deutlich festgestellt. Die Verwendung eines solchen “modernen” Schlüssels, hat also durchaus auch Nachteile. Insbesondere, wenn in Backend und Frontend unterschiedliche Technologien verwendet werden. Es besteht die Hoffnung, dass diese Unstimmigkeiten beseitigt werden, bevor die (effektive) Schlüssellänge (symmetrisch) von 128 Bit als unzureichend angesehen wird.
Datenkonflikte können prinzipbedingt auftreten, da es keinen Konsens-Algorithmus gibt. Das ist jedoch für die hiesige Anwendung vollkommen unerheblich: es werden einfach alle Zustände akzeptiert und im nächsten Verarbeitungsschritt dem neuen Zustand als Vorgänger hinzugefügt. Die so dargestellte Warenkette ist also ein gerichteter, azyklischer Graph.
Datenkonflikte werden in Blockchains durch den Konsensalgorithmus verhindert. Bei nebenläufigen Prozessen, die auch teilweise offline stattfinden können, ist dies weder sinnvoll noch angemessen. Daher werden alle Nachfolgeelemente als gültig anerkannt. Es obliegt dann der die Kette auswertende Software zu entscheiden, welcher der nebenläufigen Zustände der korrekte ist. Gegebenenfalls ist das aber auch vollkommen irrelevant für den jeweiligen Prozessschritt. Das System an sich erzwingt die Eindeutigkeit eines Zustandes nicht.
Auf dem fertigen Produkt wird dann die Signatur in Form des QR-Codes angebracht. Mit der Signatur lässt sich die gesamte Warenkette anfragen und es ist eine kryptographische Verifikation selbiger möglich. Es lässt sich im Nachhinein ein Datensatz der Kette nicht mehr ändern, ohne die Signatur auf dem Endprodukt zu invalidieren. Die Signatur stellt also das logische Äquivalent zur Abbildung der vollständigen produktindividuellen Lieferkette auf dem Produkt selbst dar. Auch eine solche beigelegte Liste ließe sich ohne Ersetzung des Produktes nicht verändern.
Es bleibt festzuhalten, dass es zahlreiche Möglichkeiten gibt, Daten veränderungssicher darzustellen. Die einen mögen dafür gleich fünf Blockchains verwenden, anderen reicht eine einfachere Lösung aus.
Bei der Bitcoin-Blockchain handelt es sich um ein öffentliches Transaktionsverzeichnis. Das bedeutet, dass sämtliche Transaktionen von allen (auch nicht Blockchainteilnehmern) vollständig einsehbar sind. Datenschutzfreundlichere Alternativen existieren jedoch (beispielsweise Monero).
Die hier umgesetzte Lösung bietet die Möglichkeit die Inhaltsdaten komplett auszublenden und berechtigungsabhängig anzuzeigen. Ohne dabei die Verifizierbarkeit der Kette zu verlieren. Ein ähnliches Konzept verfolgt in diesem Bereich auch die Hyperledger-Blockchain. Hyperledger setzt auf SHA256 ohne (erzwungenen) Salt und ohne zusätzliche Iterationen, wohingegen die hiesige Lösung auf Blake2 mit Salt und mehrere Iterationen setzt.
Grundsätzlich verfolgen wir hier das goldene Prinzip “Never do your own crypto” – baue nie Deine eigene Verschlüsselung. Das Zusammenstecken dieser etablierter Verschlüsselungskomponenten ist bereits hinreichend komplex.
Zum Absichern der Warenketten verwenden wir also eine beliebig verzweigbare und rekombinierbare Kette von kryptographisch aufeinander aufbauenden Blöcken mit beliebigem Inhalt. Man stelle sich das System am ehesten wie ein Git (Software-Versionsverwaltung) vor, bei dem Inhaltskonflikte jedoch keine Rolle spielen.
Weitere Möglichkeiten dieser Art der Datenspeicherung umfassen
- Zugangsberechtigungen zu einzelnen Blockbestandteilen
- Private Blockbestandteile, deren Werte nicht in der Kette vorgehalten werden, aber dennoch verifiziert werden
- Möglichkeit der Dezentralität der Datenhaltung (Verschiedene Warenkettensysteme können verbunden werden)
- Löschung von Blockbestandteilen, ohne die Datenintegrität zu verletzen (hinzufügen/ abändern von Informationen ist natürlich nicht möglich) – das kann wichtig für DSGVO-Anfragen sein
- Sämtliche Daten können in der Kette gehalten werden
Natürlich ist auch eine wie auch immer kryptographisch verifizierbare Kette an Informationen kein Garant für die Korrektheit des Inhaltes (es gilt auch hier: garbage in, garbage out – wenn die Dateneingabe eine schlechte inhaltliche Qualität hat, ist auch die Aussagekraft einer verifizierten Kette schlecht). Es entfernt lediglich die Möglichkeit der nachträglichen Datenmanipulation (bis auf das Löschen) nach Veröffentlichung des letzten Blockes.
Die genannten Aspekte werden bei der Umsetzung der Lieferkettennachverfolgbarkeit der SusChain-Platform berücksichtigt.