Die Erfindung betrifft ein Verfahren zur Authentifizierung von Daten, welche in einem System mit wenigstens drei Instanzen zwischen zwei dieser Instanzen übertragen werden, wobei jede der Instanzen eine eindeutige Identitätskennung hat.

Moderne Fahrzeuge sind heute typischerweise Teil eines sogenannten Fahrzeug- Ökosystems. Ein zentraler Teil dieses Systems ist das sogenannte Vehicle Backend oder verkürzt Backend, ein fahrzeugexterner Server, welcher in der Regel als herstellereigener Server betrieben wird und oft in einer kommerziellen Cloud implementiert ist. Die Fahrzeuge sind mit diesem Backend über das Internet verbunden. Die Kommunikation zwischen dem Backend und den Fahrzeugen wird dabei mit Hilfe bekannter Standardverfahren abgesichert, meist TLS, manchmal auch IPSec. Teilsysteme bzw. Instanzen dieses Fahrzeug-Ökosystems sind beispielsweise einzelne in den Fahrzeugen verbaute Steuergeräte (ECUs), die untereinander meist über fahrzeuginterne Busse, beispielsweise CAN, FlexRay oder Ethernet kommunizieren. Weitere Instanzen des Fahrzeug-Ökosystems bilden auch smarte Endgeräte bzw. darauf laufende Applikationen, meist herstellereigene Applikationen des OEM, welche beispielsweise auf Smartphones betrieben werden und mit einzelnen Steuergeräten innerhalb des Fahrzeugs und/oder mit dem Backend kommunizieren. Ihre Kommunikation mit Steuergeräten innerhalb des Fahrzeugs erfolgt meist über NFC, WLAN oder Bluetooth, ihre Kommunikation mit dem Backend typischerweise über Mobilfunk, beispielsweise UMTS, LTE oder 5G. Weitere Teilsysteme bzw. Instanzen des Fahrzeug-Ökosystems können auch herstellerspezifische externe Geräte sein, wie beispielsweise OBD-Dongles, die in der Regel über eine geeignete Schnittstelle mit einzelnen Steuergeräten innerhalb des Fahrzeugs direkt kommunizieren.

Die Absicherung der vielfältigen Kommunikationsbeziehungen innerhalb eines solchen Fahrzeug-Ökosystems ist dabei typischerweise ebenso vielfältig wie die Kommunikationsbeziehungen selbst. Viele dieser Kommunikationsbeziehungen sind mit standardisierten Protokollen wie beispielsweise TLS oder IPSec abgesichert. Bluetoothoder WLAN-Verbindungen haben weitere eigene Schutzmechanismen, die oft durch zusätzliche herstellerspezifische Schutzmechanismen auf der Anwendungsebene ergänzt werden. Die fahrzeuginterne Kommunikation zwischen Steuergeräten wird meist mit SecOC abgesichert.

In der Praxis ist es dabei so, dass das Backend typischerweise mehrere Module aufweist, welche mit den Fahrzeugen in dem Fahrzeug-Ökosystem kommunizieren. Jedes der Fahrzeuge enthält im Allgemeinen eine Telematik-Control-Unit (TCU), die wiederum eine SIM-Karte enthält und eine direkte Internetverbindung zum Backend bzw. seinen Modulen herstellen kann. Bestimmte Steuergeräte innerhalb des Fahrzeugs kommunizieren mit externen Geräten wie beispielsweise Smartphones, Laptops, Dongles über NFC, Bluetooth, WLAN oder auch über die OBD2-Buchse, welche zur OnBoard-Diagnose in allen modernen Fahrzeugen vorhanden ist. Zusätzlich sind typischerweise mehrere dieser externen Geräte, beispielsweise Smartphones, über eine mit TLS abgesicherte Verbindung ebenfalls mit dem Backend verbunden.

Grundsätzlich ist es aus dem Stand der Technik bekannt und beispielsweise in der US 2020 / 0202017 A1 beschrieben, die Kommunikation zwischen Teilnehmern eines Fahrzeug-Ökosystems über eine Verschlüsselung abzusichern. Denkbar ist hier beispielsweise eine Ende-zu-Ende-Absicherung der Kommunikation über geeignete Verschlüsselungsverfahren. Der Nachteil dieser Verschlüsselungsverfahren ist es jedoch, dass die Verschlüsselung typischerweise nicht authentifiziert ist, was bedeutet, dass das Backend oder eines seiner Module als Adressat sich nicht sicher sein kann, ob die empfangenden Daten tatsächlich von diesem Steuergerät (ECU) verschlüsselt worden sind bzw. ob im Falle eines Downloads die Anfrage und damit der für die Absicherung beispielsweise genutzte symmetrische Sitzungsschlüssel bzw.

Transportschlüssel tatsächlich von diesem Steuergerät stammt.

Um dieser Schwäche abzuhelfen, wäre es nötig, sicherzustellen, dass das mit dem Backendmodul Ende-zu-Ende-verschlüsselt kommunizierende Steuergerät auch in der Lage ist, seine Nachrichten asymmetrisch zu signieren. Dafür wäre es nun jedoch notwendig, dass das jeweilige Steuergerät mit einem geräteindividuellen privaten Schlüssel ausgestattet sein muss, dass das Steuergerät in der Lage sein muss, seinen geräteindividuellen privaten Schlüssel sicher aufzubewahren, also beispielsweise in einem Hardware-Security-Modul (HSM), und dass das Steuergerät in der Lage sein muss, eine asymmetrische Signieroperation durchzuführen, wobei beachtet werden muss, dass eine asymmetrische Signieroperation beispielsweise im Falle der Verwendung von RSA sehr rechenintensiv ist, insbesondere um Größenordnungen rechenintensiver als das Prüfen einer digitalen Signatur. Von ressourcearmen Geräten lässt sie sich also in sinnvoller Zeit kaum durchführen.

In der Praxis ist es nun jedoch so, dass viele in den Fahrzeugen verbauten Steuergeräte ressourcearme Geräte sind, welche technisch nicht in der Lage sind, ein Geheimnis wie einen geräteindividuellen privaten Schlüssel sicher aufzubewahren, insbesondere, weil sie über kein HSM verfügen. Des Weiteren sind viele Steuergeräte nicht in der Lage die erforderliche Rechenleistung bereitzustellen, um mit Hilfe ihres privaten Schlüssels eine digitale Signatur ausreichend schnell und effizient zu berechnen.

Die Aufgabe der hier vorliegenden Erfindung besteht deshalb darin, ein Verfahren zur Authentifizierung von Daten innerhalb eines Systems anzugeben, welches diese Nachteile minimiert.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1 , und hier insbesondere im kennzeichnenden Teil des Anspruchs 1 , gelöst. Weitere vorteilhafte Ausgestaltungen ergeben sich aus den hiervon abhängigen Unteransprüchen.

Bei dem erfindungsgemäßen Verfahren ist es so, dass das System, welches gemäß einer sehr vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ein Fahrzeug-Ökosystem sein kann, verschiedene Teilsysteme bzw. Instanzen umfasst. Für diese Instanzen des Systems bzw. Fahrzeug-Ökosystems werden nun für die Kommunikation verschiedene Kommunikationsmechanismen genutzt, die wiederum mit verschiedenen Schutzmechanismen abgesichert sind. Das gesamte System ist also im Sinne der Kommunikation und ihres Schutzes sehr heterogen. Häufig ist es außerdem so, dass in derartigen Systemen, und dies gilt insbesondere aber nicht nur für ein Fahrzeug-Ökosystem, an vielen Stellen ein hierarchischer Aufbau besteht. So können beispielsweise alle in einem Fahrzeug verbauten Steuergeräte, welche einzelne Instanzen des Systems darstellen, vom Backend oder einem seiner Module, welche ebenfalls Instanzen des Systems darstellen, als „das Fahrzeug“ gesehen werden. Ist aktuell gerade ein Dongle oder ein Smartphone beispielsweise via Bluetooth mit dem Fahrzeug verbunden, so kann zu diesem Zeitpunkt auch das Dongle oder das Smartphone bzw. die darauf laufende mit dem Fahrzeug verbundene Applikation als „das Fahrzeug“ aus der Sicht des Backends verstanden werden.

