DE102016007472A1

DE102016007472A1 - Verfahren zur Registrierung von multiplen Fahrzeugdaten in einer Blockchain und Sicherung gegen nachträgliche Änderungen

Info

Publication number: DE102016007472A1
Application number: DE102016007472.8A
Authority: DE
Inventors: Anmelder Gleich
Original assignee: Individual
Current assignee: Jeschke Michael Dipl Ing De
Priority date: 2016-06-18
Filing date: 2016-06-18
Publication date: 2017-12-21

Abstract

Fahrzeugbezogene Daten wie der Kilometerstand oder das Fahrtenbuch können aktuell nachträglich rückwirkend manipuliert werden, ohne dass dies von Dritten bemerkt wird. Die Erfindung beschreibt ein Verfahren zur Registrierung von Fahrzeugdaten in einer Blockchain und Sicherung gegen nachträgliche Änderungen. Fahrzeugbezogene Daten wie der Kilometerstand oder der Aufenthaltsort werden zeitnah erfasst und mittels einer kryptologischen Hashfunktion unter Wahrung des Datenschutzes via Internetverbindung in einer Blockchain wie z. B. der öffentlichen dezentralen Bitcoin Blockchain registriert. Dadurch entsteht eine kryptografisch geschützte Historie von Zustandsdaten, die nicht mehr nachträglich unbemerkt umgeschrieben und gefälscht werden kann. Eine optional durch einen zentralen Server unterstützte gleichzeitige Registrierung der Fahrzeugdaten vieler Millionen Fahrzeuge erlaubt es dabei, die Registrierung kostengünstig und Datenmengen-effizient zu gestalten, indem hohe Blockchain-Transaktionsgebühren und eine Überlastung der Blockchain-Kapazität vermieden werden, ohne dass die Wirksamkeit des Verfahrens leidet. Damit gibt es eine nachhaltig skalierbare Lösung zur Erhöhung der Vertrauenswürdigkeit von Laufleistungsangaben bei Gebrauchtwagen oder von elektronisch geführten Fahrtenbüchern unter Wahrung von Datenschutz-Belangen.

Description

EINLEITUNG
Die Erfindung betrifft ein Verfahren zur Registrierung von chronologischen Fahrzeugdaten wie z. B. dem Kilometerstand in einer Blockchain, wodurch diese Daten gegen nachträgliche Änderungen geschützt werden. Die Erfindung findet im Bereich der Automobilindustrie Anwendung und ist auf technischem Gebiet im Bereich der Internet-Blockchain-Technologie angesiedelt. Letztere wurde vor allem durch die digitale Krypto-Währung Bitcoin bekannt, welche seit dem 3. Januar 2009, 18:15:05 Uhr GMT existiert.
STAND DER TECHNIK
Nach aktuellem Stand der Technik können Aufzeichnungen über Zustandsdaten eines Fahrzeugs, wie z. B. der Kilometerstand, oft mit entsprechenden technischen Mitteln nachträglich geändert werden, ohne dass dies nach außen sichtbar wird. So existiert beim Gebrauchtwagenhandel heute das Problem, dass Kilometerzähler von zu verkaufenden Gebrauchtwagen vom Verkäufer häufig manipuliert werden, um die Laufleistung eines Autos niedriger erscheinen zu lassen und somit seinen Wiederverkaufswert zu steigern. Diese Art der Manipulation lässt sich oft kaum nachweisen, benachteiligt ehrliche Autoverkäufer, und fügt Wirtschaft und Endverbrauchern Schaden zu. Herkömmliche Anstrengungen, solche Manipulationen an der Fahrzeugelektronik wie z. B. am Kilometerzähler zu verhindern, scheitern regelmäßig daran, dass immer wieder Hintertüren gefunden werden, um etwaige Sicherungsmaßnahmen zu umgehen und eine nachträgliche spurlose Manipulation der Elektronik wie z. B. des Kilometerzählers vorzunehmen.
AUFGABE DER ERFINDUNG
Die vorliegende Erfindung bietet eine Lösung, durch die ein Gebrauchtwagenverkäufer zweifelsfrei nachweisen kann, dass der Kilometerzähler eines Automobils nicht nachträglich signifikant manipuliert wurde. Ebenso kann sich ein Gebrauchtwagenkäufer oder Interessent mittels dieser Erfindung vergewissern, dass keine derartige Manipulation vorliegt. Erreicht wird dies mittels mathematisch-kryptografischer Verfahren und einer vorzugsweise dezentralen und öffentlichen Blockchain, welche eine mit Zeitstempeln versehene unverfälschbare chronologische Datenbank darstellt. Diese Erfindung ist vom Ansatz her losgelöst von etwaigen Software-Hintertüren in der Fahrzeugelektronik und schlägt damit einen völlig neuen Lösungsweg für das genannte Problem ein. Denn selbst unter Aufbringung aller Mittel, die Fahrzeugelektronik eines Gebrauchtwagens nach Belieben zu verändern, wäre es dennoch nicht möglich, die in der Blockchain bereits registrierte Historie dieses Fahrzeugs zu löschen oder zu ändern, denn dazu müsste nicht das Auto sondern die Blockchain manipuliert werden, was erstens unrealistisch teuer und aufwändig wäre und zweitens bei öffentlichen Blockchains nicht unbemerkt von der Weltöffentlichkeit geschehen könnte. Somit kann eine derartige Manipulation de-facto praktisch ausgeschlossen werden. Daher ist mit dieser Erfindung das Problem der nachträglichen spurenlosen Kilometerstands-Rückstellung durch einen Gebrauchtwagenverkäufer endgültig gelöst. Der Gebrauchtwagenverkäufer könnte den Kilometerstand abhängig von der genauen Ausgestaltung der Erfindung eventuell unwesentlich um einige 100 km manipulieren, aber nicht in wirklich relevanten Größenordnungen.
Neben dem Kilometerstand lassen sich auch andere historische Fahrzeugdaten wie z. B. Reparatur- oder Wartungsmaßnahmen auf gleiche Weise gegen nachträgliche Verfälschungen oder Verschleierungen von Informationen sichern.
Ein anderer Anwendungsfall für die vorliegende Erfindung ist die Realisierung eines elektronisches Fahrtenbuchs als eine weitere spezielle Chronologie von Fahrzeug-Zustandsdaten. Hierfür stellt diese Erfindung eine kostengünstige Lösung dar, mit der ohne das Vorhandensein einer zentralen Vertrauensinstanz nachgewiesen werden kann, dass vergangene Einträge in ein elektronisches Fahrtenbuch zeitnah geschahen und nicht nachträglich abgeändert wurden. Somit sollte ein derartiges elektronisches Fahrtenbuch z. B. bei Steuerbehörden höhere Akzeptanz finden als etwa handschriftlich erstellte Fahrtenbücher oder mit herkömmlichen Mitteln erstellte elektronische Fahrtenbücher.
WESEN DER ERFINDUNG
Unter Fahrzeugdaten (D1) werden unterschiedlichste Arten von Informationen verstanden, die den Zustand eines Fahrzeugs zu einem gegebenen Zeitpunkt beschreiben. Hierzu gehören z. B. die Fahrzeugkennung wie Fahrgestell-Nummer, der Kilometerstand, Datum, Uhrzeit, Abfahrts-, Ankunfts- oder Aufenthaltsort, die Nutzungsart (z. B. privat/beruflich), Wartungsmaßnahmen, aber auch beliebige Zusatzinformationen, die manuell vom Benutzer oder automatisch von einem Computerprogramm dem Fahrzeugdaten-Eintrag hinzugefügt werden, wie z. B. freier Text oder vom Computer generierte Zufallszahlen. Fahrzeugdaten-Einträge (D1) zu einem Auto (A1) werden gemäß dieser Erfindung während der Lebenszeit des Autos wiederholt und in einer gewissen Regelmäßigkeit in einem nach Möglichkeit öffentlichen dezentralen chronologischen und fälschungssicheren Verzeichnis wie z. B. der Bitcoin Blockchain mittels spezieller Transaktionen „registriert”. Transaktions-Einträge in solch einer Blockchain-Datenbank sind in Blöcken zusammengefasst, welche mit Zeitstempeln versehen sind. Das öffentliche Blockchain-Verzeichnis selbst hat unterdessen die Eigenschaft, dass es dezentral arbeitet und durch kryptografische Sicherungsmaßnahmen unverfälschbar ist. Aufgrund dessen kann zu einem späteren Zeitpunkt gegenüber Dritten zweifelsfrei nachgewiesen werden, dass eine vorliegende dokumentierte Fahrzeug-Historie nicht nachträglich rückwirkend verändert worden ist sondern den Originaleinträgen entspricht. Dieser Nachweis ist aufgrund der Dezentralität und kryptografischen Sicherung des öffentlichen Bitcoin Blockchain-Verzeichnisses kostengünstig ohne Vorhandensein einer zentralen Vertrauensinstanz wie z. B. eines Automobilherstellers, einer Versicherung, einer Behörde oder eines Notars möglich. Durch eine geeignete Verkettung kryptologischer Hashs (auch kryptographische Hashs genannt) dieser Fahrzeugdaten lässt sich außerdem später nachweisen, dass die vorgelegte Fahrzeugdaten-Chronologie vollständig ist, d. h. dass nicht nachträglich Fahrzeugdaten-Einträge beim Nachweis zurückgehalten werden. Neben der Bitcoin-Blockchain gibt es viele weitere Blockchains, die nach dem gleichen Prinzip funktionieren, wie zum Beispiel Litecoin, Ethereum, Peercoin, Dash oder Vertcoin.
Ein weiteres Wesensmerkmal dieser Erfindung ist die Wahrung des Datenschutzes: Der Fahrzeugbesitzer legt die zu registrierenden Daten wie z. B. den aktuellen Kilometerstand seines Autos NICHT offen, wenn er diese Daten in der öffentlichen Blockchain registriert oder registrieren lässt. Erst später, zum Zeitpunkt des geforderten Nachweises, wenn die Integrität, also die Unverfälschtheit und ggf. auch die Vollständigkeit, der aufgezeichneten Fahrzeugdaten-Historie (KH1) belegt werden soll, kann der Zeitverlauf der Fahrzeug-Zustandsdaten (D1) vollständig, oder wahlweise auch teilweise ausgeschwärzt, gegenüber einem Dritten wie etwa einer Behörde oder einem Kaufinteressenten dargelegt werden.
Im bevorzugten Ausführungsbeispiel 2 dieser Erfindung erfolgt eine Bündelung der Registrierungen von Daten (D2) vieler Fahrzeuge (A2) durch eine einzige Blockchain-Transaktion (= z. B. Bitcoin Transaktion) (210). Dadurch können die im Blockchain-Netzwerk anfallenden Transaktionsgebühren (z. B. ”Bitcoin TX fees”) wie auch die Gesamt-Last für das Blockchain-Netzwerk stark reduziert werden, ohne dass der Datenschutz oder die Aussagekraft des Nachweises gemindert wird.
Die zeitbezogene Registrierung eines Fahrzeug-Zustandes erfolgt dadurch, dass zunächst ein Computer (C1) wie z. B. der Bordcomputer eines Fahrzeugs, oder auch ein Smartphone, die zu registrierenden neuen Daten zu einem Daten-Eintrag (D1) zusammenfasst. Danach berechnet er einen Hashwert (Z1)(Y1)(Z1')(X1), der sich je nach Realisierungsvariante in bestimmter Weise aus aus dem Daten-Eintrag (D1) und möglicherweise noch aus anderen Hashwerten (X1)(Y1), die mit früheren Daten-Einträgen (D1) assoziiert sind, errechnet. Dieser Hashwert (Z1)(Y1)(Z1')(X1) wird entweder direkt in der Blockchain (200) registriert – wofür es mehrere Optionen gibt wie weiter unten beschrieben – oder er wird an einen zentralen Registrierserver (100) gesendet, welcher eine gebündelte Registrierung für viele Fahrzeuge (A2) gleichzeitig in der Blockchain (200) vornimmt. Im letzteren Fall erhält der Registrierserver (100) entsprechende Hashwerte (Z2)(Y2)(Z2')(X2) von vielen unterschiedlichen Fahrzeugen (A2), je einen pro Daten-Eintrag (D2) von jedem Fahrzeug, und sammelt sie in einem Gesamtdatensatz (110). Von diesem Gesamtdatensatz (110) berechnet der Registrierserver (100) einen Gesamt-Hashwert (120), den er dann in der Blockchain (200) registriert. Zur Verifikation der Integrität eines Fahrzeugcomputer-Daten-Eintrags (D1) benötigt eine Verifikations-Software (VS300) in diesem Falle neben den Daten (D1) selbst auch noch einen ergänzenden Satz (111_1) einzelner Hashwerte vom Registrierserver (100), um selber den Gesamt-Hash (120) zu diesem Eintrag (D1) und dessen assoziierten Hashwert (Z1)(Y1)(Z1') (X1) berechnen zu können. Sodann kann die Software (VS300) in der Blockchain (200) nach diesem Gesamt-Hash (120) suchen. Wenn dieser Gesamt-Hash (120), oder ein „Fingerabdruck” desselben (z. B. eine Bitcoin-Adresse, die sich aus der Bitsequenz dieses Hashs mittels einer Einwegfunktion errechnet), in der Blockchain gefunden wird und der Zeitstempel dieses Blockchain-Eintrags nicht zu stark vom Datum des Daten-Eintrags (D1) abweicht, dann gilt die zeitnahe Registrierung des Daten-Eintrags (D1) in die Blockchain (200) als verifiziert, und die Daten (D1) sind damit validiert. Andernfalls kann von einer nachträglichen Manipulation des Daten-Eintrags (D1) ausgegangen werden, was z. B. auf eine Manipulation am Fahrzeugcomputer (C1) oder eine anderweitige nachträgliche Datenverfälschung hindeuten kann.
Zur Terminologie „Registrierserver”:

• Wenn in dieser Erfindung von einem Registrierserver die Rede ist, dann kann damit auch stets eine Gruppe von Computer gemeint sein, die miteinander kommunizieren und zusammenarbeiten, um die beschriebenen Aufgaben zu erledigen, die hier als Aufgaben des „Registrierservers” beschrieben werden. Zum Beispiel ist es denkbar, dass die Kontaktierung der Blockchain zur Registrierung des Hashwertes von einem auf Bitcoin-Transaktionen spezialisierten separaten Computer erledigt wird, und dieser nicht mit dem Computer identisch ist, welcher mit dem Computer (C1) des Fahrzeugbesitzers kommuniziert. Für den Zweck dieser Erfindung ist dieses Detail aber unerheblich, und darum sollte unter dem Begriff „Registrierserver” eine Gruppe von >=1 Computern verstanden werden, von denen mindestens einer ein Internet-Server ist.

Der Computer (C1) zeichnet die Chronologie (KH1) der Fahrzeugzustandsdaten (D1) auf und speichert sie in einem nicht-flüchtigen Speicher (M1) als Datenbank oder als Datei ab. Im einfachsten Falle ist diese Chronologie (KH1) eine CSV (comma separated variable) Textdatei. Neue Daten-Einträge dieser Chronologie bestehen aus den eigentlichen Nutzdaten (D1) und vorzugsweise zusätzlich einem oder mehreren Hashwerten (Z1)(Y1)(X1)(111_1), vgl. . Im einfachsten Fall wird bei einem neuen Eintrag in die Chronologie eine neue Zeile an die Chronologie-Datei (KH1) im CSV-Format angefügt. Der eine Hashwert, der Zeilenhashwert (Z1) eines solchen Eintrags, ist der Hash über alle Nutzdaten (D1) eines neuen Eintrags. Der optionale zweite Hashwert zum aktuellen Eintrag, der Verkettungshashwert (Y1), errechnet sich einerseits aus den Daten (D1) des aktuellen Eintrags (oder vorzugsweise aus deren ersten Hashwert (Z1)) und andererseits aus dem Vorgänger-Eintrag oder (vorzugsweise aus dessen Verkettungshashwert (Y1)). Alternativ ist es auch denkbar, nur einen einzigen Hashwert (X1) pro Dateneintrag (D1) zu erzeugen, wobei dieser Hash (X1) dann aus dem aktuellen Daten-Eintrag (D1(k)) und dem Hash (X1(k – 1)) des vorangegangenen Dateneintrags (D1(k – 1)) gebildet wird. Diese Alternative ist aber eine suboptimale Lösung, wie die Beschreibungen zu und aufzeigen.
Es muss nicht jeder einzelne Eintrag (D1(k)) der Fahrzeug-Chronologie (KH1) in der Blockchain direkt oder mittels Registrierserver registriert werden. Aufgrund der über Hashes (Y1)(X1) bewerkstelligten Verkettung der einzelnen Daten-Einträge ist es manchmal zur Vermeidung von Verschwendung von Datenrate oder Speicherplatz sinnvoll, einige Daten-Einträge nicht zu registrieren (vgl. Ausführungsbeispiel 3). Die nächste Registrierung schließt dann wegen der verketteten Hashes alle vorhergehenden Einträge mit ein. Um in der Fahrzeugdaten-Chronologie hierüber transparent zu sein, empfiehlt es sich, ein ”Blockchain-Registrierungs-Flag” als ein Feld in den Fahrzeugdaten (D1) mit aufzunehmen, welches anzeigt, ob der Daten-Eintrag (D1) dieser Zeile explizit registriert oder zunächst übersprungen wurde. Ein konkreter Anwendungsfall ist das elektronische Fahrtenbuch (siehe Ausführungsbeispiel 3), bei dem es oft mehrere Einträge (= Datenzeilen) pro Tag gibt, aber es ist vermutlich nicht notwendig, mehr als einmal täglich eine Registrierung in der Blockchain vorzunehmen.
Der Vorgang der Registrierung eines Hashs (Z1)(Y1)(Z1')(X1)(120) in der Blockchain (200) erfolgt dadurch, dass eine bestimmte Transaktion (210) an das Blockchain-Netzwerk (200) gesendet wird. Hierzu gibt es unterschiedliche Möglichkeiten, die von den Eigenschaften des jeweiligen Blockchain-Protokolls abhängen. Im Folgenden wird beispielhaft davon ausgegangen, dass die Bitcoin-Blockchain verwendet wird, und dass es sich bei den Hashes (Z1)(Y1)(Z1')(X1)(120) um 256-bit-Sequenzen handelt, wie etwa beim Hash-Algorithmus ”SHA-256”.
Eine erste Möglichkeit der Registrierung besteht darin, dass der Hashwert (Z1)(Y1)(Z1')(X1) (120) direkt als privater Schlüssel (private key) einer Bitcoin-Adresse aufgefasst wird. Aus diesem ”private key” kann gemäß Bitcoin-Spezifikation mittels Einwegfunktion eine Bitcoin-Adresse abgeleitet werden. Zum Zwecke der Registrierung wird darum eine Bitcoin Transaktion erzeugt, bei der ein beliebiger Bitcoin-Betrag an diese Adresse gesendet wird. Damit ist dann der 256-bit Hashwert (Z1)(Y1)(Z1')(X1)(120) in Form seiner dazugehörigen Bitcoin-Adresse (seinem „Fingerabdruck”) in der Blockchain registriert, d. h. für alle Zeiten verewigt. Denn es kann zwar sehr einfach aus der 256-bit Folge eine Bitcoin-Adresse, nicht aber aus einer Bitcoin-Adresse die zugehörige 256-bit Folge des privaten Schlüssels errechnet werden, denn das ist gerade die Eigenschaft der Einwegfunktion. Darum beweist die Existenz der Bitcoin-Adresse, dass der private key (= die 256-bit-Folge) zu dem Zeitpunkt des Auftretens der Bitcoin-Adresse in der Blockchain bereits existiert hat.
Eine zweite Möglichkeit der Registrierung in der Bitcoin Blockchain ist die, eine Bitcoin-Transaktion mit einem sogenannte OP_RETURN opcode durchzuführen. Dieser von Bitcoin unterstützte opcode ermöglicht es im Bitcoin Protokoll, bis zu 40 Bytes (= 320 bits) an beliebigen Daten in die Transaktionsdaten, und damit in die Blockchain, einzubauen. Das reicht aus, um die 256 bit eines SHA-256 Hash-Wertes in der Bitcoin Blockchain zu verewigen.
Es sind beliebig viele weitere Möglichkeiten denkbar, Bit-Sequenzen in der Blockchain zu verewigen (zu „registrieren”).
Allgemein bedeutet „Registrierung” eines Hashs oder auch einer beliebigen anderen Bitfolge „in der Blockchain” (ein Hash ist ja nichts anderes als eine bestimmte Folge von z. B. 256 bits), dass eine Bitcoin-Transaktion durchgeführt wird, die entweder den Hash/diese Bitfolge selbst enthält, oder ein Bitmuster enthält, das sich per kollisionsresistenter Einwegfunktion aus diesem Hash/dieser Bitfolge ableiten lässt. Bei kryptologischen Hash-Funktionen handelt es sich um solche Einwegfunktionen, darum ist auch z. B. eine Bitcoin-Adresse eine solche Einwegfunktion von einem 256-bit privaten Schlüssel, denn eine Bitcoin-Adresse wird mittels Hashfunktionen berechnet, die auf den 256-bit privaten Schlüssel angewendet werden.
Da Transaktionen in der Blockchain (200) in Blöcke (220) aufgenommen werden und diese Blöcke einen Zeitstempel besitzen (die Genauigkeit der Zeitstempel im Falle von Bitcoin beträgt wenige Stunden), beweist das Vorhandensein eines Hash-Wertes (Z1)(Y1)(Z1')(X1) (120) (oder einer per kollisionsresistenter Einwegfunktion daraus abgeleiteten Bitfolge wie z. B. der Bitcoin-Adresse) in der Bitcoin Blockchain, dass dieser Hashwert (Z1)(Y1)(Z1')(X1) (120) zum Zeitpunkt des Zeitstempels bereits existiert hat – ein Konzept, das im Allgemeinen als ”Existenzbeweis” (”Proof-Of-Existence”) bei Blockchains bekannt ist.
Zur Terminologie „Hash”:

• Mit Hash oder Hashwert ist in diesem Dokument immer das Ergebnis einer kollisionsresistenten Einwegfunktion gemeint, deren Umkehrfunktion sehr schwierig (d. h. mit vertretbarem Rechenaufwand praktisch unmöglich) zu berechnen ist. Hierzu gehören zum Beispiel die kryptologischen (= kryptographischen) Hashfunktionen SHA-256 oder RIPEMD-160. Aber auch das Berechnungsergebnis einer Funktion zur Berechnung des public key aus einem private key mit genannter Eigenschaft wird im Sinne dieser Erfindung als Hash oder Hashwert bezeichnet, obgleich die Verwendung kryptographischer Hashfunktionen wie SHA-256 oder RIPEMD-160 die bevorzugte Realisierungsvariante ist.

Weitere Details werden anhand der folgenden drei Ausführungsbeispiele erklärt.
AUSFÜHRUNGSBEISPIEL 1
Voraussetzungen:

• Ein Fahrzeug (A1) besitzt einen elektronischen Kilometerzähler und einen internen nicht-flüchtigen Speicher (M1), z. B. ein Flash Memory.
• Das Fahrzeug besitzt eine Datenanbindung ins Internet per Mobilfunk, wie es heute bei vielen Neuwagen schon Standard ist.
• Das Fahrzeug hat einen Boardcomputer oder Fahrzeugcomputer (C1), der in der Lage ist, Daten- und Datei-Operationen auszuführen und der Lesezugriff auf den Kilometerzähler und Zugang zum Internet hat.
• Zur Registrierung des Kilometerstands wird die Blockchain der dezentralen Digitalwährung ”Bitcoin” verwendet, dessen Protokoll sich auf tausende von Computern weltweit verteilt und seit 3. Januar 2009 18:15:05 GMT zuverlässig und unterbrechungsfrei arbeitet.

