DE102012110499A1

DE102012110499A1 - Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte

Info

Publication number: DE102012110499A1
Application number: DE102012110499.9A
Authority: DE
Inventors: Thomas M. Forest
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2011-10-28
Filing date: 2012-11-02
Publication date: 2014-03-27
Anticipated expiration: 2032-11-03
Also published as: US9280653B2; DE102012110499B4; DE102012110499B9; CN103685214A; CN103685214B; US20130111582A1

Abstract

Ein System und Verfahren zum Verwenden eines Mechanismus zum Freischalten einer Fahrzeug-ECU. Die ECU speichert einen eindeutigen ECU-Kennwert, der die jeweilige ECU identifiziert, und ein sicherer Server speichert den ECU-Kennwert und einen eindeutigen ECU-Sicherheitsschlüsselwert, wobei der Kennwert den Sicherheitsschlüsselwert in dem Server identifiziert, und wobei der sichere Server den eindeutigen ECU-Kennwert und den eindeutigen Sicherheitsschlüsselwert für viele ECUs speichert. Ein Wartungswerkzeug, das Zugang zu der ECU erlangen möchte, um Software zu reprogrammieren oder für Service, fordert den ECU-Kennwert und eine Aufforderung von der ECU an und sendet diese an den sicheren Server, welcher dann den Sicherheitsschlüsselwert, der mit diesem ECU-Kennwert und der Antwort auf die Aufforderung verbunden ist, identifiziert. Der sichere Server sendet dann die Antwort an das Wartungswerkzeug, welches diese an die ECU liefert, um diese zum Programmieren freizuschalten.

Description

QUERVERWEIS AUF ZUGEHÖRIGE ANMELDUNGEN
Diese Anmeldung beansprucht das Prioritätsdatum der U.S. Provisional Patent Application Serial No. 61/552,984 mit dem Titel: ”Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte”, angemeldet am 28. Oktober 2011.
HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Diese Erfindung bezieht sich allgemein auf ein System und ein Verfahren zum sicheren Zugang oder zum Freischalten eines elektronischen Steuergeräts (ECU) auf einem Fahrzeug und insbesondere auf ein System und ein Verfahren zum sicheren Zugang oder zum Freischalten einer ECU auf einem Fahrzeug, wobei das System einen sicheren Remote-Server beinhaltet, der einen ECU-Kennwert und eine Sicherheitsaufforderung von der ECU empfängt, und wobei der Server den ECU-Kennwert verwendet, um einen ECU-Sicherheitsschlüsselwert für die ECU zu identifizieren, um eine Antwort auf die Aufforderung zu geben.
2. Diskussion des Standes der Technik
Viele moderne Fahrzeuge beinhalten elektronische Steuereinheiten (ECUs), oder Steuergeräte, die den Betrieb der Fahrzeugsysteme, beispielsweise des Antriebsstrang, des Klimasteuersystems, des Infotainment-Systems, der Body-Systeme, der Chassis-Systeme und dergleichen steuern. Diese Steuergeräte benötigen für besondere Zwecke gestaltete Software, um die Steuerfunktionen durchzuführen. Mit der zunehmenden Zahl und Komplexität dieser Steuergeräte und der wachsenden Furcht, die von Entwicklern von Schadsoftware ausgeht, ist es wichtiger denn je, die Herkunftsquelle und den Inhalt von Softwarefiles, die in Automobilsteuergeräte installiert werden, zu authentifizieren. Die Konsequenzen vom Gebrauch von Software, die nicht einwandfrei validiert wurde oder die – schlimmer noch – schadhaft entworfen wurde, in einem Fahrzeugsteuergerät, beinhaltet das unbeabsichtigte Verhalten des Fahrzeugs oder seiner Systeme, den Verlust von Antidiebstahl-Eigenschaften auf dem Fahrzeug, das potentielle Herumpfuschen an Komponenten wie beispielsweise dem Kilometerzähler und der Verlust von anderen Fahrzeugmerkmalen und Funktionen.
Die ECUs auf einem Fahrzeug müssen manchmal aus verschiedenen Gründen gewartet oder aktualisiert werden, wobei eine Service-Einrichtung Zugang auf die ECU erlangen muss, um entweder Diagnosefehlercodes oder andere Fehler herunterzuladen, die ECU zu reprogrammieren oder manch andere Operation auszuführen, um ein Fahrzeugproblem zu lösen. Es ist aus Sicherheitsgründen allerdings wichtig, dass nur autorisiertes Personal auf eine ECU auf einem Fahrzeug Zugang haben kann, um Service-Operationen auszuführen, da ein nicht autorisierter Benutzer schädliche oder nicht ordnungsgemäße Aktionen ausführen könnte, die den Fahrzeugbetrieb negativ beeinträchtigen. Mit anderen Worten ist es wichtig, das unautorisierte Benutzer keinen Zugang auf die Fahrzeug-ECU erlangen können, um die ECU mit Software, die schadhaft sein kann oder auf andere Art das Fahrzeug beschädigen kann, zu programmieren. Demzufolge ist der Besitz von sicheren Techniken zum Freischalten einer ECU zum Programmieren, zur Wartung und anderen Operationen notwendig.
Eine Fahrzeug-ECU kann für sicherheitssensitive Diagnoseoperationen mithilfe einer Art von Aufforderung/Antwort-Mechanismus, die manchmal als ”Seed and Key” bezeichnet werden, wobei der ”Seed” die Aufforderung und der ”Key” die Antwort darstellen, freigeschaltet werden. Beispielsweise wird ein Wartungswerkzeug, das versucht, Zugang auf eine ECU zu erlangen, bewirken, dass die ECU eine Sicherheitsaufforderung erlässt, wie zum Beispiel eine Art von Frage, die in die ECU vorprogrammiert ist, und das Werkzeug muss dann die Aufforderung mit der ordnungsgemäßen Antwort, die ebenfalls in die ECU vorprogrammiert ist, beantworten, so dass, falls korrekt geantwortet wurde, die ECU dem Werkzeug die Zugangsgewährung zu ihr gestatten wird. Diagnosestandards geben vor, wie dieses Verfahren ausgeführt wird. Beispielsweise definiert ISO 14229 einen Sicherheitszugangsservice, der es erlaubt, dass ein Gerät unter Verwendung eines Aufforderung/Antwort-Mechanismus freigeschaltet wird.
Aufforderung/Antwort-Mechanismen der oben erwähnten Art zerfallen in zwei Kategorien. Die erste Kategorie beinhaltet fest vorgegebene Aufforderungen, wobei die Aufforderung und demnach die erwartete Antwort fest vorgegeben ist. In einer solchen Implementierung speichert die ECU einfach die Aufforderung und die Antwort, wobei es für das Gerät nicht notwendig ist, selbst die Fähigkeit zu besitzen, die Antwort auf eine gegebene Aufforderung zu berechnen. Ein Nachteil dieser Systeme ist, dass sobald die Antwort bekannt ist, diese für alle Zeiten bekannt ist, wobei dieselbe Antwort, die eine ECU heute freischaltet, dieselbe ECU morgen auch freischalten würde. Demzufolge ist die Sicherheit, die von dieser Art von Aufforderung/Antwort-Mechanismus gewährt wird, begrenzt.
Die zweite Kategorie beinhaltet variable Antworten, wobei jede ECU-Freischaltoperation eine unterschiedliche Aufforderung erzeugt, die von der ECU erlassen werden muss. Dies wird oft implementiert, indem dem Gerät, das freigeschaltet werden soll, die Befähigung gegeben wird, eine Antwort auf eine gegebene Aufforderung zu berechnen. In vielen Implementierungen erfolgt dies in der Gestalt eines geheimen Algorithmus, der die Berechnung einer Antwort für eine gegebene Aufforderung gestattet. Dies hat den Vorzug, dass verhindert wird, dass eine Antwort zu einem späteren Zeitpunkt verwendet werden wird, und bringt aber den Nachteil mit sich, dass die Sicherheit des Systems in der Geheimhaltung des Algorithmus liegt. Wenn alle Geräte den gleichen Algorithmus verwenden, reduziert die Offenlegung des Algorithmus, welcher in jeder ECU eingebettet sein muss, die Gesamtsicherheit des Systems.
ZUSAMMENFASSUNG DER ERFINDUNG
Im Einklang mit den Lehren der vorliegenden Erfindung werden ein System und ein Verfahren zum Freischalten einer Fahrzeug-ECU offenbart, um es zu gestatten, Files auf der ECU zu installieren. Die ECU speichert einen eindeutigen ECU-Kennwert, der die jeweilige ECU identifiziert, und ein sicherer Server speichert den ECU-Kennwert und einen eindeutigen ECU-Sicherheitsschlüsselwert, wobei der Kennwert den Sicherheitsschlüsselwert in dem Server identifiziert, und wobei der sichere Server den eindeutigen ECU-Kennwert und den eindeutigen Sicherheitsschlüsselwert für viele ECUs speichert. Ein Wartungswerkzeug, das Zugang auf die ECU zum Reprogrammieren von Software oder zu Servicezwecken erlangen will, erfragt den ECU-Kennwert und eine Aufforderung von der ECU und sendet diese an den sicheren Server, welcher dann den Sicherheitsschlüsselwert, der zu dem ECU-Kennwert gehört, und die Antwort für die Aufforderung identifiziert. Der sichere Server sendet dann die Antwort an das Wartungswerkzeug, welches diese an die ECU liefert, um diese zum Programmieren freizuschalten. Wird die ECU das nächste Mal gewartet, liefert diese eine unterschiedliche Aufforderung, auf welche der sichere Server in der Lage sein wird, korrekt zu antworten, da er den ECU-Sicherheitsschlüsselwert kennt.
Weitere Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung und den beigefügten Patentansprüchen in Verbindung mit den beigefügten Figuren deutlich.
KURZE BESCHREIBUNG DER FIGUREN
1 ist eine Darstellung eines Fahrzeugs mit einer Fahrzeug-ECU; und
2 ist ein Flussdiagramm zum Freischalten der ECU unter Verwendung einer sicheren Remote-Datenbank;
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
Die folgende Diskussion der Ausführungsformen der Erfindung, die auf ein System und ein Verfahren zum Freischalten oder zum Zugang auf eine sichere Fahrzeug-ECU gerichtet ist, ist rein beispielhafter Natur und in keiner Weise dazu gedacht, die Erfindung oder ihre Anwendungen oder Verwendungen einzuschränken. Beispielsweise hat die vorliegende Erfindung eine besondere Anwendung für den Zugang auf eine Fahrzeug-ECU. Fachleute können allerdings leicht erkennen, dass die Technik der Erfindung eine Anwendung zum Zugang bei anderen Kontrollern haben kann.
Die vorliegende Erfindung schlägt ein Verfahren vor, um einen sicheren Zugang auf eine Fahrzeug-ECU zum Installieren von Software zu gewähren. Das Verfahren ist kompatibel mit den Sicherheitszugangsverfahren, die in den relevanten internationalen Standards definiert sind, beispielsweise ISO 14229 und gewährt eine größere Sicherheit als andere Alternativen, die vorgeschlagen worden sind. Der allgemeine Erfindungsgedanke ist, dass ein ECU-spezifischer Sicherheitsschlüssel bereitgestellt wird, der sowohl der ECU als auch dem Hersteller bekannt ist. Der Sicherheitsschlüssel wird mit einem kryptographischen Authentifizierungsalgorithmus verwendet, beispielsweise einem Nachrichtenauthentifizierungscode (MAC), um ein Aufforderung/Antwort-System zu generieren. Die freizuschaltende ECU stellt eine eindeutige ID bereit, die verwendet wird, um den Sicherheitsschlüssel in einer definierten Datenbank, die beispielsweise von dem Fahrzeughersteller bereitgestellt wird, zu suchen und der Hersteller kann diesen Schlüssel verwenden, um eine gültige Antwort auf die Aufforderung, die von der ECU bereitgestellt wird, zu generieren. Der kryptographische Algorithmus in der ECU kann, ohne die Sicherheit des Systems zu mindern offengelegt werden, da die Sicherheit an dem Sicherheitsschlüssel liegt, welcher für jede einzelne ECU unterschiedlich ist.
Eine Service-Einrichtung, die versucht, eine ECU freizuschalten, muss mit einem Sicherheitsserver an einem fernliegenden Ort kommunizieren. Diese Kommunikation kann über eine direkte Verbindung zum Internet oder über andere verschiedene Kommunikationsmechanismen, beispielsweise Short Messages, Webseitenzugang, SMS-Textnachrichten, Telefonanrufbeantworter-Systeme etc. erfolgen. Diese Kommunikation wird durch den relativ kleinen Informationsgehalt, der zwischen der ECU und dem Sicherheitsserver ausgetauscht werden muss, erleichtert. Eine vorgeschlagene Weiterbildung macht es einfacher, die Datenbankfunktionalität mittels dem ECU-spezifischen Sicherheitsschlüssel, der von der eindeutigen Kennungsinformation mittels eines zweiten Kryptographie-Algorithmus abgeleitet wird, zu implementieren, der den Sicherheitsschlüssel zu der ID direkt erzeugt, d. h. dass der Schlüssel eine kryptographische Funktion der ID ist, so dass die Notwendigkeit zur Erzeugung einer Sicherheitsschlüssel-Datenbank wegfällt.
1 ist eine Darstellung eines Fahrzeugs 10, welches eine ECU 12 beinhaltet, die dazu gedacht ist, eine oder mehrere ECUs auf dem Fahrzeug 12 ohne Einschränkung des Fahrzeugtyps, des Typs der ECU 12, des Verwendungszwecks der ECU 12 etc. darzustellen. Wie unten diskutiert werden wird, beschreibt die vorliegende Erfindung eine Technik, die ECU 12 freizuschalten, so dass diese programmiert werden kann oder für die Installation von Softwarefiles von einer Service-Einrichtung mithilfe eines Wartungswerkzeugs 14 gewartet werden kann. Nach der vorliegenden Erfindung besitzt jede ECU auf demselben Fahrzeug oder jede ECU auf verschiedenen Fahrzeugen ihren eigenen ECU-Kennwert und Sicherheitscode oder Schlüssel. Wie unten im Detail diskutiert werden wird, erhält das Wartungswerkzeug 14 den ECU-Kennwert und eine Aufforderung von der ECU 12 und sendet diese zu einer fernliegenden Einrichtung oder Sicherheitsserver 16, der die Kennwerte und Sicherheitsschlüssel für alle ECUs in dem System speichert. Der Server 16 empfängt den ECU-Kennwert und die Aufforderung von dem Werkzeug 14, identifiziert den ECU-Sicherheitsschlüssel von dem Kennwert und identifiziert die Antwort auf die Aufforderung, die auf dem Server 16 von dem Sicherheitsschlüssel gespeichert ist. Der Server 16 sendet die Antwort an das Werkzeug 14, welches diese an die ECU 12 liefert und, sofern diese korrekt ist, gestattet es dem Werkzeug 14, Zugang zu der ECU 12 zu erlangen.
Der vorgeschlagene Aufforderung/Antwort-Mechanismus zum Freischalten einer Fahrzeug-ECU leidet nicht an den oben diskutierten Nachteilen. Insbesondere verwendet jede unterschiedliche ECU in dem Fahrzeug 10 einen unterschiedlichen Algorithmus. Demnach beeinträchtigt ein erfolgreiches Reverse-Engineering von einer ECU oder einem anderen Gerät nur die Sicherheit dieses Geräts und nicht die von anderen Geräten in dem System. Das Verfahren wurde allerdings modifiziert, um konsistenter mit den Anforderungen von Sicherheitsfreischaltungen für Diagnoseoperationen zu sein.
Wie erwähnt erfordert die Verwendung eines Aufforderung/Antwort-Mechanismus zum Freischalten einer ECU eine Einrichtung, die in der Lage ist, die Operation zu autorisieren, d. h. den Sicherheitsserver 16. Der Sicherheitsserver 16 ist im Besitz der gesamten Information, die erforderlich ist, um alle ECUs zu autorisieren, und somit ist die Sicherheit (physisch und IT) des Sicherheitsservers 16 kritisch für das System. In einer idealen Implementierung würde der Sicherheitsserver 16 in einem sicheren Datenzentrum sich befinden und der Zugang auf den Server 16 würde über sorgfältig kontrollierte Netzwerkverbindungen erfolgen. Der Einsatz von ”tragbaren” Sicherheitsservern, auch wenn sie nur für die Entwicklung oder für Wartungsarbeitsaktionen gedacht sind, würde die Sicherheit des Sicherheitsservers 16 und demzufolge das System als Ganzes risikobehaften und sollte demnach vermieden werden.
Jede ECU 12 besitzt einen ECU-spezifischen Kennwert ID_ECU, der für die ECU 12 eindeutig ist, d. h. alle verschiedenen ECUs vom gleichen ECU-Typ würden verschiedene ID_ECU-Werte besitzen. Der Speicher, der diesen Wert speichert, muss nicht für die Diagnose lesegeschützt sein, sondern er sollte für die Diagnose schreibgeschützt sein. Es sollte ein Mechanismus vorhanden sein, um zu gestatten, dass diese Information von der ECU 12 geholt wird, wenn sich diese in einem gesperrten Sicherheitszustand befindet, beispielsweise holbar durch einen ungesichertes DID-Lesen unter Verwendung von z. B. dem ISO 14229 ReadDataByIdentifierService. Es wird angemerkt, dass viele ECUs bereits eine Rückverfolgbarkeitsinformation über DIDs inklusive der Seriennummerninformation bereitstellen. Die Rückverfolgbarkeitsinformation könnte für den ID_ECU-Wert verwendet werden, falls dieser für jede ECU 12 eindeutig ist.
Jede ECU 12 besitzt ferner einen ECU-spezifischen geheimen Schlüsselwert K_ECU, der spezifisch für jede ECU 12 ist, d. h. zwei unterschiedliche Exemplare des gleichen Typs der ECU 12 würden verschiedene K_ECU-Werte besitzen. Der Speicher, der den K_ECU-Wert speichert, muss gegen Diagnoseoperationen, die aus dem Speicher lesen oder in den Speicher schreiben, geschützt werden und es sollte kein Diagnoseservice stattfinden, der es erlaubt, dass diese Information gelesen oder modifiziert werden kann.
Die Einrichtung, die das System betreibt, unterhält eine Datenbank mit den Paaren von ID_ECU, K_ECU-Werten für jede hergestellte ECU 12. Diese Datenbank müsste in einer sicheren Art implementiert werden, da die Offenlegung der Datenbank die Sicherheit des Systems kompromittieren würde. Die Datenbank muss Abfragefunktionen unterstützen, die bei vorgegebenem ID_ECU-Wert den korrespondierenden ECU-spezifischen Wert von K_ECU ausgeben.
Sowohl der ID_ECU-Wert als auch der K_ECU-Wert werden in die ECU 12 vor Abschluss der Fahrzeugherstellung beispielsweise von dem ECU-Hersteller oder als Teil des Herstellverfahrens des Fahrzeugs, in die die ECU 12 installiert wird, programmiert. Als Ergebnis würde jede im Betrieb befindliche ECU 12 einen unterscheidbaren Satz von ID_ECU, K_ECU-Werten aufweisen und der Sicherheitsserver 16 muss Anfragen für di ID_ECU- und K_ECU-Werte von allen im Betrieb befindlichen Werkzeugen unterstützen.
2 ist ein Flussdiagramm 40, das ein Verfahren zum Freischalten der ECU 12 in der oben diskutierten Art zeigt. Einige Schritte des Verfahrens werden von der ECU 12 ausgeführt, einige werden von dem Werkzeug 14, das von einem Service-Techniker verwendet wird, ausgeführt und einige werden von dem Sicherheitsserver 16 ausgeführt, der Zugang auf die ID_ECU, K_ECU-Paare-Datenbank hat.
Das Werkzeug 14 fragt die ECU 12 mit beispielsweise dem ISO 14229 ReadDataByIdentifier-Service, um den ECU-spezifischen ID_ECU-Wert zu erhalten, und die ECU 12 antwortet auf die Anfrage mit dem Bereitstellen ihres ID_ECU-Werts im Kasten 42. Das Werkzeug 14 initiiert dann eine ISO 14229 SecurityAccess-Service-Anfrage, in dem es von der ECU 12 den Seed für den Ressourcentyp, den es freizuschalten wünscht, beispielsweise Programmieren oder I/O-Kontrolle, im Kasten 44 anfragt. Dies kann mit einer RequestSeed- oder Request-Seed_IO_Control-Unterfunktion in der ECU 12 erfolgen.
Die ECU 12 berechnet im Kasten 46 einen Zufalls- oder Pseudozufalls-32-Bit Wert C_i, um als Seed in dem ISO 14229 SecurityAccess-Verfahren zu dienen. Es wird angemerkt, dass das Auswählen eines 32-Bit Werts als Seed nur ein nicht einschränkendes Beispiel ist, und dass jeder geeignete Seed verwendet werden kann. Dieser Wert muss jedes Mal, wenn das Verfahren initiiert wird, gewechselt werden. Er sollte nicht vorhersagbar sein und ihm darf keine verwendbare Information über den K_ECU-Wert entnehmbar sein, falls der K_ECU-Wert gehebelt wird, um unvorhersehbare Pseudozufallswerte zu generieren. Es gibt zahlreiche bekannte Techniken, um solche Zufallswerte zu generieren. Diese Praxis ist in der Automobiltechnik aufgrund ihrer Verwendung als eine Aufforderung in Wegfahrsperrsystemen gut etabliert. Die US 7,034,654 mit dem Titel ”Kraftfahrzeug-Motorwegfahrsperrsicherheitssystem und Verfahren”, erteilt am 25. April 2006 für Forest et al., eingetragen auf den Anmelder dieser Anmeldung und hiermit durch Bezugnahme inkorporiert, offenbart ein Beispiel für eine Technik, um eine pseudozufällige und eine echt zufällige Information zu kombinieren, um einen Wert für sie zu entwickeln. Die ECU 12 antwortet dann auf die ISO 14229 SecurityAccess RequestSeed Anfrage durch Bereitstellen des C_i-Werts als Seed-Wert an das Werkzeug 14 in einer ISO 14229 SecurityAccess Response-Nachricht im Kasten 48.
Das Werkzeug 14 bereitet dann eine Nachricht, die die ID_ECU- und C_i-Werte enthält, und sendet diese an den Server 16 im Kasten 50. Der Server 16 verwendet dann seinen Zugang auf die sichere Datenbank, um den K_ECU-Wert, der zu dem bereitgestellten ID_ECU-Wert korrespondiert, im Kasten 52 zu suchen. Es wird angemerkt, dass der K_ECU-Wert den Sicherheitsserver 16 niemals verlässt. Der Server 16 erzeugt dann im Kasten 54 eine Nachricht MSG_i, die aus dem C_i-Wert, der mit dem ID_ECU-Wert konkateniert ist, welcher, falls erforderlich, mit zusätzlichen vordefinierten Padding-Daten PAD konkateniert ist. Mit anderen Worten: MSG_i = C_i|ID_ECU|PAD (1)
Der Server 16 verwendet einen sicheren Nachrichtenauthentifizierungscode (MAC), der in der Fachwelt bekannt ist, der mit dem K_ECU-Wert verschlüsselt ist, um einen Authentifizierer A_i im Kasten 56 zu berechnen als: A_i = MAC(MSG_i, K_ECU) (2)
Der Authentifizierer A_i, dessen Größe über den genauen MAC-Algorithmus bestimmt wird, wird auf eine Länge von 32 Bit reduziert, beispielsweise durch Behalten der niedrigstwertigsten 32 Bit des Authentifizierers A_i. Dieser reduzierte Längenwert dient als die Antwort, die als R_i bezeichnet wird: R_i = Reduce_to_32_bits(A_i) (3)
Der Server 16 erstellt dann eine Nachricht, die die Antwort R_i enthält, und sendet diese an das Werkzeug 14 im Kasten 58, was unten beschrieben wird. Das Werkzeug 14 fährt mit dem ISO 14229-Verfahren fort, indem es eine andere SecurityAccess-Nachricht an die ECU 12 mit der Unterfunktion SendKey unter Verwendung der Antwort R_i als 32-Bit-Schlüssel, der für das SecurityAccess-Verfahren erforderlich ist, im Kasten 60 sendet. Die ECU 12 empfängt den ISO 14229-Schlüsselwert von dem Werkzeug 14 und führt eine ähnliche Berechnung aus wie die Berechnung, die von dem Server 16 ausgeführt würde, um den R_i-Wert im Kasten 62 zu berechnen, nämlich: MSG_i = C_i|ID_ECU|PAD (4) A_i = MAC(MSG_i, K_ECU) (5) R_i = Reduce_to_32_bits(A_i) (6)
In der Entscheidungsraute 64 vergleicht die ECU 12 den während des ISO 14229-SecurityAccess-Verfahrens empfangenen Schlüssel mit dem berechneten R_i-Wert. Falls die zwei Werte exakt zueinander passen, führt die ECU 12 eine Sicherheitsfreischaltoperation im Kasten 66 aus. Falls die Werte in irgendeiner Art differieren, wird die ECU 12 die Sicherheitsfreischaltung im Kasten 68 nicht ausführen. Die ECU 12 sendet ferner im Kasten 70 eine geeignete ISO 14229 Response-Nachricht abhängig von den Resultaten des Vergleichs.
Das Verfahren in den Kästen 50 und 58 erfordert eine Kommunikation zwischen dem Werkzeug 14 und dem Server 16, die jede geeignete Kommunikation sein kann. Beispielsweise wäre der zweckdienlichste Mechanismus, wenn das Werkzeug 14 und der Server 16 beide direkt mit einem Netzwerk verbunden wären, beispielsweise über das Internet. Zahlreiche andere indirektere Kommunikationsmethoden könnten verwendet werden. Da die Information, die in den Verfahren in den Kästen 50 und 58 gesendet wird, relativ kompakt ist, d. h. innerhalb einer Größe ist, die relativ leicht von einem Menschen mit einer relativ geringen Fehlerwahrscheinlichkeit gehandhabt werden kann, könnte auch eine Zahl von indirekten Mechanismen verwendet werden, falls eine direkte Verbindung nicht möglich ist. Einige Beispiele können das Anzeigen der Information auf dem Werkzeug 14 umfassen, wobei dann einem Techniker ermöglicht wird, die angezeigten Daten über ein webbasiertes Interface in den Server 16 einzugeben, wobei der Server 16 dann den resultierenden R_i-Wert auf einer Webseite anzeigen würde, und wobei der Techniker die Antwort in das Werkzeug 14 eingibt. Abänderungen dieses Verfahrens könnten die Verwendung eines Spracherkennungssystems, die Verwendung von SMS-Nachrichten, die Verwendung einer Anwendung auf einem Smartphone-ähnlichen Gerät, die Verwendung von E-Mail etc. umfassen.
Ungeachtet des Mechanismus wird angenommen, dass die Interaktion mit dem Server 16 eine Art eines effektiven Zugangskontrollmechanismusses umfasst, d. h. dass eingeschränkt wird, wer die Freischaltmöglichkeit erhalten kann. Da es wahrscheinlich ist, dass eine Firma, die einen solchen Service bereitstellen würde, eine Gebühr für die Zugangsgewährung in Rechnung stellen würde, ist es auch wahrscheinlich, dass solche Mechanismen bereits gegenwärtig sind. Darüber hinaus ist es wichtig, dass der Server 16 sichere Logbücher über die Transaktionen führt, d. h. darüber, wer diese ausführt, wann diese ausgeführt werden, über die betroffenen ECUs etc. Diese Logbücher können dazu verwendet werden, Versuche, das System zu kompromittieren, zu detektieren und an der Identifizierung zu arbeiten, wer oder was betroffen ist, falls ein Verstoß auftritt.
Einer der schwierigeren Aspekte des oben beschriebenen Sicherheitsservers 16 ist das Unterhalten der Datenbank mit den ID_ECU, K_ECU-Paaren und die schnelle Zugangsgewährung, um den K_ECU-Wert, der von dem ID_ECU-Wert indiziert ist, zu suchen. In der vorhergehenden Beschreibung gab es keine Beziehung zwischen den ID_ECU- und K_ECU-Werten, d. h. jeder davon konnte als Zufallszahl angesehen werden. Aus einer operativen Sichtweise kann es allerdings möglich sein, den Bedarf für eine sichere Datenbank zu vermeiden, falls eine sichere Beziehung zwischen den ID_ECU- und K_ECU-Werten besteht, was erlauben würde, dass der Schlüssel aus der ID bestimmt wird. Dies kann auf viele Arten erfolgen. Eine nicht einschränkende beispielhafte Implementierung wäre es, die zwei Werte durch eine kryptographische Verschlüsselungsoperation miteinander in Beziehung zu setzen, die jemandem, der im Besitz des Schlüssels ist, ermöglicht, den K_ECU-Wert bei vorgegebenem ID_ECU-Wert zu bestimmen. Dies könnte mittels einer sicheren kryptographischen MAC-Funktion bewerkstelligt werden, welche mit einem separaten geheimen Schlüssel K_MANUF verschlüsselt wäre, der dazu verwendet werden würde, den K_ECU-Wert bei einem vorgegebenen ID_ECU-Wert auf ungefähr die folgende Art zu erzeugen: MSG_ECU = (ID_ECU|PAD) (7) K_ECU = MAC(MSG_ECU, K_MANUF) (8)
Hier steht PAD für vordefinierte PADDING-Daten, falls es erforderlich ist, Eingangserfordernisse für die MAC-Funktion zu erfüllen. Darüber hinaus wird angemerkt, dass der geheime Schlüssel K_MANUF zu jedem K_ECU-Wert in dem System verschieden ist, und dass niemals ein Erfordernis besteht, den geheimen Schlüssel K_MANUF in irgendeine ECU 12 oder in das Wartungswerkzeug 14 einzugeben, d. h., dass die ECU 12, wenn vorgesehen, einfach nur mit einem ID_ECU, K_ECU-Paar ausgestattet wird, welches unter Verwendung des geheimen Schlüssels K_MANUF erzeugt wurde.
Der oben beschriebene Mechanismus wird für jeden ID_ECU-Wert einen unterschiedlichen K_ECU-Wert berechnen und die Sicherheit des kryptographischen MAC wird es für einen Hacker, der nicht den geheimen Schlüssel K_MANUF besitzt, schwierig machen, den K_ECU-Wert für eine einen vorgegebenen ID_ECU-Wert zu bestimmen. Wenn zwischen den K_ECU- und ID_ECU-Werten eine solche Beziehung besteht, kann die Datenbank für die ID_ECU, K_ECU-Paare durch eine Online-Berechnung des K_ECU-Werts unter Verwendung des ID_ECU-Werts, der von dem Sicherheitsserver 16 geliefert wird, ersetzt werden.
Es ist wichtig, sich zu vergegenwärtigen, dass die Sicherheit eines solchen Systems in kritischer Abhängigkeit von der Sicherheit des sicheren Schlüssels K_MANUF steht. Idealerweise würde der sichere Schlüssel K_MANUF niemals den Sicherheitsserver 16 verlassen und der Sicherheitsserver 16 würde dazu verwendet werden, die Sequenz von ID_ECU, K_ECU-Paaren, die für die Versorgung der ECUs erforderlich wären, zu generieren. Falls gewünscht, könnte es möglich sein, einen Versorgungsserver (nicht gezeigt) einzurichten, der die Paare, die für die Anfangsversorgung einer ECU erforderlich sind, erzeugt, welcher von dem Sicherheitsserver 16 getrennt ist, der den K_ECU-Wert bei vorgegebenen ID_ECU-Wert wiedererstellt. Das würde es beispielsweise gestatten, den Versorgungsserver in einer Produktionsstätte und den Sicherheitsserver 16 in einem sicheren Datenzentrum zu platzieren.
Es wird ferner angemerkt, dass es nicht notwendigerweise erforderlich ist, dass alle ECUs den gleichen Wert für den geheimen Schlüssels K_MANUF für das Einrichten der Beziehung zwischen den ID_ECU, K_ECU-Paaren verwenden. Die Verwendung unterschiedlicher Werte für K_MANUF für verschiedene ECU-Typen würde beispielsweise die Schaffung von Versorgungsservern ermöglichen, die nur die Versorgung eines bestimmten Typs einer ECU 12 vornehmen könnten. Ein Kompromittieren des Versorgungservers würde nur die ECUs dieses Typs kompromittieren, d. h. es würde nicht die Freischaltung anderer ECUs ermöglichen, die unterschiedliche Werte für den geheimen Schlüssel K_MANUF verwendet haben, und eine solche Implementierung würde darüber hinaus einiges an Zusatzinformation, beispielsweise die Information über den ECU-Typ, erfordern, um dem Sicherheitsserver 16 zu ermöglichen, den korrekten Wert für den geheimen Schlüssels K_MANUF zu bestimmen, der verwendet wurde, um den K_ECU-Wert für den ECU-Typ wiederzuerstellen.
Wie von Fachleuten gut verstanden wird, können verschiedene oder einige Schritte und Verfahren, die hier erörtert wurden, um die Erfindung zu beschreiben, von einem Computer, einem Prozessor oder einer anderen elektronischen Recheneinheit ausgeführt werden, die mit Hilfe elektrischer Phänomene Daten manipuliert und/oder transformiert. Diese Computer und elektrischen Geräte können verschiedene flüchtige und/oder nicht flüchtige Speicher inklusive einem festen computerlesbaren Medium mit einem darauf befindlichen ausführbaren Programm beinhalten, das verschiedene Codes oder ausführbare Instruktionen beinhaltet, die von dem Computer oder Prozessor ausgeführt werden, wobei der Speicher und/oder das computerlesbare Medium alle Formen und Arten von einem Speicher und anderen computerlesbaren Medien beinhalten kann.
Die vorhergehende Diskussion zeigt und beschreibt rein exemplarische Ausführungsbeispiele der vorliegenden Erfindung. Ein Fachmann kann leicht aus der Diskussion an den beigefügten Figuren und Patentansprüchen erkennen, dass zahlreiche Änderungen, Modifikationen und Variationen gemacht werden können, ohne dabei den Geist und den Bereich der Erfindung zu verlassen, wie er mit den folgenden Patentansprüchen definiert ist.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 7034654 [0024]

Zitierte Nicht-Patentliteratur

ISO 14229 [0005]
ISO 14229 [0013]
ISO 14229 [0018]
ISO 14229 [0023]
ISO 14229 [0023]
ISO 14229 [0024]
ISO 14229 [0024]
ISO 14229 [0024]
ISO 14229-Verfahren [0028]
ISO 14229-Schlüsselwert [0028]
ISO 14229-SecurityAccess-Verfahrens [0029]
ISO 14229 [0029]

Claims

Ein Verfahren zum Zugangsgewähren zu einem elektronischen Steuergerät (ECU) auf einem Fahrzeug, wobei das Verfahren umfasst: – Speichern eines ECU-Kennwerts, der die ECU in einem Speicher auf der ECU identifiziert; – Speichern des ECU-Kennwerts und eines ECU-Sicherheitsschlüsselwerts, der zu dem ECU-Kennwert gehört, in einer sicheren Remote-Datenbank; – Anfordern des ECU-Kennwerts von der ECU mit einem Wartungswerkzeug; – Erzeugen einer Aufforderung in der ECU als Antwort auf das Anfordern; – Senden des ECU-Kennwerts und der Aufforderung von der ECU an das Wartungswerkzeug; – Senden des ECU-Kennwerts und der Aufforderung von dem Wartungswerkzeug an die sichere Datenbank; – Identifizieren des ECU-Sicherheitsschlüsselwerts, der zu dem ECU-Kennwert korrespondiert; – Erzeugen einer Nachricht in der Datenbank basierend auf dem ECU-Sicherheitsschlüsselwert, der eine Antwort auf die Aufforderung enthält; – Senden der Nachricht von der Datenbank an das Wartungswerkzeug; – Senden der Nachricht von dem Wartungswerkzeug an die ECU; und – Zugangsgewähren zu der ECU, falls die Antwort auf die Aufforderung von der ECU akzeptiert wird.
Verfahren nach Anspruch 1, wobei das Erzeugen einer Nachricht in der Datenbank das Verwenden eines sicheren Nachrichtenauthentifizierungscodes, der mit dem ECU-Sicherheitsschlüsselwert verschlüsselt ist, um einen Authentifizierer bereitzustellen.
Verfahren nach Anspruch 1, wobei zwischen dem ECU-Kennwert und dem ECU-Sicherheitsschlüsselwert außer der Beziehung, dass der ECU-Kennwert dazu verwendet wird, um den ECU-Sicherheitsschlüsselwert zu identifizieren, keine Beziehung besteht.
Verfahren nach Anspruch 1, wobei der ECU-Kennwert und der ECU-Sicherheitsschlüsselwert über einen geheimen Schlüssel miteinander in Beziehung stehen, wobei der ECU-Sicherheitsschlüsselwert unter Verwendung des ECU-Kennwerts und des Sicherheitsschlüssels berechnet wird.
Verfahren nach Anspruch 4, wobei der ECU-Sicherheitsschlüssel unter Verwendung eines sicheren kryptographischen Nachrichtenauthentifizierungscodes berechnet wird.
Verfahren nach Anspruch 4, wobei der ECU-Sicherheitsschlüsselwert auf einem Versorgungsserver berechnet wird.
Verfahren nach Anspruch 1, wobei das Senden des ECU-Kennwertes und der Aufforderung an die sichere Datenbank und das Senden des ECU-Kennwertes und der Aufforderung von dem Wartungswerkzeug an die sichere Datenbank das Verwenden einer Kommunikationsverbindung ausgewählt aus der Gruppe, die aus Short Messages, Internet, Webseitenzugang, SMS-Textnachrichten, Smartphone, E-Mail, Spracherkennungssystem und Telefonverbindungen besteht, beinhaltet.
Verfahren nach Anspruch 1, wobei das Erzeugen einer Aufforderung in der ECU das Berechnen eines Zufalls- oder Pseudozufalls-Bit-Werts beinhaltet.
Verfahren nach Anspruch 1, wobei das Erzeugen einer Aufforderung in der ECU das Erzeugen einer unterschiedlichen Aufforderung bei jeder erfolgenden Anfrage nach dem ECU-Kennwert beinhaltet.
Ein System zum Zugangsgewähren zu einem Controller, wobei das System umfasst: – Mittel zum Speichern eines Controller-Kennwerts, der den Controller in einem Speicher auf dem Controller identifiziert; – Mittel zum Speichern des Controller-Kennwerts und eines Controller-Sicherheitsschlüsselwerts, der zu dem Controller-Kennwert gehört, in einer sicheren Remote-Datenbank; – Mittel zum Anfordern des Controller-Kennwerts und einer Aufforderung von dem Controller mit einem Wartungswerkzeug; – Mittel zum Erzeugen einer Aufforderung in dem Controller als Antwort auf die Anfrage; – Mittel zum Senden des Controller-Kennwerts und der Aufforderung von dem Controller an das Wartungswerkzeug; – Mittel zum Senden des Controller-Kennwerts und der Aufforderung von dem Wartungswerkzeug an die sichere Datenbank; – Mittel zum Identifizieren des Controller-Sicherheitsschlüsselwertes, der zu dem Controller-Kennwert korrespondiert; – Mittel zum Erzeugen einer Nachricht in der Datenbank basierend auf dem Controller-Sicherheitsschlüsselwert, der eine Antwort auf die Aufforderung enthält; – Mittel zum Senden der Nachricht von der Datenbank an das Wartungswerkzeug; – Mittel zum Senden der Nachricht von dem Wartungswerkzeug an den Controller; und – Mittel zum Zugangsgewähren zu dem Controller, falls die Antwort auf die Aufforderung von dem Controller akzeptiert wird.