Innerhalb eines solchen Systems können dann vielfältige Vertrauensbeziehungen existieren, die oft ebenfalls hierarchisch organisiert und auf unterschiedliche Weise technisch umgesetzt bzw. unterstützt werden. So kann beispielsweise ein im Fahrzeug verbautes Steuergerät ein zweites Steuergerät, dass das erste Steuergerät als im gleichen Fahrzeug verbaut erkennt, als vertrauenswürdig einstufen, weil es davon ausgeht, dass die Integrität des im Fahrzeug verbauten Gesamtsystems nicht einfach trivial umgangen werden kann. Dem liegt dann also die Erfahrung zugrunde, dass es nicht ohne weiteres möglich ist, ein zusätzliches nicht bekanntes oder nicht zugelassenes Steuergerät in das Fahrzeug einzubringen. Ferner ist es so, dass beispielsweise ein Steuergerät einem mit ihm via Bluetooth verbundenen Smartphone bzw. der darauf laufenden Applikation vertraut, weil das Bluetooth-Pairing für dieses Smartphone von einer Person durchgeführt worden ist, welche zum Zeitpunkt des Pairings im Besitz des Fahrzeugschlüssels gewesen ist und damit also offensichtlich berechtigt war, das Pairing durchzuführen. Durch die Nutzung der Bluetooth- Sicherheitsmechanismen kann das Steuergerät sich also sicher sein, dass das Smartphone, das mit ihm gerade verbunden ist, das gleiche ist, das von der berechtigten Person via Bluetooth-Pairing zugelassen worden ist. Es kann damit dem Smartphone weiterhin vertrauen. Auf der anderen Seite kann das Smartphone aus demselben Grund auch dem mit ihm verbundenen Steuergerät entsprechend vertrauen. Analog dazu kann zwischen einem in dem Fahrzeug verbauten Steuergerät, wie beispielsweise der Telematik-Control-Unit, und dem Backend oder einem bestimmten Modul innerhalb des Backends ein Vertrauensverhältnis bestehen. Ist dieses Steuergerät darüber hinaus im Besitz von Geheimnissen wie beispielsweise eines privaten Endorsement-Schlüssels und eines dazugehörenden Endorsement-Zertifikats, so kann es sich damit gegenüber einem anderen System, und hier insbesondere auch gegenüber dem Backend oder einem bestimmten Backendmodul, sicher authentifizieren. Auf diese Weise kann das Backend den von diesem Steuergerät empfangenen Nachrichten und den darin enthaltenen von diesem Steuergerät authentifizierten Informationen also vertrauen. Insbesondere kann dieses Steuergerät, wegen der oben beschriebenen Außensicht vom Backend auf das Fahrzeug als Ganzes vom Backend als vertrauenswürdiger Vertreter für das gesamte Fahrzeug und damit insbesondere als vertrauenswürdiger Vertreter für alle darin verbauten Steuergeräte angesehen werden.

Wenn nun einzelne Steuergeräte aus den eingangs beschriebenen Gründen nicht in der Lage sind, die von ihnen übertragene Daten selbst gegenüber der Zielinstanz direkt entsprechend zu authentifizieren dann können die zu übertragenden Daten dieser Instanzen über ein weiteres Steuergerät des Fahrzeugs, wie beispielsweise die Telematik-Control-Unit, oder eine andere in einem Vertrauensverhältnis mit dem Fahrzeug verbundene Instanz authentifiziert werden. Diese weitere Instanz bildet dann quasi eine Zwischeninstanz, welche der die Daten übertragenden Quellinstanz vertraut. Die Zwischeninstanz kann die zu übertragenden Daten der Quellinstanz also empfangen, mit der Identitätskennung der Quellinstanz versehen, authentifizieren und an eine Zielinstanz wie beispielsweise ein Backendmodul des Vehicle-Backends weiterreichen. Obwohl das einzelne Steuergerät in dem Fahrzeug nun nicht in der Lage ist, seine Daten zu authentifizieren, weil ihm dafür beispielsweise die Möglichkeit der sicheren Ablage eines Geheimnisses fehlt und/oder weil die erforderliche Rechenkapazität nicht zur Verfügung steht, kann es die Zwischeninstanz nutzen, um seine Daten gegenüber dem Zielsystem authentifizieren zu lassen. Die Authentifizierung wird also von der Quellinstanz an die Zwischeninstanz delegiert. Gleichzeitig wird bei dem Vorgang die Prüfung der Authentizität der von der Quellinstanz versendeten Daten von der Zielinstanz an die Zwischeninstanz delegiert, was zur Folge hat, dass die Zielinstanz der Zwischeninstanz vertrauen muss.

Bei dem erfindungsgemäßen Verfahren können dabei zwischen einer Quellinstanz und einer Zielinstanz prinzipiell beliebig viele Zwischeninstanzen vorgesehen sein. Die Übertragung der übertragenen Daten erfolgt dann zusammen mit einer Identitätskennung der Quellinstanz als Quelle der zu übertragenden Daten über die jeweiligen Zwischeninstanzen, von welchen zumindest die empfangende Zwischeninstanz der sendenden Zwischeninstanz vertraut, wobei sich natürlich auch beide gegenseitig vertrauen können. Dabei ist es so, dass die erste Zwischeninstanz die Daten samt der Identitätskennung der Quellinstanz authentifiziert, die nächste Zwischeninstanz die Authentifizierung der empfangenen Daten samt der Identitätskennung der Quellinstanz prüft, im positiven Fall der Prüfung die Daten samt der Identitätskennung der Quellinstanz neu authentifiziert und an die folgende benachbarte Zwischeninstanz weitergibt und so fort, bis die von benachbarter zur benachbarter Instanz weitergereichten Daten dann die Zielinstanz erreichen. Durch diese Delegation der Authentifizierung können also auch Daten von dafür nicht eingerichteten Instanzen entsprechend authentifiziert werden, was die Sicherheit erhöht. Man beachte, dass auf der anderen Seite die Prüfung der Authentizität jeweils von der empfangenden an die sendende benachbarte Instanz delegiert wird.

Benachbart in Sinne der hier vorliegenden Beschreibung bedeutet dabei, dass eine erste Instanz als benachbart zu wenigstens einer anderen z.B. zweiten Instanz angesehen, wenn die beiden Instanzen einen gemeinsamen Authentifizierungsmechanismus implementiert haben, mit dessen Hilfe sich die erste Instanz gegenüber der zweiten Instanz authentifizieren kann und wenn zusätzlich die zweite Instanz der ersten Instanz vertraut. Benachbart zu sein hat also nichts mit räumlicher Nähe zu tun und ist insbesondere keine symmetrische Relation.

Eine besonders günstige Ausgestaltung des Verfahrens gemäß der Erfindung sieht es nun vor, dass drei Instanzen vorgesehen sind. Eine der Instanzen ist dann die Quellinstanz, eine die Zielinstanz und eine bildet die Zwischeninstanz. Das System, beispielsweise das Fahrzeug-Ökosystem, kann dabei mehr Teilsysteme bzw. Instanzen als eben diese drei umfassen. In das Verfahren zur Authentifizierung der Daten werden jedoch nur diese drei Instanzen einbezogen. Dies macht den Aufbau relativ einfach und effizient, da nicht über eine längere Kette von Zwischeninstanzen hinweg die Daten jeweils geprüft und neu authentifiziert werden müssen.

Es wird also vorgeschlagen, für einen aus drei Instanzen mit ihrer jeweiligen Identitätskennung bestehenden Teil eines bestehenden Systems, welches insbesondere ein Fahrzeug-Ökosystem oder auch nur ein Teil eines solchen sein kann, eine Variante vorzusehen, bei welcher sowohl zwischen der ersten Instanz als Quellinstanz und der Zwischeninstanz als auch zwischen der Zwischeninstanz und der dritten Instanz als Zielinstanz ein Vertrauensverhältnis besteht. Die Quellinstanz und die Zwischeninstanz haben dabei einen ersten Authentifizierungsmechanismus implementiert, mit dessen Hilfe sich die Quellinstanz gegenüber der Zwischeninstanz authentifizieren kann. Die Zwischeninstanz und die Zielinstanz haben einen zweiten Authentifizierungsmechanismus implementiert, mit dessen Hilfe sich die Zwischeninstanz gegenüber der Zielinstanz authentifizieren kann. Von der Quellinstanz zu der Zielinstanz zu versendende Daten werden dann zuerst von der Quellinstanz mit dem ersten Authentifizierungsmechanismus authentifiziert und an die Zwischeninstanz übermittelt. Die Zwischeninstanz überprüft die Authentizität der von der Quellinstanz übermittelten Daten mittels des ersten Authentifizierungsmechanismus. Im Falle eines positiven Ergebnisses dieser Prüfung kombiniert sie die Daten dann mit der Identitätskennung der Quellinstanz und authentifiziert diese Daten mit dem zweiten Authentifizierungsmechanismus, um sie an die Zielinstanz zu übermitteln. Die Zielinstanz ist nun in der Lage, die Authentizität der aus den Daten und der Identitätskennung der Quellinstanz bestehende Kombination mittels des zweiten Authentifizierungsmechanismus zu prüfen. Im Falle eines positiven Ergebnisses dieser Prüfung kann die Zielinstanz die Daten entsprechend nutzen und/oder weiterverarbeiten und kann dabei darauf vertrauen, dass die Daten authentisch von der Quellinstanz stammen.

