DE102009053230A1

DE102009053230A1 - Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs

Info

Publication number: DE102009053230A1
Application number: DE200910053230
Authority: DE
Inventors: Josef Dr. Wagenhuber
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2009-11-06
Filing date: 2009-11-06
Publication date: 2011-05-12

Abstract

Die Erfindung betrifft ein Verfahren zur Autorisierung eines externen Systems (ES) auf einem Steuergerät (SG) eines Fahrzeugs, insbesondere eines Kraftfahrzeugs. In dem Verfahren sendet das externe System (ES) an das Steuergerät (SG) eine Dienste-Anfrage (SR) zur Ausführung von einem oder mehreren Diensten auf dem Steuergerät (SG). Anschließend generiert das Steuergerät (SG) einen Code (CH) und sendet eine Authentisierungs-Anforderungs-Nachricht (AREQ) umfassend den generierten Code (CH) an das externe System (ES), falls das Steuergerät (SG) den oder die Dienste gemäß der Dienste-Anfrage (SR) ausführen kann. Das externe System (ES) generiert daraufhin eine Authentisierungs-Antwort-Nachricht (ARES) und sendet diese an das Steuergerät (SG). Die Authentisierungs-Antwort-Nachricht enthält ein Autorisierungsticket (AT), welches unter Einbeziehung eines geheimen, einer zentralen Instanz zugeordneten Autorisierungsschlüssels (SBA) eines Autorisierungs-Schlüsselpaars aus dem geheimen Autorisierungsschlüssel (SBA) und einem öffentlichen Autorisierungsschlüssel (PBA) generiert ist, wobei das Autorisierungsticket (AT) mit dem öffentlichen Autorisierungsschlüssel erfolgreich verifizierbar ist. Des Weiteren enthält die Authentisierungs-Antwort-Nachricht eine Code-Antwort (RES), welche zumindest den an das externe System (ES) gesendeten Code (CH) enthält und unter Einbeziehung eines geheimen, dem externen System (ES) zugeordneten Authentisierungsschlüssels (SES) eines ...

Description

Die Erfindung betrifft ein Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, sowie ein entsprechendes Autorisierungssystem.
Zum Zugriff eines externen Systems, wie z. B. eines Diagnosegeräts, auf ein Steuergerät eines Fahrzeugs ist es aus dem Stand der Technik bekannt, dass Diagnosenachrichten zwischen externem System und Steuergerät ausgetauscht werden. Im Rahmen dieser Diagnosenachrichten erfolgt eine Authentisierung des externen Systems an dem Steuergerät mit Hilfe eines Schlüsselpaars aus einem geheimen und öffentlichen Schlüssel. Nach erfolgreicher Authentisierung können dann entsprechende Dienste durch das externe System auf dem Steuergerät ausgeführt werden. Diese Dienste können beispielsweise die Aktualisierung der Software des Steuergeräts, eine Reinitialisierung des Steuergeräts, das Einspielen von personalisierten Daten und dergleichen umfassen.
In herkömmlichen Authentisierungsverfahren erweist es sich als nachteilhaft, dass die Dienste, für deren Durchführung das externe System auf dem Steuergerät zu autorisieren ist, in der Regel nur grob über entsprechende Levels spezifiziert werden. Dabei muss für jeden Level sowohl ein geheimer Schlüssel im externen System sowie ein dazu passender öffentlicher Schlüssel im Steuergerät hinterlegt sein. Somit ist es zum einen nicht möglich, die Zugriffsrechte des externen Systems auf das Steuergerät im Fahrzeug feingranular zu steuern. Zum anderen muss eine Mehrzahl von Schlüsseln für die verschiedenen Levels sowohl im Steuergerät als auch im externen System gespeichert werden. Es ergibt sich ferner ein Sicherheitsrisiko dahingehend, dass zur Autorisierung zu verwendende geheime Schlüssel in dem externen System gespeichert sind.
Aufgabe der Erfindung ist es deshalb, eine einfache und sichere Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs zu schaffen.
Diese Aufgabe wird durch das Verfahren gemäß Patentanspruch 1 bzw. das Autorisierungssystem gemäß Patentanspruch 23 gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.
In dem erfindungsgemäßen Verfahren sendet in einem Schritt a) ein externes System an ein Steuergerät eine Dienste-Anfrage zur Ausführung von einem oder mehreren Diensten auf dem Steuergerät. Anschließend generiert das Steuergerät in einem Schritt b) einen Code und eine Authentisierungs-Anforderungs-Nachricht, welche den generierten Code umfasst. Unter einem von dem Steuergerät generierten Code ist dabei insbesondere eine durch das Steuergerät generierte Zufallszahl zu verstehen. Insbesondere stellt der Code eine Challenge im Rahmen eines Challenge-Response-Verfahrens dar, wobei die Response eine Ausführungsform der weiter unten beschriebenen Code-Antwort ist. Diese Authentisierungs-Anforderungs-Nachricht wird an das externe System gesendet, sofern das Steuergerät das oder die Dienste gemäß der Dienste-Anfrage ausführen kann. Dies wird vom Steuergerät überprüft. Sollten die Dienste nicht ausführbar sein, wird das Verfahren bereits in Schritt b) abgebrochen und eine Fehlermeldung von dem Steuergerät an das externe System übermittelt. Nach Empfang der Authentisierungs-Anforderungs-Nachricht generiert das externe System in einem Schritt c) eine Authentisierungs-Antwort-Nachricht und sendet diese an das Steuergerät. Diese Authentisierungs-Antwort-Nachricht enthält folgende Daten:

– ein Autorisierungsticket, welches unter Einbeziehung eines geheimen, einer zentralen Instanz zugeordneten Autorisierungs-Schlüssels eines Autorisierungs-Schlüsselpaars aus dem geheimen Autorisierungsschlüssel und einem öffentlichen Autorisierungsschlüssel generiert ist, wobei das Autorisierungsticket mit dem öffentlichen Autorisierungsschlüssel erfolgreich verifizierbar ist;
– eine Code-Antwort, welche zumindest den an das externe System gesendeten Code enthält und unter Einbeziehung eines geheimen, dem externen System zugeordneten Authentisierungsschlüssels eines Authentisierungs-Schlüsselpaars aus dem geheimen Authentisierungsschlüssel und einem öffentlichen Authentisierungsschlüssel generiert ist, wobei die Code-Antwort mit dem öffentlichen Authentisierungsschlüssel erfolgreich verifizierbar ist.

