DE102021106261A1

DE102021106261A1 - Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, Verarbeitungseinrichtung, Kraftfahrzeug und Infrastruktureinrichtung

Info

Publication number: DE102021106261A1
Application number: DE102021106261.6A
Authority: DE
Inventors: Marcel Dietz; Leonard Dorlöchter; Kevin Ostheimer; Pavlo Fomenko
Original assignee: Audi AG
Current assignee: Audi AG
Priority date: 2021-03-15
Filing date: 2021-03-15
Publication date: 2022-09-15
Also published as: US20240140249A1; CN116982332A; WO2022194658A1

Abstract

Verfahren zur Autorisierung eines ersten Teilnehmers (1-6) in einem Kommunikationsnetz (11), über das mehrere Teilnehmer (1 - 6) kommunizieren, wobei den Teilnehmern (1 - 6) jeweils eine Identifikationsinformation (7, 8, 43) zugeordnet ist, umfassend die Schritte:- Übertragen der Identifikationsinformation (7, 8, 43) des ersten Teilnehmers (1 - 6) an einen zweiten Teilnehmer (1 - 6) in dem Kommunikationsnetz (11), der eine Verarbeitungseinrichtung (12, 13, 30, 31) ist oder umfasst,- Prüfen, ob in einer Datenstruktur (16, 17) der Identifikationsinformation (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind, durch die Verarbeitungseinrichtung (12, 13, 30, 31), wobei eine Datenstruktur (16, 17) verwendet wird, die auf mehreren als Teilnehmer (1 - 6) über das Kommunikationsnetz (11) kommunizierenden Verarbeitungseinrichtungen (12, 13, 30, 31) repliziert ist und die mehrere Datenblöcke (34) umfasst, die in einer Abfolge geordnet und derart miteinander verknüpft sind, dass der Inhalt eines jeweiligen nachfolgenden Datenblocks (34) vom Inhalt wenigstens eines vorangehenden Datenblocks (34) abhängt,- Freigabe einer Funktion (26, 27) des zweiten Teilnehmers (1 - 6) ausschließlich bei Erfüllung einer die Autorisierungsdaten (42, 49) auswertenden Autorisierungsbedingung (47), die nur dann erfüllbar ist, wenn der Identifikationsinformation (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind.

Description

Die Erfindung betrifft ein Verfahren zur Autorisierung eines ersten Teilnehmers in einem Kommunikationsnetz, über das mehrere Teilnehmer kommunizieren, wobei den Teilnehmern jeweils eine Identifikationsinformation zugeordnet ist. Daneben betrifft die Erfindung eine Verarbeitungseinrichtung, ein Kraftfahrzeug und eine Infrastruktureinrichtung.
Es ist zweckmäßig, wenn Kraftfahrzeuge Interaktionen mit Infrastruktureinrichtungen, bei den auch Bezahlvorgänge relevant sein können, weitgehend automatisiert abwickeln können. Besonders relevant kann dies beispielsweise beim Laden eines Kraftfahrzeugs an einer öffentlichen Ladeeinrichtung sein, da dieser Vorgang beispielsweise regelmäßig beim Parken im öffentlichen Raum durchgeführt werden soll und somit möglichst wenig Aufwand für einen Nutzer erzeugen soll. Eine Automatisierung kann es beispielsweise auch ermöglichen, dass ein vollautomatisiertes Fahrzeug eine Ladeeinrichtung selbst anfährt und den Ladevorgang ohne Nutzereingriff ausführt oder Ähnliches.
Auch für andere Vorgänge, beispielsweise für das Befahren von nur eingeschränkt oder beispielsweise gegen Zahlung einer Gebühr befahrbaren Bereichen, beispielsweise von Parkhäusern oder bestimmten Innenstadtbereichen, ist es vorteilhaft einen entsprechenden Vorgang zu automatisieren. Zugleich soll jedoch vermieden werden, dass an eine Vielzahl von unter Umständen nicht vertrauenswürdigen Einrichtungen persönliche Daten eines Fahrzeughalters, Kontodaten oder Ähnliches bereitgestellt werden.
Ein möglicher Ansatz, um zumindest den Zahlungsvorgang zu automatisieren und hierbei eine hohe Datensparsamkeit zu erreichen, ist es, ein Blockchain-basiertes Bezahlsystem zu nutzen, wie es beispielsweise aus der Druckschrift DE 10 2017 212 904 A1 bekannt ist. Der Vorteil solcher Bezahlsysteme ist, dass bei hoher Datensparsamkeit Transaktionen innerhalb der Blockchain durch die verwendete Datenstruktur gesichert sind, sodass beispielsweise sichergestellt werden kann, dass ein einem Benutzer zugeordnetes Guthaben nur einmal ausgegeben werden kann.
Es bleibt jedoch einerseits der Nachteil, dass es sich systembedingt um ein guthabenbasiertes System handelt, das heißt, dass Nutzer vorab Guthaben in die Blockchain, insbesondere in eine dem Nutzer zugeordnete sogenannte „Wallet“, transferieren müssen und beispielsweise keine direkte Abbuchung von einem externen Konto möglich ist. Zudem können durch eine Blockchain nur Transaktionen innerhalb der Blockchain selbst abgesichert werden, sodass beispielsweise eine tatsächliche bereitgestellte Lademenge, die Einhaltung vorgegebener Parameter, eine Einhaltung von Sicherheitsstandard etc. zwischen Transaktionsteilnehmern, beispielsweise beim Laden eines Fahrzeugs, strittig sein können.
Das zweite Problem lässt sich weitgehend vermeiden, wenn für die einzelnen Teilnehmer eine Zertifizierung erfolgt, die beispielsweise eine Messgenauigkeit für eine Energiemengenerfassung und weitere technische Parameter betreffen kann. Um eine solche Zertifizierung automatisiert prüfen zu können, sind beispielsweise digitale Zertifikate nutzbar, die insbesondere mit Hilfe von asymmetrischen Kryptographieverfahren generiert werden können.
Soll es jedoch möglich sein, entsprechende Zertifikate zu wiederrufen, beispielsweise wenn ein technischer Defekt oder ein gezielter Missbrauch erkannt wird, ist eine zentrale Zertifikatverwaltung erforderlich. Bei dieser handelt es sich jedoch um einen „Single Point of Failure“, womit sie hoch verfügbar und hoch redundant ausgelegt sein muss. Hierdurch entstehen hohe Betriebskosten. Zudem führt die Nutzung einer zentralen Zertifikatverwaltung auch zu potentiellen Problemen, wenn beispielweise eine Betreiber deren Betrieb unerwartet einstellt.
Der Erfindung liegt somit die Aufgabe zugrunde, ein demgegenüber verbessertes Verfahren zur Autorisierung eines Teilnehmers in einem Kommunikationsnetz anzugeben, das insbesondere die Nachteile einer zentralen Zertifikatsverwaltung vermeidet.
Die Aufgabe wird durch ein Verfahren der eingangs genannten Art gelöst, dass die folgenden Schritte umfasst:

- Übertragen der Identifikationsinformation des ersten Teilnehmers an einen zweiten Teilnehmer in dem Kommunikationsnetz, der eine Verarbeitungseinrichtung ist oder umfasst,
- Prüfen, ob in einer Datenstruktur der Identifikationsinformation zugeordnete Autorisierungsdaten vorhanden sind, durch die Verarbeitungseinrichtung, wobei eine Datenstruktur verwendet wird, die auf mehreren als Teilnehmer über das Kommunikationsnetz kommunizierenden Verarbeitungseinrichtungen repliziert ist und die mehrere Datenblöcke umfasst, die in einer Abfolge geordnet und derart miteinander verknüpft sind, dass der Inhalt eines jeweiligen nachfolgenden Datenblocks vom Inhalt wenigstens eines vorangehenden Datenblocks abhängt,
- Freigabe einer Funktion des zweiten Teilnehmers ausschließlich bei Erfüllung einer die Autorisierungsdaten auswertenden Autorisierungsbedingung, die nur dann erfüllbar ist, wenn der Identifikationsinformation zugeordnete Autorisierungsdaten vorhanden sind.

Der Erfindung liegt die Idee zugrunde, eine Autorisierung nicht mehr mit Hilfe einer zentralen Einrichtung durchzuführen, sondern die hierfür erforderlichen Daten lokal in der jeweiligen Verarbeitungseinrichtung vorzuhalten, indem die erforderliche Datenstruktur in verschiedenen Verarbeitungseinrichtungen, insbesondere in möglichst allen Verarbeitungseinrichtungen in dem Kommunikationsnetz, repliziert ist. Durch die beschriebene Verkettung der Datenblöcke kann zugleich erreicht werden, dass durch die dezentralen Speicherung der Datenstruktur diese weitgehend manipulationssicher ist, indem geeignete Ansätze zum Anfügen weiterer Datenblöcke bzw. zur Replikation der Datenstruktur genutzt werden. Verschiedenen Implementierungsmöglichkeiten hierfür sind insbesondere aus dem Bereich der Blockchains bzw. KryptoWährungen bekannt, wobei dort statt Autorisierungsdaten Guthaben bzw. Finanztransaktionen gespeichert werden.
Da somit ein dezentrales und insbesondere manipulationssicheres System zur Prüfung einer Autorisierung genutzt wird, kann darauf verzichtet werden, eine vertrauenswürdige zentrale Zertifikatsverwaltung zu nutzen. Stattdessen kann die erforderliche Datensicherheit und somit das Vertrauen in den Inhalt der Datenstruktur durch technische Maßnahmen erreicht werden. Hierdurch bleibt das System auch beim Ausscheiden einzelner Teilnehmer stets robust und es entfallen die Kosten für eine zentrale Zertifikatsverwaltung.
Die Abfolge der Datenblöcke kann allgemein durch einen ein- oder mehrdimensionalen azyklischen Graphen definiert sein. Im einfachsten Fall wird eine eindimensionale Anordnung genutzt, sodass eine eindeutige Reihenfolge der Blöcke festgelegt ist. Hierbei kann ein nachfolgender Datenblock insbesondere von dem in dieser Reihenfolge unmittelbar vorangehenden Datenblock abhängen.
Die Abhängigkeit des nachfolgenden Datenblocks vom Inhalt des wenigstens einen vorangehenden Datenblocks kann insbesondere darin bestehen, dass der nachfolgende Datenblock einen Hashwert, insbesondere einen kryptografischen Hashwert, des vorangehenden Datenblocks bzw. der vorangehenden Datenblöcke oder eine hiervon abhängende Information umfasst. Hierdurch ist es allenfalls mit sehr hohem Rechenaufwand möglich, eine Modifikation eines Datenblocks aufzufinden, die nicht zur Änderung des Hashwertes und somit zu einer Inkonsistenz mit dem nachfolgenden Datenblock führt. Möchte somit ein Angreifer einen Datenblock verändern, muss er auch alle nachfolgenden Datenblöcke neu generieren.
Ist ein Hinzufügen gültiger Datenblöcke zur Datenstruktur beispielsweise relativ rechenaufwändig, was bezüglich Blockchains als „Proof of Work“ bezeichnet wird, oder aufgrund von weiteren Anforderungen eingeschränkt, insbesondere durch einen sogenannten „Proof of Stake“, und wird jeweils die Datenstruktur mit der höchsten Blockzahl durch die Verarbeitungseinrichtungen als aktuell gültige Datenstruktur identifiziert und repliziert, kann insgesamt eine sehr hohe Manipulationssicherheit erreicht werden.
Die weitere Anforderung kann beispielsweise so gewählt sein, dass ein bestimmter Teilnehmer in einem bestimmten Zeitintervall nur eine bestimmte Anzahl von Blöcken generieren kann. Wie häufig Blöcke durch einen bestimmten Teilnehmer generierbar sind, kann insbesondere von einem ökonomischen Interesse des jeweiligen Teilnehmers an der Verlässlichkeit der Datenstruktur abhängen. Das ökonomische Interesse kann beispielweise auf Basis der Datenstruktur selbst, beispielsweise durch Berücksichtigung der darin abgebildeten ökonomischen Werte oder auf Basis eines Transaktionsvolumens oder Ähnlichem ermittelt werden. Ein solcher Einsatz wird auch als „Proof of Stake“ bezeichnet.
Die Datenstruktur kann insbesondere eine Blockchain und/oder eine verteilte Transaktionsdatenbank („distributed ledger“), die einzelne Transaktionen speichert, sein. Im einfachsten Fall kann eine Transaktion pro Datenblock gespeichert werden. Bei hohen Transaktionszahlen kann es jedoch vorteilhaft sein, mehrere Transaktionen in einem Datenblock zusammenzufassen. Insbesondere werden frühere Transaktion in frühen Datenblöcken der Abfolge und spätere Transaktionen in späteren Datenblöcken der Abfolge gespeichert. Ein grober Zeitpunkt der Transaktion ist somit bereits aufgrund des Datenblocks, in dem sie gespeichert ist, abschätzbar. Bevorzugt werden die einzelne Transaktionen jedoch zusätzlich mit Zeitstempeln versehen.
Bevorzugt wird jede Transaktion durch den jeweiligen Teilnehmer mit Hilfe einer Geheiminformation, insbesondere eines geheimen Schlüssels eines Schlüsselpaares in einem asymmetrischen Verschlüsslungsverfahren, signiert. Transaktionen können auch durch sogenannte „Smart Contracts“, also Computerprogramme, die als Teil der Datenstruktur, insbesondere als ein Datenblock, bereitgestellt werden, ausgelöst und optional signiert werden. Hierbei erfordert das Auslösen einer Transaktion durch einen solchen Smart Contract insbesondere den Nachweis, dass ein Teilnehmer die geheime Information, also beispielsweise den privaten Schlüssel, besitzt. Dieser Nachweis kann durch Signieren einer Anfrage an den Smart Contract erfolgen, es kann jedoch auch ein Challenge-Response-Verfahren genutzt werden oder Ähnliches.
Die Autorisierungsdaten können in einem einfachen Beispiel die jeweilige Identifikationsinformation und eine Variable bzw. ein Flag umfassen, die bzw. das angibt, ob der Teilnehmer mit dieser Identifikationsinformation autorisiert ist oder nicht. Bevorzugt umfassen die Autorisierungsdaten jedoch zusätzlich Informationen, welcher Teilnehmer die Autorisierungsdaten angelegt und/oder verändert hat, und/oder eine digitale Signatur dieses Teilnehmers und/oder einem Zeitstempel.
Prinzipiell können alle Teilnehmer Verarbeitungseinrichtungen sein oder umfassen. Es können jedoch auch Teilnehmer ohne eigene oder fest zugeordnete Verarbeitungseinrichtung existieren. Beispielsweise kann einem Nutzer eine Identifikationsinformation zugeordnet werden, um diesen auch dann zu identifizieren und zu autorisieren, wenn mehrere Nutzer die gleiche Verarbeitungseinrichtung nutzen bzw. der gleiche Nutzer verschiedene Verarbeitungseinrichtungen nutzt.
Wird die Datenstruktur auch in der Verarbeitungseinrichtung des ersten Teilnehmers repliziert, ist mit dem erfindungsgemäßen Verfahren auch eine beidseitige Autorisierung und damit eine beidseitige Funktionsfreigabe von zwei Teilnehmern möglich. Dies kann es beispielsweise ermöglichen, dass ein Ladebetrieb eines Kraftfahrzeugs an einer Ladeeinrichtung nur dann freigegeben wird, wenn eine einerseits fahrzeugseitig ermittelt wurde, dass die Ladeeinrichtung autorisiert ist, und andererseits ladeeinrichtungsseitig ermittelt wurde, dass das Kraftfahrzeug autorisiert ist.
Es ist möglich, dass alle Teilnehmer stets an dem Kommunikationsnetz angebunden sind. Es sind jedoch auch Anwendungsfälle möglich, in denen einzelne Teilnehmer oder alle Teilnehmer vorübergehend vom Kommunikationsnetz getrennt werden und beispielsweise nach einer erneuten Verbindung mit dem Kommunikationsnetz zunächst, falls erforderlich, die interne Datenstruktur aktualisieren. Dies kann z.B. erfolgen, falls eine gültige Datenstruktur mit einer größeren Blockzahl von einem anderen Teilnehmer bereitgestellt wird. Anschließend kann die nun aktuelle Datenstruktur zur bedarfsgerechten Autorisierung anderer Teilnehmer genutzt werden.
Die Autorisierungsdaten können dadurch in der Datenstruktur angelegt und/oder verändert werden, dass durch eine Verarbeitungseinrichtung, die ein Teilnehmer oder ein Teil eines Teilnehmers ist, ein zusätzlicher Datenblock an die Datenstruktur angefügt wird, der von wenigstens einem der vorrangehenden Datenblöcke der Datenstruktur abhängt. Dieses Vorgehen ist insbesondere zweckmäßig, wenn die Autorisierungsbedingung stets nur die aktuellsten bzw. die aktuellsten gültigen Autorisierungsdaten auswertet. Bedingungen für die Gültigkeit einer in der Datenstruktur gespeicherten Transaktion bzw. der Autorisierungsdaten werden später noch erläutert.
Im einfachsten Fall kann das Hinzufügen des Blocks durch jenen Teilnehmer erfolgen, durch den das Anlegen und/oder die Änderung der Autorisierungsdaten ausgelöst wird. Es ist jedoch auch möglich und in Implementierungen von Blockchains bzw. verteilten Transaktionsdatenbanken durchaus üblich, mehrere Transaktionen, insbesondere auch Transaktionen von verschiedenen Teilnehmern, in einem Datenblock zusammenzufassen.
Dies kann beispielsweise dadurch realisiert werden, dass der die jeweilige Transaktion bzw. das Anlegen und/oder Ändern der Autorisierungsdaten auslösende Teilnehmer diese Transaktion in einen Transaktionspool schreibt, der zwischen den Teilnehmern oder zumindest zwischen jenen Teilnehmern, die Blöcke erzeugen sollen, repliziert wird. Dort kann optional eine Prüfung der Gültigkeit der Transaktion erfolgen, wobei beispielsweise geprüft werden kann, ob die Transaktion durch den Teilnehmer gültig signiert ist, ob der Teilnehmer für die Durchführung dieses Vorgangs berechtigt ist, etc. Nach erfolgreicher Prüfung bzw. falls eine solche Prüfung nicht erfolgt, können mehrere Transaktionen zu einem Datenblock zusammengefasst werden, der an die Datenstruktur angeführt wird.
Die Autorisierungsdaten können die Identifikationsinformation jenes Teilnehmers, durch den das oder ein Anlegen und/oder Verändern der Autorisierungsdaten ausgelöst wurde, und/oder eine mit der Identifikationsinformation verknüpfte Signatur umfassen, wobei die Erfüllung der Autorisierungsbedingung von der Identifikationsinformation und/oder der Signatur abhängt. Insbesondere können nur bestimmte Teilnehmer zur Anlage und/oder Veränderung von Autorisierungsdaten berechtigt sein. Die Autorisierungsbedingung kann nur dann erfüllt oder erfüllbar sein, wenn die Identifikationsinformation bzw. die Signatur einem solchen berechtigten Teilnehmern zugeordnet ist.
Die Verknüpfung der Signatur mit der Identifikationsinformation kann aus der Datenstruktur entnehmbar sein oder auf Basis der Datenstruktur und/oder der Identifikationsinformation prüfbar sein. Beispielsweise kann die Signatur durch ein kryptographisches Signaturverfahren, von denen verschiedene bekannt sind, unter Verwendung eines privaten Schlüssels erstellt sein. Entspricht die Identifikationsinformation dem öffentlichen Schlüssel dieses Schlüsselpaares, kann die Signatur unmittelbar auf Basis der Identifikationsinformation geprüft werden. Da der öffentliche Schlüssel in der Regel relativ lang ist, kann es vorteilhaft sein, stattdessen als Identifikationsinformation ein kürzeres Alias zu verwenden, wobei die Zuordnung dieses Alias zu dem privaten Schlüssel in der Datenstruktur abgelegt sein kann.
Die Autorisierungsbedingung kann nur dann erfüllt werden oder nur dann erfüllbar sein, wenn in der Datenstruktur der Identifikationsinformation und/oder der Signatur zugeordnete Berechtigungsdaten vorhanden sind, die eine Berechtigung des die Autorisierungsdaten anlegenden und/oder verändernden Teilnehmers anzeigen. Die Berechtigungsdaten können hierbei für sich genommen eine solche Berechtigung anzeigen.
Es ist jedoch auch eine indirekte Berechtigung möglich. Beispielsweise können die Berechtigungsdaten einem Teilnehmer eine übergeordnete Berechtigung geben, die ihn berechtigt, Unterberechtigungsdaten anzulegen bzw. zu ändern. In diesem Fall kann die Autorisierungsbedingung dann erfüllt werden bzw. erfüllbar sein, wenn Unterberechtigungsdaten für den die Autorisierungsdaten anlegenden und/oder veränderten Teilnehmer anzeigen, dass dieser hierzu berechtigt ist, wobei die Unterberechtigungsdaten eine Identifikationsinformation und/oder Signatur eines Teilnehmers aufweist, der durch Berechtigungsdaten zur Anlage bzw. Änderung von Unterberechtigungsdaten berechtigt ist. Auch eine mehrstufige Hierarchie der Berechtigungen ist möglich.
Die Berechtigungsdaten können dadurch in der Datenstruktur angelegt und/oder verändert werden, dass durch eine Verarbeitungseinrichtung, die ein Teilnehmer oder Teil eines Teilnehmers ist, ein zusätzlicher Datenblock an die Datenstruktur angefügt wird, der von wenigstens einem der vorangehenden Datenblöcke der Datenstruktur abhängt. Wie obig zu den Autorisierungsdaten erläutert, können jeweils nur die aktuellsten gültigen Berechtigungsdaten berücksichtigt werden. Wie ebenfalls zu den Autorisierungsdaten bereits erläutert wurde, kann ein Teilnehmer bzw. dessen Verarbeitungseinrichtung die Anlage bzw. Veränderung durch eine Transaktion auslösen, die für sich genommen oder gemeinsam mit anderen Transaktionen als Datenblock an die Datenstruktur angehängt wird.
Das oder ein Anlegen und/oder Verändern der Berechtigungsdaten kann automatisiert durch ein durch eine Verarbeitungseinrichtung wenigstens eines Teilnehmers ausgeführtes Programm, das insbesondere in der Datenstruktur gespeichert ist, erfolgen. Ein Speichern von Programmen in Datenstrukturen aus verketteten Datenblöcken, beispielsweise in Blockchains, ist an sich bekannt, wobei solche Programme auch als „Smart Contract“ bezeichnet werden. Der Programmcode ist typischerweise in einer maschinenunabhängigen Skriptsprache abgelegt und kann in einem relativ frühen Datenblock gespeichert sein, um hierdurch eine hohe Manipulationssicherheit zu erreichen. Optional kann der Programmcode des Programms für jeden mit der Datenstruktur bzw. Blockchain interagierenden Teilnehmer einheitlich sein. Dies ermöglicht ein festgelegtes Regelwerk und schafft Vertrauen bei den Teilnehmern.
Das Anliegen und/oder Verändern der Berechtigungsdaten kann von Abstimmungsdaten abhängen, die von mehreren Teilnehmern an die das Programm ausführende Verarbeitungseinrichtung, insbesondere als Teil der Datenstruktur, bereitgestellt werden. Anders ausgedrückt wird das Programm bzw. der Smart Contract durch bestimmte, zum Wählen autorisierter Teilnehmer gesteuert, wodurch auf eine zentrale Autorität vollständig verzichtet werden kann. Das Programm, das die Berechtigungsdaten automatisiert anlegt und/oder verändert, stellt quasi die zentrale Autorität dar und kann daher auch als „Root Contract“ bezeichnet werden.
Das Sammeln von Abstimmungsdaten kann gezielt ausgelöst werden, beispielsweise durch Aufruf dieses Programms durch einen Teilnehmer, wonach beispielsweise entsprechende Anfragen an die abstimmungsberechtigten Teilnehmer gesendet werden können, wonach diese ihre Stimme abgeben und diese beispielsweise durch eine Signatur authentifizieren.
Ergänzend und alternativ kann es jedoch auch vorteilhaft sein, das Programm automatisch zu bestimmten Zeitpunkten, beispielsweise jedes Mal, wenn ein neuer Datenblock an die Datenstruktur angehängt wird oder nach einer bestimmten Zahl von angehängten Datenblöcken, auszuführen. Die Abstimmungsdaten können durch die stimmberechtigten Teilnehmer vor diesem Zeitpunkt an die Datenstruktur angefügt werden oder in einem Transaktionspuffer abgelegt werden, sodass das Programm die Stimmen automatisiert auswerten kann.
Beispielsweise können Berechtigungsdaten nur dann angelegt und/oder verändert werden, wenn eine Mindestzahl von Ja-Stimmen und weniger Nein-Stimmen als Ja-Stimmen vorliegen. Es kann hierbei auch möglich sein, verschiedenen Teilnehmern ein unterschiedliches Stimmengewicht zuzuordnen, beispielsweise auf Basis ihres wirtschaftlichen Interesses an der Robustheit der Datenstruktur. Das Stimmrecht der Teilnehmer kann ebenfalls über die Datenstruktur verwaltet werden. Beispielsweise können dort für die einzelnen Teilnehmer Stimmrechtsdaten gespeichert sein, die angeben, ob diese stimmberechtigt sind oder nicht bzw. über wie viele Stimmen sie verfügen.
Die Berechtigungsdaten, die Autorisierungsdaten, das Stimmrecht usw. können unabhängig voneinander in der Datenstruktur gespeichert werden. Es ist jedoch auch möglich, mehrere dieser Daten in einem gemeinsamen Datensatz zusammenzufassen, der beispielsweise die Identifikationsinformation des jeweiligen Teilnehmers und dessen Rechte beschreibt. Statt die einzelnen Rechte explizit zu speichern, kann dem einzelnen Teilnehmer auch eine bestimmte Rolle zugeordnet werden, der wiederum, beispielsweise über einen Datensatz in der Datenstruktur, bestimmte Rechte zugeordnet sind.
Die Berechtigung, Autorisierungsdatensätze anzulegen und/oder zu verändern, kann allgemein gelten oder kann sich auf bestimmte Gruppen von Teilnehmern beziehen. Nehmen an dem Verfahren als Teilnehmer beispielsweise Ladestation, Kraftfahrzeuge und Fahrzeugnutzer teil, kann ein Fahrzeughersteller als Teilnehmer beispielsweise nur berechtigt sein, Autorisierungsdaten, die sich auf Kraftfahrzeuge und/oder deren Nutzer beziehen, anzulegen und/oder zu verändern. Ein Betreiber von Ladeeinrichtungen kann hingegen nur dazu berechtigten sein, Autorisierungsdaten bezüglich dieser Ladestationen anzulegen bzw. zu verändern.
Es kann beispielsweise auch möglich sein, dass nur jener Teilnehmer, der die Autorisierungsdaten eines bestimmten weiteren Teilnehmers angelegt hat, oder optional ein von diesem berechtigter Teilnehmern, diese Autorisierungsdaten ändern kann. Beispielsweise kann hierdurch ausgeschlossen werden, dass ein Fahrzeughersteller die Autorisierungsdaten eines Fahrzeugs eines anderen Herstellers modifiziert.
Zumindest ein Teil der in der Datenstruktur gespeicherten Daten kann für einen Teil der Teilnehmer nicht oder nicht im Klartext lesbar sein, insbesondere durch Verschlüsselung dieser Daten. Hierdurch können insbesondere unterschiedliche Leserechte für unterschiedliche Teilnehmer implementiert werden.
Beispielsweise können Daten durch die öffentlichen Schlüssel alle Teilnehmer verschlüsselt werden, die Zugriff auf diese Daten haben sollen, und die Daten können nicht im Klartext gespeichert werden. Somit haben nur jener Teilnehmer Zugriff auf die gespeicherten Daten, die einen jeweiligen zugeordneten privaten Schlüssel kennen.
Ist in der Anwendung sichergestellt, dass bestimmte Programme oder Programmteile, beispielsweise Smart Contracts, in einer manipulationssicheren Umgebung ausgeführt werden, kann die Kontrolle von Schreib- bzw. Leserecht auch über das Programm bzw. den Programmteil erfolgen.
Es ist zweckmäßig, Schreibrechte auf die Datenstruktur ebenfalls durch ein Programm, insbesondere einen Smart Contract, zu prüfen, der beispielsweise Signaturen von Transaktion, die bestimmte Aktionen durchführen sollen, prüfen kann. Dies kann beispielsweise erfolgen, wenn verschiedene Transaktionen zu einem Datenblock zusammengefasst werden, wobei nicht oder nicht gültig signierte Transaktionen verworfen werden können.
Unabhängig von einer solchen Prüfung vor dem Ändern der Datenstruktur kann es zweckmäßig sein, die Berechtigung des die Transaktion veranlassenden Teilnehmers bzw. dessen Signatur auch bei der Auswertung, beispielsweise im Rahmen der Autorisierungsbedingung, zu prüfen, um eine Manipulationssicherheit weiter zu erhöhen.
Es kann zweckmäßig sein, zu der jeweiligen Identifikationsinformation Metadaten vorzuhalten, die beispielsweise persönliche Daten eines Nutzers, der ein Teilnehmer ist, bzw. eines Fahrzeughalters eines teilnehmenden Fahrzeugs betreffen können. Hierbei ist es aus Gründen des Datenschutzes und der Datensparsamkeit wesentlich, dass kein unberechtigter Zugriff auf diese Daten erfolgen kann und das diese, beispielsweise auf Anfrage der Person, die diese Daten betreffen, gelöscht oder zumindest nicht lesbar gemacht werden können.
Falls solche Metadaten In der Datenstruktur gespeichert werden, können sich beispielsweise durch den öffentlichen Schlüssel des Teilnehmers verschlüsselt werden, sodass sie nur bei Kenntnis dieses privaten Schlüssels dieses Teilnehmers auslesbar sind. Ein Löschen des privaten Schlüssels führt in diesem Fall zu einer Unlesbarkeit der Daten.
Ist eine tatsächliche Löschung der Daten gewünscht oder z.B. aus Datenschutzgründen erforderlich, können entsprechende Metadaten separat von der Datenstruktur gespeichert werden, wobei beispielsweise unmittelbar über die Identifikationsinformation oder über einen in der Datenstruktur gespeicherten Verweis ein Zugriff auf die Metadaten in dieser Datenbank möglich ist, wobei diese vorzugsweise, wie obig erläutert, verschlüsselt sind, um ein unberechtigtes Auslesen auch dann zu verhindern, wenn ein Angreifer Zugriff auf die Datenbank selbst erhält. Ein Löschen des der Identifikationsinformation zugeordneten Datensatzes in dieser Datenbank führt somit zu einer vollständigen Löschung der Metadaten.
Teilnehmer können Leserechte für die eigenen öffentlichen Schlüssel und Metadaten haben. Teilnehmer, die, insbesondere wie obig erläutert durch in der Datenstruktur gespeicherte Berechtigungsdaten, berechtigt sind, Autorisierungsdaten anzulegen und/oder zu verändern, können auch als Administratoren bezeichnet werden. Administratoren können ein Leserecht auf die öffentlichen Schlüssel und Metadaten von Teilnehmern haben, deren Autorisierungsdaten durch sie angelegt wurden. Sie können zusätzlich ein Leserecht auf die Identifikationsinformation und/oder den öffentlichen Schlüssel von Teilnehmern haben, mit denen von ihnen autorisierte Teilnehmer interagieren, also beispielsweise von Teilnehmern, zu oder von denen eine Transaktion erfolgt. Optional kann auch ein Zugriff auf Metadaten dieser Teilnehmer oder zumindest auf Teile der Metadaten dieser Teilnehmer möglich sein.
Beispielsweise können Kraftfahrzeughersteller und Betreibe von Ladeeinrichtungen Leserechte für die jeweiligen miteinander interagierenden Objekten und Nutzer, die Teilnehmer bilden, haben. Kraftfahrzeughersteller können jedoch vorzugsweise keine Informationen zu Teilnehmern, also insbesondere zu Kraftfahrzeugen bzw. Nutzern, von anderen Kraftfahrzeugherstellen lesen bzw. Ladeeinrichtungsbetreiber können keine Information zu Teilnehmern, insbesondere Ladeeinrichtungen bzw. Nutzen, von anderer Ladeeinrichtungsbetreiber lesen.
Administratoren können eine Identifikationsinformation für einen Teilnehmer erstellen, insbesondere indem ein Schlüsselpaar für diesen Teilnehmer erzeugt wird. Sie können Teilnehmer bzw. diesen zugeordneten Identifikationsinformationen aktivieren, indem sie entsprechende Autorisierungsdaten anlegen bzw. derart verändern, dass die Funktion freigegeben wird. Als Funktion können hierbei auch verschiedene Funktionen, Dienste, Services, etc. separat oder gemeinsam freigegeben werden. Eine Statusänderung des jeweiligen Teilnehmers kann der jeweilige Administrator dadurch auslösen, dass er die Autorisierungsdaten ändert, beispielsweise einen Flag bzw. eine Variable auf True oder False setzt.
Administratoren können Metadaten der von ihnen autorisierten bzw. angelegten Teilnehmer löschen. Mit der Löschung der Metadaten und der Verknüpfung zwischen Metadaten und Identifikationsinformation bzw. öffentlichem Schlüssel wird ein hohes Datenschutzniveau erreicht, da danach keine unmittelbar personenbezogene Informationen mehr vorhanden sind und in der Datenstruktur gespeicherte Transaktionen nicht mehr einer bestimmten Person zugeordnet werden können.
Als erster Teilnehmer kann ein Kraftfahrzeug und als zweiter Teilnehmer eine Infrastruktureinrichtung verwendet werden oder umgekehrt. Beispielsweise kann eine Einfahrt in einen bestimmten Bereich durch einen Schranke oder Ähnliches versperrt sein und erst nach einer Autorisierung des Kraftfahrzeugs freigegeben werden. Umgekehrt kann beispielsweise eine Zahlungsanforderung einer Infrastruktureinrichtung, beispielsweise für ein Befahren eines bestimmten Gebiets oder ein Parken, erst erfüllt werden, nachdem die Infrastruktureinrichtung autorisiert wurde. Eine Autorisierung von Infrastruktureinrichtungen kann beispielsweise auch relevant sein, wenn die Kontrolle des Kraftfahrzeugs für einen automatisierten Parkvorgang oder Ähnliches an die Infrastruktureinrichtung übergeben werden soll, um sicherzustellen, dass die Infrastruktureinrichtung vorgegebene Anforderungen erfüllt. Die Infrastruktureinrichtung kann insbesondere eine Ladeeinrichtung zum Laden eines Energiespeichers des Kraftfahrzeugs sein.
Besonders vorteilhaft kann als erster Teilnehmer ein Kraftfahrzeug und als zweiter Teilnehmer eine Ladeeinrichtung zum Laden eines Energiespeichers des Kraftfahrzeugs verwendet werden oder umgekehrt, wobei die Funktion des zweiten Teilnehmers notwendig für das Laden des Energiespeichers durch die Ladeeinrichtung ist. Wie obig erläutert, kann insbesondere eine beidseitige Autorisierung erfolgen, sodass ein Laden erst dann erfolgt, wenn sowohl die Ladeeinrichtung gegenüber dem Kraftfahrzeug als auch das Kraftfahrzeug gegenüber der Ladeeinrichtung autorisiert ist. Als Funktion der Ladeeinrichtung kann somit eine Stromabgabe bzw. kraftfahrzeugseitig eine Ladesteuerung und/oder eine Bezahlfunktion freigegeben werden.
Die Datenstruktur kann zusätzlich Transaktionen zwischen Teilnehmern, insbesondere bezüglich freigegebener Funktionen, speichern. Eine Transaktion bezüglich eines Ladevorgangs kann beispielsweise eine Kennzeichnung der Transaktion als einen Ladevorgang betreffend, die Identifikationsinformation des Kraftfahrzeugs und der Ladeeinrichtung und eine Menge an übertragener Energie umfassen. Zusätzlich kann eine solche Transaktion optional einen aktuellen Ladezustand des Energiespeichers des Kraftfahrzeugs, ein Guthaben des Kraftfahrzeugs bzw. eines Nutzers des Kraftfahrzeugs in einer digitalen Währung, Qualitätskriterien der Ladestation, beispielsweise eine Genauigkeit einer Leistungsmessung, die maximal bereitstellbare Leistung oder Ähnliches, etc. umfassen.
Die Transaktion kann auch eine Bewertung des ersten Teilnehmers durch den zweiten Teilnehmer oder umgekehrt umfassen, also beispielsweise eine Bewertung des Ladevorgangs durch das Kraftfahrzeug bzw. die Ladesäule. Diese Informationen können zweckmäßig sein, um beispielsweise Fahrzeugherstellern bzw. Ladeeinrichtungsbetreibern Informationen bezüglich möglicher Verbesserungen bereitzustellen. Beispielsweise können entsprechende Daten fahrzeugherstellerseitig ausgewertet werden, um hierdurch fahrzeugseitig angebotene Informationen zur Ladeeinrichtungen zu ergänzen bzw. entsprechende Informationen bei der Routenplanung zu berücksichtigen.
Neben dem erfindungsgemäßen Verfahren betrifft die Erfindung eine Verarbeitungseinrichtung, die zur Teilnahme an dem erfindungsgemäßen Verfahren als Teilnehmer oder als Teil eines Teilnehmers ausgebildet ist. Die Verarbeitungseinrichtung kann insbesondere eine Kommunikationseinrichtung zur Kommunikation mit den weiteren Teilnehmern, insbesondere zum Replizieren der Datenstruktur, eine Speichereinrichtung zur Speicherung der Datenstruktur und ein Rechenwerk zur Durchführung der Verfahrensschritte umfassen. Die Funktion, die bei Erfüllung der Autorisierungsbedingung freigegeben wird, kann eine Funktion der Verarbeitungseinrichtung selbst sein, beispielsweise das Durchführen einer Transaktion auf der Datenstruktur. Die Funktion kann jedoch auch das Steuern einer verarbeitungseinrichtungsexternen Komponente sein oder umfassen, beispielsweise einer Ladesteuerung eines Kraftfahrzeugs bzw. einer Komponente einer Ladeeinrichtung, eines Aktors einer Schranke oder einer anderen Sperre, einer Ampelsteuerung oder von ähnlichen Einrichtungen.
Die Erfindung betrifft zudem ein Kraftfahrzeug, das eine erfindungsgemäße Verarbeitungseinrichtung umfasst, und eine Infrastruktureinrichtung, insbesondere eine Ladeeinrichtung, die eine erfindungsgemäße Verarbeitungseinrichtung umfasst.
Weitere Vorteile und Einzelheiten der Erfindung ergeben sich aus den folgenden Ausführungsbeispielen sowie den zugehörigen Zeichnungen. Hierbei zeigen schematisch:

1 Ausführungsbeispiele eines erfindungsgemäßen Kraftfahrzeugs und einer erfindungsgemäßen Infrastruktureinrichtung, nämlich eine Ladeeinrichtung, die jeweils ein Ausführungsbeispiel einer erfindungsgemäßen Verarbeitungseinrichtung umfassen und im Rahmen eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens genutzt werden,
2 ein Beispiel für eine im erfindungsgemäßen Verfahren genutzte Datenstruktur, und
3 eine durch das erfindungsgemäße Verfahren realisierbare Berechtigungshierarchie.

1 zeigt eine Betriebssituation, in der zwei Teilnehmer 1, 2 in einem Kommunikationsnetz 11 gegenüber dem jeweils anderen Teilnehmers 1, 2 autorisiert werden sollen, eine bestimmte Funktion durchzuführen. Im gezeigten Beispiel ist der Teilnehmer 1 ein Kraftfahrzeug und der Teilnehmer 2 ist eine Ladestation. Hierbei sollen jeweils Funktionen 26, 27 einer jeweiligen Ladesteuerung 24, 25 freigegeben werden, um ein Laden eines Energiespeichers 59 des Teilnehmers 1, also des Kraftfahrzeugs, zu ermöglichen.
Hierbei ist den Teilnehmern 1, 2 jeweils eine Identifikationsinformation 7, 8, beispielsweise ein öffentlicher Schlüssel eines Schlüsselpaars eines asymmetrischen Verschlüsselungsverfahrens, zugeordnet, über die der jeweilige Teilnehmer 1, 2 identifizierbar ist. Vor der Freigabe der Funktionen 26, 27 und somit dem Beginn des Ladevorgangs soll geprüft werden, ob die Teilnehmer 1, 2 auch zur Durchführung des Ladevorgangs autorisiert sind.
Eine entsprechende Autorisierung kann prinzipiell durch weitere Teilnehmer 3, 4, 5 im Kommunikationsnetz erfolgen, insbesondere durch Teilnehmer 4, 5, die als Administratoren 28, 29 berechtigt sind, eine solche Autorisierung zu erteilen und zu widerrufen. Hierbei kann beispielsweise der Teilnehmer 4 ein Backend-System eines Kraftfahrzeugherstellers sein und Autorisierungen für durch diesen hergestellte Kraftfahrzeuge 1 beziehungsweise deren Nutzer 6 erteilen und widerrufen. Der Teilnehmer 5 kann hingegen ein Betreiber von Ladeeinrichtungen sein, der Autorisierungen für von ihm betriebene Ladeeinrichtungen erteilen und widerrufen kann.
Um eine solche Autorisierung zur Freigabe einer jeweiligen Funktion 26, 27 zu ermöglichen, wird zunächst durch den anderen der Teilnehmer 1, 2 die jeweilige Identifikationsinformation 7, 8 an jenen Teilnehmer 1, 2 übertragen, der die entsprechende Funktion 26, 27 bereitstellen soll. Dies ist in 1 schematisch durch die Pfeile 9, 10 dargestellt, wobei dieser Datenaustausch über jeweilige Kommunikationseinrichtungen 20, 21 von Verarbeitungseinrichtungen 12, 13 der Teilnehmer 1, 2 erfolgt. Der Informationsaustausch kann über das Kommunikationsnetz 11 erfolgen oder auch über einen separaten Kommunikationspfad, beispielsweise über einen kurzreichweitigen drahtlosen Kommunikationspfad oder im Falle eines gewünschten Ladebetriebs auch über das Ladekabel.
Der Vollständigkeit halber sei angemerkt, dass es für das im Folgenden beschriebene Vorgehen nicht erforderlich ist, dass die einzelnen Teilnehmer 1 bis 6 zu jedem beliebigen Zeitpunkt über das Kommunikationsnetz 11 kommunizieren können, sondern es ist ausreichend, wenn in nicht allzu langen Zeitabständen ein Datenaustausch mit zumindest Teilen der weiteren Teilnehmer 1 bis 6 möglich ist. Für Teilnehmer 6, beispielsweise Nutzer von Kraftfahrzeugen, die keine eigenen Verarbeitungseinrichtungen aufweisen, erfolgt die Kommunikation insbesondere über Datenverarbeitungseinrichtungen, die auch selbst Teilnehmer mit eigener zugeordneter Identifikationsinformation sein können oder auch nicht.
Ein bekannter Ansatz, eine Autorisierung bei bekannter Identifikationsinformation 7, 8 zu prüfen, ist es, bei einer Zentraleinrichtung abzufragen, ob eine Autorisierung für diese Identifikationsinformation 7, 8 vorliegt. Dies erfordert jedoch den Betrieb einer relativ aufwendigen Zentraleinrichtung und zudem ist für eine Autorisierung eine robuste Kommunikationsverbindung zu dieser Zentraleinrichtung erforderlich.
Daher wird in dem erläuterten Verfahren ein anderer Ansatz zur Autorisierung der Teilnehmer 1, 2 gegenüber des jeweils anderen Teilnehmers 1, 2 genutzt. Die Autorisierung erfolgt nämlich jeweils lokal durch die Verarbeitungseinrichtung 12, 13 des jeweiligen Teilnehmers. Diese weist neben der bereits erwähnten jeweiligen Kommunikationseinrichtung 20, 21 eine Speichereinrichtung 18, 19 auf, in der neben der jeweiligen eigenen Identifikationsinformation 7, 8, die im Beispiel ein öffentlicher Schlüssel ist, eine geheime Information, im Beispiel einen privaten Schlüssel 14, 15, und eine Datenstruktur 16, 17 gespeichert ist. Die Datenstruktur 16, 17 kann eine dezentrale Transaktionsdatenbank implementieren. Die Verarbeitungsschritte werden durch ein jeweiliges Rechenwerk 22, 23 durchgeführt.
Wie in 2 schematisch dargestellt ist, umfasst die jeweilige Datenstruktur 16, 17 mehrere Datenblöcke 34, die derart miteinander verknüpft sind, dass der Inhalt des jeweiligen nachfolgenden Datenblocks 34 vom Inhalt des vorangehenden Datenblocks 34 abhängt. Dies wird im Beispiels dadurch implementiert, dass alle Datenblöcke 34 außer des ersten Datenblocks einen kryptographischen Hashwert 35 des vorangehenden Datenblocks speichern. Dies führt dazu, dass zur Veränderung eines der Datenblöcke 34 auch eine Veränderung aller nachfolgenden Datenblöcke erforderlich wäre, um eine Konsistenz der jeweiligen Datenstruktur 16, 17 zu erreichen.
Ist das Erstellen neuer Datenblöcke 34 hinreichend rechenaufwendig und/oder liegen hierbei andere Anforderungen vor, beispielsweise eine Begrenzung der Anzahl von Blöcken die durch einen bestimmten Teilnehmer in einem bestimmten Zeitintervall erstellt werden können, wird hierdurch eine hohe Manipulationssicherheit der Datenstruktur erreicht. Mögliche Ansätze hierfür wurden bereits im allgemeinen Teil diskutiert und sind insbesondere aus dem Bereich der Blockchains beziehungsweise Kryptowährungen wohl bekannt.
Zumindest Teile der Datenblöcke 34 speichern jeweils wenigstens eine Transaktion 36, also einen Vorgang, der durch einen der Teilnehmer 1 bis 6 oder automatisiert durch die Steuerung der Datenstruktur steuernden Programme 48, 54, 56 ausgelöst wurde. Beispielsweise kann als Transaktion 36 ein Ladedatensatz 37 gespeichert sein, der einen vorangehenden Ladevorgang des Kraftfahrzeugs 1 an der Ladeeinrichtung 2 beschreibt.
Der Ladedatensatz 37 kann beispielsweise die Identifikationsinformation 7 des Kraftfahrzeugs, eine Signatur 38, die mithilfe des privaten Schlüssels 14 des Kraftfahrzeugs erstellt wurde, die Identifikationsinformation 8 der Ladestation, eine bei diesem Ladevorgang übertragene Strommenge 39, Zusatzinformationen 40, beispielsweise eine Bewertung des Ladevorgangs, und einen Zeitstempel 41 umfassen. Werden beispielsweise sowohl durch das Kraftfahrzeug als auch durch die Ladeeinrichtung entsprechende Ladedatensätze 37 bereitgestellt, die dann in einem der Blöcke 34 der Datenstrukturen 16, 17 gespeichert werden, wird hierdurch eine manipulationssichere Dokumentation des Ladevorgangs erreicht.
Durch Ansätze, die aus dem Bereich der Blockchains beziehungsweise Kryptowährungen bekannt sind, kann zudem erreicht werden, dass die durch die einzelnen Teilnehmer beziehungsweise Verarbeitungseinrichtungen 12, 13 gespeicherten Datenstrukturen 16, 17 in der Regel identisch sind, zumindest was ältere Datenblöcke 34 betrifft. Insbesondere kann bei einer Verbindung zum Kommunikationsnetz 11 beziehungsweise in regelmäßigen Abständen durch den jeweiligen Teilnehmer 1 bis 6 beziehungsweise eine durch diesen genutzte Verarbeitungseinrichtung 12, 13 jeweils abgefragt werden, ob im Kommunikationsnetz 11 eine Datenstruktur mit höherer Blockzahl als die lokal gespeicherte Datenstruktur 16, 17 noch vorhanden ist. Ist dies der Fall, so kann die Gültigkeit dieser Datenstruktur geprüft werden und, falls die Datenstruktur mit größerer Blockzahl gültig ist, diese gespeichert werden, um die bisher genutzte Datenstruktur 16, 17 zu ersetzen.
In dem erfindungsgemäßen Verfahren wird eine solche Datenstruktur 16, 17 genutzt, um Autorisierungsdaten 42, 49 für die jeweiligen Teilnehmer 1 bis 6 zu speichern. Dies wird im folgenden Beispiel bezüglich der Autorisierung des Teilnehmers 2 erläutert, ist entsprechend jedoch auch auf die Autorisierung anderer Teilnehmer übertragbar.
Nach der Übertragung der Identifikationsinformation 8 des Teilnehmers 2 an die Verarbeitungseinrichtung 12 des Teilnehmers 1, prüft diese, ob in der lokal gespeicherten Datenstruktur 16 Autorisierungsdaten 42, 49 vorhanden sind, die dieser Identifikationsinformation 8 zugeordnet sind, ob diese gültig sind und ob sie eine Autorisierung des Teilnehmers 2 anzeigen. Die Prüfung der Autorisierungsbedingung 47 kann insbesondere durch ein Programm 48 erfolgen, das als Teil der Datenstruktur 16, 17 gespeichert ist. Hierdurch kann eine hohe Manipulationssicherheit für das Programm 48 erreicht werden.
Die Autorisierungsbedingung 47 kann zunächst nur die aktuellsten Autorisierungsdaten 42 berücksichtigen, die den Teilnehmer 2 bzw. dessen Identifikationsinformation 8 betreffen. Die jeweiligen Autorisierungsdaten 42, 49 umfassen jeweils die Identifikationsinformation 8, der sie zugeordnet sind, eine Identifikationsinformation 43 jenes Teilnehmers 1 bis 6, der das Anlegen beziehungsweise die Veränderung der Autorisierungsdaten 42, 49 ausgelöst hat, eine Signatur 44 dieses Teilnehmers, ein Status 45 der Autorisierung und ein Zeitstempel 46. Der Status 45 kann beispielsweise ein Flag sein, das anzeigt, ob eine Autorisierung vorliegt oder nicht, und kann beispielsweise den Wert 1 oder 0 oder „True“ oder „False“ aufweisen.
In einem ersten Schritt wird geprüft, ob die jeweiligen Autorisierungsdaten 42, 49 gültig sind. Hierbei kann insbesondere geprüft werden, ob die Signatur 44 gültig ist, was durch übliche kryptographische Signaturverfahren möglich ist. Zudem wird, wie später noch genauer erläutert werden wird, geprüft, ob der durch die Identifikationsinformation 43 identifizierte Teilnehmer 1 bis 6 berechtigt war, die der Identifikationsinformation 8 zugeordneten Autorisierungsdaten 42, 49 anzulegen beziehungsweise zu verändern.
Sind die aktuellsten Autorisierungsdaten 42 gültig, so wird die Statusinformation 45 ausgelesen, die angibt, ob der Teilnehmer 2 autorisiert ist oder nicht.
Zeigt die Statusinformation 45 eine Autorisierung an, so wird die Funktion 27 im Kraftfahrzeug freigeschaltet.
Sind die aktuellsten Autorisierungsdaten 42 hingegen ungültig, wir die Prüfung für die früheren Autorisierungsdaten 49 wiederholt und entsprechend vorgegangen. Sind auch die früheren Autorisierungsdaten 49 ungültig und liegen auch keine weiteren Autorisierungsdaten zur Identifikationsinformation 8 in der Datenstruktur 16 vor, so ist die Autorisierungsbedingung 47 nicht erfüllt und die Funktion 27 bleibt gesperrt, da der Teilnehmer 2 nicht für einen Ladevorgang autorisiert ist.
Die Prüfung, ob der durch die Identifikationsinformation 43 identifizierte Nutzer berechtigt war, die Autorisierungsdaten 42, 49 anzulegen beziehungsweise zu verändern, kann beispielsweise durch das Programm 54 geprüft werden, das ebenfalls durch die jeweilige Datenstruktur 16, 17 bereitgestellt wird.
Hierbei wäre es prinzipiell möglich, dass fest vorgegeben ist, welche Teilnehmer 1 bis 6 berechtigt sind, Autorisierungsdaten anzulegen beziehungsweise zu verändern. Es ist jedoch bevorzugt, wenn die Berechtigung, Autorisierungsdaten 42, 49 anzulegen und zu verändern, bedarfsgerecht bestimmten Teilnehmern erteilt beziehungsweise entzogen werden kann, um diese zu Administratoren 28, 29 zu bestimmen beziehungsweise sie aus dem Pool der Administratoren 28, 29 zu entfernen.
Ein Ansatz hierzu wird im Folgenden mit zusätzlichem Bezug auf 3 näher erläutert, wobei 3 die genutzte Autorisierungspyramide schematisch darstellt. In dem gezeigten relativ einfachen Beispiel sollen letztlich einerseits Kraftfahrzeug beziehungsweise deren Nutzer, im Beispiel also die Teilnehmer 1 und 6, und andererseits Ladeeinrichtungen, im Beispiel also der Teilnehmer 2, zur Durchführung von Ladevorgängen autorisiert werden. Wie durch die gestrichelte Linie 58 angedeutet ist, kann hierbei eine klare Trennung erfolgen, so dass einerseits als Administratoren 28 beispielsweise Backend-Systeme von Kraftfahrzeugherstellern dienen können, über die Kraftfahrzeuge und Nutzer von Kraftfahrzeugen autorisiert werden können, und andererseits als Administratoren 29 Backend-Systeme von Ladeeinrichtungsbetreibern dienen, die die durch sie betriebenen Ladeeinrichtungen autorisieren.
Hierbei können jeweils beispielsweise verschiedene Ladeeinrichtungsbetreiber nur ihre eigenen Ladeeinrichtungen autorisieren beziehungsweise deren Autorisierungen entziehen und Zusatzinformationen verwalten. Entsprechend können Fahrzeughersteller nur ihre eigenen Kraftfahrzeuge und Nutzer autorisieren, ihre Autorisierungen entziehen beziehungsweise ihre Daten verwalten.
Eine Veränderung der Berechtigung der Teilnehmer 4, 5 als Administrator 28, 29 erfolgt vorzugsweise nicht unmittelbar durch einen einzelnen Teilnehmer 1 - 6, sondern durch ein Programm 56, das insbesondere ebenfalls über die Datenstruktur 16, 17 bereitgestellt werden kann, und das ein Speichern von Berechtigungsdaten 50, 55 in der Datenstruktur 16, 17 auslöst, wenn entsprechende Abstimmungsdaten 57 von stimmberechtigten Teilnehmern 1 bis 6 vorliegen.
In dem in 3 gezeigtem Beispiel wird davon ausgegangen, dass alle Teilnehmer 4, 5, die Administratoren 28, 29 sind, stimmberechtigt sind, wobei Stimmgewichte insbesondere vom wirtschaftlichen Interesse an der Robustheit der Datenstruktur 16, 17 abhängen können, also beispielsweise von der Anzahl der durch sie autorisierten Teilnehmer 1 bis 6, von durch Ladevorgänge erzielten Umsätzen oder Ähnlichem. Insbesondere können die Stimmgewichte somit unmittelbar aus der Datenstruktur selbst abgeleitet werden. In anderen Ausgestaltungen wäre es jedoch auch möglich, dass ein Stimmrecht unabhängig von dem Administratorstatus ist.
Die Abfrage der Abstimmungsdaten 57 durch das Programm 56 kann beispielsweise dadurch erfolgen, dass das Programm 56 lokal durch einen Teilnehmer aufgerufen wird, der anschließend entsprechende Anfragen an weitere stimmberechtigte Teilnehmer sendet, die beispielsweise durch signierte Rückantworten ihre Zustimmung ausdrücken können. Wird durch das Programm 56 beispielsweise eine ausreichende Anzahl von Ja-Stimmen und insbesondere eine demgegenüber kleinere Anzahl von Nein-Stimmen erfasst, können durch dieses neue Berechtigungsdaten 50, 55 als Transaktion angelegt werden, die unmittelbar oder zu einem späteren Zeitpunkt als Teil eines zusätzlichen Datenblocks 34 an die Datenstruktur 16, 17 angefügt werden. Da dies zu einer größeren Blockzahl der Datenstruktur 16, 17 führt, wird die entsprechend verlängerte Datenstruktur 16, 17 durch die weiteren Teilnehmer übernommen und somit die Änderungen der Berechtigung an diese kommuniziert.
Wie obig erwähnt, kann im Rahmen der Autorisierungsbedingung 47, z.B. durch das Programms 54, auch geprüft werden, ob der durch die Identifikationsinformation 43 identifizierte Teilnehmer 1 bis 6 berechtigt war, die jeweils ausgewerteten Autorisierungsdaten 42, 49 anzulegen. Hierzu kann das Programm 54 prüfen, ob in der Datenstruktur 16, 17 dieser Identifikationsinformation 43 zugeordnete Berechtigungsdaten 50, 55 vorliegen.
Im in 2 gezeigten Beispiel umfassen die Berechtigungsdaten 50, 55 jeweils die Identifikationsinformation 43, der sie zugeordnet sind, und eine Statusinformation 51, die beispielsweise durch einen 0- oder 1-Wert beziehungsweise einen „True“- oder False"-Wert angibt, ob eine solche Berechtigung vorliegt. Zusätzliche können Informationen gespeichert sein, für welche der Teilnehmer 1 bis 6 beziehungsweise für welchen Typ von Teilnehmern 1 - 6 diese Berechtigung gilt.
Um eine Gültigkeit der Berechtigungsdaten 50, 55 prüfen zu können, umfassen diese zusätzlich ein Autorisierungsfeld 52, das beispielsweise Signaturen jener Teilnehmer 1 bis 6 umfasst, die für den aktuellen Berechtigungszustand gestimmt haben. Zudem wird ein Zeitstempel 53 gespeichert.
Ähnlich wie obig zu den Autorisierungsdaten 42, 49 erläutert, werden zunächst nur die aktuellsten Berechtigungsdaten 50 berücksichtigt, die der Identifikationsinformation 43 zugeordnet sind. Sind diese gültig, so gibt der Status 51 vor, ob der durch die Identifikationsinformation 43 identifizierte Teilnehmer 1 bis 6 berechtigt war, die jeweiligen Autorisierungsdaten 45, 49 anzulegen beziehungsweise zu verändern.
Sind die Berechtigungsdaten 50 hingegen ungültig, beispielsweise aufgrund fehlerhafter Signaturen, wird auf frühere Berechtigungsdaten 55 zurückgegriffen und das entsprechende Vorgehen wird wiederholt. Werden keine gültigen Berechtigungsdaten in der Datenstruktur 16, 17 aufgefunden, wird davon ausgegangen, dass der durch die Identifikationsinformation 43 bezeichnete Teilnehmer 1 bis 6 nicht berechtigt war, die Autorisierungsdaten 42, 49 anzulegen, womit diese als ungültig betrachtet werden.
Um hohe Datenschutzstandards zu erreichen, können einerseits zumindest Teile der in der Datenstruktur 16, 17 gespeicherten Daten nicht für alle Teilnehmer 1 bis 6 lesbar sein. Insbesondere können entsprechende Daten jeweils mit den öffentlichen Schlüsseln jener Teilnehmer 1 bis 6 verschlüsselt werden, die einen Lesezugriff auf die entsprechenden Daten haben sollen, womit nur diese Teilnehmer 1 bis 6 die Daten lesen können, da ihnen der zugeordnete private Schlüssel 14, 15 bekannt ist.
Andererseits werden die einzelnen Teilnehmer 1 bis 6 vorzugsweise nur durch ihre Identifikationsinformation 7, 8 identifiziert und weiterer Metadaten, beispielsweise Anschriften, Kontoverbindungen oder Ähnliches, werden durch jeweilige Administratoren 28, 29, beispielsweise Backend-Server von Fahrzeugherstellern oder Ladeeinrichtungsbetreibern, verwaltet.
Diese können als Teilnehmer 4, 5 mit dem Kommunikationsnetz 11 verbunden sein und neben einer jeweiligen Verarbeitungseinrichtung 30, 31 zusätzlich eine Datenbank 32, 33 für entsprechende Metadaten implementieren. Dies ermöglicht es beispielsweise, entsprechende Metadaten zu löschen, wenn dies durch einen Teilnehmer 1 bis 6 angefordert wird oder wenn Aufbewahrungsfristen abgelaufen sind. Entsprechende Löschungen innerhalb der Datenstruktur 16, 17 wären nicht ohne weiteres möglich, da deren Ausgestaltung wie erläutert darauf abgestellt ist, Änderungen in zeitlich früh angefügten Datenblöcken 34 zu verhindern.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102017212904 A1 [0004]

Claims

Verfahren zur Autorisierung eines ersten Teilnehmers (1 - 6) in einem Kommunikationsnetz (11), über das mehrere Teilnehmer (1 - 6) kommunizieren, wobei den Teilnehmern (1 - 6) jeweils eine Identifikationsinformation (7, 8, 43) zugeordnet ist, umfassend die Schritte: - Übertragen der Identifikationsinformation (7, 8, 43) des ersten Teilnehmers (1 - 6) an einen zweiten Teilnehmer (1 - 6) in dem Kommunikationsnetz (11), der eine Verarbeitungseinrichtung (12, 13, 30, 31) ist oder umfasst, - Prüfen, ob in einer Datenstruktur (16, 17) der Identifikationsinformation (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind, durch die Verarbeitungseinrichtung (12, 13, 30, 31), wobei eine Datenstruktur (16, 17) verwendet wird, die auf mehreren als Teilnehmer (1 - 6) über das Kommunikationsnetz (11) kommunizierenden Verarbeitungseinrichtungen (12, 13, 30, 31) repliziert ist und die mehrere Datenblöcke (34) umfasst, die in einer Abfolge geordnet und derart miteinander verknüpft sind, dass der Inhalt eines jeweiligen nachfolgenden Datenblocks (34) vom Inhalt wenigstens eines vorangehenden Datenblocks (34) abhängt, - Freigabe einer Funktion (26, 27) des zweiten Teilnehmers (1 - 6) ausschließlich bei Erfüllung einer die Autorisierungsdaten (42, 49) auswertenden Autorisierungsbedingung (47), die nur dann erfüllbar ist, wenn der Identifikationsinformation (7, 8, 43) zugeordnete Autorisierungsdaten (42, 49) vorhanden sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Autorisierungsdaten (42, 49) dadurch in der Datenstruktur (16, 17) angelegt oder verändert werden, dass durch eine Verarbeitungseinrichtung (12, 13, 30, 31), die ein Teilnehmer (1 - 6) oder Teil eines Teilnehmers (1 - 6) ist, ein zusätzlicher Datenblock (34) an die Datenstruktur (16, 17) angefügt wird, der von wenigstens einem der vorhandenen Datenblöcke (34) der Datenstruktur (16, 17) abhängt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Autorisierungsdaten (42, 49) die Identifikationsinformation (7, 8, 43) jenes Teilnehmers (1 - 6), durch den das oder ein Anlegen und/oder Verändern der Autorisierungsdaten (42, 49) ausgelöst wurde, und/oder eine mit der Identifikationsinformation (7, 8, 43) verknüpfte Signatur (44) umfassen, wobei die Erfüllung der Autorisierungsbedingung (47) von der Identifikationsinformation (7, 8, 43) und/oder der Signatur (44) abhängt.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Autorisierungsbedingung (47) nur dann erfüllt wird oder nur dann erfüllbar ist, wenn in der Datenstruktur (16, 17) der Identifikationsinformation (7, 8, 43) und/oder der Signatur (44) zugeordnete Berechtigungsdaten (50, 55) vorhanden sind, die eine Berechtigung des die Autorisierungsdaten (42, 49) anlegenden und/oder verändernden Teilnehmers (1 - 6) anzeigen.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Berechtigungsdaten (50, 55) dadurch in der Datenstruktur (16, 17) angelegt und/oder verändert werden, dass durch eine Verarbeitungseinrichtung (12, 13, 30, 31), die ein Teilnehmer (1 - 6) oder Teil eines Teilnehmers (1 - 6) ist, ein zusätzlicher Datenblock (34) an die Datenstruktur (16, 17) angefügt wird, der von wenigstens einem der vorhandenen Datenblöcke (34) der Datenstruktur (16, 17) abhängt.
Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass das Anlegen und/oder Verändern der Berechtigungsdaten (50, 55) automatisiert durch ein durch eine Verarbeitungseinrichtung (12, 13, 30, 31) wenigstens eines Teilnehmers (1-6) ausgeführtes Programm (56), das insbesondere in der Datenstruktur (16, 17) gespeichert ist, erfolgt.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das oder ein Anlegen und/oder Verändern der Berechtigungsdaten (50, 55) von Abstimmungsdaten (57) abhängt, die von mehreren Teilnehmern (1 - 6) an die das Programm (56) ausführende Verarbeitungseinrichtung (12, 13, 30, 31), insbesondere als Teil der Datenstruktur (16, 17), bereitgestellt werden.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zumindest ein Teil der in der Datenstruktur (16, 17) gespeicherten Daten für einen Teil der Teilnehmer (1 - 6) nicht oder nicht im Klartext lesbar ist, insbesondere durch Verschlüsselung dieser Daten.
Verfahren nach Anspruch einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als erster Teilnehmer (1 - 6) ein Kraftfahrzeug und als zweiter Teilnehmer (1 - 6) eine Infrastruktureinrichtung verwendet wird oder umgekehrt.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass als erster Teilnehmer (1 - 6) ein Kraftfahrzeug und als zweiter Teilnehmer (1 - 6) eine Ladeeinrichtung zum Laden eines Energiespeichers (59) des Kraftfahrzeugs verwendet wird oder umgekehrt, wobei die Funktion (26, 27) des zweiten Teilnehmers (1 - 6) notwendig für das Laden des Energiespeichers (59) durch die Ladeeinrichtung ist.
Verarbeitungseinrichtung, dadurch gekennzeichnet, dass sie zur Teilnahme an dem Verfahren nach einem der vorangehenden Ansprüche als Teilnehmer (1 - 6) oder als Teil eines Teilnehmers (1 - 6) ausgebildet ist.
Kraftfahrzeug, dadurch gekennzeichnet, dass es eine Verarbeitungseinrichtung (12, 13, 30, 31) nach Anspruch 11 umfasst.
Infrastruktureinrichtung, insb. Ladeeinrichtung, dadurch gekennzeichnet, dass sie eine Verarbeitungseinrichtung (12, 13, 30, 31) nach Anspruch 11 umfasst.