DE102017204250A1 - Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs - Google Patents

Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs Download PDF

Info

Publication number
DE102017204250A1
DE102017204250A1 DE102017204250.8A DE102017204250A DE102017204250A1 DE 102017204250 A1 DE102017204250 A1 DE 102017204250A1 DE 102017204250 A DE102017204250 A DE 102017204250A DE 102017204250 A1 DE102017204250 A1 DE 102017204250A1
Authority
DE
Germany
Prior art keywords
data
vehicle
tachometer
hash values
stored
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102017204250.8A
Other languages
English (en)
Inventor
Matthieu Chanson
Andreas Bogner
Timo Gessmann
Felix Wortmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102017204250.8A priority Critical patent/DE102017204250A1/de
Publication of DE102017204250A1 publication Critical patent/DE102017204250A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841Registering performance data
    • G07C5/085Registering performance data using electronic data carriers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84Vehicles

Abstract

Die Erfindung betrifft ein Verfahren zur Absicherung eines Tachometerstandes (10) eines Fahrzeugs (1) bei dem eine Abfolge von Datensätzen (21) mit Tachometerständen (10), Zeitdaten (12), Fahrzeugidentifikationsdaten (11) und Fülldaten (13) in einer Datenbank (4) abgelegt werden, wobei aus abgelegten Datensätzen (21) ein Hash-Wert (14) erzeugt wird, und der Hashwert (14) in einer Blockchain (15) gespeichert wird.