Unter einem geheimen Autorisierungsschlüssel im Sinne der Erfindung ist ein Schlüssel zu verstehen, auf den weder das externe System noch das Steuergerät Zugriff haben und der vorzugsweise nur der zentralen Instanz bekannt ist. Demgegenüber ist unter einem geheimen Authentisierungsschlüssel ein Schlüssel zu verstehen, auf den das Steuergerät keinen Zugriff hat und der vorzugsweise nur dem externen System bekannt ist.
Die Generierung des Autorisierungstickets bzw. der Code-Antwort unter Einbeziehung eines geheimen Autorisierungsschlüssels bzw. eines geheimen Authentisierungsschlüssels kann auf beliebige Art und Weise erfolgen. Entscheidend ist lediglich, dass die entsprechenden geheimen Schlüssel bei der Generierung mit einfließen. In einer Variante der Erfindung wird dies dadurch erreicht, dass das Autorisierungsticket bzw. die Code-Antwort mit dem entsprechenden geheimen Schlüssel signiert sind und diese Signatur über den zugeordneten öffentlichen Schlüssel des Schlüsselpaars erfolgreich verifizierbar ist. Statt einer Signatur kann gegebenenfalls auch eine Verschlüsselung des Autorisierungstickets bzw. der Code-Antwort mit dem geheimen Schlüssel erfolgen, wobei eine erfolgreiche Verifikation durch das Entschlüsseln der entsprechend verschlüsselten Daten mit dem zugeordneten öffentlichen Schlüssel des Schlüsselpaars erreicht wird.
Nach der Übermittlung der Authentisierungs-Antwort-Nachricht an das Steuergerät verifiziert das Steuergerät schließlich in einem Schritt d) das Autorisierungsticket und die Code-Antwort in der empfangenen Authentisierungs-Antwort-Nachricht, wobei hierfür entsprechende, in dem Steuergerät hinterlegte öffentliche Schlüssel verwendet werden. Sind eine oder mehrere Bedingungen erfüllt, welche zumindest die erfolgreiche Verifikation des Autorisierungstickets und der Code-Antwort umfassen, wird die Ausführung des oder der Dienste durch das Steuergerät zugelassen, wobei das Steuergerät bei Zulassung der Dienste vorzugsweise eine entsprechende Bestätigungsnachricht an das externe System sendet. Stimmen somit ein öffentlicher Schlüssel im Steuergerät mit dem öffentlichen Authentisierungsschlüssel und ein öffentlicher Schlüssel im Steuergerät mit dem öffentlichen Autorisierungsschlüssel überein, führt dies zu einer erfolgreichen Verifikation des Autorisierungstickets und der Code-Antwort, wobei dies eine notwendige Bedingung zur Autorisierung ist.
Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass neben einem geheimen, zur Authentisierung des externen Systems verwendeten Schlüssel ein geheimer Autorisierungsschlüssel eingesetzt wird, der einer zentralen Instanz zugeordnet ist und weder dem externen System noch dem Steuergerät bekannt ist. Hierdurch kann die Autorisierung durch die zentrale Instanz in geeigneter Weise überwacht und gesteuert werden kann. Die zentrale Instanz ist dabei vorzugsweise der Hersteller des Fahrzeugs, in dem das Steuergerät verbaut ist. Das externe System ist in einer bevorzugten Variante ein an das Steuergerät angeschlossenes Diagnosegerät, welches häufig auch als Tester bezeichnet wird und welches beispielsweise bei der Durchführung eines Fahrzeug-Service an das Steuergerät des Fahrzeugs angeschlossen wird. Das Steuergerät kann ein beliebiges Steuergerät im Fahrzeug sein, welches beliebige Komponenten im Fahrzeug, wie z. B. den Motor, elektrische Verbraucher und dergleichen, steuert. Ebenso kann ein durch das externe System auszuführender Dienst beliebig ausgestaltet sein. Insbesondere kann ein Dienst die Aktualisierung von Software auf dem Steuergerät, das Rücksetzen des Steuergeräts, das Reinitialisieren des Steuergeräts und dergleichen betreffen.
In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens spezifiziert die in Schritt a) an das Steuergerät übermittelte Dienste-Anfrage die auszuführenden Dienste über jeweilige Dienst-Identitäten, welche einen Dienst vorzugsweise eindeutig bezeichnen. Auf diese Weise kann feingranular die Autorisierung für vorbestimmte Dienste festgelegt werden. In einer weiteren, bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird dem Steuergerät ein Gerät-Identifikator zugewiesen, der dem externen System bekannt ist und/oder dem externen System als Teil der Authentisierungs-Anforderungs-Nachricht in Schritt b) mitgeteilt wird.
Vorzugsweise enthält das Autorisierungsticket einen oder mehrere Gerät-Identifikatoren und/oder Dienst-Identitäten, für welche das Autorisierungsticket gültig ist. Dabei wird in Schritt d) verifiziert, ob der Gerät-Identifikator des die Dienste-Anfrage empfangenden Steuergeräts und/oder die Dienst-Identität bzw. Dienst-Identitäten, welche in der Dienste-Anfrage spezifiziert sind, im Autorisierungsticket enthalten sind. Nur bei erfolgreicher Verifikation wird die Ausführung des oder der Dienste durch das Steuergerät zugelassen. Hierdurch kann in einfacher Weise über das Autorisierungsticket dediziert die Ausführung bestimmter Dienste auf bestimmten Steuergeräten zugelassen bzw. verweigert werden.
Der im Vorangegangenen beschriebene Gerät-Identifikator muss ein Steuergerät nicht eindeutig spezifizieren. Beispielsweise kann der Gerät-Identifikator einen Steuergeräte-Typ festlegen, so dass mit dem Autorisierungsticket entsprechende Dienste zur Ausführung auf allen Steuergeräten des entsprechenden Typs zugelassen werden können. Es besteht jedoch auch die Möglichkeit, dass ein Gerät-Identifikator eine eindeutige Identifikation des Steuergeräts und/oder des Fahrzeugs enthält, in dem das Steuergerät verbaut ist. Hierdurch wird eine besonders hohe Sicherheit bei der Autorisierung erreicht, da dediziert nur die Dienste-Ausführung für ein bestimmtes Steuergerät bzw. Fahrzeug autorisiert werden kann.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens enthält das Autorisierungsticket den in Schritt b) vom Steuergerät generierten Code, wobei in Schritt d) die Übereinstimmung des Codes im Autorisierungsticket mit dem vom Steuergerät generierten Code überprüft wird und wobei nur bei Vorliegen einer Übereinstimmung der Ausführung des oder der Dienste durch das Steuergerät zugelassen wird. Hierdurch wird eine besonders hohe Sicherheit bei der Autorisierung erreicht, da ein Autorisierungsticket immer an den während der Autorisierung generierten Code gekoppelt ist.
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens wird das Autorisierungsticket in Schritt c) generiert, und zwar indem durch das externe System eine Anforderungs-Nachricht an eine der zentralen Instanz zugeordnete Infrastruktur oder eine durch die zentrale Instanz autorisierte Infrastruktur übermittelt wird, wobei diese Infrastruktur anschließend das Autorisierungsticket erzeugt und an das externe System übermittelt. Diese Variante der Erfindung wird vorzugsweise mit der oben beschriebenen Ausführungsform kombiniert, bei der das Autorisierungsticket den vom Steuergerät generierten Code enthält. In diesem Fall enthält die Anforderungs-Nachricht diesen generierten Code, so dass der Code der Infrastruktur für die Generierung des Autorisierungstickets zur Verfügung steht.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens sind in dem externen System bereits vorab ein oder mehrere Autorisierungstickets hinterlegt, und in Schritt c) des erfindungsgemäßen Verfahrens wird durch das externe System nach einem hinterlegten Autorisierungsticket gesucht, welches für die an das Steuergerät zu sendende Authentisierungs-Antwort-Nachricht verwendbar ist, wobei ein Autorisierungsticket dann verwendbar ist, wenn das Ticket bzw. die darin enthaltenen Daten erfolgreich durch das Steuergerät verifiziert werden können. Dabei wird im Falle, dass ein verwendbares Authentisierungsticket gefunden wird, dieses Autorisierungsticket in die auszusendende Authentisierungs-Antwort-Nachricht eingefügt. In diesem Fall ist es bei der Durchführung des Verfahrens nicht erforderlich, dass auf die zentrale Instanz bzw. eine entsprechende Infrastruktur zur Autorisierung online zurückgegriffen werden muss. In der Variante der Erfindung, bei der die Autorisierungstickets entsprechende Gerät-Identifikatoren bzw. Dienst-Identitäten enthalten, wird in Schritt c) vorzugsweise nach Autorisierungstickets gesucht, deren enthaltene Gerät-Identifikatoren bzw. Dienst-Identitäten den Gerät-Identifikator des die Dienste-Anfrage empfangenden Steuergeräts und/oder die Dienstidentität oder die Dienst-Identitäten gemäß der Dienste-Anfrage umfassen.
In einer besonders bevorzugten Ausführungsform ist das Autorisierungsticket unmittelbar durch den der zentralen Instanz zugeordneten geheimen Autorisierungsschlüssel generiert, und zwar dadurch, dass das Autorisierungsticket mit dem geheimen Autorisierungsschlüssel signiert ist, der in einer der zentralen Instanz zugeordneten Infrastruktur hinterlegt ist.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens enthält das Autorisierungsticket ein Delegationsticket, welches mit dem geheimen Autorisierungsschlüssel der zentralen Instanz signiert ist und einen dem Delegationsticket zugeordneten öffentlichen Delegationsschlüssel umfasst, wobei das Autorisierungsticket mit einem geheimen Delegationsschlüssel des Delegationstickets signiert ist, wobei zur Verifikation des Autorisierungstickets die Signaturen basierend auf dem jeweiligen öffentlichen Delegations- oder Autorisierungsschlüssel überprüft werden, dessen geheimer Delegations- oder Autorisierungsschlüssel zum Signieren verwendet wurde, wobei bei einer erfolgreichen Überprüfung aller Signaturen das Autorisierungsticket erfolgreich verifiziert ist. Auf diese Weise wird die Autorisierung des Autorisierungstickets von der zentralen Instanz an eine Delegationsinstanz übertragen.
In einer weiteren Variante besteht auch die Möglichkeit, dass eine entsprechende Delegationsinstanz die Autorisierung an weitere Delegationsinstanzen überträgt, so dass bei der Verifikation eine Kette von Signaturen überprüft werden muss. In diesem Fall enthält das Autorisierungsticket eine Reihe von mehreren, aufeinander folgenden Autorisierungstickets, wobei das erste Delegationsticket der Reihe mit dem geheimen Autorisierungsschlüssel der zentralen Instanz signiert ist und einen dem ersten Delegationsticket zugeordneten öffentlichen Delegationsschlüssel enthält und wobei die restlichen Delegationstickets jeweils mit einem geheimen, dem vorhergehenden Delegationsticket zugeordneten Delegationsschlüssel signiert sind und jeweils einen dem Delegationsticket zugeordneten öffentlichen Delegationsschlüssel enthalten, wobei das Autorisierungsticket mit dem geheimen Delegationsschlüssel des letzten Delegationstickets signiert ist, wobei zur Verifikation des Autorisierungstickets die Signaturen basierend auf dem jeweiligen öffentlichen Delegations- oder Autorisierungsschlüssel überprüft werden, dessen geheimer Delegations- oder Autorisierungsschlüssel zum Signieren verwendet wurde, wobei bei einer erfolgreichen Überprüfung aller Signaturen das Autorisierungsticket erfolgreich autorisiert ist.
In einer weiteren Variante des erfindungsgemäßen Verfahrens wird der öffentliche Authentisierungsschlüssel, mit dem die Authentizität des externen Systems überprüft wird, innerhalb des Autorisierungstickets an das Steuergerät übermittelt. Alternativ oder zusätzlich besteht auch die Möglichkeit, dass der öffentliche Autorisierungsschlüssel des externen Systems mittels einer separaten Nachricht oder eines separaten Nachrichtenteils, insbesondere mittels eines Zertifikats, an das Steuergerät übermittelt wird. Die separate Nachricht oder der separate Nachrichtenteil kann dabei unter Einbeziehung des geheimen Autorisierungsschlüssels generiert sein und mit dem öffentlichen Autorisierungsschlüssel erfolgreich verifizierbar sein.
In einer weiteren Variante der Erfindung enthält die Dienste-Anfrage und/oder das Autorisierungsticket eine Identifikation des externen Systems, welches die Dienste-Anfrage in Schritt a) an das Steuergerät sendet. Hierdurch kann im Steuergerät protokolliert werden, welches externe System einen oder mehrere Dienste auf dem Steuergerät ausführen möchte.
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens, bei der Gerät-Identifikatoren und Dienst-Identitäten im Autorisierungsticket enthalten sind, umfasst das Autorisierungsticket eine Liste von Identifikationen von externen Systemen, welche berechtigt sind, die Dienste gemäß den in dem Autorisierungsticket enthaltenen Dienstidentitäten auf den Steuergeräten gemäß den im Autorisierungsticket enthaltenen Gerät-Identifikatoren auszuführen. Die Übermittlung dieser Information dient ebenfalls für Protokollierungszwecke.
In einer bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens wird in der Dienste-Anfrage oder durch das Steuergerät selbst festgelegt, ob im Verfahren ein neues Autorisierungsticket zu verwenden ist, wobei im Falle, dass ein neues Autorisierungsticket zu verwenden ist, in Schritt b) ein neues Autorisierungsticket generiert wird, d. h. es wird nicht auf gegebenenfalls im externen System bereits hinterlegte Autorisierungstickets zurückgegriffen.
In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens wird in der Dienste-Anfrage oder durch das Steuergerät selbst festgelegt, ob im Verfahren ein Sitzungsschlüssel zur gesicherten Kommunikation zwischen dem externen System und dem Steuergerät bei der Ausführung von Diensten zu verwenden ist, wobei im Falle, dass ein Sitzungsschlüssel zu verwenden ist, der Sitzungsschlüssel in Schritt d) generiert wird und an das externe System übermittelt wird.
Insbesondere wenn mehrere externe Systeme mit dem Steuergerät kommunizieren, können in dem erfindungsgemäßen Verfahren Sitzungsidentitäten zur Identifikation eines entsprechenden Autorisierungsvorgangs verwendet werden. Dabei wird die Sitzungsidentität in Schritt b) vom Steuergerät generiert, wobei diese Sitzungsidentität bei der Übermittlung von nachfolgenden Nachrichten zwischen Steuergerät und externem System mit übertragen wird, um hierdurch verschiedene Autorisierungsvorgänge voneinander zu unterscheiden.
Neben dem oben beschriebenen Verfahren umfasst die Erfindung ferner ein Autorisierungssystem umfassend ein externes System und ein Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, wobei das Autorisierungssystem derart ausgestaltet ist, dass jede Variante des oben beschriebenen Verfahrens durchführbar ist. Dabei kann in bestimmten Ausführungsformen auch die einer externen Instanz zugeordnete Infrastruktur bzw. eine Infrastruktur, an welche die Autorisierung durch die externe Instanz delegiert wurde, Bestandteil des Autorisierungssystems sein.
Die Erfindung betrifft darüber hinaus eine Einrichtung zur Ausführung von Diensten auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, wobei die Einrichtung als das externe System in dem erfindungsgemäßen Verfahren fungieren kann. Dabei umfasst die Einrichtung ein Mittel zum Aussenden einer Dienste-Anfrage zur Ausführung von einem oder mehreren Diensten an das Steuergerät sowie ein Mittel zum Generieren und Aussenden einer Autorisierungs-Antwort-Nachricht an das Steuergerät. Die Dienste-Anfrage und die Authentisierungs-Antwort-Nachricht wurden weiter oben bei der Beschreibung des erfindungsgemäßen Verfahrens definiert.
Die Erfindung umfasst des Weiteren ein Steuergerät für ein Fahrzeug, insbesondere ein Kraftfahrzeug, wobei das Steuergerät als das Steuergerät in dem erfindungsgemäßen Verfahren fungieren kann. Das Steuergerät umfasst dabei ein Mittel zum Generieren eines Codes und zum Aussenden einer Authentisierungs-Anforderungs-Nachricht sowie ein Mittel zum Verifizieren eines Autorisierungstickets und einer Code-Antwort in einer empfangenen Authentisierungs-Antwort-Nachricht. Der Code, die Authentisierungs-Anforderungs-Nachricht, das Authentisierungsticket und die Code-Antwort wurden weiter oben bei der Beschreibung des erfindungsgemäßen Verfahrens definiert.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten 1A und 1B detailliert beschrieben. Diese Figuren zeigen ein Ablaufdiagramm, welches die Generierung und den Austausch von Nachrichten zur Autorisierung eines externen Geräts an einem Steuergerät gemäß verschiedenen Varianten der Erfindung verdeutlichen.
In dem nachfolgend anhand von 1A und 1B beschriebenen Ausführungsbeispiel des erfindungsgemäßen Verfahrens erfolgt die Autorisierung eines externen Geräts ES zur Ausführung von Diensten auf einem Steuergerät SG eines Fahrzeugs. Das externe Gerät ES ist beispielsweise ein Diagnosegerät, welches insbesondere bei der Durchführung eines Fahrzeugservice in einer Werkstatt an das Fahrzeug und somit auch an Steuergeräte des Fahrzeugs angeschlossen wird. Dieses Diagnosegerät, welches auch als Tester bezeichnet wird, kann verschiedene Dienste auf entsprechenden Steuergeräten im Fahrzeug durchführen, wobei es sich bei den Steuergeräten um entsprechende elektronische Steuereinheiten im Fahrzeug handelt. Diese elektronischen Steuereinheiten können verschiedene Einheiten des Fahrzeugs, wie z. B. den Motor, das Fahrwerk, elektrische Steller, optische und akustische Einrichtungen und dergleichen, steuern. Ein auszuführender Dienst ist beispielsweise das Zurücksetzen oder die Reinitialisierung eines Steuergeräts oder die Übertragung von Daten an das Steuergerät, beispielsweise von personalisierten Daten. Ein Dienst kann insbesondere auch die Aktualisierung von Software auf einem entsprechenden Steuergerät betreffen. In der hier beschriebenen Ausführungsform der Erfindung ist an der Autorisierung unmittelbar eine dem Fahrzeughersteller zugeordnete Infrastruktur in der Form von einem oder mehreren Rechnern beteiligt, welche häufig auch als IT-Backend (IT = Informationstechnologie) bezeichnet wird und in 1A bzw. 1B mit dem Bezugszeichen BA bezeichnet ist.
Nachfolgend werden die einzelnen Schritte zur Autorisierung des externen Geräts ES an das Steuergerät SG erläutert, wobei in 1A und 1B optionale Schritte in mit „opt” bezeichneten Rechtecken wiedergegeben sind und alternative Schritte in mit „alt” bezeichneten Rechtecken wiedergegeben sind.
In Schritt S1 sendet das externe System ES, welches mit dem Steuergerät SG verbunden wurde, eine Dienste-Anfrage SR an das Steuergerät SG. Innerhalb dieser Anfrage sind die entsprechenden Dienste, welche das System ES auf dem Gerät SG durchführen möchte, über entsprechende Dienst-Identitäten spezifiziert. Neben den Dienst-Identitäten wird in der Dienste-Anfrage SR ferner durch entsprechende boolsche Variablen spezifiziert, ob bei der Ausführung der Dienste ein Sitzungsschlüssel erforderlich ist. Ein solcher Sitzungsschlüssel wird zur vertraulichen Kommunikation zwischen externem Gerät und Steuergerät benötigt, beispielsweise wenn im Rahmen der Dienste-Ausführung geheime bzw. personalisierte Informationen zwischen Steuergerät SG und externem Gerät ES übertragen werden. Ferner wird durch eine weitere boolsche Variable in der Dienste-Anfrage SR spezifiziert, ob im Rahmen der Autorisierung ein neues/frisches Autorisierungsticket zu erzeugen ist oder ob gegebenenfalls auf ein bereits im externen System ES hinterlegtes Autorisierungsticket zurückgegriffen werden kann. Als Datenformat für die in der Dienste-Anfrage SR enthaltenen Dienst-Identitäten wird ein vorzeichenloser, 16 Bit langer Ganzzahlwert verwendet. Die Dienste-Anfrage enthält darüber hinaus eine Identifikation des externen Geräts ES basierend auf einer dem externen System zugewiesenen logistischen Nummer mit der Datenstruktur authentificatorIdentifier, die einen 32 Bit langen Ganzzahlwert darstellt.
In Schritt S2 der 1A wird im Steuergerät SG überprüft, ob das Steuergerät die in der Dienste-Anfrage SR spezifizierten Dienste überhaupt unterstützt. Ist dies nicht der Fall, wird eine Fehlermeldung an das System ES zurückgegeben und das Verfahren beendet. Ansonsten wird in Schritt S3 überprüft, ob ein Sitzungsschlüssel im Rahmen eines auszuführenden Dienstes benötigt wird. Das Erfordernis eines Sitzungsschlüssels kann sich dabei entweder daraus ergeben, dass über die entsprechende boolsche Variable in der Dienste-Anfrage SR ein Sitzungsschlüssel angefordert wird und vom Steuergerät SG die Generierung eines Sitzungsschlüssels unterstützt wird, oder daraus, dass vom Steuergerät selbst die Verwendung eines Sitzungsschlüssels erzwungen wird. In beiden Fällen wird eine Variable so gesetzt, dass zu einem späteren Zeitpunkt im Verfahren der Sitzungsschlüssel generiert wird.
Im nächsten Schritt S4 wird vom Steuergerät SG ermittelt, ob die Erstellung eines neuen Autorisierungstickets AT erforderlich ist. Dies kann sich entweder daraus ergeben, dass in der entsprechenden boolschen Variablen in der Dienste-Anfrage SR die Erzeugung eines neuen Autorisierungstickets festgelegt ist und durch das Steuergerät unterstützt wird, oder daraus, dass die Erzeugung eines neuen Autorisierungstickets durch das Steuergerät SG erzwungen wird. In beiden Fällen wird eine Variable so gesetzt, dass zu einem späteren Zeitpunkt im Verfahren ein neues Autorisierungsticket AT erzeugt wird.
Im darauffolgenden, optionalen Schritt S5 wird eine Sitzungsidentität in der Form einer Sitzungsnummer vergeben, welche das anfragende externe System ES eindeutig unter allen verbundenen Systemen identifiziert. Das heißt, die Erzeugung einer Sitzungsidentität kommt dann in Betracht, wenn mehrere externe Geräte an dem Steuergerät SG angeschlossen sind. In diesem Fall ist das Steuergerät SG für die Verwaltung und Zuordnung von Informationen und Sitzungsnummern verantwortlich. Im nächsten Schritt S6 erzeugt das Steuergerät SG eine sog. Challenge CH, welche nachfolgend zur Authentisierung des externen Systems ES am Steuergerät SG genutzt wird. Bei der Challenge handelt es sich in der hier beschriebenen Ausführungsform um eine durch das Steuergerät SG generierte Zufallszahl.
Anschließend erfolgt die optionale Ausführung einer der alternativen Schritte S701, S702 oder S703. Die Ausführung dieser Schritte kommt immer dann in Betracht, wenn dem externen System ES ein entsprechender Identifikator des Steuergeräts SG noch nicht bekannt ist. Ein solcher Identifikator kann beispielsweise im Vorfeld vor der Durchführung des hier beschriebenen Authentisierungsverfahrens bei Anschluss des externen Systems an das Steuergerät bereits übermittelt worden sein. Ist dies nicht der Fall, erfolgt die Festlegung eines entsprechenden Identifikators, der in 1 mit eculd bezeichnet ist. In dem alternativen Schritt S701 setzt sich der Identifikator eculd aus der sog. SGBM-Nummer, welche den Typ des Steuergeräts SG spezifiziert und ein 32 Bit langer Binärwert ist, und einer verkürzten Fahrzeugidentifikationsnummer VIN in der Form einer siebenstelligen Zeichenkette zusammen. In dem alternativen Schritt S702 setzt sich der Identifikator eculd wiederum aus der SGBM-Nummer, jedoch nunmehr kombiniert mit der Steuergeräteseriennummer SN in der Form eines 80 Bit langen Binärwerts zusammen. Gemäß dem alternativen Schritt S703 kann der Identifikator eculd auch nur durch die SGBM-Nummer spezifiziert sein. Je nach Sicherheitsanforderung an das Verfahren kann somit ein geeigneter Identifikator festgelegt werden. Wird beispielsweise lediglich die SGBM-Nummer verwendet, so kann die Autorisierung für eine größere Menge von Steuergeräten vom gleichen Typ eingesetzt werden. Demgegenüber ist bei anderen Varianten von Identifikatoren die Authentisierung auf ein bestimmtes Fahrzeug bzw. ein bestimmtes Steuergerät beschränkt.
In einem nächsten Schritt S8 wird schließlich eine Authentisierungs-Anforderungs-Nachricht AREQ von dem Steuergerät SG an das externe System ES gesendet. Diese Nachricht enthält die generierte Challenge CH sowie entsprechende boolsche Variablen, welche spezifizieren, ob ein Sitzungsschlüssel erforderlich ist bzw. die Herstellung eines neuen Autorisierungstickets notwendig ist. Darüber hinaus unterstützt die hier beschriebene Ausführungsform der Erfindung zwei verschiedene Arten von Autorisierungstickets. Die eine Art von Autorisierungstickets wird hier als compactAA und die andere Art als splittedAA bezeichnet, wobei die Unterschiede zwischen diesen beiden Arten weiter unten beschrieben werden. Durch eine entsprechende boolsche Variablen wird dabei in der Authentisierungs-Anforderungs-Nachricht AREQ festgelegt, welche Arten von Authentisierungstickets durch das Steuergerät unterstützt werden. Gegebenenfalls können auch beide Arten von Authentisierungstickets unterstützt werden. Optional enthält die Authentisierungs-Anforderungs-Nachricht AREQ ferner die in den alternativen Schritten S701 bzw. S702 bzw. S703 bestimmte Steuergerät-Identität eculd. Ebenso enthält die Nachricht AREQ optional die Sitzungsidentität, sofern diese in Schritt S5 generiert wurde.
Nach Empfang der Nachricht AREQ im externen System ES erzeugt das System eine entsprechende Antwort RES auf die in der Nachricht AREQ enthaltene Challenge CH. Hierfür wird ein geheimer, dem externen System ES zugeordneter Schlüssel SES verwendet, der nur dem externen System bekannt ist. Durch einen zu dem geheimen Schlüssel SES gehörigen öffentlichen Schlüssel PES, der weiter unten beschrieben wird, kann dann zu einem späteren Zeitpunkt des Verfahrens aus der Antwort RES die Challenge CH im Steuergerät SG rückgerechnet werden und hierdurch das externe System ES authentisiert werden. In einer Variante des Verfahrens wird die Antwort RES dadurch erzeugt, dass die Challenge CH, gegebenenfalls in Kombination mit der zuvor generierten Sitzungsidentität, mit dem geheimen Schlüssel SES signiert wird. Gegebenenfalls kann die Challenge CH jedoch auch mit dem geheimen Schlüssel kryptographisch verschlüsselt werden, wobei eine Entschlüsselung über den entsprechenden öffentlichen Schlüssel PES durchgeführt werden kann.
Das hier beschriebene Verfahren zeichnet sich dadurch aus, dass neben einer Authentisierung des Geräts ES ferner eine Autorisierung zur Durchführung der über der Anfrage SR spezifizierten Dienste unmittelbar oder mittelbar unter Einbeziehung der Infrastruktur einer zentralen Instanz erfolgt. Diese Infrastruktur entspricht in 1A und 1B dem IT-Backend BA des Fahrzeugherstellers. Diese Autorisierung erfolgt über das bereits oben erwähnte Autorisierungsticket AT, wobei die Bereitstellung dieses Ticket entweder basierend auf dem Schritt S1001 oder basierend auf einem der Schritte S1002 oder S1003 erfolgt. Die Bereitstellung basierend auf Schritt S1001 wird dann gewählt, wenn das Autorisierungsticket nur einmal zur Autorisierung der Dienste verwendet werden soll. Diese Variante kommt dann zum Einsatz, wenn in der Authentisierungs-Anforderungs-Nachricht AREQ durch die entsprechende boolsche Variable spezifiziert wurde, dass ein frisches Authentisierungsticket zu erstellen ist. Gemäß Schritt S1001 wird von dem externen System ES eine Nachricht zum Anfordern eines Authentisierungstickets AT an das Backend BA des Fahrzeugherstellers übermittelt, wobei diese Nachricht die zuvor generierte Challenge CH enthält. Schließlich wird im Backend BA das Authentisierungsticket AT neu generiert und anschließend an das externe System ES übermittelt.
Das Autorisierungsticket ist dabei mit einem geheimen bzw. privaten Schlüssel SBA signiert, wobei dieser geheime Schlüssel eindeutig dem Fahrzeughersteller zugeordnet ist und weder dem Steuergerät SG noch dem externen System ES bekannt ist. Auf diese Weise wird in der hier beschriebenen Ausführungsform sichergestellt, dass eine Autorisierung zur Durchführung der entsprechenden Dienste nur durch das IT-Backend BA des Fahrzeugherstellers erteilt werden kann. Basierend auf dem Autorisierungsticket wird einem externen System das Recht erteilt, bestimmte Aktionen auf dem Steuergerät durchzuführen. Die Überprüfung der Autorisierung erfolgt zu einem späteren Zeitpunkt des Verfahrens durch das Steuergerät SG mit Hilfe eines entsprechenden öffentlichen Schlüssels PBA, der eindeutig dem Fahrzeughersteller zuordenbar ist und mit dem die Signatur des Authentisierungstickets als gültig verifiziert werden kann. Der genaue Aufbau des Autorisierungstickets AT wird weiter unten noch näher beschrieben. Bei der Durchführung des Schritts S1001 ist zu berücksichtigen, dass das Autorisierungsticket AT unter Einbeziehung der Challenge CH generiert wird, die an das Backend-System BA übermittelt wurde. Das heißt, die Challenge wird in das Autorisierungsticket als dessen Bestanteil aufgenommen. Hierdurch ist das Ticket nur einmal für einen Autorisierungsvorgang verwendbar, da die Challenge eine nicht reproduzierbare Zufallszahl ist.
Alternativ zu Schritt S1001 kann das Autorisierungsticket gemäß Schritt S1002 bzw. S1003 auch ohne Einbeziehung der Challenge CH generiert sein. Der Schritt S1002 bzw. S1003 wird dabei immer dann durchgeführt, wenn die Erzeugung eines frischen Autorisierungstickets nicht erforderlich ist. In Schritt S1002 wird das Autorisierungsticket ohne Einbeziehung der Challenge CH angefordert und im Backend BA generiert. Das Ticket ist dabei mit dem geheimen Schlüssel SBA des Fahrzeugherstellers signiert. Da das Ticket AT nunmehr nicht mehr an die Challenge CH gekoppelt ist, kann es gegebenenfalls noch in späteren Autorisierungsvorgängen verwendet werden. Alternativ zu Schritt S1002 kann ein entsprechendes Autorisierungsticket AT auch ohne unmittelbare Zwischenschaltung des IT-Backends BA bereitgestellt werden. In diesem Fall werden zuvor auf dem externen System ES hinterlegte Autorisierungstickets AT durchsucht. Dabei werden entsprechende Spezifikationen in dem Autorisierungsticket dahingehend überprüft, ob sich das jeweilige Ticket zur Verwendung für den Autorisierungsvorgang eignet. Wird ein passendes Ticket gefunden, kann dieses Ticket zur Autorisierung eingesetzt werden, ohne dass eine Verbindung zum Backend BA herzustellen ist. In Analogie zu den oben beschriebenen, vom Backend BA angeforderten Autorisierungstickets sind die Autorisierungstickets wiederum mit dem geheimen, nur dem Fahrzeughersteller bekannten Schlüssel SBA signiert.
Nach der Generierung bzw. Bereitstellung des Autorisierungstickets AT wird dieses Ticket schließlich in Schritt S11 der 1B als Bestandteil einer Authentisierungs-Antwort-Nachricht ARES an das Steuergerät SG übermittelt. Die Authentisierungs-Antwort-Nachricht ARES enthält dabei neben dem Autorisierungsticket AT die in Schritt S9 generierte Antwort RES sowie optional die Sitzungsidentität, sofern diese in Schritt S5 erzeugt wurde.
Im Folgenden wird nunmehr die Datenstruktur des Autorisierungstickets AT erläutert. Zunächst wird die bereits oben erwähnte Datenstruktur compactAA beschrieben. Mit dieser Art von Autorisierungsticket wird innerhalb des Tickets auch der öffentliche Schlüssel PES des externen Systems ES übermittelt, der später zur Authentisierung des externen Systems ES genutzt wird. Die Datenstruktur compactAA des Autorisierungstickets besteht aus drei elementaren Datenfeldern, welche im Folgenden als token, tokenSignature und delegation bezeichnet werden. Die eigentlichen Authentisierungsinformationen sind in token enthalten. tokenSignature entspricht der Signatur über alle Daten in token, wobei diese Signatur mit dem geheimen Schlüssel SBA generiert wird und vom Typ signature ist, der ein 32 bis 256 Byte langes Binärdatenfeld darstellt. Das Datenfeld delegation ist optional und bezeichnet die Datenstruktur des weiter unten beschriebenen Delegationstickets, über welches eine Kette von Berechtigungsdelegationen abbildbar ist.