Dabei ist es im Allgemeinen nicht notwendig, dieselben Authentifizierungsmechanismen zu verwenden. Vielmehr können der erste und der zweite Authentifizierungsmechanismus verschiedene Mechanismen sein, sodass die Zielinstanz die Authentizität der von der Quellinstanz mit dem ersten Authentifizierungsmechanismus authentifizierten Daten nicht prüfen kann, beispielsweise weil die Zielinstanz den passenden Mechanismus nicht implementiert hat und/oder weil der Zielinstanz das zur Überprüfung der Authentizität der von der Quellinstanz mittels des ersten Authentifizierungsmechanismus authentifizierter Daten notwendige kryptografische Material fehlt und/oder weil eine Voraussetzung des ersten Authentifizierungsmechanismus, beispielsweise die örtliche Nähe zwischen den beteiligten Instanzen oder die Kommunikation der beteiligten Instanzen über einen bestimmten Bus, für die Quellinstanz einerseits und die Zielinstanz andererseits nicht gegeben ist. Die örtliche Nähe kann beispielsweise gemäß der DE 10 2021 001 170 A1 erfasst werden.

Dabei könnte die Quellinstanz ein Smartphone sein, das sich gegenüber einer Zwischeninstanz, beispielsweise einem im Fahrzeug verbauten Steuergerät, mittels Bluetooth-Mechanismen authentifiziert, während dieses Steuergerät als die Zwischeninstanz wiederum ein Endorsement-Authentifizierungsmechanismus implementiert hat. Die Zwischeninstanz wäre hier also im Besitz eines privaten Endorsement-Schlüssels und eines dazugehörigen Endorsement-Zertifikats, mit denen die Zwischeninstanz sich gegenüber der Zielinstanz, beispielsweise einem Backendmodul, authentifizieren kann. Das Backendmodul als Zielinstanz kann dabei die Bluetooth-Authentifizierung der Quellinstanz nicht überprüfen. Die Zielinstanz kann aus diesem Grund nur dann davon ausgehen, dass die übertragenen Daten tatsächlich von der Quellinstanz stammen, wenn sie ihrerseits der Zwischeninstanz vertraut, dass diese sichergestellt hat, dass die Daten von der Quellinstanz stammen, und ergänzend dazu dann, wenn die Zielinstanz davon ausgeht, dass der zweite Authentifizierungsmechanismus, welcher zwischen ihr und der Zwischeninstanz zur Anwendung kommt, sicher ist.

Eine weitere außerordentlich günstige Ausgestaltung des erfindungsgemäßen Verfahrens kann es ferner vorsehen, dass wenigstens eine der Instanzen zumindest eine, typischerweise mehrere Unterinstanzen mit eindeutiger Identitätskennung umfasst. Die Instanz vertraut dabei zumindest dieser einen Unterinstanz, wobei die zumindest eine Unterinstanz einen Authentifizierungsmechanismus implementiert hat, mittels welchem sie sich gegenüber der Instanz, welcher sie untergeordnet ist, authentifizieren kann. Das Verfahren kann also nicht nur bei einer Kette von Instanzen und Zwischeninstanzen entsprechend eingesetzt werden, sondern auch dann, wenn von einer Instanz aus zu mehreren weiteren Unterinstanzen verzweigt wird, welchen die Instanz allen vertraut. Diese Unterinstanzen können dann Quellinstanzen oder auch die Datenquellen für die übergeordnete Instanz als Quellinstanz bilden.

Eine weitere sehr vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht es vor, dass zumindest einer der nachfolgenden Authentifizierungsmechanismen verwendet wird. Beispielsweise können auf digitalen Signaturen basierende Authentifizierungen eingesetzt werden. Ergänzend oder alternativ dazu können auf symmetrischen Verfahren basierende Authentifizierungen genutzt werden wie beispielsweise die MAC-Verfahren. Auch die implementieren Mechanismen von Bluetooth, WLAN, NFC oder SecOC sowie TLS, die meist auf digitalen Signaturen und/oder symmetrischen Verfahren basieren, können die Basis für die Authentifizierung bilden. Daneben sind jedoch auch Authentifizierungsverfahren bzw. -mechanismen denkbar, welche nicht auf kryptografischen Verfahren und/oder Geheimnissen basieren, sondern beispielsweise auf biometrischen Verfahren der technisch festgestellten örtlichen Nähe und/oder der Nutzung eines sicheren und vertrauenswürdigen Kommunikationskanals. Dabei sind auch Kombinationen denkbar.

Dabei müssen, wie die obige Liste zeigt, die Authentifizierungsmechanismen nicht notwendigerweise auf kryptographischen Verfahren und/oder auf Geheimnissen basieren, vielmehr können es auch andere Verfahren, wie insbesondere biometrische Verfahren, sein. Beispielsweise kann eine der Instanzen eine Kombination aus einem mobilen Datenträger, bspw. ein USB-Stick oder eine USB-Festplatte oder dergleichen, und einer Person mit eindeutiger individueller Identitätskennung sein, wobei auf dem mobilen Datenträger die zu übertragenden Daten gespeichert sind. Wenn nun die Person den mobilen Datenträger an einen passenden Anschluss einer im Fahrzeug verbauten Head Unit, welche die zweite Instanz bildet, anschließt und an die Head Unit eine Kamera angeschlossen ist, die bspw. per Iriserkennung die Person, die den Datenträger angeschlossen hat, eindeutig identifiziert, dann kann auf diese Weise durch die Head Unit festgestellt werden, welche Person den mobilen Datenträger angeschlossen hat. Die Head Unit als Zwischeninstanz kann die Daten dann unter Angabe der Zuordnung der Daten zu der Person, die den mobilen Datenträger angeschlossenen hat, also ihrer Identitätskennung, authentifiziert, bspw. per TLS, an eine weitere Instanz, z.B. ein Backend-Modul, als Zielinstanz übertragen.

Ferner kann die erste Instanz aber auch direkt eine Person sein, die Daten über die Eingabeeinheit einer im Fahrzeug verbauten Head Unit, welche die nächste Instanz bildet, eingibt, an die Head Unit eine Kamera angeschlossen ist, die per Iriserkennung die Person, die die Daten eingibt, eindeutig identifiziert. Auf diese Weise stellt die Head Unit als zweite Instanz fest, welche Person die Daten eingegeben hat und kann diese Daten unter Angabe der Zuordnung der Daten zu der Identitätskennung der sie eingegebenen Person, mit einem Authentifizierungsmechanismus, bspw. per TLS, authentifiziert an die Zielinstanz, bspw. ein Backend-Modul, übertragen.

Bei der mit dem ersten Authentifizierungsmechanismus authentifizierten Übertragung der Daten von der Quellinstanz an die Zwischeninstanz und der mit dem zweiten Authentifizierungsmechanismus authentifizierten Übertragung der Daten samt der Identitätskennung der Quellinstanz von der Zwischeninstanz an die Zielinstanz können, je nach Art und Beschaffenheit der beiden Authentifizierungsmechanismen, noch zusätzliche Daten von der Quellinstanz zu der Zwischeninstanz oder von der Zwischeninstanz zu der Zielinstanz übertragen werden müssen, die von den empfangenden Instanzen dazu benötigt werden, die Authentifizierung der jeweiligen empfangenen Daten zu überprüfen. Beispielsweise können diese zusätzlichen Daten sogenannte Authentifizierungsstempel sein, wie bspw. digitale Signaturen oder Message Authentication Codes (MACs).

Wie oben bereits angesprochen kann es gemäß einer sehr vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ferner vorgesehen sein, als Authentifizierungsmechanismus gegenüber der Zielinstanz eine Authentifizierung mit Hilfe eines privaten Endorsement-Schlüssels der die Daten sendenden Instanz und ihres Endorsement-Zertifikats zu nutzen. Diese Übertragung ist besonders sicher hinsichtlich der Authentifizierung und kann beispielsweise von einer TCU als Zwischeninstanz genutzt werden, welche den zentralen Kommunikationskanal eines Fahrzeugs mit dem Backend oder einem Modul des Backends ausbildet.

Das erfindungsgemäße Verfahren in einer seiner Ausgestaltungen schützt nun die von der Quellinstanz versendeten Daten nicht gegen ein Mitlesen durch die Zwischeninstanz, welche die Authentizität dieser Daten gegenüber der Zielinstanz bestätigt. Es wird daher gemäß einer sehr vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens vorgeschlagen, dass eine Verschlüsselung der übermittelten Daten zwischen der Quellinstanz und der Zielinstanz, quasi als Ende-zu-Ende Verschlüsselung, realisiert wird.