Description

  • Stand der Technik
  • Die Erfindung geht aus von einem Verfahren und Vorrichtungen nach der Gattung der unabhängigen Patentansprüche.
  • Es sind bereits Verfahren zur Absicherung von Tachometerständen eines Fahrzeugs bekannt, bei denen die Tachometerstände eines Fahrzeugs in verschlüsselter Form in einem elektronischen Steuergerät im Fahrzeug gespeichert werden. Durch die Verschlüsselung wird dabei versucht, eine nachträgliche Manipulation der Daten, die in dem Fahrzeug selbst gespeichert sind, zu erschweren. Als eine Variante können dabei die Fahrzeugdaten, insbesondere die Tachometerdaten in einer Vielzahl von unterschiedlichen Steuergeräten des Fahrzeugs mehrfach abgelegt werden. Weiterhin gibt es Vorgehensweisen, bei denen die Tachometerstände eines Fahrzeugs in einer externen Datenbank, beispielsweise bei einem Fahrzeughersteller oder bei einer staatlichen Institution oder einer sonstigen vertrauenswürdigen Institution, wie beispielsweise einem technischen Überwachungsverein, zu speichern. Diese Vorgehensweise bringt aber datenschutzrechtliche Nachteile mit sich, da fahrerspezifische Daten, wie beispielsweise die Fahrzeugidentifikationsnummer und die Kilometerstände bei Dritten entweder beim Fahrzeughersteller, der vertrauenswürdigen staatlichen Institution oder sonst einem Trustcenter gespeichert sind. Zusätzlich bringt die zentrale Speicherung der Daten bei einem (Plattform-)Anbieter auch das Risiko mit sich, dass die gespeicherten Daten zentral an einer Stelle verändert werden können. Außerdem ist der Besitzer der Daten im Fall eines zentralen (Plattform-)Anbieters auf die Verfügbarkeit des Datenservices durch den Anbieter verantwortlich. D.h. schaltet der Anbieter z. B. den Datenservice ab, hat der Besitzer der Daten keinen Zugriff mehr auf seine Daten. Des Weiteren ist eine Weitergabe der Daten durch den Besitzer selbst nicht möglich, sondern ist auch hier auf den Service des Anbieters angewiesen. Schwierig ist dabei auch, dass diese Lösungen in der Regel national sind und daher keine Absicherung über Ländergrenzen hinweg erlauben.
  • Vorteile der Erfindung
  • Das erfindungsgemäße Verfahren bzw. die erfindungsgemäße Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs hat demgegenüber den Vorteil, dass ein Fahrzeugbesitzer eine vollständige Inhaberschaft über seine Daten behält und trotzdem für den Fall des Verkaufs oder aus sonstigen Gründen der Kilometerstand eines Fahrzeugs sehr zuverlässig überprüft werden kann. Es kann somit mit großer Zuverlässigkeit sichergestellt werden, dass ein Fahrzeug tatsächlich nur die Kilometer zurückgelegt hat, die in dem Fahrzeugtachometer angegeben werden. Dazu werden die Datensätze mit den Tachometerständen direkt aus dem Fahrzeug (aus den entsprechenden Steuergeräten bzw. direkt aus dem betreffenden Sensor, welche die zurückgelegte Wegstrecke misst) in einer privaten Datenbank des Fahrzeugbesitzers abgelegt. Dabei wird der aus dem Fahrzeug ausgelesene Tachometerstand zusammen mit der jeweiligen Fahrzeugidentifikationsnummer („VIN“) noch im Fahrzeug mit einem spezifischen „Private Key“ des Fahrzeugdatenbesitzers verschlüsselt. Dies hat den Vorteil, dass diese personenbezogenen Daten (Tachometerstand, Fahrzeugidentifikationsnummer) nur von berechtigten Personen, welche den passenden „digitalen Key“ besitzen gelesen werden können. Zusätzlich werden Hash-Werte dieser Datensätze gebildet und in einer dezentralen Datenbank (Blockchain-Technologie) gespeichert. Diese Blockchain wird von einem Computernetzwerk bestehend aus mehreren öffentlich zugänglichen Rechnern gespeichert. Durch Blockchain-Technologie-spezifische kryptografische Methoden, sowie durch einen „Konsensus-Mechanismus“ werden die in der Blockchain gespeicherten Daten gegen nachträgliche Manipulationen geschützt. Durch eine erneute Erzeugung der Hash-Werte aus den abgelegten Datensätzen und Vergleich mit den Hash-Werten, die in der Blockchain gespeichert sind, lässt sich dann der Tachometerstand eines Fahrzeugs zuverlässig verifizieren. Insbesondere kann so über einen langen Zeitraum jede Veränderung eines Tachometerstandes nachträglich verifiziert werden.
  • Weitere Vorteile und Verbesserung ergeben sich durch die Maßnahmen der abhängigen Patentansprüche. Für die Verifikation des Tachometerstandes werden aus den abgelegten Datensätzen die Hash-Werte der Datensätze neu errechnet und mit den in der Blockchain gespeicherten Hash-Werten verglichen. Durch diesen einfachen Vergleich kann jede Manipulation der Datensätze sicher erkannt werden. Durch die Speicherung von Datensätzen verschiedener Fahrzeuge in der Blockchain kann erreicht werden, dass eine Vielzahl von Fahrzeugbesitzern einen Vorteil aus der Blockchain zieht, so dass die entsprechenden Aufwendungen für den Betrieb der Blockchain gerechtfertigt sind. Insbesondere bietet die Blockchain-Technologie den Vorteil, dass diese allen interessierten Teilnehmern (Fahrzeughersteller-unabhängig, Endkunden, OEMs, Zulieferer usw.) frei zugänglich ist und zur Verfügung steht. Dadurch kann diese Technologie weltweit, ohne die Abhängigkeit z. B. von einem (Plattform-)Anbieter, genutzt werden. Weiterhin wird in der Blockchain weitere Identifikationsdaten abgelegt, die es erlauben, eine Zuordnung der in der Blockchain gespeicherten Hash-Werte zu den Datensätzen, aus denen die Hash-Werte errechnet wurden, herzustellen. Es lässt sich so aus einer großen Blockchain, in der Daten einer Vielzahl von Fahrzeugbenutzern gespeichert sind, für jedes Fahrzeug individuell der Tachometerstand verifizieren. Die Datenbank mit den Datensätzen ist dabei so ausgestaltet, dass die jeweiligen Daten nur von einem Besitzer des Fahrzeugs bzw. Inhaber des „digitalen Keys“ zur Entschlüsselung der jeweiligen Daten zugänglich ist. Um eine Rückrechnung der Datensätze aus den Hash-Werten zu erschweren, sollten die Datensätze zusätzlich noch Fülldaten aufweisen, die ein Rückrechnen der Datensätze verhindern. Dies ist insbesondere deswegen wichtig, da alle in der Blockchain gespeicherten Daten via Internet allen frei zugänglich sind und es sich bei den Tachometerständen um kontinuierlich wachsende Daten handelt, wodurch ein eventuelles Zurückrechnen aus den Hash-Werten erleichtert werden könnte. Da für die Verifikation der Tachometerstände aufwendige Berechnungen ausgehend von der Blockchain erforderlich sind, können diese Berechnungen beispielsweise durch ein Trustcenter vorgenommen werden.
  • Figurenliste
  • Ausführungsbeispiele der Erfindungen werden in den 1 bis 3 dargestellt und in der nachfolgenden Beschreibung näher erläutert.
  • Es zeigen:
    • 1 ein Fahrzeug, ein Mobiltelefon und eine Cloud, die gemeinsam das erfindungsgemäße Verfahren realisieren,
    • 2 ein Fahrzeug, einen Applikationsserver und eine Cloud, die gemeinsam die Erfindungen realisieren, und
    • 3 die Verifikation des Tachometerstandes durch ein Trustcenter.
  • Beschreibung der Ausführungsbeispiele
  • In der 1 wird ein erstes Ausführungsbeispiel der Erfindung gezeigt, wobei das erfindungsgemäße Verfahren hier durch ein Zusammenwirken eines Fahrzeugs 1 mit einem Mobiltelefon 2 und einer Cloud 3, d. h. einem Rechnerverbund aus einer Vielzahl von Rechnern realisiert ist. Das Fahrzeug 1, dessen Tachometerstand abgesichert werden soll, sendet kontinuierlich oder in regelmäßigen Abständen seinen Tachometerstand 10 an das Mobiltelefon 2. Zusätzlich zu dem Tachometerstand 10, können auch Fahrzeugidentifikationsdaten 11, beispielsweise eine Fahrgestellnummer von dem Fahrzeug 1 an das Mobiltelefon 2, übertragen werden. Außerdem können diese Daten noch direkt im Fahrzeug bzw. im jeweiligen Sensor oder Steuergerät im Fahrzeug signiert und gehasht werden. Durch die persönliche Signierung (Bsp. durch einen „Private Key“) der betreffenden Daten im Fahrzeug, können diese verschlüsselt aus dem Fahrzeug übertragen werden, wodurch sichergestellt wird, dass kein Dritter diese personenbezogenen Daten einsehen kann. Alternativ ist es auch möglich, dass das Mobiltelefon 2 und das Fahrzeug 1 durch ein Paarungsprozess einander zugeordnet werden, so dass dies vollständigen Fahrzeugidentifikationsdaten 11 nur bei dieser Paarung von Fahrzeug 1 und Mobiltelefon 2 übertragen werden. Das Mobiltelefon 2 hat Zugang zu einer Datenbank 4 und einer Cloud 3. Bei dieser Datenbank 4 kann es sich insbesondere um eine in dem Mobiltelefon 2 selbst vorgesehene Datenbank handeln. Alternativ kann die Datenbank 4 auch extern von dem Mobiltelefon 2 sein, wobei dann ein Datenaustausch zwischen dem Mobiltelefon 2 und der Datenbank 4 nur in verschlüsselter Form erfolgen sollte. Aus den Tachometerständen 10 und der Fahrzeug-ID 11 erzeugt das Mobiltelefon 2 einen Datensatz 21, der in der Datenbank 4 abgelegt wird. Der Datensatz 21 enthält neben dem Tachometerstand 10 und der Fahrzeug-ID 11 zusätzlich noch Zeitdaten 12 und Fülldaten 13. Durch die Zeitdaten 12 wird der Tachometerstand 10 einer Zeit zugeordnet. Diese Zeitdaten 12 können beispielsweise in einem Datum oder aber sonstigen Zeitdaten, die eine Zuordnung der Tachometerstände in der Zeit erlauben, bestehen. Beispielsweise können die Zeitdaten 12 auch einfach die verstrichene Zeit seit einer ersten Inbetriebnahme des Fahrzeugs 1 enthalten. Weiterhin sind noch Fülldaten 13 enthalten. Diese Fülldaten dienen dazu, den Datensätzen 21 eine bestimmte Menge an Inhalten zuzuordnen, um eine Rückrechnung auf die Inhalte der Datensätze 21 aus einem daraus gebildeten Hash-Wert zu erschweren. Insbesondere sollten die Fülldaten 13 dabei aus zufälligen Fülldaten bestehen. Das Mobiltelefon 2 berechnet aus den Datensätzen 21 einen Hash-Wert 14, der an eine Cloud 3 (Blockchain-Technologie) gegeben wird.
  • Die Speicherung der Tachometerdaten 11 in den Datensätzen 21 kann variabel gehandhabt werden. Um den Berechnungsaufwand zu minimieren, kann beispielsweise vorgesehen sein, dass die Tachometerstände 11 nur einmal in der Woche einem Datensatz 21 gespeichert werden. Alternativ kann auch vorgesehen sein, nach jeder Fahrt des Fahrzeugs, einen entsprechenden Tachometerstand 10 abzulegen. Alternativ kann dies auch zu fest vorgegebenen Zeiten oder zufälligen Zeiten erfolgen. Eine weitere Möglichkeit liegt darin, einen Tachometerstand 10 immer dann zu speichern, wenn eine Verbindung zwischen dem Fahrzeug 1 und dem Mobiltelefon 2 hergestellt wird. Weiterhin muss nicht aus jedem Datensatz 21 ein Hash-Wert 14 errechnet werden. Es können auch mehrere Datensätze 21 zusammengefasst werden, um einen Hash-Wert 14 zu erzeugen. Auch die Erzeugung des Hash-Wertes kann dann zu fest vorgegebenen Zeiten, in regelmäßigen Abständen oder zufällig von Zeit zu Zeit erfolgen oder aber nur dann, wenn eine Verbindung zwischen dem Mobiltelefon 2 und der Cloud 3 hergestellt ist.
  • Die aus den Datensätzen 21 errechneten Hash-Werte 4 erlauben eine Überprüfung der Echtheit der Datensätze 21, gegenüber nachträglichen Manipulationen der Datenbank 4. Wenn also durch regelmäßige Speicherung von Datensätzen 21 eine Historie der Tachometerstände und zugeordneter Zeiten aufgezeichnet wurde, so kann durch die Hash-Werte 14 überprüft werden, ob diese Datensätze 21 nachträglich verändert wurden. Dazu ist es jedoch erforderlich, die Hash-Werte 14 ebenfalls in einer Art und Weise abzuspeichern, die eine nachträglichen Manipulation der Hash-Werte 14 bzw. ein völlig neues Aufspielen von Datensätzen 21 und Hash-Werten 14 verhindert. Dies erfolgt dadurch, dass die Hash-Werte 14 regelmäßig an eine Cloud 3 (Blockchain-Technologie), d. h. einen Verbund mehreren Rechnern gegeben werden und in einer Blockchain 15 gespeichert werden.
  • Bei einer derartigen Blockchain 15 handelt es sich um eine dezentrale Datenbank, zu welcher kontinuierlich neue Daten in Form von Transaktionen, insbesondere neue Hash-Werte 14 hinzugefügt werden. Um die Integrität dieser Blockchain sicherzustellen, werden die neuen Hash-Werte 14, die der bereits bestehenden Blockchain 15 hinzugefügt werden, wieder dadurch abgesichert, dass aus den bisherigen Daten der Blockchains 15 und den neuen Hash-Werten 14 ebenfalls ein neuer Hash-Wert errechnet wird. Dieser wird dann zusammen mit den Daten gespeichert und bildet so den erneuten Block der Blockchain 15. Bei einer derartigen Blockchain 15 handelt es sich somit um einen kontinuierlich wachsenden Datensatz aus dem aber aller hinzugefügten Daten seit dem Beginn der Blockchain 15 rückrechenbar sind, d. h. alle neu eingespeicherten Hash-Werte 14 lassen sich durch eine Rückrechnung aus der aktuellen Blockchain 15 errechnen. Aufgrund der kompletten notwendigen Berechnung ist es so gut wie unmöglich, die Blockchain 15 so zu manipulieren, um einen in der Vergangenheit eingespeisten Hash-Wert 14 zu verändern. Es wird so eine besonders sichere Speicherung der Hash-Werte 14, mit denen die Echtheit der Datensätze 21 bestätigt werden kann, sichergestellt.
  • Weiterhin ist es so, dass die jeweilige Blockchain-Datenbank 15 dezentral auf allen beteiligten Rechnern vorhanden ist. Bei jeder Hinzufügung neuer Hash-Werte 14 zu der Blockchain 15 wird dabei jede Kopie der Blockchain 15 in allen verschiedenen Rechnern aktualisiert. Die verschiedenen Rechner der Cloud 3 stimmen sich dabei untereinander via Konsenus-Mechanismus ab, wie die gültige letzte Blockchain 15 aussieht. Wenn es somit durch aufwendige Berechnungen doch möglich sein sollte, eine einzelne Kopie der Blockchain 15 zu verändern, so wäre dies spätestens durch einen Vergleich mit den anderen Kopien der Blockchain 15 leicht feststellbar.
  • Aus den Datensätzen 21 werden somit Hash-Werte erzeugt, die eine Verifikation der Datensätze 21 erlauben, wenn die Echtheit der Hash-Werte 14 feststeht. Da die Hash-Werte 14 kontinuierlich in einer Blockchain 15 gespeichert werden, wird die Echtheit der Hash-Werte durch die Blockchain 15 sichergestellt. Die Sicherheit der Blockchain 15 wiederum ist dadurch sichergestellt, dass eine Vielzahl von Kopien der Blockchain auf eine Vielzahl von verteilten Rechnern vorliegt und somit eine Manipulation der Blockchain 15 in einem einzelnen Rechner durch den Vergleich der verschiedenen Kopien der Blockchain 15 in den verschiedenen Rechnern sichergestellt ist. Es wird so ein Verfahren dargestellt, bei dem die Tachometerstände eines Fahrzeugs 1 in einer Datenbank 4 abgelegt werden, wobei die Echtheit dieser Datenbank durch die Blockchain 15 die parallel auf einer Vielzahl von Rechnern in der Cloud 3 (Blockchain-Technologie) gespeichert ist, sichergestellt werden kann. Durch dieses Verfahren wird daher eine größtmögliche Sicherheit bei der Absicherung von Tachometerständen eines Fahrzeugs erreicht.
  • Für die Überprüfung des Tachometerstandes des Fahrzeugs 1 muss dann mindestens ein Datensatz 21 aus dem Speicher 4 durch die Ermittlung des dazugehörigen Hash-Wert 14 aus der Blockchain 15 überprüft werden. Dabei kann entweder die Gesamtheit der Datensätze 21 in dem Speicher 4 oder aber nur die Überprüfung des letzten Datensatzes 21 in dem Speicher 4 erfolgen. Da zur Auswertung der Blockchain 15 aufwendigere Berechnungen erforderlich sind, wird eine derartige Überprüfung eines oder aller Datensätze 21 in der Datenbank 4 üblicherweise durch ein Trustcenter 22 erfolgen. Bei einem derartigen Trustcenter 22 handelt es sich um einen Rechner, der unter der Kontrolle eine vertrauenswürdige Institution ist. Eine derartige Institution kann beispielsweise in einer staatlichen Institution oder einer sonstigen vertrauenswürdigen Institution, wie beispielsweise einem technischen Überwachungsverein stehen. Alternativ kann es auch möglich sein, dass diese Dienstleistung durch einen entsprechenden Dienstleister als Service im Internet angeboten wird. Damit eine derartige Überprüfung eines Tachometerstandes erfolgt, muss der Eigentümer des Fahrzeugs 1 einen Zugriff auf die Datenbank 4 freigeben. Das Trustcenter 22 kann somit auf die jeweils zu prüfenden Rohdaten (Datensätze 21) in der jeweiligen Datenbank 4 zugreifen. Außerdem kann das Trustcenter 22 auf die den Rohdaten entsprechenden Transaktionen und Hash-Werte in der Blockchain 15 zugreifen und das das Trustcenter 22 errechnet aus den zur Verfügung gestellten Rohdaten (Datensätze 21) die dazugehörigen Hash-Werte und vergleicht diese Hash-Werte mit den in der Blockchain 15 gespeicherten Daten. Wenn beide Hash-Werte 14 übereinstimmen, so ist die Echtheit der Rohdaten (Datensätze 21) in der Datenbank 4 bestätigt.
  • Alternativ zu einem externen Mobiltelefon 2 kann es sich dabei auch um eine Einheit handeln, die fest in dem Fahrzeug 1 verbaut ist. Beispielsweise enthalten viele Fahrzeuge heute bereits einen Kommunikationsrechner, der mittels eines GSM-Mobiltelefons oder einer sonstigen Datenverbindung ein Datenaustauch mit der Cloud 3 vornehmen kann. Entsprechend könnte dann die Datenbank 4 auch unmittelbar im Fahrzeug angeordnet sein. Alternativ kann die Datenbank 4 auch in der Cloud angeordnet sein, wobei dann eine verschlüsselte Kommunikation mit der Datenbank 4 erfolgen muss.
  • Statt eines Trustcenters 22 an eine Überprüfung der Tachometerstände auch dadurch erfolgen, dass auf einem Rechner ein entsprechendes Auswerteprogramm vorhanden ist. Der Inhaber des Fahrzeugs 1 würde dann die Datensätze 21 an diesen Rechner senden. Weiterhin liest dieser Rechner die zu den Datensätze 21 korrespondierenden Transaktionen (Hash-Werte) aus der Blockchain 15 ein und vergleicht die entsprechenden Hash-Werte aus Datensätze 21 und Blockchain 15. Beispielsweise möchte sich der Käufer eines Wagens von der Echtheit des Tachometerstandes überzeugen. Um den Käufer die Echtheit des Tachometerstandes zu beweisen, gewährt der Verkäufer des Fahrzeugs 1 dem Käufer Zugang zu der Datenbank 4. Der Käufer liest die korrespondierenden Transaktionen (Hash-Werte) aus der Blockchain 15 aus und errechnet aus den Rohdaten (Datenbank 4) des Verkäufers die Hash-Werte der Datensätze 21, die ihm der Verkäufer zur Verfügung gestellt hat. Durch Vergleich der in der Blockchain 15 gespeicherten Hash-Werte mit den aus den Datensätzen 21 ermittelten Hash-Werte, kann sich so ein Käufer eines Fahrzeugs von der Richtigkeit des Tachometerstandes versichern ohne sich dabei auf einen Dritten zu verlassen. Alternativ kann diese Richtigkeit natürlich auch durch Betreiber eines Trustcenters 22, der dies als Dienstleistung entsprechend anbietet, sichergestellt werden.
  • In der 2 wird ein alternatives Ausführungsbeispiel gezeigt, bei dem nicht ein Mobiltelefon 2, sondern ein Applikationsserver 200 eines Dienstleisters Verwendung findet. Dieser Applikationsserver 200 ist als Rechner ausgebildet, der die gleichen Funktionen wahrnimmt, wie das Mobiltelefon 2 in der 1. Das heißt, der Application Server 200 erhält die Tachometerstände 10 und die Fahrzeug-ID 11 bildet daraus entsprechende Datensätze 21, die über eine verschlüsselte Verbindung 210 in einer Datenbank 4 abgelegt werden. Dabei können die jeweiligen Daten (Tachometerstände 10 und die Fahrzeug-ID 11) auch direkt im Fahrzeug (Steuergerät, im Sensor) bereits mit dem „Private Key“ des Fahrzeugdatenbesitzers signiert und gehasht werden, damit der Eigentümer bzw. Betreiber des Application Server 200 die personenbezogenen Fahrzeugdaten nicht einsehen kann. Weiterhin ermittelt der Applikationsserver 200 aus den Datensätzen 21 die dazugehörigen Hash-Werte 14 und kommuniziert diese an die Cloud 3 zur Ablage in der Blockchain 15. Der Applikationsserver 200 kann die Datensätze auch alternativ von einem OEM-Rechner 201 erhalten. Bei einem derartigen OEM-Rechner handelt es sich um einen Rechner des Herstellers des Fahrzeugs 1, der zur Diagnosezwecken kontinuierlich Daten von dem Fahrzeug 1 erhält. In diesen Daten sind dann unter anderem auch die Tachometerstände 10 und die Fahrzeug-ID 11 enthalten. Der OEM-Rechner 201 gibt diese Daten 10, 11 dann entsprechend an den Application Server 200 weiter. Wesentlich ist dabei, dass der Application Server 200 keinerlei unverschlüsselte Daten weitergibt. Sowohl die Datenablage im Speicher 4 erfolgt über eine verschlüsselte Verbindung 210 wie auch der Austausch von Daten mit der Cloud 3.
  • In der 3 werden noch Details der Verifikation durch einen Trustcenter 22 dargestellt. Das Trustcenter 22 ist mit dem Application Server 200, wie bereits zur 2 beschrieben wurde, verbunden und erhält von dem Application Server 200 die Hash-Werte 14 zu den Datensätzen 21. Die Hash-Werte 14 werden vom Rechner des Application Server 200 aus der Blockchain 15 gelesen. Alternativ kann das Trustcenter 22 aber auch die Hash-Werte 14 unmittelbar aus der Blockchain 15 auslesen oder aber erhält die Hash-Werte direkt von einem Rechner der Cloud 3, die eine Kopie der Blockchain 15 besitzt. Auf jeden Fall liegt in dem Trustcenter 22 für den Zweck des Vergleichs die Hash-Werte 14 entsprechend zu den Datensätzen 21 vor. Die Zuführung der Datensätze 21 erfolgt mit Hilfe eines Mobiltelefons 2, welches unter der Kontrolle des Eigentümers des Fahrzeugs steht. Das Mobiltelefon 2 greift auf die Datenbank 4 zu und erhält verschlüsselte Daten 210. Durch Entschlüsselung wird aus diesen von der Datenbank 4 übertragenen Daten 210 die ursprünglichen Datensätze 21 wieder gewonnen. Entsprechend gibt das Mobiltelefon 2 dann die entschlüsselten Datensätze 21 an das Trustcenter 22 zum Zweck der Verifikation, dass diese Daten nicht verfälscht wurden. Wie bereits beschrieben, werden dazu aus den übermittelten Datensätzen 21 wieder die Hash-Werte 14 errechnet und mit dem Hash-Werten 14, die in der Blockchain 15 gespeichert waren, verglichen. Alternativ kann der Eigentümer des Fahrzeugs auch dem Trustcenter durch Übergabe eines Verschlüsselungscodes oder einer Zugangsberechtigung einen Zugang zur Datenbank 4 gewähren, wodurch das Trustcenter 22 die Datensätze 21 unmittelbar in direkter Kommunikation mit der Datenbank 4 ermitteln kann.
  • Das beschriebene Verfahren kann nicht nur zur Absicherung von Tachometerständen eines Fahrzeugs, sondern zur Absicherung von jeglichen Betriebsdaten eines technischen Gegenstandes oder einer technischen Maschine verwendet werden. Statt Tachometerständen könnten somit Betriebszeiten, Belastungen während des Betriebs, aufgetretene Messwerte, Sensordaten, Ansteuerdaten von Aktuatoren oder alle beliebigen Betriebsdaten eines Gegenstandes oder einer Maschine abgesichert werden. Diese Betriebsdaten werden dann zusammen mit Zeitdaten und einer Identifikationsinformation des technischen Gegenstandes oder der Maschine und Fülldaten in einer Datenbank entsprechend der Datenbank 4, den in den 1 bis 3 beschrieben wurde, abgelegt. Aus den so abgelegten Datensätzen werden dann wieder Hash-Werte erzeugt und in einer Blockchain gespeichert. Durch erneutes Speichern von Betriebsdaten und Ablegen der entsprechenden Hash-Werte in der Blockchain kann auch so eine Betriebshistorie jedes technischen Gegenstandes oder jeder technischen Maschine gebildet werden und durch Speicherung der entsprechenden Hash-Werte in der Blockchain zuverlässig mitprotokolliert werden. Beispiele wären zum Beispiel Betriebszeiten einer Werkzeugmaschine oder Betriebszeiten einer Baumaschine oder die dabei auftretenden mechanischen Belastungen oder Besonderheiten. Jegliche Form von Messdaten einer technischen Vorrichtung können so in einer Datenbank 4 gesammelt werden und durch Ablegen der Hash-Werte in einer Blockchain verifiziert werden. Dies ist beispielsweise dann von Bedeutung, wenn entsprechende Vorrichtungen vermietet werden und die Berechnung des Mietpreises nicht nur aufgrund der Zeit, sondern aufgrund der Betriebsdauer oder Belastungen während der Mietzeit abgerechnet werden. Durch Abspeichern der Betriebsdaten in entsprechenden Datensätzen und Übermittlung der Hash-Werte an eine Blockchain kann so auch über einen längeren Zeitraum zuverlässig übermittelt werden, welchen Belastungen ein bestimmter technischer Gegenstand ausgesetzt war.