Beschreibung des Verfahrens im Detail:
In Abständen von jeweils wenigen Wochen bis einigen Monaten registriert das Fahrzeug (A1) mittels seines Computers (C1) und seiner Mobilfunkanbindung ans Internet seinen Kilometerstand in der Bitcoin Blockchain (200). Hierzu geht der Fahrzeugcomputer (C1) wie folgt vor:
Teil 1: Lokale Erstellung eines neuen Daten-Eintrags zum Kilometerstand:
Das Computerprogramm (C1) erstellt eine neue Zeile (E1) in einer zu Anfang leeren (oder nur aus der Überschriftzeile bestehenden) CSV-Textdatei bestehend aus folgenden Einträgen (weitere Felder wie z. B. ”freier Text/Kommentar/Random Nonce” könnten hinzukommen und sind hier nicht aufgeführt):
Beispiel-Eintragszeilen (E1) der Kilometerstand- und Daten-Historie (KH1):
Zum Zwecke der einfacheren Lesbarkeit in dieser Beschreibung werden die Hashwerte im Folgenden abgekürzt. Nun ist besser zu erkennen, dass die „Kilometerstand-Historie” oder „Fahrzeugdaten-Historie” (KH1) aus in diesem Falle vier Eintragszeilen (E1) besteht:
Der erste Eintrag (= 1. Zeile) (E1(1)) besagt, dass am 31.10.2016 das Fahrzeug mit Fahrgestellnummer XY12345 einen Kilometerstand von 15047 km hat. Gemäß Boardcomputer-Einstellung durch den Autobesitzer (B1) wird die Uhrzeit standardmäßig nicht erfasst. Der SHA-256 (256 bit) Hash-Wert der Zeichenkette ”XY12345, 31.10.2016,-,-,15047” ist weiter am Ende der Zeile als Zeilen-Hashwert (Z1(1)) ”e0fbdbxxx” vermerkt. Der zweiter Hashwert (Y1(1)) macht in der allerersten Zeile noch wenig Sinn, wird aber trotzdem berechnet, hier einfach als SHA-256 Hash des ersten Hashs (Z1(1)).
Der zweite Eintrag (= 2. Zeile) ist entsprechend aufgebaut. Der zweite Hashwert dieser Zeile ist der ”Verkettungs-Hashwert” (Y1(2)). Er ergibt sich durch Berechnung des Hashs der Hashwerte (Y1(k – 1)) aus vorhergehender Zeile und (Z1(k)) aus aktueller Zeile, in diesem Falle also:
Der dritte Eintrag ist entsprechend aufgebaut. Hier gilt für den ”Verkettungs-Hashwert” (Y1(3)):
Etc.
Teil 2: Zeitnahe Registrierung eines jeden neuen Zeilen-Eintrags (D1(k)) in der Bitcoin Blockchain – zum Beispiel des Eintrags am 17.07.2017 aus Zeile k = 3:
Der Fahrzeugcomputer (C1) veranlasst eine bestimmte Bitcoin-Transaktion (210) im Bitcoin-Netzwerk. Aufgrund des Designs der Bitcoin-Blockchain wird die Bitcoin-Transaktion, die damit stattfindet, dauerhaft für alle Ewigkeit in der Bitcoin-Blockchain (= dem Verzeichnis aller jemals stattgefundenen Bitcoin-Transaktionen) erhalten und nachvollziehbar bleiben. Das besondere an der bestimmten Bitcoin-Transaktion (210), die hier veranlasst wird, ist, dass die Bitcoin-Transaktionsdaten eine indirekte aber eindeutig zuordenbare Kennung des neuen Kilometerstands enthalten. Hierzu kann man sich des Zeilen-Hashwertes (Z1) des neu zu registrierenden Datenzeilen-Eintrags (D1) bedienen, natürlich jeweils für Zeile k = 3. Noch besser ist es, die Information über die Art der Verkettung der einzelnen Eintragszeilen (E1) ebenfalls in der Blockchain zu registrieren. Das ist einfach möglich, indem anstelle des Zeilenhashwertes (Z1) der Verkettungshashwert (Y1) der selben Eintragszeile verwendet wird, vgl. auch . Wie die Diskussion zu weiter unten zeigt, ist es sogar noch vorteilhafter, stattdessen einen kombinierten Hashwert (Z1') zu registrieren, der sich ergibt als Z1' = hash(Z1, Y1) der selben Eintragszeile (E1). Darum wird in diesem Beispiel der kombinierte Hashwert (Z1') registriert.
Eine Möglichkeit wäre nun, eine Transaktion (210) mit einem sogenannte OP_RETURN opcode zu veranlassen, die es ermöglicht, im Falle von Bitcoin bis zu 40 bytes (320 bits) an beliebigen Daten in die Blockchain einzubauen. Das reicht aus, um die 256 bit eines SHA-256 Hash-Wertes (Z1') in der Bitcoin Blockchain zu verewigen.
In diesem Beispiel wird ein anderes, im Prinzip gleichwertiges Verfahren, angewendet, indem der 256 bit Hashwert (Z1') als privater Schlüssel einer Bitcoin-Adresse aufgefasst wird. Aus diesem ”private key” kann gemäß Bitcoin-Spezifikation unter Verwendung bestimmter Hash-Funktionen eine eindeutige Bitcoin-Adresse generiert werden. Es wird nun eine Bitcoin Transaktion (210) veranlasst, bei der ein beliebiger Betrag an diese Adresse gesendet wird. Damit ist auch der 256-bit Hashwert (Z1') in der Blockchain für alle Zeiten verewigt (registriert). Diese letztgenannte Variante ist universeller, da sie die Zahlungsfunktion von Bitcoin direkt benutzt und nicht auf das spezielles Leistungsmerkmal OP_RETURN angewiesen ist, welches in zukünftigen Versionen des Bitcoin-Protokolls vielleicht verändert werden könnte.
Da SHA-256 eine kryptografisch sichere Hash-Methode (kollisionsresistente Einwegfunktion) ist, ist es mathematisch praktisch unmöglich, rückwärts aus einem Hashwert einen Datensatz zu generieren, der den gegebenen Hash erzeugt. Somit bedeutet alleine das Vorhandensein eines Hash-Wertes (oder seiner Bitcoin-Adresse) in der Bitcoin-Blockchain, dass die Daten, aus dem sich dieser Hash-Wert ableitet, zum Zeitpunkt des entsprechenden Bitcoin-Zeitstempels bereits existiert haben. Es lässt sich also nicht nachträglich eine Buchführung zurückdatieren, ohne die gesamte Bitcoin Blockchain ab diesem Zeitpunkt neu zu schreiben, was aufgrund der starken Sicherung dieser Blockchain praktisch unmöglich ist.
Es sei angemerkt, dass nur die Hashwerte (Z1') der Fahrzeugdaten in der Bitcoin-Blockchain registriert sind, und nicht die Daten selbst. Die zugrunde liegenden Original-Daten (D1) selbst (Fahrgestellnummer, Datum, Kilometerstand etc.) befinden sich weiterhin nur auf dem Fahrzeugcomputer (C1) bzw. dessen Flash-Speicher (M1) und sind nicht öffentlich über die Blockchain (200) einsehbar. Natürlich ist es sinnvoll, von diesen Daten (D1)(KH1) auf herkömmliche Weise Sicherungskopien (Backups) anzulegen, z. B. manuell mittels USB-Stick am Auto, oder mittels automatisierter Backups auf Cloud-Services wie Dropbox oder Automobilhersteller-spezifische Cloud-Services, um sich gegen einen Hardware-Defekt abzusichern, der sonst die gesamte bis dato angefertigte Kilometerstand-Historie (KH1) auslöschen würde. Solche Backups finden natürlich außerhalb der Blockchain statt.
Teil 3: Validierung der Kilometerstand-Historie (KH1):
Zu einem späteren Zeitpunkt soll ein möglicher Gebrauchtwagenkäufer überprüfen können, ob der angezeigte Kilometerstand plausibel ist und nicht nachträglich manipuliert wurde. Zum Beispiel hat das Auto am 15.11.2017 einen Kilometerstand von 30123 km.
Dazu übergibt der Verkäufer dem Kaufinteressenten die Datei der Fahrzeugdaten-Historie (KH1) (z. B. überträgt er sie per E-Mail, USB-Stick, Bluetooth oder Near Field Communication aus dem Fahrzeugcomputer (C1) heraus auf das Smartphone des Kaufinteressenten). Die vom Kaufinteressenten auf dessen Smartphone eingesetzte Validierungs-Software (VS300) erhält also die folgende CSV-Textdatei:
Wie man sieht, hat der Verkäufer in diesem Beispiel vor dem Dateiexport eine Kilometerstands-Angabe aus Datenschutzgründen unkenntlich gemacht, was sein gutes Recht ist. Dennoch kann der Kaufinteressent mit Hilfe seiner Validierungs-Software-App (VS300) auf seinem Smartphone einiges mit Hilfe der Bitcoin Blockchain und deren Zeitstempeln verifizieren, nämlich...

• ...dass der Hash (Z1') = hash(e0fbdbxxx,89fcl6xxx) tatsächlich am 31.10.2016 in der Bitcoin Blockchain registriert wurde, und dass dieser Hash sich mittels Zeilenhash (Z1) ”e0fbdbxxx” aus dem Dateneintrag (D1) von Zeile 1 errechnet.
• ...dass der Hash (Z1') = hash(9d8db8xxx,9d0468xxx), tatsächlich am 17.07.2017 in der Bitcoin Blockchain registriert wurde, und dass dieser Hash sich mittels Zeilenhash (Z1) ”9d8db8xxx” aus dem Dateneintrag (D1) von Zeile 3 errechnet.
• ...dass der Hash (Z1') = hash(53631bxxx,34962cxxx), tatsächlich am 30.10.2017 in der Bitcoin Blockchain registriert wurde, und dass dieser Hash sich mittels Zeilenhash (Z1) ”53631bxxx” aus dem Dateneintrag (D1) von Zeile 4 errechnet.
• Weiterhin kann er nachvollziehen, dass Zeilen 1, 2, 3, 4 aufeinander aufbauen, aufgrund der Verkettungshashwerte (Y1) der letzten Spalte, die auch alle chronologisch in Form der kombinierten Hashwerte (Z1') in der Blockchain registriert sind. Das heißt, die vier Einträge sind voneinander abhängig und nacheinander entstanden und vollständig, d. h. es fehlt kein Glied in der Kette.

Auch kann der Kaufinteressent verifizieren, dass der Hashwert (Z1') = hash(e9d579xxx,407a47xxx) am 30.11.2016 in der Bitcoin Blockchain registriert wurde, aber der dazugehörige Dateneintrag (D1) ist aufgrund der geschwärzten Information nicht validierbar. Er ließe sich in diesem konkreten Beispiel jedoch durch reines Ausprobieren (bruteforce) aller Kilometer-Zahlen von 15047 bis 20987 dennoch ermitteln, was offenbar nicht im Sinne des Verkäufers wäre. Um also dem Datenschutzgedanken Rechnung zu tragen, bedürfte es noch einer zusätzlichen Spalte, in der freier Text oder eine zufällig Zeichenkette (”random nonce”) eingetragen werden kann, die dann ebenfalls zu schwärzen wäre. Dies würde dann eine brute-force Attacke auf die geschwärzte Information aussichtslos machen. Ausführungsbeispiel 3 illustriert die Verwendung so eines „random nonce”.
Der Kaufinteressent sieht nun also, dass bereits ab 31.10.2016 regelmäßige Buchführungen zum Kilometerstand des Autos durchgeführt worden sind, er sieht, wie viele solcher Registrierungen es gab, wann diese stattgefunden haben und dass sie lückenlos aufeinander aufbauen, und er sieht zu drei der vier Registrierungen (inkl. der jüngsten) auch den Kilometerstand selbst. Somit ist es ausgeschlossen, dass z. B. der tatsächliche Kilometerstand im Oktober 2017 viel höher war und etwa Anfang November 2017 stark zurückgestellt wurde. Bei einer häufigeren, z. B. einwöchentlichen, Kilometerstands-Registrierung wäre das Vertrauen in die Integrität dieser Daten noch höher.
Ein Betrug ist natürlich theoretisch immer noch nicht vollständig auszuschließen, er hätte dann aber schon im Voraus geplant über einen längeren Zeitraum stattfinden müssen durch von vornherein getätigte Blockchain-Registrierungen gefälschter Daten. So ein Szenario ist unrealistisch, weil in der Regel erst dann der Kilometerstand manipuliert wird, wenn der Gebrauchtwagenverkauf bevorsteht, und weil der normale Fahrzeughalter sich nicht schon im Voraus als Hacker betätigt, der den Fahrzeugcomputer manipuliert.
Ein Nachteil des hier beschriebenen Ausführungsbeispiels 1 ist, dass jedes Fahrzeug (A1) zur Registrierung eine eigene Blockchain-Transaktion auslösen muss. Dies kann zu hohen kumulierten Blockchain-Transaktions-Kosten führen. Außerdem ist die Blockchain möglicherweise auf so viele Transaktionen kapazitätsmäßig gar nicht ausgelegt, wenn Millionen von Fahrzeugen weltweit diese Methode verwenden. Zum Vergleich: Die Bitcoin Blockchain ist zur Zeit (Juni 2016) protokollseitig auf eine weltweite Transaktions-Kapazität von maximal rund 8 Millionen Transaktionen pro Monat begrenzt (diese Grenze ist seit Jahren unverändert), was bei 100 Millionen Autos, die sich wöchentlich registrieren wollen, nicht annähernd ausreichen würde. Das folgende Ausführungsbeispiel 2 behebt diesen Nachteil.
AUSFÜHRUNGSBEISPIEL 2
In diesem Ausführungsbeispiel registriert der Fahrzeugcomputer (C1) den Daten-Eintrag (D1) nicht eigenständig in der Blockchain, sondern überlässt dies einem zentralen „Registrierserver” (100), der zu registrierende Hashwerte aus vielen unterschiedlichen Quellen, insbesondere von vielen unterschiedlichen Autos (A2), sammelt und dann eine gebündelte „Sammelregistrierung” in der Blockchain (200) vornimmt.
Z. B. soll das in Ausführungsbeispiel 1 betrachtete Auto am 17.07.2017 einen Kilometerstand-Eintrag mit Hash (Z1') „hash(9d8db8xxx,9d0468xxx)” registrieren. 10000 andere Autos des gleichen Herstellers weltweit möchten am selben Tag ebenfalls ihre Fahrzeugdaten-Einträge in der Blockchain registrieren.
Alle 10001 Autos senden darum ihren jeweils zu registrierenden Hashwert (Z1') als „Blockchain-Registration-Request” zu einem zentralen Blockchain-Registrierserver (100) – das ist z. B. ein Server eines bestimmten Automobilherstellers. Dieser Server sammelt alle eingehenden Hash-Werte (Z1') (Z2') und fasst diese in einem zusammenhängenden Gesamt-Datensatz (110) zusammen, um einen daraus resultierenden Gesamt-Hashwert (120) zu berechnen:
Dann registriert der Server (100) den Gesamt-Hash 2a7619xxx (120) in der Bitcoin Blockchain (200).
Der Server (100) muss den Gesamt-Datensatz (110) aller 10001 Hashwerte nun noch jedem der 10001 Autos in einer Form zugänglich machen, so dass diese die Registrierung ihrer Dateneinträge in der Blockchain selber eigenständig verifizieren können. Je nach Art der Berechnung des Gesamt-Hashs (120) durch den Registrierserver (100) ist der an die Autos (A2) bzw. derer Computer (C2) mitzuteilende Auto-spezifische Ergänzungs-Datensatz (111_2) mehr oder weniger unterschiedlich zu (110), vor allem was die Datenmenge betrifft.
Der jeweilige Fahrzeugcomputer (C1) speichert den Auto-spezifischen Ergänzungs-Datensatz (111_1) als zusätzlichen Teil seiner eigenen Kilometerstands-Historie (KH1) ab, d. h. zu jedem Kilometerstands-Eintrag (D1) gibt es neben den Hashwerten (Z1) (Y1) einen dazugehörigen Fahrzeug-spezifischen Ergänzungs-Datensatz (111_1) vom Registrierserver (100), vgl. . Bemerkenswert ist hierbei, dass der Fahrzeug-spezifische Ergänzungs-Datensatz (111_1), den der Registrierserver dem Fahrzeugcomputer (C1) schickt oder zum Abruf bereithält, nicht für alle 10001 Autos derselbe ist, sondern vom Auto abhängt, wie unter „Gesamt-Hash-Berechnung” weiter unten näher erläutert wird. Alternativ zum aktiven Versenden des Auto-spezifischen Ergänzungs-Datensatzes (111_1) kann der Registrierserver auch einen Link (URL) angeben, den der Fahrzeugcomputer (C1) dann anstelle des Fahrzeug-spezifischen Ergänzungs-Datensatzes (111_1) in der Fahrzeugdaten-Historie (KH1) speichern kann. Der Link zeigt an, dass der Registrierserver (100) den Gesamt-Datensatz (110) langfristig aufbewahrt und wo er den Auto-spezifischen Ergänzungs-Datensatz (111_1) zum Abruf bereit hält. Gegebenenfalls könnte der Registrierserver sich die Bereitstellung des Ergänzungs-Datensatzes (111_1) auch bezahlen lassen.
Der Fahrzeug-Computer (C1) speichert nun also die folgenden Daten:
Die Validierung der Kilometerstands-Historie (KH1) durch den Kaufinteressenten (oder der von ihm verwendeten Validierungs-Software (VS300)) erfolgt dann wie folgt, für jeden einzelnen Zeilen-Eintrag (E1) der Gesamt-Historie (KH1):

• Verifiziere, dass der Zeilen-Hash (Z1) zum Dateneintrag (D1) der Zeile passt.
• Berechne den Gesamt-Hash (120) aus dem Zeilen-Hash (Z1), Verkettungs-Hash (Y1) und dem Auto-spezifischen Ergänzungs-Datensatz (111_1).
• Verifiziere, dass der Hash (120) in der Blockchain (200) zeitnah zum Datum des Daten-Eintrags (D1) registriert wurde.
• Und: Ohne Blockchain: Verifiziere, dass die Verkettungs-Hashwerte (Y1) der Kilometerstand-Historie (KH1) eine lückenlose Kette bilden, um sicherzustellen, dass nicht nachträglich vom Verkäufer vor der Übergabe der Datei (KH1) noch Zeilen (E1) selektiv entfernt wurden.

Gesamt-Hash-Berechnung:
Es gibt mindestens zwei Wege, wie der Gesamt-Hash (120) berechnet werden kann. Der Geradeaus-Weg (Alternative 1) ist hochgradig suboptimal, es sollte der zweite Weg (Alternative 2) gewählt werden, wie im Folgenden beschrieben. Es ist deutlich vorteilhafter, wenn der Registrierserver (100) den Gesamt-Hash (120) nicht berechnet, indem er einfach einen Hash aus N = 10001 verketteten Hashwerten berechnet, sondern indem er Hashwerte kaskadiert gemäß einem Binär-Baum sukzessive berechnet. Dies wird am Beispiel von N = 16 Autos im Folgenden erklärt:
Alle N = 16 Autos senden ihre einzelnen Hashwerte (Z1')...(Z16') jeweils zum Registrierserver (100). Es sei angemerkt, dass im Folgenden die Nomenklatur (Z1) statt (Z1') verwendet wird. Dies bringt zum Ausdruck, dass es für den Registrierserver (100) irrelevant ist, auf welche Weise die jeweiligen Fahrzeugcomputer ihre Hashes berechnet haben, denn der Registrierserver (100) hat lediglich die Aufgabe, die erhaltenen Bitsequenzen in der Blockchain (200) zu registrieren, ohne zu wissen, was hinter einer jeweiligen Bitsequenz steckt – er weiß noch nicht einmal, ob es sich bei einer Bitsequenz um einen Hash handelt, das ist auch unerheblich. Der Registrierserver (100) berechnet nun den Gesamt-Hash (120) wie folgt: Alternative 1: Lineare Methode:
Alternative 2: Kaskadierte Baum-Methode (BM248), z. B. mittels folgendem Binärbaum-Schema:
Wenn der Gesamt-Hash (120) nach Alternative 1 berechnet wird, dann müssen dem jeweiligen Computer (C1) die N – 1 = 15 Hashwerte {Z2, Z3, ..., Z16} als Ergänzungs-Datensatz (111_1) zur Validierung zur Verfügung gestellt werden (den Hash Z1 hat der Computer (C1) ja schon selbst).
Wenn der Gesamt-Hash (120) nach Alternative 2 berechnet wird, dann müssen dem jeweiligen Computer (C1) viel weniger Ergänzungs-Daten (111_1) zur Validierung zur Verfügung gestellt werden als bei Alternative 1. Z. B. müssen dem Computer (C1), der (Z1) an den Registrierserver (100) geschickt hat, nur die folgenden vier (log2(16) = 4) fremden Hashwerte zurückgeschickt werden: {Z2, I2, K2, L2}. Das reicht aus, damit der Computer (C1) oder ein anderes unabhängiges Programm (VS300) später eigenständig anhand der Datei (KH1) die Registrierung des Hash-Wertes (Z1) in der Blockchain (200) verifizieren kann.
Allgemein gilt: Die Datenmenge wächst bei Alternative 1 linear (Fahrzeug-spezifischer Ergänzungs-Datensatz (111_1) umfasst ”N – 1” fremde Hashes), bei Alternative 2 dagegen nur logarithmisch (Fahrzeug-spezifischer Ergänzungs-Datensatz (111_1) umfasst ”log2(N)” fremde Hashes. Wenn zum Beispiel eine Million Hashes in einem Gesamt-Datensatz (110) zur Blockchain-Registrierung zusammengefasst werden, macht das einen sehr großen Unterschied für die Größe des Fahrzeug-spezifischen Ergänzungs-Datensatzes (111_1): Statt 999999 fremde Hashwerte müssen nur zwanzig Hash-Werte pro Daten-Eintrag (D1) vom Fahrzeugcomputer (C1) abgespeichert werden. Dadurch wird die Lösung mit der Sammelregistrierung mittels Registrierserver (100) sehr skalierbar, wie folgende Beispielrechnung zeigt:
Wenn ein Auto (A1) z. B. 25 Jahre lange jede Woche eine Blockchain-Registrierung mittels Registrierserver vornimmt im Pool mit 1 Million anderen Autos, und den dazugehörigen vom Registrierserver (100) erhaltenen Ergänzungs-Datensatz (111_1) lokal abspeichert, dann ergibt sich nach 25 Jahren ein Speicherbedarf von nur rund 1 MByte. Herleitung:
1 Hash = 256 bit = 32 Bytes. Größe des Ergänzungs-Datensatzes (111_1) ist ceil(log2(1 Million)) = 20 Hashes, plus die zwei eigenen Hashes (Z1) und (Y1) ergibt 22 Hashes = 22·32 Bytes = 704 Bytes. Unter der Annahme, dass der Nutzdaten-Eintrag (D1) im Mittel 96 Bytes pro Eintragszeile (E1) umfasst, kommt man auf einen Schätzwert von 800 Bytes Speicherbedarf pro Eintragszeile (E1). Bei einem Daten-Eintrag pro Woche ergibt das nach 25 Jahren eine Datenmenge von lediglich 800 Bytes·365/7·25 = 1,04 MBytes, die in dem Flash-Speicher (M1) des Fahrzeugs abgespeichert werden müssen.
Mit Alternative 1 hingegen liegt der Speicherbedarf im gleichen Szenario bei 42 GByte statt 1 MByte, weil 1 Million satt nur 4 Hashes jede Woche ergänzend gespeichert werden müssen.
AUSFÜHRUNGSBEISPIEL 3
In diesem Beispiel werden die Fahrzeugdaten (D1) zum Zwecke der Führung eines elektronischen Fahrtenbuchs in einem Smartphone (C1) des Autobesitzers (B1) erfasst, die Spaltenüberschriften der chronologischen Historie (KH1) lauten wie folgt:
Beispiel-Einträge der aufgezeichneten Daten (KH1):
Hier muss der Fahrer (B1) die Daten (D1) jedes Mal manuell (oder zumindest halb-manuell) in seine Fahrtenbuch-App (C1) eintragen. Der „Random Nonce”, der ein Teil der Zeile eines Daten-Eintrags (D1) ist, wird von der App automatisch erzeugt. Dann werden die beiden Hash-Werte (Z1) und (Y1) in der dritt- und zweitletzten Spalte ebenfalls von der App (C1) hinzugefügt. Da es recht viele Einträge pro Tag geben kann, wird nicht jede einzelne Datenzeile (D1) in der Blockchain registriert. Stattdessen wird die Registrierung von der App (C1) oder vom Benutzer (B1) in sinnvollen Zeitabständen veranlasst, z. B. „nicht öfter als einmal täglich”, oder „nicht öfter als alle 500 km aber mindestens alle zwei Tage”, oder nach ähnlichen Regeln. Um für eine spätere Validierung hierüber Transparenz zu schaffen, zeigt die Spalte „Blockchain-Registrierungs-Flag” an, ob die jeweilige Datenzeile absichtlich nicht registriert wurde.
Die Registrierung erfolgt via Registrierserver (100) wie in Ausführungsbeispiel 2. Jedoch gibt der Registrierserver hier nicht den Fahrzeug-spezifischen Ergänzungs-Datensatz (111_1) nach der Registrierung an das Smartphone (C1) zurück, sondern nur einen Web-Link (URL), unter dem dieser Ergänzungs-Datensatz (111_1) jetzt oder in ferner Zukunft abrufbar ist (kostenlos oder gegen eine Gebühr).
Zur Verifizierung, dass die Dateneinträge (D1) in der Blockchain registriert sind, muss also der Benutzer (B1) bzw. sein Smartphone (C1) bzw. die Steuerbehörde, welcher der Benutzer (B1) sein elektronisches Fahrtenbuch (KH1) übergibt, die Ergänzungs-Datensätze (111_1) pro Zeile von dem Web-Link abrufen, um dann die Validierung der Daten (D1) der Zeile (E1) vornehmen zu können.
Die Spalte „Random Nonce” dient dem Datenschutz und der Privatsphäre, denn sie erleichtert die Möglichkeit, bei einer späteren Offenlegung der Daten z. B. gegenüber einem Kaufinteressenten ausgewählte Felder einzelner Zeilen zu schwärzen, inkl. dem Feld ”Random-Nonce”. Auf diese Weise wird es kaum möglich sein, mit einem Brute-Force-Angriff den Inhalt der geschwärzten Felder zu erraten, weil es zu viele Möglichkeiten gibt. Ansonsten gilt das in Ausführungsbeispiel 1 gesagte – dass trotzt Schwärzung vereinzelter Einträge die Historie noch einen starken Aussagewert besitzt.
ÜBERSICHT DER SYMBOLHAFTEN BEZEICHNUNGEN:

• A1 = Fahrzeug Nr. 1.
• B1 = Benutzer oder Besitzer des Fahrzeugs A1.
• C1 = ein Computerprogramm auf einem Computer oder der Computer selbst. Dieser Computer kann z. B. der Bordcomputer/Fahrzeugcomputer des Fahrzeug A1 sein, oder ein Smartphone/Tablet PC/Notebook von Benutzer B1.
• D1, D1(k) = (k-ter) Eintrag aus Fahrzeugdaten von Fahrzeug (A1), enthält normalerweise zumindest eine Fahrzeugkennung, den Kilometerstand und das Datum, kann aber auch andere manuell eingegebene oder vom Computer (C1) generierte Zusatzdaten enthalten.
• E1, E1(k) = (k-te) Eintragszeile bestehend aus D1(k) und ggf. einem oder mehreren Hashwerten Z1(k), Y1(k), X1(k), 111_1(k) und ggf. einem Link zu Ergänzungs-Hashwerten (111_1)(k).
• KH1 = Fahrzeugdaten-Historie für Fahrzeug (A1), bestehend aus der Abfolge von Einträgen E1(k), z. B. in Form einer Datenbank oder einer CSV (comma separated variable) Text-Datei, in welcher unterschiedliche Einträge E1(k) als unterschiedliche Zeilen auftauchen.
• M1 = Nicht-flüchtiger Speicher (z. B. Flash Memory) des Computers (C1).
• X1(k) = Einfacher Verkettungs-Hashwert, der sich errechnet aus D1(k) und X1(k – 1).
• Y1(k) = Verkettungs-Hashwert, der sich errechnet aus Z1(k) und Y1(k – 1).
• Z1(k) = Zeilen-Hashwert, der sich errechnet aus D1(k).
• Z1'(k) = Kombinierter Hashwert, der sich aus Z1(k) und Y1(k) errechnet, z. B. mittels Z1' = hash(Z1, Y1).
• (100) = Der Registrierserver, ein Computer oder eine Gruppe von Computern, der eine Registrierung in der Blockchain von einem oder mehreren Hashwerten von mindestens einer Quelle gebündelt vornimmt.
• (110) = Gesamt-Datensatz aller Hashes {Z1', Z2', ..., ZM'} (oder sonstiger Bitsequenzen von unterschiedlichen Quellen), die gebündelt mittels einer Blockchain-Transaktion registriert werden sollen.
• (111_n) = Ein für Auto An bzw. Computer Cn (n = 1...M) spezifischer Ergänzungs-Datensatz von Hashwerten oder Bitsequenzen, aus dem sich zusammen mit den im Computer Cn schon vorliegenden Hashwerten der Gesamt-Hashwert (120) berechnen lässt, der in der Blockchain (200) registriert wurde.
• (120) = Der Hashwert, der aus dem Gesamt-Datensatz (110) errechnet und in der Blockchain registriert wird. Auch als Gesamt-Hashwert bezeichnet.
• (200) = Die Blockchain, in der Fahrzeugdaten bzw. deren Hashwerte registriert werden, z. B. die Bitcoin Blockchain.
• (210) = Eine Blockchain-Transaktion, die aus einem Hashwert generiert und in die Blockchain (200) gesendet wird. Der Hashwert (Z1)(Y1)(Z1')(X1)(120) ist in den Transaktionsdaten (210) entweder explizit oder implizit enthalten. Implizit bedeutet hierbei, dass sich ein Teil der Transaktionsdaten über eine kyptologische kollisionsresistente Einwegfunktion aus dem Hash (Z1(120) errechnet, so dass die Existenz dieser Transaktionsdaten kryptografisch zwingend die Existenz des Hashwertes (Z1)(Y1)(Z1')(X1)(120) voraussetzt.
• (220) = Der zeit-gestempelte Block innerhalb der Blockchain (200), der die Blockchain-Transaktion (210) enthält.
• (250) = Eine Funktion, die prüft, ob ein Hash (Z1)(Y1)(Z1')(X1)(120) in der Blockchain registriert worden ist.
• (260) = Eine Funktion, die prüft, ob und wann ein Hash (Z1)(Y1)(Z1')(X1)(120) in der Blockchain registriert worden ist.
• (270) = Eine Funktion, die über eine Programm- oder Benutzerschnittstelle Rückmeldung über das Prüfergebnis von (260) bzw. (270) gibt.

BESCHREIBUNG DER ABBILDUNGEN:
zeigt das einfache Beispiel einer Fahrzeugdaten-Registrierung in Anlehnung an Ausführungsbeispiel 1, aber ohne Beachtung des Verkettungshashwertes (Y1). Fahrzeugdaten zu Auto (A1) wie die Fahrgestellnummer, der Kilometerstand und das Datum werden vom Computer (C1) zu bestimmten Zeitpunkten erfasst und in einem zusammenhängenden Daten-Eintrag (D1) abgelegt. Optional kann ein Benutzer (B1) auch noch manuell Daten in den Computer (C1) eingeben, die dieser dann dem Dateneintrag (D1) noch hinzufügt. Der Hash (Z1) des Daten-Eintrags (D1) bildet zusammen mit dem Daten-Eintrag (D1) eine komplette Eintragszeile (E1) der Fahrzeugdaten-Historie (KH1). Aus dem Hash (Z1) berechnet der Computer eine Bitcoin-Transaktion (210), die an die Blockchain (200) gesendet wird und dort schließlich in einen Block (220) mit Zeitstempel aufgenommen wird. Der Computer (C1) kann durch eine Überprüfungsfunktion (250) verifizieren, ob die Registrierung in der Blockchain erfolgreich war, indem er die Transaktion (210) bzw. die Kennung des Hashwertes (Z1) in einem Block (220) der Blockchain wiederfindet. Anmerkung: Für eine komplettere Lösung unter Miteinbeziehung der Verkettungshashwerte (Y1) gemäß sollte in anstelle des Zeilenhashwertes (Z1) der kombinierte Hashwert (Z1') = hash(Z1, Y1) für die Erstellung der Transaktion (210) zwecks Registrierung in der Blockchain (200) verwendet werden.
zeigt das Beispiel einer Fahrzeugdaten-Registrierung in Anlehnung an Ausführungsbeispiel 2 oder 3, aber ohne Beachtung des Verkettungshashwertes (Y1). Fahrzeugdaten zu Auto (A1) wie die Fahrgestellnummer, der Kilometerstand und das Datum werden vom Computer (C1) erfasst und in einem Daten-Eintrag (D1) abgelegt. Optional kann ein Benutzer (B1) auch noch manuell Daten in den Computer (C1) eingeben, die dieser dann dem Dateneintrag (D1) noch hinzufügt. Der Hash (Z1) des Daten-Eintrags (D1) bildet zusammen mit dem Daten-Eintrag (D1) eine komplette Eintragszeile (E1) der Fahrzeugdaten-Historie (KH1). Der Computer sendet den Hashwert (Z1) an den Registrierserver (100), welcher von anderen Autos ebenfalls Hashwerte (Z2)(ZM) erhält. Die Zahl M kann dabei zwischen 1 und vielen Millionen oder gar Milliarden liegen. Der Registrierserver (100) bündelt alle diese Hashwerte (Z1)(Z2)(ZM) in einem Gesamt-Datensatz (110) und berechnet hieraus einen Gesamt-Hash (120), wobei er vorzugsweise die kaskadierte Baum-Methode (BM248) anwendet. Aus dem Hash (120) berechnet der Registrierserver (100) eine Bitcoin-Transaktion (210), die an die Blockchain (200) gesendet wird und dort schließlich in einen Block (220) mit Zeitstempel aufgenommen wird. Der Registrierserver (100) kann durch eine Überprüfungsfunktion (250) verifizieren, ob die Registrierung erfolgreich war, indem er die Transaktion (210) bzw. die Kennung des Hashwertes (120) in einem Block (220) der Blockchain wiederfindet. Der Registrierserver (100) erstellt Fahrzeug-spezifische Ergänzungs-Datensätze (111_1)(111_2)(111_M), die sich aus der Gesamtheit aller Einzel-Hashwerte (Z1) (Z2)(ZM) ergeben. Der Registrierserver (100) schickt den Fahrzeug-spezifischen Ergänzungs-Datensatz (111_1) an den jeweiligen Fahrzeug-Computer (C1), welcher diesen in die Eintragszeile (E1) mit aufnimmt, vgl. auch . Damit ist die Eintragszeile vollständig und kann gemäß völlig autonom mit Hilfe der Blockchain (200) validiert werden. Es ist zu bemerken, dass der Registrierserver den Ergänzungs-Datensatz (111_1) auch an einen anderen Computer als Computer (C1) schicken kann, sofern dieser andere Computer auch über die restlichen Daten der Eintragszeile (E1) verfügt. Anmerkung: Für eine komplettere Lösung unter Miteinbeziehung der Verkettungshashwerte (Y1) gemäß sollte in anstelle des Zeilenhashwertes (Z1) der kombinierte Hashwert (Z1') = hash(Z1, Y1) an den Registrierserver (100) gesendet werden.
zeigt das Beispiel einer Fahrzeugdaten-Validierung in Anlehnung an Ausführungsbeispiel 1, aber ohne Beachtung des Verkettungshashwertes (Y1), weil sonst vorzugsweise der Verkettungshash (Y1) oder besser noch der kombinierte Hashwert (Z1') mit Z1' = hash(Z1, Y1) anstelle des Zeilenhashwertes (Z1) verwendet werden sollte. Eine Validierungs-Software (VS300) erhält eine Eintragszeile (E1) der Fahrzeugdaten-Historie von Computer (C1) und extrahiert hieraus den Hash (Z1) und die Nutzdaten (D1). Wenn (Z1) sich aus (D1) errechnen lässt, dann macht die Software (VS300) weiter, indem sie auf die Blockchain-Datenbank (200) zugreift und diese nach Blöcken (220) durchsucht, welche Transaktionen (210) enthalten, welche den Hash (Z1) oder einen Fingerabdruck dieses Hashs (Z1) enthalten. Die Software (VS300) verifiziert mittels einer Überprüfungsfunktion (260), ob es hier zu Übereinstimmungen kommt, wobei bei mehrfachen Übereinstimmungen der älteste Block (220) zählt, und ob auch der Zeitstempel des Blocks (220) mit der Zeitangabe des Daten-Eintrags (D1) in etwa übereinstimmt. Schließlich erteilt die Software (VS300) über eine Schnittstelle (270) eine entsprechende Rückmeldung zum Überprüfungsergebnis.
zeigt das Beispiel einer Fahrzeugdaten-Validierung in Anlehnung an Ausführungsbeispiel 2 oder 3, aber ohne Beachtung des Verkettungshashwertes (Y1), weil sonst vorzugsweise der Verkettungshash (Y1) oder besser noch der kombinierte Hashwert (Z1') mit Z1' = hash(Z1, V1) anstelle von des Zeilenhashwertes (Z1) verwendet werden sollte. Eine Validierungs-Software (VS300) erhält eine Eintragszeile (E1) der Fahrzeugdaten-Historie von Computer (C1) und extrahiert hieraus den Hash (Z1), den Fahrzeug-spezifischen Ergänzungs-Datensatz (111_1) und die Nutzdaten (D1). Wenn (Z1) sich aus (D1) errechnen lässt, dann macht die Software (VS300) weiter, indem sie nach bekannter Rechenvorschrift aus dem Hash (Z1) und den Hashes des Fahrzeug-spezifischen Ergänzungs-Datensatzes (111_1) den Gesamt-Hashwert (120) berechnet. Dann greift sie auf die Blockchain-Datenbank (200) zu und durchsucht diese nach Blöcken (220), welche Transaktionen (210) enthalten, welche den Gesamt-Hash (120) oder einen Fingerabdruck dieses Hashs (120) enthalten. Die Software (VS300) verifiziert mittels einer Überprüfungsfunktion (260), ob es hier zu Übereinstimmungen kommt, wobei bei mehrfachen Übereinstimmungen der älteste Block (220) zählt, und ob auch der Zeitstempel des Blocks (220) mit der Zeitangabe des Daten-Eintrags (D1) in etwa übereinstimmt. Schließlich erteilt die Software (VS300) über eine Schnittstelle (270) eine entsprechende Rückmeldung zum Überprüfungsergebnis.
zeigt das Beispiel einer abgespeicherten Fahrzeugdaten-Historie (KH1), die eine suboptimale Struktur der Hash-Verkettung besitzt. Hier gibt es nur einen einzigen Hash (X1) statt zwei Hashs (Z1) (Y1) pro Datenzeile (E1), und es wird davon ausgegangen, dass einige oder alle Hashes (X1) in der Blockchain registriert sind. Diese Struktur hat zur Folge, dass bei Schwärzung eines einzelnes Feldes eines Daten-Eintrags (D1) die Kette der Hashes unterbrochen wird. Es lässt sich dann nicht mehr überprüfen, ob die vorliegende Kette abgesehen von dem geschwärzten Daten-Eintrag (D1) noch vollständig ist, oder ob vor dem geschwärzten Eintrag noch sehr viele weitere Datenzeilen (E1) vollständig aus der vorliegenden Fahrzeugdaten-Historie (KH1) gelöscht worden sind. Dies ist ein Nachteil, der den Datenschutz-Spielraum des Benutzers (B1) einschränkt, da er sich mit einer berechtigten selektiven Schwärzung eines einzelnen Dateneintrag-Feldes dem unberechtigten Verdacht aussetzt, viele Eintragszeilen (E1) komplett gelöscht zu haben. Ein weiterer aber weniger schwerwiegender Nebeneffekt dieser Hash-Verkettungs-Struktur besteht darin, dass für den Fall, dass eine Eintragszeile (E1(k)) komplett entfernt wird, auch der direkt folgende Daten-Eintrag D1(k + 1) nicht mehr validierbar ist. Beide aufgezeigten Nachteile werden mit der Hash-Verkettungs-Struktur gemäß beseitigt.
zeigt das Beispiel einer abgespeicherten Fahrzeugdaten-Historie (KH1), die eine bevorzugte Struktur von Hash-Verkettungen besitzt. Sie befindet sich in Übereinstimmung mit Ausführungsbeispiel 1, und es wird davon ausgegangen, dass für einige oder alle Zeilen (E1) jeweils die kombinierten Hashes (Z1') in der Blockchain registriert sind, wobei der kombinierte Hash (Z1') sich ergibt als Ergebnis einer Hashfunktion aus Zeilenhashwert (Z1) und Verkettungshashwert (Y1) der selben Zeile (E1). Bei dieser Variante mit zwei Hashes (Z1) (Y1) pro Eintragszeile (E1) würde die Kette der Hashes auch bei Schwärzung eines Feldes eines Daten-Eintrags (D1) erhalten bleiben, weil die verketteten Hashwerte (Y1) zu ihrer Berechnung nur die Zeilen-Hashs (Z1) und nicht die Daten-Einträge selbst (D1) verwenden. Die Gesamtzahl der registrierten Einträge wäre also weiterhin eindeutig, denn ein unbemerktes Löschen ganzer Eintragszeilen (E1) wäre nicht möglich. Auch wäre eine Validierung aller nicht-geschwärzten Datenzeilen weiterhin möglich. Wenn man eine komplette Zeile (E1) aus der Gesamthistorie (KH1) entfernt, sind die verbleibenden Einzelzeilen (D1) alle noch weiterhin validierbar, auch die direkte Nachfolgezeile. Allerdings wäre es dann wie im Falle von nicht mehr nachvollziehbar, ob nur eine oder viele Eintragszeilen (E1) entfernt worden sind. Wenn für einige Eintragszeilen keine Registrierung vorgenommen wurde, hat dies genauso wie bei keine Auswirkungen auf die Verkettung der Struktur der Gesamthistorie (KH1) und auch nicht auf die Integrität als Ganzes. Denn sobald einer Folge von unregistrierten Zeilen eine Zeile folgt, die mittels (Z1') registriert wird, schließt dies implizit die Registrierung aller vorherigen Zeilen mit ein. In dieser Eigenschaft verhält sich die Hash-Verkettungsstruktur identisch wie die aus . Insgesamt ist die Variante mit zwei Hashes (Z1) (Y1) und der Registrierung von (Z1') = hash(Z1, Y1) also derjenigen mit einem Hash (X1) aus generell vorzuziehen, da die Variante mit zwei Hashwerten in bestimmten Fällen Vorteile aber in keinem Falle Nachteile hat.
Anmerkung: Wenn man anstatt des kombinierten Hashwertes Z1' = hash(Z1, Y1) einfach den Verkettungshashwert Y1 in der Blockchain registrieren würde, hätte man eine Lösung, die ebenfalls den Hauptnachteil der Lösung aus beseitigt, dass eine Schwärzung eines Datenfeldes die Hashkette unterbricht. Jedoch hätte man dann immer noch den selben nachteiligen Nebeneffekt der Lösung aus , dass bei Streichung einer kompletten Datenzeile (E1) die Nachfolgezeile nicht mehr validierbar wäre. Darum kann man sagen, dass die Registrierung des Hashs (X1) mit dem Schema aus die schlechteste Lösung, die Registrierung des Verkettungshashs (Y1) nach eine deutlich verbesserte Lösung, und die Registrierung des kombinierten Hashs (Z1') = hash(Z1, V1), ebenfalls nach , die beste Lösung darstellt.
zeigt das Beispiel einer abgespeicherten Fahrzeugdaten-Historie (KH1) bei Registrierung mittels eines Registrierservers (100). Es besitzt die bevorzugte Struktur von Hash-Verkettungen aus und befindet sich in Übereinstimmung mit Ausführungsbeispiel 2. In Ergänzung zu werden die Eintragszeilen (E1) hier noch um Ergänzungs-Hash-Datensätze (111_1(k)) erweitert, die vom Registrierserver (100) stammen. Diese Hashwerte (111_1(k)) sind notwendig, um den jeweiligen Daten-Eintrag D1(k) mit Hilfe der Blockchain validieren zu können. Die Verhashung zwischen D1(k), Z1(k) und Y1(k) ist hier identisch zu und wurde der Einfachheit halber nicht erneut eingezeichnet.
zeigt eine Legende der Grafikelemente in den verschiedenen Zeichnungen.

Claims

Ein Verfahren, wonach eine chronologische Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1), die sich auf ein bestimmtes Fahrzeug (A1) beziehen, von einem Computerprogramm (C1) erfasst und gespeichert wird und mindestens einer dieser Fahrzeugdaten-Einträge (D1) in einer Blockchain-Datenbank (200) registriert wird, so dass zu einem späteren Zeitpunkt die Integrität der dann vorliegenden Fahrzeugdaten-Einträge mittels einer unabhängigen Validierungs-Software (VS300) überprüft werden kann, dadurch gekennzeichnet, dass • die Fahrzeugdaten-Einträge (D1) in Form von Hash-Werten (Z1)(Y1)(Z1')(X1)(120), in der Blockchain registriert werden, wobei die Hash-Werte basierend auf den Fahrzeugdaten-Einträgen (D1) berechnet werden, • die Registrierung eines Hash-Wertes (Z1)(Y1)(Z1')(X1)(120) in der Blockchain (200) dadurch erfolgt, dass eine Transaktion (210) in die Blockchain (200) gesendet wird, wobei diese Transaktion (210) eine Bitsequenz enthält, die unter Berücksichtigung des aktuell geltenden kryptografischen Kenntnisstands nicht existieren könnte, wenn der zu registrierende Hash-Wert (Z1)(Y1)(Z1')(X1)(120) nicht existieren würde, • die besagte Transaktion (210) in einen Block (220) der Blockchain (200) dauerhaft aufgenommen wird, • der Block (220) der Blockchain-Datenbank (200) einen Zeitstempel besitzt, • das Protokoll und der Betrieb der Blockchain (200) darauf ausgelegt sind, dass eine Rückabwicklung der Blockchain-Historie in der Größenordnung von einer Stunde oder mehr vermieden wird, • besagte Software (VS300) die Integrität einer chronologischen Aufzeichnung (KH1) von Fahrzeugdaten-Einträgen (D1) mit Hilfe der Transaktionen (210) in der Blockchain überprüfen kann, dadurch gekennzeichnet, dass – besagte Software (VS300) eine chronologische Abfolge (KH1) von mindestens einem Fahrzeugdaten-Eintrag (D1) als Eingabewert verarbeiten kann, – besagte Software (VS300) die Blockchain (200), in der die Fahrzeugdaten-Einträge (D1) registriert sind, auf bestimmte Bitsequenzen hin durchsuchen kann, wobei sich diese Bitsequenzen aus Hash-Werten ergeben, zu deren Berechnung die Fahrzeugdaten-Einträge (D1) notwendig sind.
Ein Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass • mindestens zwei der besagten Fahrzeugdaten-Einträge (D1) in einer Blockchain-Datenbank (200) registriert werden, • die einzelnen besagten Fahrzeugdaten-Einträge (D1) der besagten chronologische Abfolge (KH1) durch mit diesen Fahrzeugdaten-Einträgen (D1) verknüpften Hash-Werten (Z1) (Y1) (X1) ergänzt werden, • besagte Hash-Werte (Z1)(Y1)(X1) die Fahrzeugdaten-Einträge (D1) in geordneter Reihenfolge miteinander verketten, • es unter diesen Hash-Werten (Z1)(Y1)(X1) eine erste Art von Hash-Werten (Y1(k)) (X1(k)) gibt, die so berechnet werden, dass sie eine Funktion des aktuellen Fahrzeugdaten-Eintrags (D1(k)) und des vorherigen Hash-Werts (Y1(k – 1))(X1(k – 1)) dieser ersten Art von Hash-Werten sind, so dass ein Entfernen einer einzelnen Eintragszeile (E1) bestehend aus Fahrzeugdaten-Eintrag (D1) und dazugehörigen Hash-Werten (Z1)(Y1)(X1) innerhalb der chronologische Abfolge (KH1) diese Verknüpfungskette aufbricht und die Unvollständigkeit besagter chronologischer Abfolge (KH1) offenlegt, sofern die entfernte Eintragszeile (E1) nicht am äußersten Anfang oder Ende der chronologische Abfolge (KH1) liegt. • die Bitsequenzen, die in der Blockchain (200) registriert werden, zu deren Erzeugung besagte erste Art von Hash-Werten (Y1(k))(X1(k)) benötigen.
Ein Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass • es unter den besagten mit den Fahrzeugdaten-Einträgen (D1) verknüpften Hash-Werten (Z1) (Y1)(X1) eine zweite Art von Hash-Werten (Z1) gibt, die eine Funktion lediglich der Fahrzeugdaten-Einträge (D1) der selben Eintragszeile (E1) sind aber nicht eine Funktion von Hash-Werten aus anderen Eintragszeilen (E1), • die Bitsequenzen, die in der Blockchain (200) registriert werden, zu deren Erzeugung besagte zweite Art von Hash-Werten (Z1) benötigen.
Ein Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass • besagtes Computerprogramm (C1) die in der Blockchain zu registrierenden Hash-Werte (Z1)(Y1)(Z1')(X1) als zu registrierende Bitsequenz an einen zentralen Registrierserver (100) schickt, • besagter Registrierserver (100) einen Gesamt-Datensatz (110) erstellt, der aus mindestens einer in der Blockchain (200) zu registrierenden Bitsequenz besteht, die der Registrierserver von mindestens einem Computerprogramm (C1) erhalten hat, • besagter Registrierserver (100) einen Gesamt-Hashwert (120) auf Basis des besagten Gesamt-Datensatzes (110) berechnet, • besagter Registrierserver (100) diesen Gesamt-Hashwert (120) mittels der Transaktion (210) in der Blockchain registriert, • besagter Registrierserver (100) einen zu dem jeweiligen Fahrzeugdaten-Eintrag (D1) passenden Ergänzungs-Datensatz (111_1) zur Verwendung für ein Verifikations-Computerprogramm (C1)(VS300) zur Verfügung stellt, welches die Registrierung des Hash-Wertes (Z1)(Y1)(Z1')(X1) in der Blockchain verifiziert, wobei besagter Ergänzungs-Datensatz (111_1) aus Ergänzungs-Bitsequenzen besteht, die notwendig sind, um diese Verifikationsaufgabe durchführen zu können, so dass das Verifikations-Computerprogramm (C1)(VS300) die Integrität der chronologischen Aufzeichnung (KH1) von Fahrzeugdaten-Einträgen (D1) mit Hilfe der Transaktion (210) in der Blockchain (200) überprüfen kann.
Ein Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass • besagter Registrierserver (100) den Gesamt-Hash (120) mittels einer kaskadierten Baum-Methode (BM248) berechnet und der Fahrzeugdaten-Eintrag-spezifische Ergänzungs-Datensatz (111_1) aus einer Zahl von Bitsequenzen besteht, die logarithmisch mit der Anzahl der Bitsequenzen im Gesamt-Datensatz (110) wächst, • besagtes Verifikations-Computerprogramm (C1)(VS300) den Fahrzeug-spezifischen Ergänzungs-Datensatz (111_1) erhält, der zur Validierung der Registrierung des Hash-Wertes (Z1)(Y1)(Z1')(X1) in der Blockchain (200) nötig ist.
Ein als Registrierserver (100) bezeichneter Verbund von mindestens einem Computer, von denen mindestens ein Computer ein Internet-Server ist, dadurch gekennzeichnet, dass • der Registrierserver (100) Bitsequenzen von unterschiedlichen Absender-Computern (C1) empfängt, • der Registrierserver (100) diese Bitsequenzen zu einem Gesamt-Datensatz (110) zusammenfasst, • der Registrierserver (100) basierend auf dem Gesamt-Datensatz (110) einen Gesamt-Hash (120) berechnet, • der Registrierserver (100) diesen Gesamt-Hash (120) mittels einer Blockchain-Transaktion (120) in einer Blockchain (200) registriert, und • der Registrierserver (100) zu den Bitsequenzen jeweils passende Ergänzungs-Datensätze (111_1) zur Verfügung stellt, so dass ein unabhängiges Computerprogramm (C1)(VS300) die Registrierung einer dieser Bitsequenzen in der Blockchain (200) überprüfen kann, indem es die Registrierung des Gesamt-Hashwertes (120) in der Blockchain (200) überprüft, wobei sich dieser Gesamt-Hashwert (120) aus besagter Bitsequenz und dem hierzu passenden Ergänzungs-Datensatz (111_1) errechnet.
Ein mit Funktechnik ausgestattetes Fahrzeug (A1), das einen Computer (C1) mit Internet-Anbindung enthält, welcher eine chronologische Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) auf einem nicht-flüchtigen Speicher (M1) abspeichert, dadurch gekennzeichnet, dass • besagter Computer (C1) Hash-Werte (Z1)(Y1)(Z1')(X1) aus Fahrzeugdaten-Einträgen (D1) berechnet und diese Hash-Werte über das Internet versendet, damit diese Hash-Werte in einer Blockchain-Datenbank (200) registriert werden, • besagter Computer (C1) die chronologische Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) über eine Datenschnittstelle an ein Computerprogramm (VS300) auf einer vom Fahrzeug (A1) getrennten Hardware übertragen kann, so dass dieses Computerprogramm (VS300) verifizieren kann, ob die Hash-Werte (Z1)(Y1)(Z1')(X1), die sich aus der chronologischen Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) errechnen, in der Blockchain (200) registriert sind, um damit die Integrität der chronologischen Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) zu validieren.
Ein Computerprogramm (C1) auf einem mit Funktechnik und Internet-Anbindung ausgestatteten elektronischen Benutzer-Endgerät, welches eine chronologische Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1), von denen mindestens ein Teil manuell vom Benutzer eingegeben wird, auf einem nicht-flüchtigen Speicher (M1) abspeichert, dadurch gekennzeichnet, dass • besagtes Computerprogramm (C1) Hash-Werte (Z1)(Y1)(Z1')(X1) aus Fahrzeugdaten-Einträgen (D1) berechnet und diese Hash-Werte über das Internet versendet, damit diese Hash-Werte in einer Blockchain-Datenbank (200) registriert werden, • besagtes Computerprogramm (C1) die chronologische Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) an ein anderes Computerprogramm (VS300) auf einer anderen Hardware übertragen kann, so dass dieses andere Computerprogramm (VS300) verifizieren kann, ob die Hash-Werte (Z1)(Y1)(Z1')(X1), die sich aus der chronologischen Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) errechnen, in der Blockchain (200) registriert sind, um damit die Integrität der chronologischen Abfolge (KH1) von Fahrzeugdaten-Einträgen (D1) zu validieren.
Eine Software (VS300), welche die Integrität einer chronologischen Abfolge (KH1) von Daten-Einträgen (D1) validiert, dadurch gekennzeichnet, dass • die Software diese chronologische Abfolge (KH1) von Daten-Einträgen (D1) als Eingabewert verarbeitet, • die Software (VS300) eine Blockchain (200), in der die Daten-Einträge (D1) registriert sind, auf bestimmte Bitmuster durchsucht, wobei sich diese Bitmuster aus Hash-Werten ergeben, welche eine Funktion der Menge von Daten-Einträgen (D1) sind, wobei jedes der besagten Bitmuster zu einem bestimmten Daten-Eintrag (D1) aus der Gesamtmenge an Daten-Einträgen korrespondiert, • die Software (VS300) die Zeitstempel von Blöcken (220) der Blockchain (200), die das besagte Bitmuster enthalten, mit den Zeitangaben der zu diesem Bitmuster korrespondierenden Daten-Einträge (D1) vergleicht, • die Software (VS300) nach Prüfung der Integrität eine Rückmeldung über das Prüfungsergebnis gibt.
Eine Software (VS300) nach Anspruch 9, dadurch gekennzeichnet, dass • die Software zusätzlich Ergänzungs-Datensätze (111_1) als Eingabewerte verarbeitet, die Ergänzungs-Bitsequenzen enthalten, wobei diese Ergänzungs-Bitsequenzen sich nicht aus besagter chronologischer Abfolge (KH1) von Daten-Einträgen (D1) ableiten lassen, und wobei jeder Ergänzungs-Datensatz (111_1) zu einem bestimmten Daten-Eintrag (D1) aus der Gesamtmenge an Daten-Einträgen korrespondiert, • die Software besagte Blockchain (200), in der die Daten-Einträge (D1) registriert sind, auf besagte Bitmuster durchsucht, wobei sich diese Bitmuster aus Hash-Werten ergeben, welche nicht nur eine Funktion der Menge von Daten-Einträgen (D1) sind, sondern auch eine Funktion der Ergänzungs-Datensätze (111_1), die jeweils zu bestimmten Daten-Einträgen (D1) aus der Gesamtmenge an Daten-Einträgen korrespondieren.