Gemäß einer außerordentlich günstigen Weiterbildung hiervon kann es dabei vorgesehen sein, dass die Zielinstanz mit einem asymmetrischen Entschlüsselungsverfahren und einem passenden asymmetrischen Schlüsselpaar ausgestattet ist, und dass der private Schlüssel in der Zielinstant sicher hinterlegt ist. Die Quellinstanz ist dann mit einem korrespondierenden asymmetrischen Verschlüsselungsverfahren und dem öffentlichen Schlüssel der Zielinstanz ausgestattet. Die von der Quellinstanz zu der Zielinstanz zu übertragenden Daten können so vor deren Übermitteln an die Zielinstanz mit dem öffentlichen Schlüssel mittels des Verschlüsselungsverfahrens direkt verschlüsselt werden. Die wenigstens eine Zwischeninstanz kann die Daten dann nicht mitlesen, so dass eine Ende-zu-Ende Verschlüsselung umsetzbar ist, bei welcher die Authentifizierung dennoch auf die der Quellinstanz vertrauende Zwischeninstanz delegiert werden kann.

Gemäß einer entsprechenden Weiterbildung hiervon kann es auch vorgesehen sein, dass die Quellinstanz zusätzlich mit einem symmetrischen Verschlüsselungsverfahren und die Zielinstanz mit dem korrespondierenden symmetrischen Entschlüsselungsverfahren ausgestattet ist und die von der Quellinstanz an die Zielinstanz zu übermittelnden Daten vor deren Versenden an die Zwischeninstanz mit einem (jeweils) neu erzeugten sicheren, bspw. zufälligen, zu dem symmetrischen Ver- und Entschlüsselungsverfahren passenden symmetrischen Schlüssel, einem sog. Transportschlüssel, verschlüsselt werden. Diesen neu erzeugten Transportschlüssel verschlüsselt die Quellinstanz dann mit dem von oben bekannten asymmetrischen öffentlichen Schlüssel der Zielinstanz. Den so verschlüsselten Transportschlüssel übermittelt die Quellinstanz dann als Teil der zu authentifizierenden Daten an die Zwischeninstanz mit.

Diese beschriebene Variante des erfindungsgemäßen Verfahrens sieht es also vor, dass die Quellinstanz mit dem öffentlichen Schlüssel der Zielinstanz ausgestattet wird, wobei dieser öffentliche Schlüssel als reiner Schlüssel und nicht als Zertifikat hinterlegt wird. Daher muss das Einbringen dieses Schlüssels auf eine sichere Weise erfolgen. Es muss also sichergestellt sein, dass der Quellinstanz bekannt ist, dass der öffentliche Schlüssel zu der Zielinstanz gehört und sowohl diese Information als auch der öffentliche Schlüssel selbst müssen in der Quellinstanz gegen Manipulation geschützt sein. Diese Anforderungen lassen sich jedoch in der Praxis relativ gut bei einer initialen Ausstattung der Quellinstanz mit Kryptomaterial erfüllen. Allerdings ist das spätere dynamische Einbringen von Schlüssel während der Laufzeit entsprechend erschwert. Insbesondere das Einbringen von öffentlichen Schlüsseln von weiteren Kommunikationspartnern, welche als weitere Zielinstanzen während der Laufzeit des Systems in dieses integriert werden, ist komplex und schwierig. Dieses Problem stellt sich jedoch erst gar nicht, wenn die für die Verschlüsselung zu nutzenden öffentlichen Schlüssel der Zielinstanz in Form von Zertifikaten in die Quellinstanz eingebracht werden, da in diesem Fall das sichere Einbringen und das integritätsgeschützte Aufbewahren des öffentlichen (Wurzel-) Schlüssels einer Zertifizierungsstelle genügt, um die Integrität aller nachträglich eingebrachten Zertifikate jederzeit sicher überprüfen zu können.

Gemäß einer sehr vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens ist es daher vorgesehen, dass innerhalb des Systems eine auf einem asymmetrischen Schlüsselpaar basierende Zertifizierungsstelle eingerichtet wird. Das Wurzelzertifikat dieser Authentifizierungsstelle enthält dabei den öffentlichen Schlüssel der Zertifizierungsstelle, der dazu genutzt werden kann, die Korrektheit der die zur eigentlichen Verschlüsselung genutzte öffentliche Schlüssel enthaltenden Blattzertifikate und damit insbesondere die Herkunft bzw. Zugehörigkeit der einzelnen Verschlüsselungsschlüssel zu der jeweiligen Zielinstanz zu überprüfen. Weil die von der Zertifizierungsstelle ausgestellten Blattzertifikate Verschlüsselungsschlüssel enthalten, werden diese Blattzertifikate im Weiteren auch als Verschlüsselungszertifikate bezeichnet. Gemäß der vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens ist die Zertifizierungsstelle dabei mit einer abgesicherten Schnittstelle ausgestattet, welche das Ausstellen von Blattzertifikaten für zu der Zielinstanz gehörende individuelle öffentliche Schlüssel ermöglicht, wobei die in den Blattzertifikaten enthaltenen öffentlichen Schlüssel sich zum asymmetrischen Verschlüsseln mittels eines asymmetrischen Verschlüsselungsverfahren und die korrespondierenden privaten Schlüssel zum Entschlüsseln mittels des asymmetrischen Verschlüsselungsverfahrens eignen. Alle von der Zertifizierungsstelle für die Zielinstanzen ausgestellten Blattzertifikate werden dabei in der Zertifizierungsstelle oder einem mit der Zertifizierungsstelle verbunden Drittsystem entsprechend abgelegt. Dabei wird eine Abholschnittstelle angeboten, über welche die Quellinstanzen für die Zielinstanzen ausgestellte Blattzertifikate von der Zertifizierungsstelle oder dem Drittsystem abholen bzw. herunterladen können. Ferner ist es dabei so, dass für alle Zielinstanzen des Systems von der Zertifizierungsstelle unter Ausnutzung der abgesicherten Schnittstelle initial ein den öffentlichen Schlüssel der jeweiligen Zielinstanz enthaltendes Zertifikat ausgestellt wird und/oder die Zielinstanzen mit der Möglichkeit ausgestattet werden, sich solche Zertifikate von der Zertifizierungsstelle unter Ausnutzung der abgesicherten Schnittstelle auszustellen zu lassen. Alle Quellinstanzen des Systems sind dabei auf sichere Weise mit dem öffentlichen Schlüssel der Zertifizierungsstelle ausgestattet und legen diesen als Vertrauensanker für die von der Zertifizierungsstelle ausgestellten Blattzertifikate, welche im oben beschriebenen Sinn Verschlüsselungszertifikate darstellen, ab. Alle Quellinstanzen des Systems sind ferner mit der Möglichkeit ausgestattet, von der Zertifizierungsstelle oder dem Drittsystem die dort abgelegten benötigten oder zusätzlich benötigten Blattzertifikate der Zielinstanzen dynamisch abzuholen.

Die Nutzung einer solchen Zertifizierungsstelle und von ihr ausgestellter Verschlüsselungszertifikate ermöglicht es, Daten an neu hinzugekommene bzw. vor der Inbetriebnahme des Quellsystems noch nicht bekannte Zielinstanzen verschlüsselt zu übertragen, was in der praktischen Anwendung, insbesondere in einem sich dynamisch verändernden System, wie einem Fahrzeug-Ökosystem, von erheblichem Vorteil ist.

Die Abholschnittstelle selbst muss dabei nicht notwendigerweise als abgesicherte Schnittstelle ausgebildet werden, was den Aufbau bzw. Ablauf weiter vereinfacht.

Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens sowie seiner Varianten ergeben sich auch anhand der Ausführungsbeispiele, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben sind.

Dabei zeigen:

Fig. 1 eine schematische Darstellung eines Fahrzeug-Ökosystems;

Fig. 2 eine schematische Darstellung einer ersten Variante des erfindungsgemäßen

Verfahrens zu Delegation der Authentifizierung;

Fig. 3 eine schematische Darstellung einer weiteren Variante des erfindungsgemäßen Verfahrens zu Delegation der Authentifizierung; und

Fig. 4 eine schematische Darstellung des Provisionings der Instanzen eines Fahrzeug-Ökosystems mit Verschlüsselungszertifikaten. Figur 1 zeigt schematisch ein beispielhaftes Fahrzeug-Ökosystem 1 mit zwei Fahrzeugen Fzg1 , Fzg2 und einem aus zwei Modulen BEModulX und BEModulY bestehendes Backend. Jedes der Fahrzeuge Fzg1 , Fzg2 enthält eine Telematic Control Unit TCU, die wiederum eine SIM-Karte SIM enthält und eine direkte mit TLS abgesicherte Internetverbindung zum Backend herstellen kann. Bestimmte Steuergeräte (ECUs) der Fahrzeuge Fzg1 , Fzg2 kommunizieren mit externen Geräten ExtGerl - ExtGer6, bspw. Smartphones, Laptops, Dongles etc., über Near Field Communication NFC, Bluetooth BT, WLAN und/oder die Onboard-Diagnose-Buchse OBD etc. Auf der anderen Seite sind mehrere externe Geräte ExtGerA, ExtGerB, ExtGerC, bspw. Smartphones, Laptops etc., über eine mit TLS abgesicherte Verbindung mit dem Backend verbunden. Alle TCUs, ECUs sowie das Backend bzw. seine Module BEModulX und BEModulY stellen dabei ebenso wie die externen Geräte ExtGerl - ExtGer6 und die externen Geräte ExtGerA, ExtGerB, ExtGerC Teilsysteme bzw. Instanzen IZi des Fahrzeug-Ökosystems 1 dar, wobei 1 < i < n und n eine beliebige natürliche Zahl ist.