Claims (9)

  1. Verfahren zur Absicherung eines Tachometerstandes (10) eines Fahrzeugs (1) bei dem eine Abfolge von Datensätzen (21) mit Tachometerständen (10), Zeitdaten (12), Fahrzeugidentifikationsdaten (11) und Fülldaten (13) in einer Datenbank (4) abgelegt werden, wobei aus abgelegten Datensätzen (21) ein Hash-Wert (14) erzeugt wird, und der Hash-Wert (14) in einer Blockchain (15) gespeichert wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zur Verifizierung des Tachometerstandes (10) aus den abgelegten Datensätze (21) Hash-Werte (14) der Datensätze (21) neu errechnet werden und mit gespeicherten Hash-Werten (14) in der Blockchain (15) verglichen werden.
  3. Verfahren nach einem der vorhergehenden Ansprüche dadurch gekennzeichnet, dass in der Blockchain (15) Hashwerte (14) von Datensätze (21) verschiedener Fahrzeuge (1) gespeichert werden und bei der Speicherung neuer Hash-Werte (14) in der Blockchain (15) die Blockchain (15) auf einer Vielzahl von Rechnern aktualisiert wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zusätzlich zu den Hash-Werten (14) weitere Identifikationsdaten in der Blockchain (15) abgelegt werden, die eine Zuordnung der Hash-Werte (14) zu den Datensätzen (21) aus denen die Hash-Werte (14) errechnet wurden für die Verifikation der Tachometerstände (10) erlaubt.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Datenbank (4) nur für einen Besitzer des Fahrzeugs (1) zugänglich ist.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Fülldaten (13) so gewählt sind, dass eine Rückrechnung der Datensätze (21) aus den Hash-Werten (14) erschwert ist.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Verifikation durch ein Trustcenter (22) erfolgt welche aus den Datensätze (21) die Hash-Werte (14) der Datensätze (21) neu errechnet und mit gespeicherten Hash-Werten (14) in der Blockchain (15) vergleicht.
  8. Vorrichtung zur Absicherung eines Tachometerstandes (10) eines Fahrzeugs (1) die aus Tachometerständen (10) eines Fahrzeugs (1) eine Abfolge von Datensätzen (21) mit Tachometerständen (10), Zeitdaten (12), Fahrzeugidentifikationsdaten (11) und Fülldaten (13) in einer Datenbank (4) abgelegt, aus den abgelegten Datensätzen (21) ein Hash-Wert (14) erzeugt, und den Hash-Wert (14) zur Speicherung an eine Blockchain (15) weiter gibt.
  9. Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs bei dem mindestens ein Datensatz (21) mit einem Tachometerstand (10), Zeitdaten (12), Fahrzeugidentifikationsdaten (11) und Fülldaten (13) aus einer Datenbank (4) eingelesen wird, wobei aus dem Datensätzen (21) ein Hash-Wert (14) erzeugt wird, und der Hash-Wert (14) mit einem Hashwert aus einer Blockchain (15) verglichen wird.