Die Authentisierungsinformationen in token bestehen aus folgenden Teilen:

– validEculds:	eine Liste aller Steuergerät-Identifikatoren eculds, für welche
	das Autorisierungsticket gültig ist;
– allowedServices:	eine Liste aller Dienst-Identitäten, für welche das externe
	System ES durch das Autorisierungsticket AT autorisiert
	wird;
– publicKeyExt:	der öffentliche Schlüssel bzw. Schlüsselanteil PES des ex-
	ternen Systems ES in der Form eines zwischen 32 und 256
	Byte langen Binärdatenfelds;
– authenticator:	eine Identität des externen Systems ES basierend auf der
	oben erwähnten Datenstruktur AuthenticatorIdentifier, wobei
	die Verwendung dieser Variablen optional ist und nur zum
	Zwecke der Protokollierung im Steuergerät verwendet wird;
– expiryDate:	ein Datum zur Gültigkeitsbeschränkung des Tickets, forma-
	tiert in koordinierter Weltzeit, wobei auch diese Variable op-
	tional ist;
– challenge:	die bereits oben beschriebene Challenge CH, wobei diese
	Variable ebenfalls optional ist und nur dann verwendet wird,
	wenn das Autorisierungsticket basierend auf dem Schritt
	S1001 generiert wird.