Ein Verfahren zur Authentifizierung von Daten in einem solchen Fahrzeug-Ökosystem 1 mit mehreren Instanzen IZi wird nachfolgend am Beispiel von drei beteiligten Teilsystemen bzw. Instanzen IZ1 , IZ2 und IZ2 beschreiben. Es kann aber selbstverständlich auch weitere Instanzen IZi mit einbeziehen.

Für das Beispiel werden in dem Fahrzeug-Ökosystem 1 also drei verschiedenen Instanzen IZ1 , IZ2, IZ3 mit den jeweiligen eindeutigen Identitätskennungen IZ1JD, IZ2_ID, IZ3_ID aktiv. Sowohl zwischen der ersten Instanz IZ1 und der zweiten Instanz IZ2 als auch zwischen der zweiten Instanz IZ2 und der dritten Instanz IZ3 besteht ein Vertrauensverhältnis in zumindest eine Richtung. In jedem Fall sollte also die zweite Instanz IZ2 der ersten Instanz IZ1 vertrauen und die dritte Instanz IZ3 der zweiten Instanz IZ2. Die erste und die zweite Instanz IZ1, IZ2 sowie die zweite und die dritte Instanz IZ2, IZ3 sind damit im Sinne der Beschreibung benachbarte Instanzen. Die Instanzen IZ1 und IZ2 haben einen Authentifizierungsmechanismus AUTH 12 implementiert, mit dessen Hilfe sich IZ1 gegenüber IZ2 authentifizieren kann. Die Instanzen IZ2 und IZ3 haben ebenfalls einen - ggf. anderen - Authentifizierungsmechanismus AUTH23 implementiert, mit dessen Hilfe sich IZ2 gegenüber IZ3 authentifizieren kann. Figur 2 zeigt nun in einer schematischen Darstellung diese drei Instanzen und die dem Verfahren zugrundeliegende Aufgabe. Diese besteht darin, Daten DAT13 von der ersten Instanz IZ1 als Quellinstanz IZ1 zu der dritten Instanz IZ3 als Zielinstanz IZ2 authentifiziert zu übertragen, wie es durch den gestrichelten Pfeil angedeutet ist. Die Quellinstanz ist nun aber ein Steuergerät (ECU), dass nicht die Möglichkeit besitzt ein Geheimnis sicher abzulegen und dass nicht die Rechenkapazität für eine geeignete Authentifizierung gegenüber der Zielinstanz IZ3 aufweist. Die von der Quellinstanz IZ1 an die Zielinstanz IZ3 zu versendenden Daten DAT13 werden daher zuerst von der Quellinstanz IZ1 mit dem Authentifizierungsmechanismus AUTH12, der kein Geheimnis benötigt, authentifiziert an eine Zwischeninstanz IZ2 übermittelt. Dort wird die Authentizität der übermittelten Daten von der Zwischeninstanz IZ2 mittels des Authentifizierungsmechanismus AUTH12 geprüft. Im Falle eines positiven Ergebnisses dieser Prüfung werden eine Kombination der Daten DAT13 und einer Identitätskennung IZ1_ID der Zielinstanz mit dem Authentifizierungsmechanismus AUTH23 authentifiziert von der Zwischeninstanz IZ2 an die Zielinstanz IZ3 übermittelt. Dort wird dann die Authentizität der aus den Daten DAT13 und der Identitätskennung IZ1_ID bestehenden Kombination von der Zielinstanz IZ3 mittels des Authentifizierungsmechanismus AUTH23 geprüft. Für den Fall eines positiven Ergebnisses dieser Prüfung kann die Zielinstanz IZ3 dann darauf vertrauen, dass die Daten DAT13 authentisch von der Quellinstanz IZ1 empfangen worden sind und sie entsprechend behandeln bzw. nutzen.

Dabei ist es so, dass im allgemeinen die Authentifizierungsmechanismen AUTH12 und AUTH23 verschiedene Mechanismen sind und die Zielinstanz IZ3 die Authentizität der von der Quellinstanz IZ1 mit dem Authentifizierungsmechanismus AUTH12 authentifizierten Daten nicht überprüfen kann, bspw., weil die Zielinstanz IZ3 den Mechanismus AUTH12 nicht implementiert hat und/oder weil der Zielinstanz IZ3 das zur Überprüfung der Authentizität der von der Quellinstanz IZ1 mittels des Authentifizierungsmechanismus AUTH 12 authentifizierten Daten notwendige kryptographische Material fehlt und/oder weil eine der Voraussetzungen des Authentifizierungsmechanismus AUTH 12, bspw. die örtliche Nähe zwischen den beteiligten Instanzen oder die Kommunikation der beteiligten Instanzen über einen bestimmten Bus, für die Quellinstanz IZ 1 und die Zielinstanz IZ3 nicht gegeben ist. Wenn bspw. die Quellinstanz IZ1 keine Steuergerät sondern ein Smartphone ist, das sich gegenüber einer Zwischeninstanz IZ2, welche bspw. ein im Fahrzeug verbautes Steuergerät ist, mittels Bluetooth-Mechanismen authentifiziert, und dieses Steuergerät als Zwischeninstanz IZ2 wiederum einen Endorsement-Authentifizierungsmechanismus implementiert hat, die Zwischeninstanz IZ2 also im Besitz eines privaten Endorsement- Schlüssels und eines dazugehörigen Zertifikats ist, mit denen sie sich gegenüber der Zielinstanz IZ3, die bspw. ein Backend-Modul ist, authentifizieren kann, so kann das Backend-Modul als Zielinstanz IZ3 die Bluetooth-Authentifizierung ALITH12 der Quellinstanz nicht überprüfen. Aus diesem Grunde kann die Zielinstanz IZ3 nur dann davon ausgehen, dass die Daten DAT13 tatsächlich von der Quellinstanz IZ1 stammen, wenn es der Zwischeninstanz IZ2 vertraut, dass diese sichergestellt hat, dass die Daten DAT13 von der Quellinstanz IZ1 stammen, und wenn die Zielinstanz IZ3 davon ausgeht, dass der Authentifizierungsmechanismus ALITH23 sicher ist.

Unter der speziellen Annahme, dass sowohl der Authentifizierungsmechanismus AUTH12 als auch der Authentifizierungsmechanismus AUTH23 auf Authentifizierungstempeln, bspw. digitalen Signaturen oder MACs, basieren, also Authentifizierungstempel erzeugen und diese überprüfen, wobei AUTH12_GEN bzw. AUTH23_GEN die zu AUTH12 bzw. AUTH23 gehörende Funktion zur Erzeugung eines Authentifizierungstempels bezeichnet, AUTH12_VER bzw. AUTH23_VER die zu AUTH12 bzw. AUTH23 gehörende Funktion zur Prüfung (Verifikation) eines Authentifizierungstempels bezeichnet und sowohl AUTH12 als auch AUTH23 bereits das benötigte kryptographische Material implizit enthalten, das benötigte kryptographische Material also nicht explizit als Parameter ausgewiesen wird, besteht das vorgeschlagene Verfahren aus folgenden Schritten:

• In der Quell-Instanz IZ1 :

■ der Authentifizierungsstempel AuthSt12 der Daten DAT13 wird mit AUTH12_GEN berechnet, also AuthSt12 := AUTH12_GEN (DAT13);

■ Die Nachricht (DAT13, AuthSt12) wird an die Zwischeninstanz IZ2 übermittelt;

• In der authentifizierenden Zwischeninstanz IZ2 nach Empfang von (DAT13, AuthSt12)):

■ Die Korrektheit des empfangenen Authentifizierungsstempels AuthSt12 der empfangenen Daten DAT13 wird mit AUTH12_VER geprüft, es wird also der boolesche Wert AUTH12_VER(DAT13, AuthSt12) berechnet; ■ Fällt die Prüfung positiv aus, wird der Authentifizierungsstempel AuthSt23 der Kombination der Daten DAT13 und der Identitätskennung IZ1_ID von IZ1 , also von (DAT13, IZ1JD) mit AUTH23_GEN, berechnet, also

AuthSt23 := AUTH23_GEN((DAT13, IZ1_I D)), andernfalls wird eine Sonderbehandlung eingeleitet;

■ die Nachricht (DAT13, IZ1_ID, AuthSt23) an die Quellinstanz IZ3 übermittelt.

• In der Zielinstanz IZ3 nach dem Empfang von (DAT13, IZ1JD, AuthSt23):

■ die Korrektheit des empfangenen Authentifizierungsstempels AuthSt23 der empfangenen Daten (DAT13, IZ1_ID) wird mit AUTH23_VER geprüft, also der boolesche Wert AUTH23_VER((DAT13, IZ1JD), AuthSt23) berechnet;

■ Fällt die Prüfung positiv aus, wird davon ausgegangen, dass die Daten DAT13 von IZ1 stammen und die Daten DAT13 werden entsprechend genutzt, andernfalls wird eine Sonderbehandlung eingeleitet.

Das vorgestellte Verfahren schützt die von der Quellinstanz IZ1 versendeten Daten DAT13 nicht gegen das Mitlesen durch das die Authentizität dieser Daten DAT13 gegenüber der Zielinstanz IZ3 bestätigenden Zwischeninstanz IZ2. Aus dem allgemeinen Stand der Technik ist es bekannt, wie bspw. über eine auf asymmetrischer Verschlüsselung basierende Ende-zu-Ende-Verschlüsselung zwischen zwei Instanzen eines Fahrzeug-Ökosystems 1 eine Absicherung von ausgetauschten Daten erreicht werden kann. So kann bspw. die Zielinstanz IZ1 die Daten DAT13 vor deren Übermittlung an die Zwischeninstanz IZ2 verschlüsseln, um sie auf diese Weise einem lesenden Zugriff durch die Zwischeninstanz IZ2 zu entziehen. In der Kombination mit der oben beschriebenen Delegierung der Authentifizierung der Daten DAT13 gegenüber der Zielinstanz IZ3 von der Quellinstanz IZ1 zu der Zwischeninstanz IZ2 entsteht dann der in Figur 3 schematisch dargestellt Ablauf.

Als spezielle Ausprägung des Verfahrens kann die Zielinstanz IZ3 mit einem asymmetrischen Entschlüsselungsverfahren AsymmDECR und einem dazu passenden asymmetrischen Schlüsselpaar (IZ3Pub, IZ3Priv) ausgestatten werden. Der private Schlüssel IZ3Priv wird in der Zielinstanz IZ3 sicher hinterlegt, die Quellinstanz IZ1 mit dem zu dem Entschlüsselungsverfahren AsymmDECR korrespondierenden asymmetrischen Verschlüsselungsverfahren AsymmENCR und dem öffentlichen Schlüssel IZ3Pub der Zielinstanz IZ3 ausgestattet und die von der Quellinstanz IZ1 an die Zielinstanz IZ3 zu übermittelnden Daten DAT13Plain werden vor deren Übermitteln an die Zielinstanz IZ3 mit dem öffentlichen Schlüssel IZ3Pub mittels des Verschlüsselungsverfahrens AsymmENCR direkt verschlüsselt. Alternativ dazu könnte zusätzlich die Quellinstanz IZ1 mit einem symmetrischen Verschlüsselungsverfahren SymmENCR und die Zielinstanz IZ3 mit dem zu dem Verschlüsselungsverfahren SymmENCR korrespondierenden symmetrischen Entschlüsselungsverfahren SymmDECR ausgestattet werden. Dann könnten die von der Quellinstanz IZ1 an die Zielinstanz IZ3 zu übermittelnden Daten DAT13Plain vor deren Versenden an die Zwischeninstanz IZ2 mit einem neu erzeugten sicheren, bspw. zufälligen, zu den Ver- und Entschlüsselungsverfahren SymmENCR/SymmDECR passenden symmetrischen Schlüssel, einem sog. Transportschlüssel, verschlüsselt werden. Es reicht dann aus, diesen neu erzeugten Transportschlüssel mit dem asymmetrischen öffentlichen Schlüssel IZ3Pub zu verschlüsseln und den so verschlüsselten Transportschlüssel als Teil der zu authentifizierenden Daten DAT13 an die Zwischeninstanz IZ2 mit zu übermitteln.

Unter der schon oben getätigten Annahme, dass sowohl AUTH12 als auch AUTH23 auf Authentifizierungstempeln, bspw. digitalen Signaturen oder MACs, basieren, also Authentifizierungstempel erzeugen und diese überprüfen, AUTH12_GEN bzw. AUTH23_GEN die zu AUTH12 bzw. AUTH23 gehörende Funktion zur Erzeugung von Authentifizierungstempeln bezeichnet, AUTH12_VER bzw. AUTH23_VER die zu AUTH12 bzw. AUTH23 gehörende Funktion zur Prüfung (Verifikation) von Authentifizierungstempeln bezeichnet und sowohl AUTH12 als auch AUTH23 bereits das benötigte kryptographische Material implizit enthalten, das benötigte kryptographische Material also nicht explizit als Parameter ausgewiesen wird, besteht die zweite Variante des vorgeschlagenen Verfahrens, also die Variante mit der Nutzung eines symmetrischen Transportschlüssels, aus folgenden Schritten:

• In der Quellinstanz IZ1 :

■ Wird mit Hilfe eines sicheren Verfahrens ein neuer symmetrischer Transportschlüssel transpKey erzeugt;

■ Werden die zu versendenden Daten DAT13Plain mit SymmENCR unter Verwendung von transpKey verschlüsselt, also

DAT13ENCR := SymmENCR(transpKey, DAT13Plain); ■ Wird der Transportschlüssel transpKey asymmetrisch mit AsymmENCR unter Verwendung von IZ3Pub verschlüsselt, also transpKeyENCR := AsymmENCR(IZ3Pub, transpKey);

■ Werden die für IZ3 bestimmten zu übermittelten Daten DAT13 als die Kombination von DAT13ENCR und transpKeyENCR gebildet, also DAT13 := (DAT13ENCR, transpKeyENCR);

■ Wird der Authentifizierungsstempel AuthSt12 der zu übermittelnden Daten DAT13 mit AUTH12_GEN berechnet, also

AuthSt12 := AUTH12_GEN (DAT13);

■ Wird die Nachricht (DAT13, AuthSt12) an IZ2 übermittelt.

• In der authentifizierenden Zwischeninstanz IZ2, nach dem Empfang von (DAT13, AuthSt12)):

■ Wird die Korrektheit des empfangenen Authentifizierungsstempels AuthSt12 der empfangenen Daten DAT13 mit AUTH12_GEN geprüft, also der boolesche Wert AUTH12_VER(DAT13, AuthSt12) berechnet;

■ Fällt die Prüfung positiv aus, wird der Authentifizierungsstempel AuthSt23 der Kombination der Daten DAT13 und der Identitätskennung IZ1_ID von IZ1 , also von (DAT13, IZ1JD) mit AUTH23_GEN berechnet, also

AuthSt23 := AUTH23_GEN((DAT13, IZ1_I D)), andernfalls wird eine Sonderbehandlung eingeleitet;

■ Es wird die Nachricht (DAT13, IZ1_ID, AuthSt23) an IZ3 übermittelt.

• In der Zielinstanz IZ3, nach dem Empfang von (DAT13, IZ1_ID, AuthSt23):

■ Wird die Korrektheit des empfangenen Authentifizierungsstempels AuthSt23 der empfangenen Daten (DAT13, IZ1_ID) mit AUTH23_VER geprüft, also der boolesche Wert AUTH23_VER((DAT13, IZ1JD), AuthSt23) berechnet;

■ Fällt die Prüfung positiv aus, werden aus DAT13 die beiden Bestandteile DAT13ENCR und transpKeyENCR extrahiert, andernfalls wird eine Sonderbehandlung eingeleitet;

■ Mit Hilfe des privaten Schlüssels IZ3Priv wird transpKeyENCR entschlüsselt und dadurch der Transportschlüssel transpKey ermittelt, also transpKey := AsymmDECR(IZ3Priv, transpKeyENCR);

■ Mit Hilfe des Transportschlüssels transpKey wird DAT13ENCR entschlüsselt und dadurch die Nutzdaten DAT13Plain ermittelt, also

DAT13Plain := SymmDECR(transpKey, DAT13ENCR); ■ Es wird davon ausgegangen, dass die Daten DAT13Plain von IZ1 stammen und die Daten DAT13Plain werden entsprechend genutzt.

In der beschriebenen mit einer Verschlüsselung versehenen Variante des Verfahrens wird die Quellinstanz IZ1 mit dem öffentlichen Schlüssel IZ3Pub der Zielinstanz IZ3 ausgestattet. Wird dieser öffentliche Schlüssel IZ3Pub als reiner Schlüssel und nicht als Zertifikat hinterlegt, so muss das Einbringen dieses Schlüssels auf eine sichere Weise erfolgen, insb. muss sichergestellt sein, dass der Quellinstant IZ1 bekannt ist, dass der Schlüssel IZ3Pub zu der Zielinstanz IZ3 gehört und sowohl diese Information als auch der Schlüssel IZ3Pub selbst müssen in der Quellinstanz IZ1 gegen Manipulation geschützt sein. Diese Anforderungen können relativ gut bei der initialen Ausstattung der Quellinstanz IZ1 mit Kryptomaterial erfüllt werden, sie erschweren jedoch das dynamische Einbringen solcher Schlüssel, insbesondere das Einbringen von zu weiteren Kommunikationspartnern gehörenden öffentlichen Schlüsseln, während der Laufzeit signifikant.

Es kann daher sinnvoll sein, innerhalb des Fahrzeug-Ökosystems 1 eine Verschlüsselungs-Zertifizierungsstelle ENCR-CA für asymmetrische öffentliche Verschlüsselungsschlüssel enthaltende Blattzertifikate einzurichten. Das Wurzelzertifikat EncrRootCert dieser Zertifizierungsstelle ENCR-CA enthält den öffentlichen Schlüssel EncrRootPub der Zertifizierungsstelle ENCR-CA, der dazu genutzt werden kann, die Korrektheit der die eigentlichen Verschlüsselungsschlüssel EncrlndPub enthaltenden Blattzertifikate EncrlndCert und damit insbesondere die Herkunft bzw. die Zugehörigkeit der Verschlüsselungsschlüssel EncrlndPub zu den jeweiligen Zielinstanzen zu überprüfen. Weil die von der Zertifizierungsstelle ENCR-CA ausgestellten Blattzertifikate Verschlüsselungsschlüssel enthalten, werden diese Blattzertifikate nachfolgend auch als Verschlüsselungszertifikate bezeichnet.

Die Figur 4 zeigt das Provisioning der Instanzen IZi eines beispielhaften Fahrzeug- Ökosystems 1 , welches mit einer Zertifizierungsstelle ENCR-CA und einem Zertifizierungsservice Cert-Service, der von einem Drittsystem implementiert wird und zur Verteilung der von der der Zertifizierungsstelle ENCR-CA ausgestellten Blattzertifikate genutzt wird, ausgestattet ist. Dabei wird angenommen, dass für alle Zielinstanzen IZ3 (BEModulX, BEModulY, ExtGerA) dieselbe Zertifizierungsstelle ENCR-CA genutzt wird. Außerdem zeigt die Figur 4 den Zustand der einzelnen Instanzen IZi nach deren Ausstattung mit Endorsement-Kryptomaterial, also mit individuellen privaten Endorsement-Schlüsseln, individuellen Endorsement-Zertifikaten, Wurzel-Endorsement- Zertifikaten etc. Dabei wird angenommen, dass die individuellen Endorsement-Zertifikate für alle authentifizierenden Instanzen IZ2 (ExtGer2, ExtGerß, TCU) von derselben Endorsement-Zertifizierungsstelle END-CA ausgestellt werden, also mit demselben privaten Wurzelschlüssel EndRootPriv signiert sind.

Um nun alle Instanzen IZ1 , IZ2, IZ3 mit den benötigten Zertifikaten auszustatten, wird der Systemaufbau so gestaltet, dass Innerhalb des Fahrzeug-Ökosystems eine auf einem asymmetrischen Schlüsselpaar (EncrRootPub, EncrRootPriv) basierende Verschlüsselungs-Zertifizierungsstelle ENCR-CA eingerichtet wird. Die Verschlüsselungs-Zertifizierungsstelle ENCR-CA wird mit einer abgesicherten Schnittstelle GENCERT ausgestattet, die das Ausstellen von Blattzertifikaten EncrlndCertlZ3 für zu Zielinstanzen IZ3 gehörende individuelle öffentliche Schlüssel EncrlndPublZ3 ermöglicht, wobei die in den Blattzertifikaten enthaltenen öffentlichen Schlüssel EncrlndPublZ3 sich zum asymmetrischen Verschlüsseln mittels des asymmetrischen Verschlüsselungsverfahrens AsymmENCR und die korrespondierenden privaten Schlüssel EncrlndPrivlZ3 sich zum Entschlüsseln mittels des asymmetrischen Entschlüsselungsverfahrens AsymmDECR eignen.

Alle von der Verschlüsselungs-Zertifizierungsstelle ENCR-CA für Zielinstanzen IZ3 ausgestellte Blattzertifikate werden in der Verschlüsselungs-Zertifizierungsstelle ENCR- CA oder in einem mit der Verschlüsselungs-Zertifizierungsstelle ENCR-CA verbundenem Drittsystem abgelegt bzw. aufbewahrt. Eine (nicht notwendigerweise abgesicherte) Abholschnittstelle GETCERT wird eingerichtet, über die Quellinstanzen IZ1 für die Zielinstanzen IZ3 ausgestellte Blattzertifikate direkt von der Verschlüsselungs- Zertifizierungsstelle ENCR-CA oder von dem die Blattzertifikate aufbewahrenden Drittsystem herunterladen bzw. abholen können. Wie oben schon angedeutet, ist es dabei so, dass die Abholschnittstelle GETCERT nicht abgesichert werden muss, da die Blattzertifikate gegen Manipulation durch eine Signatur mit EncrRootPriv geschützt sind und die in den Zertifikaten enthaltenen Informationen i.d.R. nicht vertraulich, also öffentlich, sind. Des Weiteren ist es vorgesehen, alle Zielinstanzen IZ3 des Fahrzeug-Ökosystems 1 mit einem individuellen asymmetrischen für die Verschlüsselung bzw. Entschlüsselung geeigneten asymmetrischen Schlüsselpaar (EncrlndPublZ3, EncrlndPrivlZ3) auszustatten und den privaten Schlüssel EncrlndPrivlZ3 gegen unberechtigtes Lesen geschützt in den Zielinstanzen IZ3 zu hinterlegen. Dafür wird für alle Zielinstanzen IZ3 des Fahrzeug-Ökosystems 1 von der Verschlüsselungs-Zertifizierungsstelle ENCR-CA unter Ausnutzung der abgesicherten Schnittstelle GENCERT initial ein (mit EncrRootPriv signiertes) den individuellen öffentlichen Schlüssel EncrlndPublZ3 enthaltendes individuelles Zertifikat ausgestellt und/oder die Zielinstanzen IZ3 werden mit der Möglichkeit ausgestattet, sich solche Zertifikate zur Laufzeit von der Verschlüsselungs- Zertifizierungsstelle ENCR-CA unter Ausnutzung von GENCERT ausstellen zu lassen.

Alle Quellinstanzen IZ1 des Fahrzeug-Ökosystems 1 werden nun (initial oder zur Laufzeit) auf eine sichere Weise mit dem öffentlichen Schlüssel EncrRootPub der Verschlüsselungs-Zertifizierungsstelle ENCR-CA ausgestattet und legen diesen in der jeweiligen Quellinstanz IZ1 manipulationssicher als Vertrauensanker für die von der Verschlüsselungs-Zertifizierungsstelle ENCR-CA ausgestellten Blattzertifikate (Verschlüsselungszertifikate) ab. Ferner ist es vorgesehen, alle Quellinstanzen IZ1 des Fahrzeug-Ökosystems 1 mit der Möglichkeit auszustatten, von der Verschlüsselungs- Zertifizierungsstelle ENCR-CA oder dem Drittsystem die dort abgelegten benötigten oder zusätzlich benötigten Blattzertifikate der Zielinstanzen IZ3 dynamisch, also zur Laufzeit, abzuholen bzw. zu erhalten.

Im Betrieb ist der Ablauf dann so, dass jede Zielinstanz IZ3, welche von Quellinstanzen IZ1 verschlüsselte Daten empfangen und entschlüsseln will und deren Verschlüsselungszertifikat EncrlndCertlZ3 noch nicht in der Verschlüsselungs- Zertifizierungsstelle ENCR-CA oder in dem die Verschlüsselungszertifikate aufbewahrenden Drittsystem vorliegt, über die abgesicherte Schnittstelle GENCERT die Erzeugung eines Verschlüsselungszertifikats EncrlndCertlZ3 durch die Verschlüsselungs-Zertifizierungsstelle ENCR-CA und dessen Ablage in der Verschlüsselungs-Zertifizierungsstelle ENCR-CA oder dem Drittsystem veranlasst.

Jede Quellinstanz IZ1 , die Daten DAT 13Plain verschlüsselt an eine Zielinstanz IZ3 senden will, führt folgende Schritte aus: • Falls das Verschlüsselungszertifikat der Zielinstanz IZ3 in der Quellinstanz IZ1 noch nicht vorliegt oder dieses Verschlüsselungszertifikat erneuert werden soll, lädt die Quellinstanz IZ1 das aktuelle Verschlüsselungszertifikat EncrlndCertlZ3 von der Verschlüsselungs-Zertifizierungsstelle ENCR-CA oder dem Drittsystem unter Ausnutzung der Abholschnittstelle GETCERT herunter.

• Die Quellinstanz IZ1 prüft die Korrektheit des heruntergeladenen Verschlüsselungszertifikats EncrlndCertlZ3 mit Hilfe des in der Quellinstanz IZ1 manipulationsgeschützt abgelegten öffentlichen Schlüssel EncrRootPub der Verschlüsselungs-Zertifizierungsstelle ENCR-CA, wobei der Schlüssel EncrRootPub (wie in Figur 4 dargestellt) auch Teil des Wurzelzertifikats EncrRootCert sein kann.

• Fällt die Prüfung des Verschlüsselungszertifikats EncrlndCertlZ3 positiv aus, wird der in dem Verschlüsselungszertifikat EncrlndCertlZ3 enthaltene öffentliche Schlüssel EncrlndPublZ3 der Zielinstanz IZ3 extrahiert und es wird gemäß dem weiter oben beschriebenen Verfahren mit Verschlüsselung fortgefahren, indem als der asymmetrische Schlüssel IZ3Pub der aus dem Verschlüsselungszertifikat EncrlndCertlZ3 extrahierte Schlüssel EncrlndPublZ3 genutzt wird. Fällt die Prüfung negativ aus, wird eine Sonderbehandlung eingeleitet.

Es ist zu beachten, dass das die Verschlüsselungszertifikate EncrlndCertlZ3 aufbewahrende Drittsystem mehrfach im Fahrzeug-Ökosystem 1 vorhanden sein kann, um den Quellinstanzen IZ1 das Abholen von Verschlüsselungszertifikaten EncrlndCertlZ3 möglichst komfortabel zu machen. Insbesondere kann eine alle oder einen Teil der verfügbaren Verschlüsselungszertifikate EncrlndCertlZ3 enthaltende Drittstelle bspw. in einem Fahrzeug-Steuergerät eingerichtet sein und damit den im gleichen Fahrzeug verbauten Steuergeräten ein besonders einfaches Abholen von Verschlüsselungszertifikaten EncrlndCertlZ3 ermöglichen.

Die obige Beschreibung des Verfahrens geht davon aus, dass die Verschlüsselungs- Zertifizierungsstelle ENCR-CA nur Wurzel- und Blattzertifikate, also keine Intermediate- Zertifikate, unterstützt. Das Verfahren kann aber auf eine offensichtliche Weise auf auf die Verschlüsselungs-Zertifizierungsstelle ENCR-CA zurückgehende Zertifikats ketten erweitert werden. In diesem Fall müssen bei der Generierung von Verschlüsselungszertifikaten EncrlndCertlZ3 mittels der abgesicherten Schnittstelle GENCERT ggf. noch Intermediate-Zertifikate erzeugt werden und beim Abholen von Verschlüsselungszertifikaten EncrlndCertlZ3 mittels der Abholschnittstelle GETCERT wird statt des einen Verschlüsselungszertifikats EncrlndCertlZ3 ggf. eine das Verschlüsselungszertifikat EncrlndCertlZ3 enthaltende Zertifikats kette zurückgeliefert, die dann komplett von der Zielinstanz IZ1 mittels des dort abgelegten öffentlichen Wurzelschlüssels EncrRootPub der Verschlüsselungs-Zertifizierungsstelle ENCR-CA überprüft wird.

Die Abholschnittstelle GETCERT, über die Verschlüsselungszertifikate EncrlndCertlZ3 abgeholt werden können, kann auf vielfältige Weise umgesetzt werden. Insbesondere kann sie einen JSON Web Key (JWK) zurückliefernden Service implementieren, wie in RFC7517 beschrieben, der auch Zertifikatsketten beliebiger Länge zurückliefern kann.

Die für die Verschlüsselungs-Zertifizierungsstelle ENCR-CA angestellten Überlegungen lassen sich auch auf eine Endorsement-Zertifizierungsstelle END-CA übertragen, welche die Verwendung der oben angesprochenen Endorsement-Zertifikaten erleichtert.

Dafür wird eine Endorsement-Zertifizierungsstelle END-CA aufgesetzt. Dann erfolgt ein Ausstatten der Endorsement-authentifizierungsfähigen Instanzen bzw.

Zwischeninstanzen IZ2 (z.B. ExtGer2, ECLIß, TCU) mit einem individuellen asymmetrischen privaten Endorsement-Schlüssel EndlndPrivlZ2 und einem dazugehörigen individuellen von der Endorsement-Zertifizierungsstelle END-CA ausgestellten Endorsement-Zertifikat EndlndCertlZ2 (wie in der Figur 4 dargestellt) oder mit einer von der Endorsement-Zertifizierungsstelle END-CA ausgestellten

Zertifikats kette, deren Blattzertifikat zu EndlndPrivlZ2 korrespondiert (nicht in der Figur dargestellt).

Die Verschlüsselungs-Zertifizierungsstelle ENCR-CA wird aufgesetzt, indem ein asymmetrisches Schlüsselpaar (EncrRootPub, EncrRootPriv) generiert wird und ggf. (wie in der Figur 4 dargestellt) ein selbstsigniertes den öffentlichen Schlüssel EncrRootPub enthaltendes Wurzelzertifikat EncrRootCert erzeugt wird. Der öffentliche Wurzelschlüssel EndRootPub der Endorsement-Zertifizierungsstelle END-CA wird (bspw. initial bspw. als roher öffentlicher Schlüssel oder als diesen Schlüssel enthaltendes selbstsigniertes Wurzelzertifikat EndRootCert (wie in der Figur dargestellt)) an alle Zielinstanzen IZ3 (z.B. BEModulX, BEModulY, ExtGerA) verteilt, die mit Hilfe von privaten Endorsement-Schlüsseln erzeugte Signaturen prüfen können sollen und dort als Vertrauensanker manipulationssicher abgelegt.

Der öffentliche Wurzelschlüssel EncrRootPub der Verschlüsselungs-Zertifizierungsstelle ENCR-CA wird (bspw. initial, bspw. als roher öffentlicher Schlüssel oder als diesen Schlüssel enthaltendes selbstsigniertes Wurzelzertifikat EncrRootCert (wie in der Figur dargestellt)) an alle Quellinstanzen IZ1 (ExtGerl , ExtGer2, ExtGer3, ECLIa, ECLIß, TCU) verteilt, die mit Hilfe von in Verschlüsselungszertifikaten enthaltenen öffentlichen Schlüsseln verschlüsselte Daten an eine der Zielinstanzen IZ3 senden wollen.

Die individuellen privaten Endorsement-Schlüssel EndlndPrivlZ2 und die dazugehörigen Endorsement-Zertifikate EndlndCertlZ2 werden in bekannter Weise erzeugt und in die Zwischeninstanzen IZ2 eingebracht. Die Verschlüsselungszertifikate können bspw. erzeugt werden, indem (wie in der Figur dargestellt) jede der Zielinstanzen IZ3 ein individuelles Schlüsselpaar (EncrlndPublZ3, EncrlndPrivlZ3) erzeugt und anschließend einen den öffentlichen Schlüssel EncrlndPublZ3 enthaltenden Certificate Signing Request (CSR) EncrlndCSRIZ3 auf authentifizierte Weise, die in der Figur nicht dargestellt ist, unter Ausnutzung der Schnittstelle GENCERT der Verschlüsselungs- Zertifizierungsstelle ENCR-CA zukommen lässt, worauf diese aus dem Certificate Signing Request CSR ein individuelles Verschlüsselungszertifikat EncrlndCertlZ3 erzeugt oder alternativ (in der Figur nicht dargestellt) ein weiteres vertrauenswürdiges System, das die Verschlüsselungs-Zertifizierungsstelle ENCR-CA sein kann aber nicht muss, das individuelle Schlüsselpaar (EncrlndPublZ3, EncrlndPrivlZ3) erzeugt, den privaten Schlüssel EncrlndPrivlZ3 auf sichere Weise in die Zielinstanz IZ3 einbringt und einen den öffentlichen Schlüssel EncrlndPublZ3 enthaltenden Certificate Signing Request EncrlndCSRIZ3 auf authentifizierte Weise der Verschlüsselungs- Zertifizierungsstelle ENCR-CA zukommen lässt, worauf diese aus dem CSR ein individuelles Verschlüsselungszertifikat EncrlndCertlZ3 erzeugt. Die von der Verschlüsselungs-Zertifizierungsstelle ENCR-CA erzeugten Verschlüsselungszertifikate werden an den Verschlüsselungszertifikate-Verteilservice Cert-Service übertragen und dort abgelegt. Die Quellinstanzen IZ1 können so bei Bedarf vom Verschlüsselungszertifikate-Verteilservice Cert-Service unter Ausnutzung der Abholschnittstelle GETCERT die von ihnen benötigten Verschlüsselungszertifikate abholen bzw. herunterladen. Die oben dargelegten Überlegungen zu den Zertifikats ketten gelten analog auch für die die Endorsement-Zertifizierungsstelle betreffenden Überlegungen, die ebenfalls leicht auf Zertifikatsketten angepasst werden können.