DE102017204250.8A 2017-03-14 2017-03-14 Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs Pending DE102017204250A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102017204250.8A DE102017204250A1 (de) 2017-03-14 2017-03-14 Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102017204250.8A DE102017204250A1 (de) 2017-03-14 2017-03-14 Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs

Publications (1)

Publication Number Publication Date
DE102017204250A1 true DE102017204250A1 (de) 2018-09-20

Family

ID=63372445

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017204250.8A Pending DE102017204250A1 (de) 2017-03-14 2017-03-14 Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs

Country Status (1)

Country Link
DE (1) DE102017204250A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020064055A1 (de) * 2018-09-24 2020-04-02 Akarion Ag Datenbank und verfahren zur datenlöschung
DE102019002139A1 (de) * 2019-03-26 2020-10-01 Diehl Defence Gmbh & Co. Kg Verfahren zur Prozessdokumentation
DE102019205866A1 (de) * 2019-04-24 2020-10-29 Continental Automotive Gmbh Verfahren zur Speicherung und Freigabe von nutzerbezogenen Daten, Fahrerassistenzsystem, Computerprogramm und computerlesbares Medium
CN112733197A (zh) * 2019-10-28 2021-04-30 本田技研工业株式会社 信息管理系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GIPP, B. et al.: Decentralized Trusted Timestamping using the Crypto Currency Bitcoin. Proceedings of the iConference 2015. 24.-27.03.2015 [abgerufen am 30.10.2017]
KALTOFEN, T.: Tachofälschung Adé – Dank Blockchains. URL: https://faizod.com/wp-content/downloads/Tachofaelschungen-ade---dank-Blockchains.pdf. 20.06.2016 [abgerufen am 30.10.2017]
Ventum Consulting & Solutions: Millionenschäden durch Tachomanipulation. URL: http://www.ventum-consulting.com/site/de/ventum/ueber-uns/news/2017-02-22-millionenschaeden-durch-tachomanipulationen.html. 22.02.2017 [abgerufen am 30.10.2017]

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020064055A1 (de) * 2018-09-24 2020-04-02 Akarion Ag Datenbank und verfahren zur datenlöschung
DE102019002139A1 (de) * 2019-03-26 2020-10-01 Diehl Defence Gmbh & Co. Kg Verfahren zur Prozessdokumentation
DE102019205866A1 (de) * 2019-04-24 2020-10-29 Continental Automotive Gmbh Verfahren zur Speicherung und Freigabe von nutzerbezogenen Daten, Fahrerassistenzsystem, Computerprogramm und computerlesbares Medium
CN112733197A (zh) * 2019-10-28 2021-04-30 本田技研工业株式会社 信息管理系统