Im Unterschied zum Autorisierungsticket basierend auf der Datenstruktur compactAA wird in dem Autorisierungsticket splittedAA nicht der öffentliche Schlüssel PES des externen Systems ES übertragen. Die Übertragung dieses Schlüssels erfolgt bei der Datenstruktur splittedAA in einem separaten Schlüsselzertifikat, welches weiter unten beschrieben wird.
In der Datenstruktur splittedAA werden Autorisierungsdaten in dem Datenfeld assertion geführt. Neben einer Signatur assertionSignature über alle Daten in assertion, welche mit dem geheimen Schlüssel SBA generiert ist, und einer optionalen Berechtigungsdelegation delegation wird der öffentliche Schlüssel PES des externen Systems – wie oben erwähnt – separat in der Datenstruktur authenticatorCertificate gespeichert.

Das Datenfeld assertion besteht aus folgenden Bestandteilen:

– validEculds:	eine Liste aller Steuergeräte, für welche das Autorisierungs-
	ticket gültig ist;
– allowedServices:	eine Liste aller Dienst-Identitäten, für welche das externe
	System durch das Autorisierungsticket autorisiert ist;
– allowedOperators:	eine optionale Liste aller externen Systeme, die berechtigt
	sind, die Dienste gemäß dem Datenfeld allowedServices auf
	den Steuergeräten gemäß dem Datenfeld validEculds aus-
	zuführen (sollte dieses Datenfeld nicht verwendet werden,
	handelt es sich um ein Autorisierungsticket ohne Identitäts-
	bindung);
– expiryDate:	ein Datum zur Gültigkeitsbeschränkung des Tickets, forma-
	tiert in koordinierter Weltzeit, wobei auch diese Variable op-
	tional ist;
– challenge:	die bereits oben beschriebene Challenge CH, wobei diese
	Variable ebenfalls optional ist und nur dann verwendet wird,
	wenn das Autorisierungsticket basierend auf dem Schritt
	S1001 generiert wird.

Wie bereits oben erwähnt, wird in der Datenstruktur splittedAA der öffentliche Schlüssel PES des externen Systems ES nicht übertragen, sondern in einem separaten Schlüsselzertifikat übermittelt. Dieses Schlüsselzertifikat kann getrennt oder als Teil der Authentisierungs-Antwort-Nachricht ARES übersendet werden. Das Zertifikat wird von der zentralen Instanz in der Form des Fahrzeugherstellers erstellt und ist mit dem geheimen Schlüssel SBA des Fahrzeugherstellers signiert. Insbesondere enthält dieses Schlüsselzertifikat folgende Datenfelder:

– publicKey:	den öffentlichen Schlüssel PES des externen Systems ES;
– identifier:	die Identität des externen Systems vom Typ authenticatorIdentifier,
	dem der Schlüssel PES gemäß dem Datenfeld publicKey zugeord-
	net ist, wobei dieses Datenfeld optional ist;
– expiryDate:	ein Datum zur Gültigkeitsbeschränkung des Zertifikats, welches in
	koordinierter Weltzeit formatiert ist, wobei dieses Datenfeld optional
	ist;
– issuer:	die Identität des Ausstellers des vorliegenden Zertifikats vom Typ
	authenticatorIdentifier, wobei dieses Datenfeld optional ist;
– signature:	die Signatur über die Datenfelder publicKey, identifier, expiryDate
	und issuer, wobei diese Signatur vom Typ signature ist und mit dem
	privaten Schlüssel SBA des Fahrzeugherstellers erstellt ist.

Nach dem Übermitteln des Autorisierungstickets als Teil der Nachricht ARES wird gemäß 1B im optionalen Schritt S12 überprüft, ob die Sitzungsidentität gültig ist, sofern die Nachricht ARES eine Sitzungsidentität enthält. Schließlich erfolgt in Schritt S13 die Verifikation des an das Steuergerät SG übermittelten Autorisierungstickets AT mit dem öffentlichen Schlüssel PBA des Fahrzeugherstellers, der im Steuergerät SG hinterlegt ist. Ist die Verifikation erfolgreich, wird in Schritt S14 ferner die in Schritt S9 generierte und zusammen mit der Authentisierungs-Antwort-Nachricht ARES übermittelte Antwort RES mit dem öffentlichen Schlüssel PES des externen Systems ES verifiziert. Ist auch diese Verifikation erfolgreich, wird in Schritt S15 überprüft, ob die im Autorisierungsticket enthaltenen Dienste gemäß dem Datenfeld allowedServices gültig sind, d. h. ob die Dienste auf dem Steuergerät SG ausführbar sind. Bei erfolgreicher Verifikation wird in Schritt S16 analog für die im Autorisierungsticket enthaltenen Steuergerätenummern SGBM überprüft, ob sie für das Steuergerät SG gültig sind, d. h. ob die Steuergerätenummer des Geräts SG einer Nummer im Autorisierungsticket AT entspricht.
Anschließend werden optional die Schritte S17 bis S21 durchgeführt. Der Schritt S17 wird dann aufgerufen, wenn als Identifikator eculd des Steuergeräts die Variante gemäß Schritt S701 basierend auf einer Identifikation VIN des Fahrzeugs gewählt wurde. In diesem Fall wird in Schritt S17 überprüft, ob die im Autorisierungsticket AT enthaltene Fahrzeug-Identifikation VIN mit der Identifikation des Fahrzeugs übereinstimmt, in dem das Steuergerät SG verbaut ist. Der Schritt S18 wird dann durchgeführt, wenn als Identifikator eculd des Steuergeräts die Variante gemäß Schritt S702 basierend auf der Seriennummer SN des Steuergeräts gewählt wurde. In diesem Fall wird überprüft, ob die Seriennummer SN in dem Autorisierungsticket AT mit der Seriennummer des Steuergeräts SG übereinstimmt. Im optionalen Schritt S19, der immer dann durchgeführt wird, wenn im Autorisierungsticket AT die Challenge CH mit enthalten ist, wird überprüft, ob diese Challenge mit der ursprünglich vom Steuergerät SG generierten Challenge übereinstimmt. Im optionalen Schritt S20, der im Falle einer Gültigkeitsbeschränkung des Autorisierungstickets AT durchgeführt wird, erfolgt eine Überprüfung dahingehend, ob das Autorisierungsticket abgelaufen ist. Schließlich kann noch der optionale Schritt S21 durchgeführt werden, sofern zuvor festgelegt wurde, dass für eine nachfolgende Kommunikation zwischen externem System ES und Steuergerät SG Sitzungsschlüssel zu verwenden sind. In diesem Fall wird im Rahmen des Schritts S21 ein entsprechender Sitzungsschlüssel erzeugt und in geeigneter Weise mit dem öffentlichen Schlüssel des externen Systems verschlüsselt.
Sollten die zuvor beschriebenen Verifikationsschritte ab Schritt S12 jeweils erfolgreich gewesen sein, wird schließlich in Schritt S22 eine Bestätigungsnachricht an das externe System ES übermittelt, mit der dem externen System mitgeteilt wird, dass die Autorisierung erfolgreich abgeschlossen wurde und nunmehr die entsprechenden Dienste auf dem Steuergerät ausgeführt werden können. Im Falle, dass optional eine Sitzungsidentität verwendet wird bzw. ein Sitzungsschlüssel erzeugt wurde, wird die Sitzungsidentität sowie der in Schritt S21 verschlüsselte Sitzungsschlüssel innerhalb der Bestätigungsnachricht an das externe System ES übermittelt. Sollte hingegen einer der Verifikationsschritte ab Schritt S12 nicht erfolgreich gewesen sein, wurde das Verfahren bereits zuvor durch Übermittlung eines entsprechenden Fehlercodes an das externe System ES abgebrochen.
Im Vorangegangenen wurde eine Variante der Erfindung beschrieben, bei der zur Autorisierung unmittelbar ein Schlüsselpaar aus einem geheimen Schlüssel SBA und einer öffentlichen Schlüssel PBA des Fahrzeugherstellers verwendet wird. Es besteht jedoch gegebenenfalls auch die Möglichkeit, den Vorgang der Autorisierung durch den Fahrzeughersteller an eine dritte Instanz bzw. eine Mehrzahl von dritten Instanzen zu übertragen, welche sich gegenseitig über entsprechende Schlüssel authentisiert haben. Diese vollständige bzw. gegebenenfalls auch teilweise Delegation von Authentisierungsrechten an eine neue dritte Instanz wird dadurch ermöglicht, dass das bisher alleinig autorisierende Backend BA des Fahrzeugherstellers der neuen, als Autorisierungsstelle fungierenden Instanz ein Autorisierungsdelegationsticket bereitstellt, welches folgende Daten enthält:

– die Identität der neuen Autorisierungsstelle, d. h. deren öffentlicher Schlüssel PDEL;
– eine Liste aller Dienste, für welche die neue Autorisierungsstelle Autorisierungstickets erstellen darf;
– eine Liste der Identifikationen der Steuergeräte, für welche die neue Autorisierungsstelle Autorisierungstickets erstellen darf.

Das Autorisierungsdelegationsticket wird in der ersten Delegationsebene wiederum mit dem geheimen Schlüssel SBA des Fahrzeugherstellers signiert. Die erste Delegationsebene bezeichnet dabei diejenige neue Autorisierungsstelle, welche unmittelbar durch den Fahrzeughersteller zur Autorisierung beauftragt wurde. Die weiteren Delegationsebenen stellen weitere Autorisierungsstellen dar, welche basierend auf einer Kette von der vorhergehenden Autorisierungsstelle zur Autorisierung beauftragt wurden. Es wird dabei eine maximale Delegationstiefe festgelegt, welche definiert, wie oft eine Autorisierung vom Fahrzeughersteller zu einer Delegationsstelle und von einer Delegationsstelle zu einer weiteren Delegationsstelle weitergegeben werden darf. Das Autorisierungsdelegationsticket jeder weiteren Delegationsebene ist dabei mit einem geheimen Delegationsschlüssel der Autorisierungsstelle der vorhergehenden Delegationsebene signiert.
Stellt nun eine neue Autorisierungsstelle ein Autorisierungsticket AT aus, so müssen zusätzlich zu den sonst erforderlichen Daten das oder die Autorisierungsdelegationstickets enthalten sein. Das Autorisierungsticket ist dabei mit dem geheimen Schlüssel der neuen Autorisierungsstelle signiert. Erhält ein Steuergerät nunmehr ein Autorisierungsticket, in dem ein oder mehrere Autorisierungsdelegationstickets enthalten sind, so muss das Steuergerät zuerst das Autorisierungsdelegationsticket der ersten Delegationsebene, welches mit dem privaten Schlüssel SBA verschlüsselt ist, mit dem öffentlichen Schlüssel PBA prüfen. Sind weitere Autorisierungsdelegationstickets in tieferen Delegationsebenen vorhanden, müssen diese mit dem öffentlichen Schlüssel PDEL der jeweils vorhergehenden Delegationsebene überprüft werden. Bei Erfolg wird der Schlüssel PDEL des Autorisierungsdelegationstickets der letzten Delegationsebene extrahiert und anschließend mit PDEL das Autorisierungsticket geprüft, welches mit dem entsprechenden geheimen Schlüssel SDEL signiert ist.
Im Folgenden wird die Datenstruktur DelegationTicket eines entsprechenden Autorisierungsdelegationstickets erläutert. Dieses Ticket besteht aus dem Datenfeld payload mit allen Delegationsinformationen, dem Datenfeld delegationSignature in der Form von Signature zur Authentizitätssicherung des Tickets und optional aus dem Datenfeld delegation als Nachweis einer übergeordneten Rechtedelegation in der Form von DelegationTicket.

Das Datenfeld payload besteht aus folgenden Feldern:

– publicKeyIT:	der öffentliche Schlüssel der Autorisierungsstelle, an welche
	das Recht delegiert wurde, wobei dieser Schlüssel in der
	Form eines 32 bis 256 Byte lange Binärfelds vorliegt;
– delegatedServices:	eine Liste aller delegierter Dienst-Identitäten;
– delegateEculds:	eine Liste aller Steuergeräte, für welche die delegierten
	Rechte gültig sind;
– maxDelegationDepth:	eine Beschränkung, wie oft ein Recht maximal delegiert
	werden darf;
– expiryDate:	eine optionale Begrenzung der Gültigkeit in der Form eines
	Zeitstempels in koordinierter Weltzeit.

Die im Vorangegangenen beschriebenen Ausführungsformen des erfindungsgemäßen Verfahrens weisen eine Reihe von Vorteilen auf. Insbesondere wird im Rahmen des Verfahrens sowohl eine Authentisierung eines externen Systems als auch eine entsprechende Autorisierung des externen Systems zur Durchführung entsprechender Dienste auf dem Steuergerät durchgeführt. Die Autorisierung wird dabei durch eine zentrale Instanz gesteuert, bei der es sich vorzugsweise um den Fahrzeughersteller handelt. Diese zentrale Instanz ist für die Erstellung entsprechender Autorisierungstickets verantwortlich, welche zur Durchführung der Autorisierung benötigt werden. Das oben beschriebene Verfahren ermöglicht in flexibler Weise, beliebige Dienste mit sehr feiner Granularität vor beliebigen Zugriffen zu schützen. Durch die zentrale Erstellung des Autorisierungstickets ist eine Kontrolle über die externen Systeme und darüber möglich, welche Dienste im Fahrzeug die externen Systeme jeweils nutzen dürfen. Die Erstellung eines Autorisierungstickets kann gegebenenfalls durch die zentrale Instanz an beliebige Dritte, wie beispielsweise Zulieferer, übertragen werden.
Ein weiterer Vorteil des Verfahrens besteht darin, dass geheimes Schlüsselmaterial der zentralen Instanz nicht in dem externen System gespeichert werden muss, welches entsprechende Dienste auf einem Steuergerät ausführen möchte. Der in dem externen System gespeicherte geheime Schlüssel gilt vielmehr nur für das individuelle externe System. Darüber hinaus muss im Steuergerät nur ein öffentlicher Schlüssel zur Prüfung des Autorisierungstickets gespeichert werden, und zwar unabhängig von der Anzahl der ausführbaren Dienste.
Abhängig von der notwendigen Sicherheit für den auszuführenden Dienst kann im Rahmen des Autorisierungsverfahrens die Erlaubnis für ein externes System, einen bestimmten Dienst zu nutzen, auf einen bestimmten Typ eines Steuergeräts bzw. ein individuelles Steuergerät bzw. ein individuelles Fahrzeug beschränkt werden. Dies wird durch die Festlegung entsprechender eculds gemäß den oben beschriebenen alternativen Schritten S701 bzw. S702 bzw. S703 erreicht. Für die Schritte S701 bzw. S702 benötigt das externe System dabei in der Regel eine Online-Verbindung zu der zentralen Instanz bzw. einem berechtigten Dritten.
Für einen sehr hohen Sicherheitsbedarf kann gemäß dem oben beschriebenen Verfahren in das Autorisierungsticket die von dem Steuergerät generierte Challenge einbezogen werden. Dadurch wird erzwungen, dass für jeden Autorisierungsvorgang immer ein frisches Autorisierungsticket erstellt wird. Dies erfordert in jedem Fall eine Online-Verbindung zur zentralen Instanz oder einem berechtigten Dritten.

Claims

Verfahren zur Autorisierung eines externen Systems (ES) auf einem Steuergerät (SG) eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, bei dem: a) das externe System (ES) an das Steuergerät (SG) eine Dienste-Anfrage (SR) zur Ausführung von einem oder mehreren Diensten auf dem Steuergerät (SG) sendet; b) das Steuergerät (SG) einen Code (CH) generiert und eine Authentisierungs-Anforderungs-Nachricht (AREQ) umfassend den generierten Code (CH) an das externe System (ES) sendet, falls das Steuergerät (SG) das oder die Dienste gemäß der Dienste-Anfrage (SR) ausführen kann; c) das externe System (ES) eine Authentisierungs-Antwort-Nachricht (ARES) generiert und an das Steuergerät (SG) sendet, wobei die Authentisierungs-Antwort-Nachricht (ARES) enthält: – ein Autorisierungsticket (AT), welches unter Einbeziehung eines geheimen, einer zentralen Instanz zugeordneten Autorisierungsschlüssels (SBA) eines Autorisierungs-Schlüsselpaars aus dem geheimen Autorisierungsschlüssel (SBA) und einem öffentlichen Autorisierungsschlüssel (PBA) generiert ist, wobei das Autorisierungsticket (AT) mit dem öffentlichen Autorisierungsschlüssel (PBA) erfolgreich verifizierbar ist; – eine Code-Antwort (RES), welche zumindest den an das externe System (ES) gesendeten Code (CH) enthält und unter Einbeziehung eines geheimen, dem externen System (ES) zugeordneten Authentisierungsschlüssels (SES) eines Authentisierungs-Schlüsselpaars aus dem geheimen Authentisierungsschlüssel (SES) und einem öffentlichen Authentisierungsschlüssel (PES) generiert ist, wobei die Code-Antwort (RES) mit dem öffentlichen Authentisierungsschlüssel (PES) erfolgreich verifizierbar ist; d) das Steuergerät (SG) das Autorisierungsticket (AT) und die Code-Antwort (RES) in der empfangenen Authentisierungs-Antwort-Nachricht (ARES) basierend auf in dem Steuergerät (SG) hinterlegten öffentlichen Schlüsseln verifiziert, wobei bei Erfüllung einer oder mehrerer Bedingungen, welche zumindest die erfolgreiche Verifikation des Autorisierungstickets (AT) und der Code-Antwort (RES) umfassen, die Ausführung des oder der Dienste durch das Steuergerät (SG) zugelassen wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Dienste-Anfrage (SR) die auszuführenden Dienste über jeweilige Dienst-Identitäten spezifiziert.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass dem Steuergerät (SG) ein Gerät-Identifikator (eculd) zugewiesen ist, der dem externen System (ES) bekannt ist und/oder dem externen System (ES) als Teil der Authentisierungs-Anforderungs-Nachricht (AREQ) in Schritt b) mitgeteilt wird.
Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) einen oder mehrere Gerät-Identifikatoren (eculd) und/oder DienstIdentitäten enthält, für welche das Autorisierungsticket (AT) gültig ist, wobei in Schritt d) verifiziert wird, ob der Gerät-Identifikator (eculd) des die Dienste-Anfrage (SR) empfangenden Steuergeräts (SG) und/oder die Dienst-Identität oder die Dienst-Identitäten, welche in der Dienste-Anfrage (SR) spezifiziert sind, im Autorisierungsticket (AT) enthalten sind, wobei nur bei erfolgreicher Verifikation die Ausführung des oder der Dienste durch das Steuergerät (SG) zugelassen wird.
Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass ein Gerät-Identifikator (eculd) einen Steuergeräte-Typ festlegt.
Verfahren nach einem der Ansprüche 3 bis 5, dadurch gekennzeichnet, dass ein Gerät-Identifikator (eculd) eine eindeutige Identifikation des Steuergeräts (SG) oder des Fahrzeugs enthält.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) den in Schritt b) vom Steuergerät (SG) generierten Code (CH) enthält, wobei in Schritt d) die Übereinstimmung des Codes (CH) im Autorisierungsticket (AT) mit dem vom Steuergerät (SG) generierten Code (CH) überprüft wird und wobei nur bei Vorliegen einer Übereinstimmung die Ausführung des oder der Dienste durch das Steuergerät (SG) zugelassen wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) in Schritt c) generiert wird, indem durch das externe System (ES) eine Anforderungs-Nachricht an eine der zentralen Instanz zugeordnete Infrastruktur (BA) oder eine durch die zentrale Instanz autorisierte Infrastruktur übermittelt wird, welche anschließend das Autorisierungsticket (AT) erzeugt und an das externe System (ES) übermittelt.
Verfahren nach Anspruch 7 und 8, dadurch gekennzeichnet, dass die Anforderungs-Nachricht den in Schritt b) von dem Steuergerät (SG) generierten Code (CH) enthält.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in dem externen System (ES) ein oder mehrere Autorisierungstickets (AT) hinterlegt sind, wobei durch das externe System (ES) in Schritt c) nach einem hinterlegten Autorisierungsticket (AT) gesucht wird, welches für die an das Steuergerät (SG) zu sendende Authentisierungs-Antwort-Nachricht (ARES) verwendbar ist, wobei im Falle, das ein verwendbares Autorisierungsticket (AT) gefunden wird, dieses Autorisierungsticket (AT) in die auszusendende Authentisierungs-Antwort-Nachricht (ARES) eingefügt wird.
Verfahren nach Anspruch 10 in Kombination mit Anspruch 4, dadurch gekennzeichnet, dass in Schritt c) nach hinterlegten Autorisierungstickets gesucht wird, deren enthaltene Gerät-Identifikatoren (eculd) und/oder Dienst-Identitäten den Gerät-Identifikator (eculd) des die Dienste-Anfrage (SR) empfangenden Steuergeräts (SG) und/oder die Dienst-Identität oder die Dienst-Identitäten gemäß der Dienste-Anfrage (SR) umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) mit dem geheimen Autorisierungsschlüssel (PBA) signiert ist, der in einer der zentralen Instanz zugeordneten Infrastruktur (BA) hinterlegt ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) ein Delegationsticket enthält, welches mit dem geheimen Autorisierungsschlüssel (PBA) signiert ist und einen dem Delegationsticket zugeordneten öffentlichen Delegationsschlüssel umfasst, wobei das Autorisierungsticket (AT) mit einem geheimen Delegationsschlüssel des Delegationstickets signiert ist, wobei zur Verifikation des Autorisierungstickets (AT) die Signaturen basierend auf dem jeweiligen öffentlichen Delegations- oder Autorisierungsschlüssel überprüft werden, dessen geheimer Delegations- oder Autorisierungsschlüssel zum Signieren verwendet wurde, wobei bei einer erfolgreichen Überprüfung aller Signaturen das Autorisierungsticket (AT) erfolgreich verifiziert ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) eine Reihe von mehreren aufeinander folgenden Delegationstickets enthält, wobei das erste Delegationsticket der Reihe mit dem geheimen Autorisierungsschlüssel (PBA) signiert ist und einen dem ersten Delegationsticket zugeordneten öffentlichen Delegationsschlüssel enthält und wobei die restlichen Delegationstickets jeweils mit einem geheimen, dem vorhergehenden Delegationsticket zugeordneten Delegationsschlüssel signiert sind und jeweils einen dem Delegationsticket zugeordneten öffentlichen Delegationsschlüssel enthalten, wobei das Autorisierungsticket (AT) mit dem geheimen Delegationsschlüssel des letzten Delegationstickets signiert ist, wobei zur Verifikation des Autorisierungstickets (AT) die Signaturen basierend auf dem jeweiligen öffentlichen Delegations- oder Autorisierungsschlüssel überprüft werden, dessen geheimer Delegations- oder Autorisierungsschlüssel zum Signieren verwendet wurde, wobei bei einer erfolgreichen Überprüfung aller Signaturen das Autorisierungsticket (AT) erfolgreich verifiziert ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der öffentliche Authentisierungsschlüssel (PES) innerhalb des Autorisierungstickets (AT) an das Steuergerät (SG) übermittelt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der öffentliche Authentisierungsschlüssel (PES) mittels einer separaten Nachricht oder eines separaten Nachrichtenteils, insbesondere mittels eines Zertifikats, an das Steuergerät (SG) übermittelt wird.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die separate Nachricht oder der separate Nachrichtenteil unter Einbeziehung des geheimen Autorisierungsschlüssels (SBA) generiert ist und mit dem öffentlichen Autorisierungsschlüssel (PBA) erfolgreich verifizierbar ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Dienste-Anfrage (SR) und/oder das Autorisierungsticket (AT) eine Identifikation des externen Systems enthält, welches die Dienste-Anfrage in Schritt a) an das Steuergerät (SG) sendet.
Verfahren nach einem der vorhergehenden Ansprüche, wenn abhängig von Anspruch 4, dadurch gekennzeichnet, dass das Autorisierungsticket (AT) eine Liste von Identifikationen von externen Systemen enthält, welche berechtigt sind, die Dienste gemäß den in dem Autorisierungsticket (AT) enthaltenen DienstIdentitäten auf Steuergeräten (SG) mit den in dem Autorisierungsticket (AT) enthaltenen Gerät-Identifikatoren (eculd) auszuführen.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der Dienste-Anfrage (SR) oder durch die Steuergerät (SG) festgelegt wird, ob im Verfahren ein neues Autorisierungsticket (AT) zu verwenden ist, wobei im Falle, dass ein neues Autorisierungsticket (AT) zu verwenden ist, in Schritt b) ein neues Autorisierungsticket (AT) generiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der Dienste-Anfrage (SR) oder durch das Steuergerät (SG) festgelegt wird, ob im Verfahren ein Sitzungsschlüssel zur gesicherten Kommunikation zwischen dem externen System (ES) und dem Steuergerät (SG) bei der Ausführung von Diensten zu verwenden ist, wobei im Falle, dass ein Sitzungsschlüssel zu verwenden ist, der Sitzungsschlüssel in Schritt d) generiert wird und an das externe System (ES) übermittelt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in Schritt b) vom Steuergerät (SG) eine Sitzungsidentität generiert wird, welche bei der Übermittlung von nachfolgenden Nachrichten zwischen Steuergerät (SG) und externem System (ES) mit übertragen wird.
Autorisierungssystem umfassend ein externes System (ES) und ein Steuergerät (SG) eines Fahrzeugs, insbesondere eines Kraftfahrzeugs, wobei das Autorisierungssystem derart ausgestaltet ist, dass ein Verfahren nach einem der vorhergehenden Ansprüche durchführbar ist.
Einrichtung zur Ausführung von Diensten auf einem Steuergerät (SG) eines Fahrzeug, insbesondere eines Kraftfahrzeugs, wobei die Einrichtung als das externe System (ES) in dem Verfahren nach einem der Ansprüche 1 bis 22 fungieren kann, wobei die Einrichtung ein Mittel zum Aussenden einer Dienste-Anfrage (SR) zur Ausführung von einem oder mehreren Diensten an das Steuergerät (SG) und ein Mittel zum Generieren und Aussenden einer Authentisierungs-Antwort-Nachricht (ARES) an das Steuergerät (SG) umfasst.
Steuergerät (SG) für ein Fahrzeug, insbesondere ein Kraftfahrzeug, wobei das Steuergerät (SG) als das Steuergerät (SG) in dem Verfahren nach einem der Ansprüche 1 bis 22 fungieren kann, wobei das Steuergerät (SG) ein Mittel zum Generieren eines Codes (CH) und zum Aussenden einer Authentisierungs-Anforderungs-Nachricht (AREQ) sowie ein Mittel zum Verifizieren eines Autorisierungstickets (AT) und einer Code-Antwort (RES) in einer empfangenen Authentisierungs-Antwort-Nachricht (ARES) umfasst.