Similar Documents

Publication Publication Date Title
EP3596878A1 (de) Protokollieren von zustandsdaten einer vorrichtung in einer blockchain
DE102017204250A1 (de) Verfahren und Vorrichtung zur Absicherung eines Tachometerstandes eines Fahrzeugs und Vorrichtung zur Verifikation eines Tachometerstandes eines Fahrzeugs
WO2015124726A1 (de) Verfarhen und system zum erstellen und zur gültigkeitsprüfung von gerätezertifikaten
DE102018204021A1 (de) Verfahren zum Datenaustausch mit einem Fahrzeugsteuergerät
DE112018003781T5 (de) Kontoverwaltungsvorrichtung, kontoverwaltungssystem, und fahrzeuggebundene informationsbereitstellungsvorrichtung
EP1185026B1 (de) Verfahren zur Datenübertragung
EP3452941A1 (de) Verfahren zur elektronischen dokumentation von lizenzinformationen
DE19959764A1 (de) Verbesserte digitale Signatur
DE102018210318A1 (de) Verfahren zur Sicherung von Fahrzeugkomponenten und entsprechende Fahrzeugkomponente
WO2018104277A1 (de) Bidirektional verkettete blockchainstruktur
DE102014210282A1 (de) Erzeugen eines kryptographischen Schlüssels
DE112018007132T5 (de) Fahrzeuginternes Funktionszugriffkontrollsystem, fahrzeuginterne Vorrichtung und fahrzeuginternes Funktionszugriffkontrollverfahren
WO2020064346A1 (de) System, verfahren und vorrichtung zur durchführung von kryptographisch gesicherten transaktionen
EP1652337B1 (de) Verfahren zum signieren einer datenmenge in einem public-key-system sowie ein datenverarbeitungssystem zur durchführung des verfahrens
DE202012104439U1 (de) Vorrichtung zur Kontrolle der Laufleistung eines Kraftfahrzeugs
WO2021110425A1 (de) Verfahren und messeinheit zur identitätsgesicherten bereitstellung eines messdatensatzes
DE102016207145A1 (de) Steuersystem für eine Verarbeitung von Bilddaten
DE102019000023A1 (de) Verfahren und System zur Informationsübermittlung
DE102021106261A1 (de) Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung
DE102018202676A1 (de) Verfahren zum Authentifizieren eines Benutzers
DE10112166A1 (de) Verfahren zum Transaktionsnachweis
EP1609097B1 (de) Verfahren und kommunikationssystem zur freigabe einer datenverarbeitungseinheit
WO2004017182A2 (de) Übernehmen eines datensatzes in eine recheneinheit
EP1358734A1 (de) Telekommunikationsprotokoll, -system und -vorrichtungen zur anonymen und authentischen abwicklung einer elektronischen wahl
DE102019210625A1 (de) Steuergerät und Verfahren zum Betreiben desselben

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication